Ideas about how to automate initial configuration of certificates

[jfall]

I understand the basics of let’s encrypt and have used it to manually generate some certs using webroot validation on my Centos/Nginx servers. This is fine and dandy for getting working SSL certs and auto-renewal looks like it would work fairly easily.

What I want to do is go a step beyond that and automate the initial configuration of the certificates for every domain on the web server. We deploy our production web servers using ansible and try to automate as much of the process as possible. Initially generating the certs on the command line manually and letting a renewal cron keep them in check is fine and dandy, until we have to redploy the server using ansible. I could technically just copy the letsencrypt folder after rebuilding the server but I would rather have it setup automatically via ansible.

I guess really the hitch here is having to specify the webroot path manually. It’s not always the same format for each site. Is there any way that I can have certbot detect the web root using the nginx configuration files?

If not I’m sure I could come up with some other way to map domains to web roots in a single file deployed by ansible then somehow have cergbot generate certs for all of the domains outlined in that file.

Perhaps tools or methods exist all ready for accomplishing this?

[schoen]

Hi @jfall,

Do you have to use --webroot as opposed to --nginx? As of Certbot 0.21, --nginx will complete HTTP-01 authentication automatically (by editing your nginx configuration files) without your having to specify a webroot directory. I believe it effectively makes it own temporary webroot and tells nginx how to use that specifically for the /.well-known/acme-challenge path.

@jfall

If not I’m sure I could come up with some other way to map domains to web roots in a single file deployed by ansible then somehow have cergbot generate certs for all of the domains outlined in that file.

If you do that, there is a --webroot-map option in Certbot that may be useful to you.

@jfall

Initially generating the certs on the command line manually and letting a renewal cron keep them in check is fine and dandy, until we have to redploy the server using ansible. I could technically just copy the letsencrypt folder after rebuilding the server but I would rather have it setup automatically via ansible.

If you do this very frequently, like several times per week, you're fairly likely to run into a Let's Encrypt issuance rate limit.

[jvanasco]

Instead of using the “webroot”, you could just use the “standalone” authenticator – either running on port80 on startup, or on a higher port and proxying all the /.well-known/acme-challenge location from nginx (port 80) to the lentencrypt app. I do the latter approach with nginx.

[schoen]

@jvanasco

Instead of using the “webroot”, you could just use the “standalone” authenticator – either running on port80 on startup, or on a higher port and proxying all the /.well-known/acme-challenge location from nginx (port 80) to the lentencrypt app. I do the latter approach with nginx.

That also seems like a very practical suggestion, especially if the server isn't actively serving anything yet at that moment!

[jvanasco]

FYI, my nginx config has this block as a standalone file, which is included into each server.

location  /.well-known/acme-challenge  {
	if (-f /etc/nginx/_flags/certbot-8181) {
		proxy_set_header  X-Real-IP  $remote_addr;
		proxy_set_header  X-Forwarded-For  $proxy_add_x_forwarded_for;
		proxy_set_header  Host  $host;
		proxy_pass  http://127.0.0.1:8181;
		break;
	}
	rewrite ^.*$ @acme_503 last;
}
location = @acme_503 {
	internal;
	return 503;
}

and my certbot command is:

    ./certbot-auto renew --standalone --preferred-challenge=http-01 --http-01-port=8181  --force-renewal --pre-hook "touch /etc/nginx/_flags/certbot-8181" --post-hook "rm /etc/nginx/_flags/certbot-8181"

/etc/nginx/_flags/certbot-8181 is used as a filesystem semaphore. if it exists, traffic is proxied up into the certbot port; if it doesn’t exist, we redirect to a 503 error. this is an old nginx performance trick i learned a long time ago for toggling downtime or other config situations - in practice even under high load, most of these FS checks should happen within memory by the os, and never touch the disk.

you still need to restart nginx if there is a new cert, but we do that daily as part of app deployments.