How does the Apache module work without downtime during the challenge process?

I’m interested in using Certbot to obtain and automatically renew certificates from LE for Apache. I understand that there’s an option to have it not modify configuration files and only request/download certificates which is what I would prefer.

However, from reading various documents and the Apache module code I’m trying to figure out how it actually achieves this process without modifying config files. From what I can see, the module uses the TLS SNI challenge, and to facilitate this makes temporary changes to the vhost conf files.

Does this mean that a website being served by a valid SSL certificate on port 443 is temporarily offlined by this module serving a temporary certificate to facilitate the challenge? This would be the case for the renewal process for example?

The Apache certbot plugin always modifies your configuration files. What you have a choice over is whether it only does so temporarily in order to complete validation or whether you also want to it to permanently set up SSL for you as well.

If you don’t want to certbot to touch your Apache configuration in any what whatsoever, use the Webroot certbot plugin, not the Apache plugin.

The tls-sni-01 verification process as used by the Apache plugin will not affect your working SSL virtual host. Certbot configures a virtual host with a random name that serves a special invalid certificate given to it by Let’s Encrypt, and then Let’s Encrypt connects to the IP address associated with your hostname, requests this special virtual host via Server Name Indication, and then confirms the certificate matches what it expects. All while your regular SSL virtual host continues to work normally.

2 Likes

Thanks for the quick response and detailed explanation. That seems to be the missing part of the jigsaw, but now I wonder, how does creating a random virtual host and serving a certificate to the CA validate ownership for the original domain name in question?

Edit: I think I twigged. The domain is resolved to the IP of the server (DNS), the CA connects to that IP and requests the random domain and so said domain must be under control?

1 Like

You got it. The validation server(s) resolve and connect to your server like normal, and only when they are speaking to it do they ask for the random domain.

Let’s Encrypt needs to know that you are not some random user with shell access and are actually supposed to be administering the domain in question. Being able to configure a virtual host to their specifications on the fly is a pretty good indicator! It is perhaps the most secure* validation method.

(*By this I don’t mean that you should prefer it, the additional risks of other validation methods are there whether you use them or not.)

Thank you so much for the info. I’m torn between the Apache module and webroot. I like the simplicity of a file being written to a predictable path for verification vs. on-the-fly config changes and reloads. I appreciate at least one reload is required to use any newly written certificates using either method. Is there a good reason to favour one method over the other?

Not really. There are benefits and drawbacks to each method, which is why they’re all offered in parallel.

The most common issue with http-01 is that rewrite rules from various applications and password protection tend to get in its way. So if you’re deploying Let’s Encrypt across several varying websites, it’s a bit easier to use tls-sni-01 even when configuring SSL manually, since it requires no cooperation from the existing virtual host.

But if that isn’t an issue for you, you may indeed prefer the simplicity of http-01.

I don’t really have a preference regarding the challenge type, though I do end up using the HTTP (webroot) challenge more often.

One thing that’s worth mentioning is that apache (and most other popular web servers) perform configuration reloads gracefully (without downtime). What the web servers does is basically spawn new child processes and instruct the old ones to shutdown after they’re done handling their active requests. At no point does apache stop accepting new requests.

Certbot makes use of this, so there’s no downtime involved with either option.

3 Likes

You could say that http-01 is safer in the sense of being less intrusive (you don’t need Certbot itself to change anything about your web server configuration, or even reload Apache at all). I would agree that it doesn’t provide quite as strong a proof of control of the site.

2 Likes

Great point raised about redirects and things that could get in the way of serving the required file for webroot validation.

Am I correct that a 301 from HTTP to HTTPS is acceptable? What about a different subdomain (i.e. forcing www)?

I’m leaning towards the Apache module :blush:

That is fine for the http-01 challenge. It can be either HTTP or HTTPS and can be any domain name. It doesn’t have to be a subdomain of the requested name.

I think I was advocating that it should also allow other protocol schemas like gopher://, but apparently the CA implementers didn’t want that complexity. :slight_smile:

There seems to be some debate in the industry as to whether redirects should be followed (https://cabforum.org/pipermail/public/2017-July/011682.html). Comodo follow them but it’s unsupported and due to be phased out. Seems to me if you have the ability to implement a redirect that ultimately points to the required file then you control the server.

I’m assuming the Apache module doesn’t like UTF-8 encoded conf files (https://github.com/h5bp/server-configs-apache/blob/master/dist/.htaccess) as I’m getting a syntax error parsing it with certbot --apache.

I think @jsha’s interpretation about redirects is quite sensible (you can also see it in that thread). Maybe there will be further discussion to clarify this if anyone suggests that it’s ambiguous enough to be of concern.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.