“You warrant to ISRG and the public-at-large, and You agree, that You will immediately inspect the
contents of Your Certificate (“Initial Inspection”), and to immediately request revocation if you
become aware of any inaccuracies, errors, defects, or other problems (collectively, “Certificate
Problems”) with Your Certificate. Your ACME Client Software may perform this task for You. You
agree that You will have accepted Your Certificate when You first use Your Certificate or the
corresponding Private Key after obtaining Your Certificate, or if You fail to request revocation of
Your Certificate immediately following Initial Inspection.”
What is considered as “Initial Inspection”? What checks should I perform?
Additionally, I noticed this “Your ACME Client Software may perform this task for You”, I’m using acme4j Java client, do you know if this client performs this task for me? @shred?
acme4j just downloads the certificate from the Let’s Encrypt server, but does not perform any plausibility checks on it.
I guess an initial inspection would be to check that the certificate has actually been signed by Let’s Encrypt. You could also check that it only contains those domains that were ordered, and that it has a plausible valid from and valid until date.
(BTW, acme4j offers methods to revoke your certificate if that inspection should fail. )
acme4j doesn’t offer a way for this. It could verify that your certificate was signed by the intermediate certificate that was sent by Let’s Encrypt along with your certificate. However, an attacker would certainly also change the intermediate certificate, so it wouldn’t help much.
What you can do is to download the intermediate certificate from the Let’s Encrypt website. You can then load this certificate as X509Certificate instance. After that, invoke verify() on the X509Certificate you got from acme4j. Something like this (untested):
X509Certificate intermediateCert = // intermedate cert from the LE website
X509Certificate yourCert = cert.getCertificate();
yourCert.verify(intermediateCert.getPublicKey());
It looks like this seems to be a copy paste of an agreement from an paid CA. (maybe its a standarized agreement from the CAB forum that all CAs must use?)
Because it wouldn’t hurt if you did not do this initial inspection, and a broken certificate would of course not load and/or not work, and if the certificate would contain other fatal errors, Lets Encrypt would revoke it (like if google.com somehow accidentially made it into the SubjectAltNames list)
Also such a immidiate revocation (as compared to “accepting” the certificate) does not have any bearing on the rate limits either, so you don’t gain anything of a “immidiate revocation” as compared to revoking the certificate after you notice you get bad certificates and your webserver software fails to load.
For paid CAs however, it is usually a timeframe where you have to immidiately request revocation if the certificate contains an error, to have the right to a new certificate (for free) due to an error. And if you do not do it, you have considered “accepted” the certificate and refunds/replacements are no longer possible.
Can I be sure that the intermediate certificate will be under the same url and will always be available?
If not, it sounds a little problematic to make it automatic (with no maintenance required).
There is a way to verify it against well known trusted certificate (like browsers do)? this will avoid downloading the intermediate certificate by my self.
do you write your own client? If yes, you can extract the intermediate certificate, it's sent with your new certificate. Then check it - with OpenSsl or your programming language.
If you don't write an own client, there may be an OpenSsl - option to check the certificate.
Hi @JuergenAuer
I am using the acme4j Java client. I believe that I can extract the intermediate certificate that sent with my new certificate, but as shred wrote it less secured:
The maintenance problem is the main reason why I try to avoid a verification in acme4j. From experience, old and obsoleted versions of libraries stick around for much too long.
What you could do is download the ISRG Root X1 certificate and embed it in your program. Then you can validate your certificate and the certificate chain up to the root certificate, and check that the root certificates are identical. The root certificate is valid until June 2035, so this solution should do for a while.
But I agree to @sebastiannielsen that this seems to be a rather formal legal request. I wonder if any ACME client actually verifies the downloaded certificate like that.
Let’s Encrypt currently primarily uses DST Root CA X3, though. Validating against ISRG Root X1 might be trickier, depending on how your software works.
)