WordPress.org

Make WordPress Core

Opened 18 months ago

Last modified 2 months ago

#50828 reviewing defect (bug)

Update ca-bundle.crt and remove expired certificates

Reported by: barry Owned by: SergeyBiryukov
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Security Keywords: has-patch
Focuses: Cc:

Description

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 :)

Attachments (5)

50828.diff (23.4 KB) - added by barry 18 months ago.
50828-split-file-verbatim.patch (265.7 KB) - added by ayeshrajans 18 months ago.
50828-additional-removals.patch (5.7 KB) - added by ayeshrajans 18 months ago.
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)
wordpress-custom-1024bit-certificates.patch (8.5 KB) - added by ayeshrajans 18 months ago.
Out current ca-cert.pem can be generated by applying this patch to any upstream CA root certificate store.
50828.2.diff (90.9 KB) - added by whyisjake 4 months ago.

Download all attachments as: .zip

Change History (36)

@barry
18 months ago

#1 @SergeyBiryukov
18 months ago

  • Component changed from General to Security

Previously: [46094] / #45807.

#2 @SergeyBiryukov
18 months ago

  • Milestone changed from Awaiting Review to 5.6

#3 follow-up: @desrosj
18 months ago

@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.

#4 @SergeyBiryukov
18 months ago

  • Milestone changed from 5.6 to 5.5

#5 @barry
18 months ago

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

#6 @whyisjake
18 months ago

  • Keywords commit dev-feedback added

#7 in reply to: ↑ 3 ; follow-up: @ayeshrajans
18 months ago

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.

#8 @ayeshrajans
18 months ago

  • Keywords has-patch added

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:

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.

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

#9 in reply to: ↑ 7 @SergeyBiryukov
18 months ago

  • Keywords dev-reviewed added; dev-feedback removed

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.

#10 @SergeyBiryukov
18 months ago

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.

#11 @SergeyBiryukov
18 months ago

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.

#12 @SergeyBiryukov
18 months ago

  • Keywords dev-reviewed removed
  • Milestone changed from 5.5 to 5.6

#13 @ayeshrajans
18 months ago

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.

Last edited 18 months ago by ayeshrajans (previous) (diff)

@ayeshrajans
18 months ago

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
18 months ago

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

This ticket was mentioned in Slack in #core by helen. View the logs.


17 months ago

#15 @SergeyBiryukov
17 months ago

  • Owner set to SergeyBiryukov
  • Status changed from new to reviewing

This ticket was mentioned in Slack in #core by helen. View the logs.


15 months ago

#17 @SergeyBiryukov
14 months ago

  • Milestone changed from 5.6 to 5.7

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

#18 @SergeyBiryukov
11 months ago

  • Milestone changed from 5.7 to 5.8

This ticket was mentioned in Slack in #core by chaion07. View the logs.


8 months ago

#20 @hellofromTonya
8 months ago

  • Keywords commit removed
  • Milestone changed from 5.8 to Future Release

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

#21 @SergeyBiryukov
4 months ago

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:

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

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

@whyisjake
4 months ago

#22 follow-up: @whyisjake
4 months ago

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

#23 in reply to: ↑ 22 ; follow-up: @dd32
4 months ago

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.

#24 in reply to: ↑ 23 @SergeyBiryukov
4 months ago

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.

#25 @desrosj
3 months ago

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:

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.

#26 @desrosj
2 months ago

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:

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.

#27 @desrosj
2 months ago

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:

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.

#28 @desrosj
2 months ago

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:

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.

#29 @desrosj
2 months ago

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:

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.

#30 @desrosj
2 months ago

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:

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.

#31 @desrosj
2 months ago

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:

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.

Note: See TracTickets for help on using tickets.