Certificate renewal behavior when some domains can't validate?


General question here: What happens when my http (apache) based renewal goes to deploy a certificate and can’t validate one or more of the domains? Will it still renew the certificate for the domains that validate? Or will the entire renewal fail?

I have a certificate set up for my primary domain as well as a handful of subdomains and at times, we may choose to deactivate one of the subdomains at times. It’s fine if the certificate renewal then excludes the deactivated domain but I want to make sure that it still works for the active domains.



If it’s using certbot:
The renewal will fail. (and it might throw a error message & let cron mail it)

Thank you


Yes I am using certbot - but the renewal is handled by systemd and not sure if there would be any alert email like I’d get if it were cron.


If those “dynamic” subdomains are all part of the same base domain(s), you might want to opt to using a wildcard certificate. You’d need to get DNS validation to work, which requires a authorative DNS server with an API, one way or another, to automatically update (multiple) TXT records. So it might not work for your situation. But a wildcard certificate would be more logical (to me) when dealing with “dynamic” subdomains.


Yeah I’ve shied away from DNS validation because the apache plugin is so darned easy.

I just found this in the cerbot docs:

     When performing domain validation, do not consider it
     a failure if authorizations can not be obtained for a
     strict subset of the requested domains. This may be
     useful for allowing renewals for multiple domains to
     succeed even if some domains no longer point at this

Unless I am misunderstanding, this sounds like what I want.


Yes and no. Permanently removing names from certificates has to be treated with caution.

What if, in the middle of a certificate renewal, you have a momentary outage that causes validation to fail for 90% of your subdomains?

Your sites would break until you manually issued new certificates.

--allow-subset-of-names isn’t safe to use in totally automated renewals.


I suppose there are pros and cons to any approach here - but I feel the likelihood of a power outage during the 15 or so seconds of a certificate renewal which happens 3 times per year is something I’d feel comfortable rolling the dice on. That puts any network outage at approx 1/700000 chance of happening during a certificate renewal.

All the same, I will take your word of caution under advisement and hopefully my cavalier attitude will not bring me to the land of broken SSL.


You could also have an outage in some other infrastructure that Let’s Encrypt relies on to validate your domain, like DNS servers. So I generally consider it somewhat risky.

The key thing to remember is that it doesn’t have an “aspirational domain set” that it tries to cover, so coverage for a particular name would be removed permanently if validation for that domain ever failed during a renewal while validation for any other domain succeeded. So if you do decide to use --allow-subset-of-names, you might want to periodically run certbot certificates to make sure that your certificate coverage hasn’t decreased in an unexpected way.


That makes sense Seth - Do you think that implementing an “aspirational domain" would be a worthwhile feature request? The ability to designate a set of domains as inconsequential, while keeping others as required would be ideal. For that matter, it’d be nice if those domains that dropped off could be kept in the configuration so subsequent attempts might re-activate them.

The underlying issue being that some older browsers don’t support SNI and the ability to issue multi-domain SSL eliminates the need to allocate multiple dedicated IP4 addresses. I just don’t want my certificate to break if one of the domains gets turned off, expires or fails to validate for any number of other reasons. Do you have any other workaround suggestions?


Yes, I’ve thought about this before but I’m not sure what the best user interface for this would be.

Probably we could show more information in certbot certificates and perhaps we could have an additional_desired_domains option in the renewal configuration for each individual certificate. If present, renewal attempts would try to add those domains but would not fail due to the inability to validate them. Then, we could create an equivalent of --allow-subset-of-names where failed validations add the associated names to additional_desired_domains.

For example, maybe you would be able to run something like certbot renew --remember-failed-renewal-names and then if the existing name example.com worked but the existing name subdomain.example.com failed, the renewed certificate would cover only example.com but the renewal configuration would be updated with additional_desired_domains = subdomain.example.com. Any subsequent use of certbot renew would then try to cover both example.com and subdomain.example.com. If it succeeded with both, subdomain.example.com would be removed from additional_desired_domains.

That’s just a thought.

Not really—you can get greater reliability by putting every name in its own certificate, but that could trigger the Let’s Encrypt rate limits if there are many subdomains of a single domain, and also does mean SNI will become a requirement for visiting any of the hosted sites.


A post was merged into an existing topic: Generación de un certificado de seguridad SSL Let’s Encrypt