In Certify we pass the list of all the identifiers we need as part of our request for a new certificate, we don’t however check the final certificate to see if it has all the requested names when we receive it. Recently we’ve found cert renewals haven’t always contained all of the requested SAN names. Is anyone else seeing similar behaviour?
I’m trying to determine if the bug is with Certify (I can’t see any reason in our code) or if it’s actually with the LE API results.
DNS names are taken from the submitted CSR as-is, and then checked against valid authorizations. There’s no code path that removes names from a CSR. If there’s no valid authorization for any name in the CSR, or if there’s some other issue with a name or the CSR in general, the entire request fails.
You can find the relevant code in the CA software here.
I’m not familiar with Certify, but a quick search shows that you’re maintaining a vault where fields like the authorization status and expiration dates are stored. Any chance the code that produces CSRs looks at these fields and drops names when it encounters non-valid authorizations? Do you by any chance have a CSR that produced such a certificate?
Thanks, that does provide good food for thought, I’m sure the bug must be on our side rather than LE otherwise others would have seen it with different clients but the cause just isn’t obvious currently.
I can second @pfg’s (excellent as usual! thank you!) answer that Boulder/Let’s Encrypt wouldn’t remove domains from the CSR. It turns out that (at least with the current draft of ACME) that all ACME CA’s are supposed to error if they can’t create a certificate with all of the requested domains. See draft-07, section 7.4:
The server MUST return an error if it cannot fulfill the request as specified, and MUST NOT issue a certificate with contents other than those requested.
@webprofusion Can you share some information I can use to identify the requests in question on our backend? If you know of a specific issuance that didn’t have all of the domains you intended it would be helpful to know approximately when you created it (in UTC) and what some of the domain names that did appear in the certificate were. If I can find the requests I can decode the corresponding CSR and we can see what the client sent vs what’s in the cert
Thanks, yes indeed it led me down the right path, I found the corresponding CSR and sure enough it was only requesting one domain (not the 5 others it should have included). I’m currently pursuing my time-honoured ‘if in doubt, rewrite the whole thing’ approach to problem solving as I don’t now have confidence in the part of our code that was ensuring authorizations were valid. This could potentially be surfacing because the authorizations are starting out valid, whereas we used to assume all new authorizations were generally pending to begin with.