[gnutls-devel] GnuTLS | Handle expiration of AddTrust root certificate (urgent) (#1008)
Development of GNU's TLS library
gnutls-devel at lists.gnutls.org
Sun May 31 05:54:38 CEST 2020
Kenneth J_ Miller commented:
The ticket name should be changed to describe the underlying issue, the failing validation of certificates chaining back to the expired Sectigo root/intermediate is a symptom of deeper issue with the way GnuTLS currently validates certificate paths.
I recreated the issue locally with **GnuTLS 3.6.13**, Nginx, and some test certificates. From my observation, GnuTLS fails if the first path validated contains an expired certificate, even if there exist possible valid alternative paths.
Here the X.509 PKI I tested with an intermediate cross-signed by a valid and expired root certificate respectively:
```
ROOT 1 ROOT 2
(valid) (expired)
\ /
\ /
INTERMEDIATE 1
(valid)
|
|
LEAF 1
(valid)
```
Note that this is a slightly different hierarchy than the issue presented by Sectigo's certificates where the public keys of an intermediate certificate were used to re-create a self-signed root. However, the underlying issue presents itself in the same way.
Depending on the order in which Nginx serves the above cross-signed INTERMEDIATE 1 certificates after the LEAF 1 certificate, a request will either succeed or fail.
When the certificate bundle supplied by Nginx contains the INTERMEDIATE 1 signed by the valid ROOT 1 *before* the one signed by ROOT 2, the TLS handshake succeeds:
```
asd# gnutls-cli example.test
Processed 2 CA certificate(s).
Resolving 'example.test:443'...
Connecting to '127.0.1.1:443'...
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
- subject `CN=example.test', issuer `CN=INTERMEDIATE 1', serial 0x6ce0398c3f993ad4f5509763fc2ed69286df6631, RSA key 3072 bits, signed using RSA-SHA256, activated `2020-05-31 03:20:16 UTC', expires `2020-06-28 03:20:17 UTC', pin-sha256="ySlPmQ0lv9y4f7hwsopslzgEdiUnU3/5u4nFya2WwSo="
Public Key ID:
sha1:66fc0194e47a524774be3c64c1fcf11dab218ebd
sha256:c9294f990d25bfdcb87fb870b28a6c973804762527537ff9bb89c5c9ad96c12a
Public Key PIN:
pin-sha256:ySlPmQ0lv9y4f7hwsopslzgEdiUnU3/5u4nFya2WwSo=
- Certificate[1] info:
- subject `CN=INTERMEDIATE 1', issuer `CN=ROOT 1', serial 0x17662e3e54ea343b5e81205e0c69aafb94c2b29d, RSA key 3072 bits, signed using RSA-SHA256, activated `2020-05-31 03:25:19 UTC', expires `2020-06-29 03:25:22 UTC', pin-sha256="SbBuckO3jO2KQK2OTZ1s92tOYBU1Zh2cULbe6dZ+tK4="
- Certificate[2] info:
- subject `CN=INTERMEDIATE 1', issuer `CN=ROOT 2', serial 0x1040f78089e97ffefc343f977eaeedd78fc15f87, RSA key 3072 bits, signed using RSA-SHA256, activated `2020-05-31 03:22:12 UTC', expires `2020-06-28 03:22:14 UTC', pin-sha256="SbBuckO3jO2KQK2OTZ1s92tOYBU1Zh2cULbe6dZ+tK4="
- Status: The certificate is trusted.
- Description: (TLS1.3-X.509)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
- Options:
- Handshake was completed
```
When the certificate bundle supplied by Nginx contains the INTERMEDIATE 1 signed by the ROOT 1 *after* the one signed by the expired ROOT 1, the TLS handshake fails:
```
# gnutls-cli example.test
Processed 2 CA certificate(s).
Resolving 'example.test:443'...
Connecting to '127.0.1.1:443'...
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
- subject `CN=example.test', issuer `CN=INTERMEDIATE 1', serial 0x6ce0398c3f993ad4f5509763fc2ed69286df6631, RSA key 3072 bits, signed using RSA-SHA256, activated `2020-05-31 03:20:16 UTC', expires `2020-06-28 03:20:17 UTC', pin-sha256="ySlPmQ0lv9y4f7hwsopslzgEdiUnU3/5u4nFya2WwSo="
Public Key ID:
sha1:66fc0194e47a524774be3c64c1fcf11dab218ebd
sha256:c9294f990d25bfdcb87fb870b28a6c973804762527537ff9bb89c5c9ad96c12a
Public Key PIN:
pin-sha256:ySlPmQ0lv9y4f7hwsopslzgEdiUnU3/5u4nFya2WwSo=
- Certificate[1] info:
- subject `CN=INTERMEDIATE 1', issuer `CN=ROOT 2', serial 0x1040f78089e97ffefc343f977eaeedd78fc15f87, RSA key 3072 bits, signed using RSA-SHA256, activated `2020-05-31 03:22:12 UTC', expires `2020-06-28 03:22:14 UTC', pin-sha256="SbBuckO3jO2KQK2OTZ1s92tOYBU1Zh2cULbe6dZ+tK4="
- Certificate[2] info:
- subject `CN=INTERMEDIATE 1', issuer `CN=ROOT 1', serial 0x17662e3e54ea343b5e81205e0c69aafb94c2b29d, RSA key 3072 bits, signed using RSA-SHA256, activated `2020-05-31 03:25:19 UTC', expires `2020-06-29 03:25:22 UTC', pin-sha256="SbBuckO3jO2KQK2OTZ1s92tOYBU1Zh2cULbe6dZ+tK4="
- Status: The certificate is NOT trusted. The certificate chain uses expired certificate. The signature in the certificate is invalid.
*** PKI verification of server certificate failed...
*** Fatal error: Error in the certificate.
```
--
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1008#note_352387084
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20200531/51d09394/attachment.html>
More information about the Gnutls-devel
mailing list