Update ca-bundle.crt and remove expired certificates

[barry]

The existing ca-bundle.crt contains expired certificates which in older OpenSSL versions will prevent TLS connections even if there is another certificate chain option that is not expired. This patch syncs the bundle with the latest version from Mozilla, removing the expired certs, adding a few new ones, and keeping the 1024 bit certificates that were added for backwards compatibility in [35919]

It will be nice when we can use the upstream version as-is and update it with every release :)

[SergeyBiryukov]

Previously: [46094] / #45807.

[desrosj]

@SergeyBiryukov I know it is RC, but is there any reason not to consider for 5.5 including as this will prevent the described issue.

Going forward, it would be nice to set this to update with an NPM command.

[barry]

FWIW, we are running this update on WordPress.com already.

[ayeshrajans]

Replying to desrosj:

@SergeyBiryukov I know it is RC, but is there any reason not to consider for 5.5 including as this will prevent the described issue.

Going forward, it would be nice to set this to update with an NPM command.

Wouldn't it be possible to store separate files for the 1024-bit certificates, and Mozilla/curl certificates in src/wp-includes/certificates directory? The final ca-bundle.crt file can then be built with a simple concat of the two files.

This way, we can make updates to CA bundle directly from Curl project (​https://curl.haxx.se/ca/cacert.pem) without having to manually verify each update. As long as the content is verbatim, we know we have the up to date bundles.

As of now, the file sha checksum is not valid, and one would need to individually check each certificate to make sure no bits are changed. This is obviously not to say that the patch from @barry is not to be trusted.

[ayeshrajans]

Attaching a patch with the approach from the comment above.

1.Use verbatim copy of Mozilla certificates

The cacert.pem file is a 1:1 copy of the Curl/Mozilla certificates. Future updates to this bundle can be made by simply downloading the latest cacert.pem and cacert.pem.sha256 files and overwriting existing.

See:

• ​https://curl.haxx.se/ca/cacert.pem
• ​https://curl.haxx.se/ca/cacert.pem.sha256
• ​https://curl.haxx.se/docs/caextract.html

2.New legacy-1024bit.pem file contains the legacy certificates

All legacy certificates in the ca-bundle.crt file so far are moved to a new legacy-1024bit.pem file. We can remove certificates when necessary without having to re-check the upstream 2048/2096 certificates in cacert.pem file.

3.Removed expired certificates

The following 1024 bit certificates are expired and thus removed.

• June 20, 2020 - Equifax Secure Global eBusiness CA
• June 20, 2020 - Equifax Secure eBusiness CA 1

4.Create ca-bundle.crt file by combining cacert.pem and legacy-2014bit.pem files

This is the original file name, so we ensure backwards compatibility.

Current legacy certificates

I checked all current legacy certificates to make sure they are valid and not revoked. All modern browsers will refuse to use the due to its hash algorithm, and them being 1024 bit (not to mention the whole Symantec mess), but OpenSSL 0.9 should still accept them provided a CRL is not objecting and OpenSSL configured to validate against an OCSP server.

• Thawte Server CA: ​https://crt.sh/?q=23E594945195F2414803B4D564D2A3A3F5D88B8C
• Thawte Premium Server CA: ​https://crt.sh/?q=627F8D7827656399D27D7F9044C9FEB3F33EFA9A
• Verisign Class 3 Public Primary Certification Authority: ​https://crt.sh/?q=742C3192E607E424EB4549542BE1BBC53E6174E2
• Verisign Class 3 Public Primary Certification Authority - G2: ​https://crt.sh/?q=85371CA6E550143DCE2803471BDE3A09E8F8770F
• Verisign Class 3 Public Primary Certification Authority: ​https://crt.sh/?q=A1DB6393916F17E4185509400415C70240B0AE6B

The first two legacy certificates expire end of this year, perhaps just in time for WordPress 5.6.

[SergeyBiryukov]

Replying to ayeshrajans:

Wouldn't it be possible to store separate files for the 1024-bit certificates, and Mozilla/curl certificates in src/wp-includes/certificates directory? The final ca-bundle.crt file can then be built with a simple concat of the two files.

This way, we can make updates to CA bundle directly from Curl project (​https://curl.haxx.se/ca/cacert.pem) without having to manually verify each update. As long as the content is verbatim, we know we have the up to date bundles.

This looks great, but I think it's too big a change for 5.5 RC2 and would require more testing.

Let's get 50828.diff​ in for now and 50828-split-file-verbatim.patch​ early in 5.6.

[SergeyBiryukov]

In 48707:

HTTP: Update the Root Certificate bundle.

Keep 1024-bit legacy root certificates re-added in [35919], except for those already expired, for compatibility with older OpenSSL versions.

Props barry, ayeshrajans, desrosj, whyisjake.
See #50828.

[SergeyBiryukov]

In 48708:

HTTP: Update the Root Certificate bundle.

Keep 1024-bit legacy root certificates re-added in [35919], except for those already expired, for compatibility with older OpenSSL versions.

Props barry, ayeshrajans, desrosj, whyisjake.
Reviewed by whyisjake, SergeyBiryukov.
Merges [48707] to the 5.5 branch.
See #50828.

[ayeshrajans]

Thanks for bumping this to 5.6 and committing to 5.5 too, albeit it being RC2.

May I suggest that we remove these certificates from our store?

• America Online Root Certification Authority 1
• America Online Root Certification Authority 2

They were removed from Mozilla/curl store a while ago, and are 2048 bits. These two roots were requested to be removed (​https://bugzilla.mozilla.org/show_bug.cgi?id=1083294) over 6 years ago, which is over the CA/B baseline requirements of maximum three year length. All certificates signed by this root must be technically expired by now.

• EE Certification Centre Root CA

This certificate is already in Mozilla/curl root store, and is a duplicate in our copy.

[ayeshrajans]

Attaching a patch that removes EE Certification Centre Root CA, America Online Root Certification Authority 1, and merica Online Root Certification Authority 2 root certificates (1 duplicate, 2 requested removals)

[ayeshrajans]

Out current ca-cert.pem can be generated by applying this patch to any upstream CA root certificate store.

[SergeyBiryukov]

Didn't get a chance to review the latest patches in time for 5.6 RC, moving to the next release for now.

[hellofromTonya]

The latest patch needs review. It's been punted 2x. Moving it to Future Release as today is 5.8 Beta 1.

[SergeyBiryukov]

In 51883:

HTTP: Remove the DST Root CA X3 certificate expired on September 30, 2021.

The currently recommended certificate chain as presented to Let’s Encrypt ACME clients when new certificates are issued contains an intermediate certificate (ISRG Root X1) that is signed by an old DST Root CA X3 certificate that expires on 2021-09-30. In some cases the OpenSSL 1.0.2 version will regard the certificates issued by the Let’s Encrypt CA as having an expired trust chain.

Most up-to-date CA cert trusted bundles, as provided by operating systems, contain this soon-to-be-expired certificate. The current CA cert bundles also contain an ISRG Root X1 self-signed certificate. This means that clients verifying certificate chains can find the alternative non-expired path to the ISRG Root X1 self-signed certificate in their trust store.

Unfortunately this does not apply to OpenSSL 1.0.2 which always prefers the untrusted chain and if that chain contains a path that leads to an expired trusted root certificate (DST Root CA X3), it will be selected for the certificate verification and the expiration will be reported.

References:

• ​Old Let’s Encrypt Root Certificate Expiration and OpenSSL 1.0.2
• ​DST Root CA X3 Expiration (September 2021)

Follow-up to [25224], [25426], [25569], [27307], [30491], [30765], [34283], [35919], [36570], [46094].

Props bradleyt, fierevere.
Fixes #54207. See #50828.

[whyisjake]

In attachment:50828.2.diff​ I added the mk-ca-bundle.pl script so that we can generate the certs during a build or release.

npm run cert:generate will drop the bundle in the right spot. It feels weird to be running a Perl script with node, better than composer tho?

More details here on the script: ​https://curl.se/docs/mk-ca-bundle.html

[dd32]

Replying to whyisjake:

In attachment:50828.2.diff​ I added the mk-ca-bundle.pl script so that we can generate the certs during a build or release.

Can the file be imported from somewhere directly instead of using perl? Note that it looks like that reverts the changes from https://core.trac.wordpress.org/ticket/34935#comment:10 which is something I no longer recall the details of.. other than that it was needed at the time.

[SergeyBiryukov]

Replying to dd32:

Can the file be imported from somewhere directly instead of using perl?

Yeah, looks like comment:7 and comment:8 would be the preferred direction here.

[desrosj]

In 51948:

HTTP: Remove the DST Root CA X3 certificate expired on September 30, 2021.

The currently recommended certificate chain as presented to Let’s Encrypt ACME clients when new certificates are issued contains an intermediate certificate (ISRG Root X1) that is signed by an old DST Root CA X3 certificate that expires on 2021-09-30. In some cases the OpenSSL 1.0.2 version will regard the certificates issued by the Let’s Encrypt CA as having an expired trust chain.

Most up-to-date CA cert trusted bundles, as provided by operating systems, contain this soon-to-be-expired certificate. The current CA cert bundles also contain an ISRG Root X1 self-signed certificate. This means that clients verifying certificate chains can find the alternative non-expired path to the ISRG Root X1 self-signed certificate in their trust store.

Unfortunately this does not apply to OpenSSL 1.0.2 which always prefers the untrusted chain and if that chain contains a path that leads to an expired trusted root certificate (DST Root CA X3), it will be selected for the certificate verification and the expiration will be reported.

References:

• ​Old Let’s Encrypt Root Certificate Expiration and OpenSSL 1.0.2
• ​DST Root CA X3 Expiration (September 2021)

Follow-up to [25224], [25426], [25569], [27307], [30491], [30765], [34283], [35919], [36570], [46094].

Props bradleyt, fierevere, SergeyBiryukov.
Merges [51883] to the 5.8 branch.
Fixes #54207. See #50828.

[desrosj]

In 52097:

HTTP: Remove the DST Root CA X3 certificate expired on September 30, 2021.

The currently recommended certificate chain as presented to Let’s Encrypt ACME clients when new certificates are issued contains an intermediate certificate (ISRG Root X1) that is signed by an old DST Root CA X3 certificate that expires on 2021-09-30. In some cases the OpenSSL 1.0.2 version will regard the certificates issued by the Let’s Encrypt CA as having an expired trust chain.

Most up-to-date CA cert trusted bundles, as provided by operating systems, contain this soon-to-be-expired certificate. The current CA cert bundles also contain an ISRG Root X1 self-signed certificate. This means that clients verifying certificate chains can find the alternative non-expired path to the ISRG Root X1 self-signed certificate in their trust store.

Unfortunately this does not apply to OpenSSL 1.0.2 which always prefers the untrusted chain and if that chain contains a path that leads to an expired trusted root certificate (DST Root CA X3), it will be selected for the certificate verification and the expiration will be reported.

References:

• ​Old Let’s Encrypt Root Certificate Expiration and OpenSSL 1.0.2
• ​DST Root CA X3 Expiration (September 2021)

Follow-up to [25224], [25426], [25569], [27307], [30491], [30765], [34283], [35919], [36570], [46094].

Props bradleyt, fierevere, SergeyBiryukov, peterwilsoncc.
Merges [51883] to the 5.7 branch.
Fixes #54207. See #50828.

[desrosj]

In 52098:

HTTP: Remove the DST Root CA X3 certificate expired on September 30, 2021.

The currently recommended certificate chain as presented to Let’s Encrypt ACME clients when new certificates are issued contains an intermediate certificate (ISRG Root X1) that is signed by an old DST Root CA X3 certificate that expires on 2021-09-30. In some cases the OpenSSL 1.0.2 version will regard the certificates issued by the Let’s Encrypt CA as having an expired trust chain.

Most up-to-date CA cert trusted bundles, as provided by operating systems, contain this soon-to-be-expired certificate. The current CA cert bundles also contain an ISRG Root X1 self-signed certificate. This means that clients verifying certificate chains can find the alternative non-expired path to the ISRG Root X1 self-signed certificate in their trust store.

Unfortunately this does not apply to OpenSSL 1.0.2 which always prefers the untrusted chain and if that chain contains a path that leads to an expired trusted root certificate (DST Root CA X3), it will be selected for the certificate verification and the expiration will be reported.

References:

• ​Old Let’s Encrypt Root Certificate Expiration and OpenSSL 1.0.2
• ​DST Root CA X3 Expiration (September 2021)

Follow-up to [25224], [25426], [25569], [27307], [30491], [30765], [34283], [35919], [36570], [46094].

Props bradleyt, fierevere, SergeyBiryukov, peterwilsoncc.
Merges [51883] to the 5.6 branch.
Fixes #54207. See #50828.

[desrosj]

In 52099:

HTTP: Remove the DST Root CA X3 certificate expired on September 30, 2021.

The currently recommended certificate chain as presented to Let’s Encrypt ACME clients when new certificates are issued contains an intermediate certificate (ISRG Root X1) that is signed by an old DST Root CA X3 certificate that expires on 2021-09-30. In some cases the OpenSSL 1.0.2 version will regard the certificates issued by the Let’s Encrypt CA as having an expired trust chain.

Most up-to-date CA cert trusted bundles, as provided by operating systems, contain this soon-to-be-expired certificate. The current CA cert bundles also contain an ISRG Root X1 self-signed certificate. This means that clients verifying certificate chains can find the alternative non-expired path to the ISRG Root X1 self-signed certificate in their trust store.

Unfortunately this does not apply to OpenSSL 1.0.2 which always prefers the untrusted chain and if that chain contains a path that leads to an expired trusted root certificate (DST Root CA X3), it will be selected for the certificate verification and the expiration will be reported.

References:

• ​Old Let’s Encrypt Root Certificate Expiration and OpenSSL 1.0.2
• ​DST Root CA X3 Expiration (September 2021)

Follow-up to [25224], [25426], [25569], [27307], [30491], [30765], [34283], [35919], [36570], [46094].

Props bradleyt, fierevere, SergeyBiryukov, peterwilsoncc.
Merges [51883] to the 5.5 branch.
Fixes #54207. See #50828.

[desrosj]

In 52100:

HTTP: Remove the DST Root CA X3 certificate expired on September 30, 2021.

The currently recommended certificate chain as presented to Let’s Encrypt ACME clients when new certificates are issued contains an intermediate certificate (ISRG Root X1) that is signed by an old DST Root CA X3 certificate that expires on 2021-09-30. In some cases the OpenSSL 1.0.2 version will regard the certificates issued by the Let’s Encrypt CA as having an expired trust chain.

Most up-to-date CA cert trusted bundles, as provided by operating systems, contain this soon-to-be-expired certificate. The current CA cert bundles also contain an ISRG Root X1 self-signed certificate. This means that clients verifying certificate chains can find the alternative non-expired path to the ISRG Root X1 self-signed certificate in their trust store.

Unfortunately this does not apply to OpenSSL 1.0.2 which always prefers the untrusted chain and if that chain contains a path that leads to an expired trusted root certificate (DST Root CA X3), it will be selected for the certificate verification and the expiration will be reported.

References:

• ​Old Let’s Encrypt Root Certificate Expiration and OpenSSL 1.0.2
• ​DST Root CA X3 Expiration (September 2021)

Follow-up to [25224], [25426], [25569], [27307], [30491], [30765], [34283], [35919], [36570], [46094].

Props bradleyt, fierevere, SergeyBiryukov, peterwilsoncc.
Merges [51883] to the 5.4 branch.
Fixes #54207. See #50828.

[desrosj]

In 52101:

HTTP: Remove the DST Root CA X3 certificate expired on September 30, 2021.

The currently recommended certificate chain as presented to Let’s Encrypt ACME clients when new certificates are issued contains an intermediate certificate (ISRG Root X1) that is signed by an old DST Root CA X3 certificate that expires on 2021-09-30. In some cases the OpenSSL 1.0.2 version will regard the certificates issued by the Let’s Encrypt CA as having an expired trust chain.

Most up-to-date CA cert trusted bundles, as provided by operating systems, contain this soon-to-be-expired certificate. The current CA cert bundles also contain an ISRG Root X1 self-signed certificate. This means that clients verifying certificate chains can find the alternative non-expired path to the ISRG Root X1 self-signed certificate in their trust store.

Unfortunately this does not apply to OpenSSL 1.0.2 which always prefers the untrusted chain and if that chain contains a path that leads to an expired trusted root certificate (DST Root CA X3), it will be selected for the certificate verification and the expiration will be reported.

References:

• ​Old Let’s Encrypt Root Certificate Expiration and OpenSSL 1.0.2
• ​DST Root CA X3 Expiration (September 2021)

Follow-up to [25224], [25426], [25569], [27307], [30491], [30765], [34283], [35919], [36570], [46094].

Props bradleyt, fierevere, SergeyBiryukov, peterwilsoncc.
Merges [51883] to the 5.3 branch.
Fixes #54207. See #50828.

[desrosj]

In 52102:

HTTP: Remove the DST Root CA X3 certificate expired on September 30, 2021.

The currently recommended certificate chain as presented to Let’s Encrypt ACME clients when new certificates are issued contains an intermediate certificate (ISRG Root X1) that is signed by an old DST Root CA X3 certificate that expires on 2021-09-30. In some cases the OpenSSL 1.0.2 version will regard the certificates issued by the Let’s Encrypt CA as having an expired trust chain.

Most up-to-date CA cert trusted bundles, as provided by operating systems, contain this soon-to-be-expired certificate. The current CA cert bundles also contain an ISRG Root X1 self-signed certificate. This means that clients verifying certificate chains can find the alternative non-expired path to the ISRG Root X1 self-signed certificate in their trust store.

Unfortunately this does not apply to OpenSSL 1.0.2 which always prefers the untrusted chain and if that chain contains a path that leads to an expired trusted root certificate (DST Root CA X3), it will be selected for the certificate verification and the expiration will be reported.

References:

• ​Old Let’s Encrypt Root Certificate Expiration and OpenSSL 1.0.2
• ​DST Root CA X3 Expiration (September 2021)

Follow-up to [25224], [25426], [25569], [27307], [30491], [30765], [34283], [35919], [36570], [46094].

Props bradleyt, fierevere, SergeyBiryukov, peterwilsoncc.
Merges [51883] to the 5.2 branch.
Fixes #54207. See #50828.