I'm reporting this problem *before* it reaches Fedora. Debian's recent update of ca-certificates has broken access to bugs.webkit.org (and likely several other websites) due to the removal of GeoTrust Global CA. The Debian users I know who are complaining about this have not reported any bugs to Debian afaik, so I don't have any issue reference for this, but here is what a gnutls-cli test looks like in current F32: $ gnutls-cli bugs.webkit.org Processed 157 CA certificate(s). Resolving 'bugs.webkit.org:443'... Connecting to '54.190.50.174:443'... - Certificate type: X.509 - Got a certificate list of 3 certificates. - Certificate[0] info: - subject `C=US,ST=California,O=Apple Inc.,OU=management:idms.group.764034,CN=*.webkit.org', issuer `C=US,O=Apple Inc.,OU=Certification Authority,CN=Apple IST CA 2 - G1', serial 0x3d37861580f4b94a082ed0165cb50323, RSA key 2048 bits, signed using RSA-SHA256, activated `2019-03-14 15:17:01 UTC', expires `2021-04-12 15:17:01 UTC', pin-sha256="tL+87jiddochHD2CErYBSivCwH5FN4kI6I+/yylNJ0M=" Public Key ID: sha1:6ad4b778c6ccf1cd37110f86451c8cdee4fca511 sha256:b4bfbcee389d7687211c3d8212b6014a2bc2c07e45378908e88fbfcb294d2743 Public Key PIN: pin-sha256:tL+87jiddochHD2CErYBSivCwH5FN4kI6I+/yylNJ0M= - Certificate[1] info: - subject `C=US,O=Apple Inc.,OU=Certification Authority,CN=Apple IST CA 2 - G1', issuer `CN=GeoTrust Global CA,O=GeoTrust Inc.,C=US', serial 0x023a74, RSA key 2048 bits, signed using RSA-SHA256, activated `2014-06-16 15:42:02 UTC', expires `2022-05-20 15:42:02 UTC', pin-sha256="tc+C1H75gj+ap48SMYbFLoh56oSw+CLJHYPgQnm3j9U=" - Certificate[2] info: - subject `CN=GeoTrust Global CA,O=GeoTrust Inc.,C=US', issuer `CN=GeoTrust Global CA,O=GeoTrust Inc.,C=US', serial 0x023456, RSA key 2048 bits, signed using RSA-SHA1, activated `2002-05-21 04:00:00 UTC', expires `2022-05-21 04:00:00 UTC', pin-sha256="h6801m+z8v3zbgkRHpq6L29Esgfzhj89C1SyUCOQmqU=" - Status: The certificate is trusted. - Description: (TLS1.2-X.509)-(ECDHE-SECP256R1)-(RSA-SHA512)-(AES-128-GCM) - Session ID: 67:A5:FF:EF:89:10:54:2E:64:96:89:7F:86:3F:0D:79:26:78:74:6E:D7:5D:B7:9B:A3:27:29:63:B3:0B:00:7E - Options: safe renegotiation, - Handshake was completed - Simple Client Mode: - Peer has closed the GnuTLS connection So it's easy to see that removing GeoTrust Global CA authority from the trust store is likely to break the connection, and will have to be tested before we update to new ca-certificates. Now, the website still works in Firefox and Chrome on Debian, even with GeoTrust removed, just not in GnuTLS. I'm not sure why, but my guess is somehow these browsers have a hack to manually whitelist certificates issued by Apple IST CA 2 - G1, and maybe other intermediates of GeoTrust Global CA as well.
Hi Bob, please confirm that you've seen this bug. The next update of ca-certificates will need to be handled carefully to deal with this issue. Debian has decided to simply revert this change. We are guessing Mozilla has some sort of hack in Firefox to whitelist trust for intermediate CAs signed by this root, which isn't a plausible solution to implement for each TLS library available in Fedora.
I've seen it. I believe it's removed with the new NOT_AFTER flag. GeoTrust is still in the trust store, and NSS explicitly untrusts it except for certain certificates. I'll put more info after a full investigation. bob
So mozilla lists relevent changes between NSS processing and the raw cert trust database here: https://wiki.mozilla.org/CA/Additional_Trust_Changes . NSS was indeed whitelisting accepted intermediates, but it also didn't explicitly removed the target CA's from the trust list. It now uses CKA_NSS_SERVER_DISTRUST_AFTER to handle how it distrusts the given CA's. I've verified that the cert has not been removed from the current trust list, but CKA_NSS_SERVER_DISTRUST_AFTER has been set in the latest version. This means if the certs issued from this CA was issued after the specified date, then the trust would be distrusted, otherwise it will continue to be trusted. I suspect Debian took out the certs from the trust store altogether, rather than process the list straight from mozilla. Upshot: if you process CKA_NSS_SERVER_DISTRUST_AFTER, then you will get safer behavior, otherwise the ca's are still trusted in the latest list.
Thanks!
(In reply to Bob Relyea from comment #3) > Upshot: if you process CKA_NSS_SERVER_DISTRUST_AFTER, then you will get > safer behavior, otherwise the ca's are still trusted in the latest list. (Something to consider for GnuTLS.)