Standalone works but how?

So we are in AWS cloudfront, so we redirect port 80/443 /.well-known/* to a particular server.

What is unusual is that an admin can run standalone renewal on a different server that isn't the target of the /.well-known and it appears to work. This server is related to the site but should not server /.well-known/*

There is no sharing of file systems between the server that now serves /.well and the standalone renewer. I verified that /.well-known requests go to the correct server, the one that has the redirect.

The standalone renewer is likely always been the way the system got the certs originally and the redirect might have been more recent.

The only way I think that this works is if the verification ignores DNS and tries the original IP that requested for standalone request not the one given by DNS currently just can't see a path to the renewal server unless this is true.

This sounds like a case of authorization caching. Let's Encrypt will reuse authorizations that were successful for the same domain name, on the same ACME account. for a period of time.

If the administrator on the other server is using Certbot, they can use --dry-run to ensure that any cached authorizations are deactivated before trying to renew the certificate.


Is that "other system" using the same ACME account [as the "authorized system"]?


No in fact the server (redirector) has not tried to renew it at all, it doesn't have the cert in its renewal directory.

If it does any auth caching, that explains it. We are definitely going to unscrew this situation as soon as possible. It was just a mystery that questioned my understanding of how things work.

1 Like

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