SAN renewal and invalid domain

Hi all,
I would like some clarifications on how the HTTP-based renewal of a certificate with multiple SAN is expected to work when some of the domain in the list are not available and/or not managed by my server anymore.

Premise: I read the thread here, but I see mixed (and unexptected) results.

Example: I obtain a certificate for www2.example.com, www3.example.com and www4.example.com via the following command: certbot certonly --webroot -w /var/www/html -d www2.example.com -d www3.example.com -d www4.example.com
When I obtained the certificate via HTTP challenge, all hostname where clearly managed by my server. After that, www3.example.com is deleted and www4.example.com is changed to point an external server that I do not control.

Now the strange part:

  • if I force a renewal re-executing certbot certonly --webroot -w /var/www/html -d www2.example.com -d www3.example.com -d www4.example.com, it seems to work without issues even if www3.example.com and www4.example.com can’t really be renewed via the HTTP challenge;
  • if I use add “–dry-run” to the command above, verification fails stating “Challenge failed for domain …”, as expected (and as suggested in the linked thread).

So, my questions:

  • why I see such different behavior?
  • are the hostnames/domains really checked via HTTP challenge during a renewal? If so, why a forced renewal succeeds?

Thanks.

Hi @shodanshok,

This is probably due to cached authorizations. When you successfully issue a certificate using Let’s Encrypt, your ACME account on the Let’s Encrypt service is marked as authorized for the subject domains, and those authorizations can be reused for a period of time without revalidating. That can allow you to skip validation checks if you request a related certificate soon after requesting the original certificate.

1 Like

Hi @schoen, thank you for the quick and detailed reply. This means that “–dry-run” fails because it explicitly bypassed the cached authorization, showing the outcome of a “true” renew, right?

Thanks.

Yes, using --dry-run is a good way to see what the real future renew behavior will be.

@schoen thank you so much for the direct confirmation.

1 Like

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