Issuance with non-common / application servers

There are two ways go get certificates when using a non-common server, standalone and manual mode.

For a first time issuance it seems to be easiest to use the standalone mode, since there isn't a server running on port 443 yet. However, that will change once HTTPS is setup and live, because you don't want a service interruption every 60 days for renewal (assuming that the revalidation time frame will be changed to the same as reissuance, so it's always the same process instead of two different ones).

It's a non-issue adding a route serving the ACME challenge once HTTPS is setup, but how can the manual mode be automated to prevent downtimes and / or expires, because it wasn't automated? Does the challenge change every time?

I'd like to make HTTPS setups very easy using our application server, same applies to node apps. How can we make simple components that just have to be added to the router of choice to make automation possible where (almost) everything is configured through code instead of easy to parse and change config files?

1 Like

It depends on what validation method the manual mode is using. Currently I think it’s defaulting to SimpleHTTP, where you add a specified file to the existing web server (somewhat akin to validation processes used by some other DV CAs). That particular method shouldn’t cause downtime.

The challenge will be different every time – it’s randomly generated.

If you’re familiar with Python programming, you can customize the code in our open source client application to produce a higher level of integration with whatever kind of applications you’re working with, or to produce a somewhat different UI flow. You can make those changes privately, or, if you think they’d be generally useful, you’re welcome to contribute them back to our project.

1 Like

i am personally looking forward to the simplefs plugin method Jakub wrote up see Allow letsencrypt client to pass the web root path on cmd for creation of SimplyHTTP/ACME challenge file · Issue #742 · certbot/certbot · GitHub and pull request at SimpleFS plugin (fixes #742) by kuba · Pull Request #757 · certbot/certbot · GitHub and tested it out on my non-common Centmin Mod Nginx web stack at

basically if you can already automate the https nginx or apache vhost creation for a domain, you only need to pass the nginx or apache web root for the domain in simplefs mode via --simplefs-root flag for SimpleHTTP file challenge to be automated

./venv/bin/letsencrypt -a simplefs --simplefs-root /home/nginx/domains/ --text --agree-eula -d auth

looking forward when that pull request gets merged :smiley:

You need to add the right content type header, too, otherwise that method is probably fine for already running hosts.

1 Like

yup you do, my Centmin Mod LEMP stack's auto nginx vhost generator does the http and https vhost generation automatically + right application/jose+json content-type header for the well known uri verification file automatically so passing the web root to letsencrypt client is all I need :smile:

curl -Ik
HTTP/1.1 200 OK
Date: Sat, 29 Aug 2015 07:51:27 GMT
Content-Type: application/jose+json
Content-Length: 911
Last-Modified: Sat, 29 Aug 2015 07:51:14 GMT
Connection: keep-alive
ETag: "55e16472-38f"
Server: nginx centminmod
Alternate-Protocol: 443:npn-spdy/3
Accept-Ranges: bytes

But this is still nginx, not some application server configured directly though code. Application servers may not even have a doc root.

yeah… hopefully other plugins are made for other usage cases :slight_smile:

That’s exactly my question. Any idea how a process could look like for such environments?

If you can configure the certificates that the other servers present for various SNI hosts, you should be able to use DVSNI validation in this case without having a DocumentRoot.

I wish there was a simpler solution for cases like loadbalancers that handle HTTPS encryption/decryption.

It looks like I’d have to script out something to run on each of the servers behind the loadbalancer which would be able to handle certificate renewal, then be able to update the certificate on the loadbalancer remotely. Seems like a PITA.

With a longer renewal period than 60 days (1 year), a manual process is feasible, but having to renew it every 60 days manually adds to the PITA factor.

If the load balancer adds LE support, it can respond to the challenges without forwarding to the backends.

1 Like

That’s a pretty big if, especially with cloud provided load balancers like Amazon EC2.

Wait, then you can just use the SimpleHTTP challenge?