A couple weeks ago we created a cert on one of our alias ip’s in Pfsense. Since then we have added in a frontend load balancer and renewed the cert.
We’re seeing that the cert is registered to the correct IP 147.135.143.151 and the site works fine.
But Lets Encrypt/Acme is showing that the communication is still with the alias ip. Is There away to force this communication to the load balancer or is it something funny with Lets Encrypt DNS.
Hi @blair,
What’s your domain name?
Where do you see the incorrect IP address displayed and in what circumstances?
So domain is media.viservers.ch
/tmp/acme/media.viservers.ch/acme_issuecert.log
Could you except part of that log showing the IP address? Are you for example trying to renew the certificate and seeing the renewal fail with an error message that refers to the old address?
Thanks! So, I don’t think this is a problem.
When you get a certificate from Let’s Encrypt, your client application automatically creates an account with the Let’s Encrypt CA. That account is then associated with requests that you make for various certificates, and also with challenges and authorizations, in our CA’s jargon. The challenges are occasions where the CA has asked you to do something to prove that you control a particular domain name, and the authorizations are occasions where the CA has agreed that you do, in fact, control that domain name (because you successfully completed a challenge).
The authorizations are associated with your account and I believe that they remain active for a week (but the exact amount of time has changed in the past). This allows you to issue a new certificate, using the same account, that covers the same domain name. without revalidating immediately. (This is particularly useful for large sites that more frequently want to add and remove sites from their certificates; because of caches authorizations, they can often simply ask for a new certificate with a slightly different combination of names on it without doing any new proof of control.) Of course, the authorizations eventually do expire and have to be revalidated.
What I believe you’re seeing here is a detailed log of a message from the certificate authority advising you that you still have an active cached authorization with respect to this name (and therefore aren’t required to revalidate your control over it in order to issue additional certificates covering it, for the time being). The reference to the old IP address in this log message is just for debugging purposes, to show that it was “used” in obtaining the authorization, and does not mean that Let’s Encrypt is still connecting to that address or plans to connect to that address again in the future. This interpretation is plausible because you’ve obtained new certificates for this name less than a week after obtaining previous certificates.
Every correctly-operating ACME client application understands this mechanism and understands whether it does or doesn’t have to revalidate particular names at particular moments in time. In this case, I think your client application simply logged a very large amount of detailed technical information, exposing a detail that’s easy to misinterpret.
2 Likes
Thank you for the response I’ll pass this information along to the team
Is there a way to get some more documentation on this. As we are worried in weeks time the cert will break.
Which part would you like to know more about?
Your most recent certificate is valid until May 17. The certificate doesn't have to be reissued when the authorization expires; currently, Let's Encrypt certificates last much longer than authorizations do. The certificate that you're currently using on the site is not the most recent one, but it's valid until May 14. So there's no immediate risk to your site's certificate validity.
If you want to try the validation from scratch to see if it will work in your current configuration, the tricky way is to invalidate the authorization (there are a couple of scripts to do this which you might find if you search this forum for "invalidate authz", even though the reason people most often use those scripts is different from yours). The easy way would be to register a new account and try to reissue your certificate using that new account, since the old authorization won't be associated with the new account.
I don't know offhand how to do this with your client, but we can figure that out if it isn't clear to you and isn't documented anywhere.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.