As part of an automated process for renewing LetsEncrypt certs , we run a post renewal command which hot reloads the new certs. The hot reload is only successful if both the Issuer and Subject details are the same for the new and old certs.
This worked unattended without issues when the R3 intermediates were used during cert issuance , but since the recent changes, the random use of R10 and R11 intermediate CA can cause the hot reload process to fail due to issuer mismatch, despite the certs being perfectly valid.
Eg -
Issuer: C = US, O = Let's Encrypt, CN = R10
vs
Issuer: C = US, O = Let's Encrypt, CN = R11
I expect the answer is no, but just checking on the offchance - Is there a way to request usage of a specific CA at cert renewal time?
No. And we may have to switch issuers without warning in event of an incident.
A big part of why we are using four issuers is to help ensure that the ecosystem tolerates them switching. I would suggest you update your check to allow for different issuers.
OK no problem, understood - thanks for the prompt response . Unfortunately the hot reload mechanism is a feature of software we don't maintain. I'll investigate workarounds on this side .
The intermediate certificate (issuer of the end leaf certificate) is provided by the ACME server at issuance. Usually, if there is a problem with issuer/intermediate mismatch, this means the software design is flawed.
I don't know what "hot reloads" means exactly, but sounds like it's not designed properly.
The intermediate certificate and end leaf certificate are renewed successfully and are present on disk - this is not a LetsEncrypt problem. The problem occurs when we run a post renewal task which triggers a certificate reload in an application which is secured with the LetsEncrypt cert. The application runs a validation check which compares the Issuer & Subject of the current live certificate with the new certificate and throws an error if there is a mismatch. A manual service restart bypasses that validation check, but I was hoping for an alternative.
Thanks! Yes the assumption is bad, it's not an in inhouse application , so options to change this behaviour are limited. Not a problem though, will work around somehow.
Until that takes effect...
You could try switching to another CA - that has less [Intermediate cert] variance.
[only a temporary fix; As all CAs are allowed to change Intermediates as needed]
@Nekit , Complaining to the vendor not an option (application version we are running is EoL ) .
@Osiris, The error is not fatal to the application, it just aborts the SSL cert reload , so left unchecked can result in expired certs. Manual service restart required to apply.
What client are you using? If you are using Certbot, there is a deploy-hook which only runs on successful issue - that can be used to trigger a reload. Several other clients have similar hooks.
FWIW, I like to use Fabric to script post-issuance hooks in Python. Aside from controlling that particular machine, Fabric lets me easily ssh into various other machines to perform updates and reloads.
