Let’s Encrypt, a non-profit organization that helps people obtain free SSL/TLS certificates for websites, plans to revoke a non-trivial number of its certs on Friday because they were improperly issued.
In a post to the Let’s Encrypt discussion community forum, site reliability engineer Jillian Tessa explained that on Tuesday, a third party reported “two irregularities” in the code implementing the “TLS Using ALPN” validation method (BRs 184.108.40.206.20, RFC 8737) in Boulder, its Automatic Certificate Management Environment (ACME) software.
“All active certificates that were issued and validated with the TLS-ALPN-01 challenge before 0048 UTC on 26 January 2022 when our fix was deployed are considered mis-issued,” explained Tessa. “In compliance with the Let’s Encrypt CP [Certificate Policy], we have 5-days to revoke and will begin to revoke certificates at 1600 UTC on 28 January 2022.”
Let’s Encrypt estimates that less than one per cent of active certificates are affected; this is still a large number – about two million, according to a spokesperson – given that there are currently about 221 million active Let’s Encrypt-issued certificates.
Affected certificate holders will be notified of the revocation by email, at which point certificate renewal will be necessary.
This is not the remediation of an exploit. “The update to the TLS-ALPN-01 challenge type was made to be in compliance with the Baseline Requirements, which requires use of TLS 1.2 or higher,” a spokesperson for Let’s Encrypt told The Register in an email.
When you get a certificate from Let’s Encrypt, the organization’s servers attempt to validate that you have control over the relevant resources by presenting a challenge, per the ACME standard. This challenge may be conducted using HTTP, DNS, or TLS, depending upon what works or doesn’t work with the client setup. It’s similar in concept to sending an email verification link that must be clicked to complete the setup of an online account.
The TLS-ALPN-01 challenge is available for those unable or unwilling to use port 80 for an HTTP-01 challenge. According to Let’s Encrypt, “It is best suited to authors of TLS-terminating reverse proxies that want to perform host-based validation like HTTP-01, but want to do it entirely at the TLS layer in order to separate concerns.”
Let’s Encrypt developer Aaron Gable said in a separate post that two changes were made to the organization’s verification code affecting client applications that specifically use TLS-ALPN-01. First, the software now enforces network negotiation using TLS 1.2 or higher. Previously the code allowed connections over TLS 1.1, which is now considered to be insecure.
Second, the software no longer supports the legacy OID (Object Identifier) 220.127.116.11.18.104.22.168.30.1, which served to identify the “acmeIdentifier” extension in early versions of RFC 8737. The Let’s Encrypt software now only accepts the standardized OID 22.214.171.124.126.96.36.199.31.
Certificate verification attempts using TLS 1.1 or the discontinued OID will fail under the revised software; those certificates verified via TLS-ALPN-01 under the old code fail to comply with Let’s Encrypt policy and thus need to be reissued. ®