sozu-proxy / sozu-acme Goto Github PK

that way we could use the staging environment if needed. That should be an optional command line flag

otherwise sozu will keep the configuration

Since we create a new application with its own frontend and backend, this could just be a random application id

Hello,
I tried to compile sozy-acme in a dedicated container. I install same package from Dockerfile sozu project. I re-produced it manually

Based on alpine latest sha256:ca1c944a4f8486a153024d9965aafbe24f5723c1d5c02f4964c045a16d19dc54 4d90542f0623

I hit this bug in rust-openssl sfackler/rust-openssl#987 with openssl version not compatible.
The root cause is acme-client in rush, there is a patch onur/acme-client#44 but not merged at this moment.
If you cherry pick it, it works with this change in Cargo.toml :

--acme-client = "^0.5"
++acme-client = { version = "^0.5" , path = "../acme-client" }

I don't know how you want to solve this for the long term...
Regards

Since this repo is really new.

Will DNS-01 method supported ? Even if the certificate is really long to obtain. For example on OVH DNS, you need 30 sec sleep before saying to let's Hey ok, you can try validate against the DNS TXT record. I think DNS is more suitable for large deployment.
The problem is that you need to put a pre-hook and post-hook in order to do that, which is not really a great design...

instead use a channel to notify the main thread that the webserver is actually launched

What do we do if the user provides the key instead of letting the tool generate it? This can happen if we replace a certificate