Let's Encrypt Revokes 2M Certificates Due to TLS-ALPN-01 Implementation Issues

Let's Encrypt, a non-commercial, community-controlled CA that provides certificates free of charge to anyone, has announced early revocation of about two million TLS certificates, which is about 1% of all active certificates of this CA. The revocation of certificates was initiated due to a non-compliance with the requirements of the specification in the code used in Let's Encrypt with the implementation of the TLS-ALPN-01 extension (RFC 7301, Application-Layer Protocol Negotiation). The discrepancy was due to the absence of some of the checks performed in the connection negotiation process based on the ALPN TLS extension used in HTTP/2. Detailed information about the incident will be published after the completion of the revocation of problematic certificates.

On January 26 at 03:48 (MSK), the problem was fixed, but all certificates that were issued using the TLS-ALPN-01 method for verification were decided to be invalidated. Certificate revocation will begin on January 28 at 19:00 (MSK). Before this time, users using the TLS-ALPN-01 verification method are advised to have time to renew their certificates, otherwise they will be invalidated ahead of time.

Corresponding notifications about the need to renew certificates were sent by email. Users using the Certbot and dehydrated tools to obtain a certificate were not affected by the issue when using the default settings. The TLS-ALPN-01 method is supported in the Caddy, Traefik, apache mod_md and autocert packages. You can check the correctness of your certificates by searching for identifiers, serial numbers or domains in the list of problematic certificates.

Since the changes affect TLS-ALPN-01 verification behavior, you may need to update the ACME client or change settings (Caddy, bitnami/bn-cert, autocert, apache mod_md, Traefik) to continue working. The changes are reduced to the use of TLS versions not lower than 1.2 (clients will no longer be able to use TLS 1.1) and the deprecation of support for OID 1.3.6.1.5.5.7.1.30.1, which identifies the obsolete acmeIdentifier extension, supported only in early drafts of the RFC 8737 specification (when generating a certificate, now only OID 1.3.6.1.5.5.7.1.31 is allowed, and clients using OID 1.3.6.1.5.5.7.1.30.1 will not be able to obtain a certificate).

Source: opennet.ru

Add a comment