Bug 1134602 - Odd certificate validation difference between F20 and F21/F22 with identical ca-certificates
Summary: Odd certificate validation difference between F20 and F21/F22 with identical ...
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: gnutls
Version: 20
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Nikos Mavrogiannopoulos
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-27 22:12 UTC by Michael Catanzaro
Modified: 2014-10-31 19:28 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-10-31 19:23:05 UTC


Attachments (Terms of Use)
glib test (528 bytes, text/plain)
2014-08-27 22:12 UTC, Michael Catanzaro
no flags Details

Description Michael Catanzaro 2014-08-27 22:12:54 UTC
Created attachment 931695 [details]
glib test

I'm confused by a difference between gnutls in F20 and F21/F22 in validating certs from www.amazon.com (which as you can imagine is a pretty bad site to fail). I'm trying to figure out if there is a bug somewhere in the GNOME stack, or if it's in gnutls.

Test matrix:

F20

ca-certificates-2014.2.1-1.0.fc20 (from updates-testing)
gnutls-3.1.25-1.fc20
glib2-2.38.2-2.fc20

F22

ca-certificates-2014.2.1-2.fc22
gnutls-3.3.6-2.fc22
glib2-2.41.3-1.fc22

I also attached a little test script I stole from someone in an unrelated bug report, to see if glib's certificate validation (which uses gnutls) will accept the certificate.

Results:

* The glib test script rejects the chain in both F20 and F22 with the updated ca-certificates package.
* The glib test script accepts the chain when the ca-certificates package is downgraded to 2013.1.97-1.fc20. OK, so it seems like the root certificate was simply removed....
* gnutls-cli rejects the chain in F20, but accepts the chain in F22. Normally I would use gnutls-cli as a known-good tool to see if there is a bug in the glib layer, but the inconsistent results have left me stumped. If you're able to explain the inconsistency, that would be great. (I notice gnutls loads more certificates in F22, for example....)

Here is the result in F20:

$ gnutls-cli www.amazon.com
Processed 153 CA certificate(s).
Resolving 'www.amazon.com'...
Connecting to '176.32.98.166:443'...
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
 - subject `C=US,ST=Washington,L=Seattle,O=Amazon.com Inc.,CN=www.amazon.com', issuer `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)10,CN=VeriSign Class 3 Secure Server CA - G3', RSA key 2048 bits, signed using RSA-SHA1, activated `2014-02-27 00:00:00 UTC', expires `2015-02-28 23:59:59 UTC', SHA-1 fingerprint `5655ef6fac0abd86d9d30970bebcc633e34b05e5'
	Public Key Id:
		1e8dd51d6c23aa588f80966a68632a6099afc422
	Public key's random art:
		+--[ RSA 2048]----+
		|             ..  |
		|           ...+. |
		|     o    ...o.. |
		|    + . .+.      |
		| .oo   +S+.      |
		|+Bo   ..o..      |
		|E+o     .        |
		|*  .             |
		|...              |
		+-----------------+

- Certificate[1] info:
 - subject `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)10,CN=VeriSign Class 3 Secure Server CA - G3', issuer `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=(c) 2006 VeriSign\, Inc. - For authorized use only,CN=VeriSign Class 3 Public Primary Certification Authority - G5', RSA key 2048 bits, signed using RSA-SHA1, activated `2010-02-08 00:00:00 UTC', expires `2020-02-07 23:59:59 UTC', SHA-1 fingerprint `5deb8f339e264c19f6686f5f8f32b54a4c46b476'
- Certificate[2] info:
 - subject `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=(c) 2006 VeriSign\, Inc. - For authorized use only,CN=VeriSign Class 3 Public Primary Certification Authority - G5', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 2048 bits, signed using RSA-SHA1, activated `2006-11-08 00:00:00 UTC', expires `2021-11-07 23:59:59 UTC', SHA-1 fingerprint `f4a80a0cd1e6cf190b8cbc6fbc991711d482c9d0'
- Status: The certificate is NOT trusted. The certificate issuer is unknown. 
*** Verifying server certificate failed...
*** Fatal error: Error in the certificate.
*** Handshake has failed
GnuTLS error: Error in the certificate.

When run in F22, it is accepted by gnutls-cli (but not by glib!) even though the output seems identical:

$ gnutls-cli www.amazon.com
Processed 173 CA certificate(s).
Resolving 'www.amazon.com'...
Connecting to '176.32.98.166:443'...
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
 - subject `C=US,ST=Washington,L=Seattle,O=Amazon.com Inc.,CN=www.amazon.com', issuer `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)10,CN=VeriSign Class 3 Secure Server CA - G3', RSA key 2048 bits, signed using RSA-SHA1, activated `2014-02-27 00:00:00 UTC', expires `2015-02-28 23:59:59 UTC', SHA-1 fingerprint `5655ef6fac0abd86d9d30970bebcc633e34b05e5'
	Public Key ID:
		1e8dd51d6c23aa588f80966a68632a6099afc422
	Public key's random art:
		+--[ RSA 2048]----+
		|             ..  |
		|           ...+. |
		|     o    ...o.. |
		|    + . .+.      |
		| .oo   +S+.      |
		|+Bo   ..o..      |
		|E+o     .        |
		|*  .             |
		|...              |
		+-----------------+

- Certificate[1] info:
 - subject `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)10,CN=VeriSign Class 3 Secure Server CA - G3', issuer `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=(c) 2006 VeriSign\, Inc. - For authorized use only,CN=VeriSign Class 3 Public Primary Certification Authority - G5', RSA key 2048 bits, signed using RSA-SHA1, activated `2010-02-08 00:00:00 UTC', expires `2020-02-07 23:59:59 UTC', SHA-1 fingerprint `5deb8f339e264c19f6686f5f8f32b54a4c46b476'
- Certificate[2] info:
 - subject `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=(c) 2006 VeriSign\, Inc. - For authorized use only,CN=VeriSign Class 3 Public Primary Certification Authority - G5', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 2048 bits, signed using RSA-SHA1, activated `2006-11-08 00:00:00 UTC', expires `2021-11-07 23:59:59 UTC', SHA-1 fingerprint `f4a80a0cd1e6cf190b8cbc6fbc991711d482c9d0'
- Status: The certificate is trusted. 
- Description: (TLS1.0)-(ECDHE-RSA-SECP256R1)-(AES-128-CBC)-(SHA1)
- Session ID: D0:EF:D2:EF:AC:A0:60:AE:10:E2:F0:02:D6:E0:23:3E:F2:D2:8B:31:3D:DB:18:6E:AD:D7:BE:DF:EE:5B:10:A7
- Ephemeral EC Diffie-Hellman parameters
 - Using curve: SECP256R1
 - Curve size: 256 bits
- Version: TLS1.0
- Key Exchange: ECDHE-RSA
- Cipher: AES-128-CBC
- MAC: SHA1
- Compression: NULL
- Handshake was completed

Comment 1 Nikos Mavrogiannopoulos 2014-08-28 06:57:07 UTC
Hello,
 There is a difference in the gnutls certificate validation in F20 and F21. In F20 the file /etc/pki/tls/cert.pem is used to load the trusted CA certificates, while in F21 the p11-kit trust module is queried (shown with p11tool --list-tokens). That shouldn't have had much differences though, as the trust module is the one that generates the /etc/pki/tls/cert.pem in the first place.

However, I'm confused by the test case. In F20 connecting to www.amazon.com succeeds (or at least it should). Have you tweaked the trusted certificate database? (did you run update-ca-trust after then?)

Comment 2 Michael Catanzaro 2014-08-28 14:29:25 UTC
(In reply to Nikos Mavrogiannopoulos from comment #1)
> However, I'm confused by the test case. In F20 connecting to www.amazon.com
> succeeds (or at least it should).

It succeeds unless I install ca-certificates-2014.2.1-1.0.fc20 from updates-testing (to match the version used in F21/F22), in which case it fails. Installing or downgrading this package is sufficient to cause gnutls-cli in F20 to reject or accept the certificate from www.amazon.com. In F21/F22 it makes no difference to gnutls-cli, but does to glib.

> Have you tweaked the trusted certificate
> database? (did you run update-ca-trust after then?)

This is run in %post when upgrading or downgrading the ca-certificates package.

Comment 3 Nikos Mavrogiannopoulos 2014-08-28 19:21:55 UTC
I suspect the issue is that glib uses gnutls_certificate_set_x509_trust_file() and sets /etc/pki/tls/cert.pem, while gnutls-cli in F21 uses gnutls_certificate_set_x509_system_trust() which uses the p11-kit trust module.

However, even in that case ca-certificates should have provided the same set of anchors. That's why I'm assigning this issue to ca-certificates.

Comment 4 Nikos Mavrogiannopoulos 2014-08-29 09:49:57 UTC
It seems it's easy to reproduce:

$ sudo dnf install https://kojipkgs.fedoraproject.org//packages/ca-certificates/2014.2.1/1.0.fc20/noarch/ca-certificates-2014.2.1-1.0.fc20.noarch.rpm

#using gnutls 3.3.x or the shipped in f20
$ gnutls-cli www.amazon.com --x509cafile /etc/pki/tls/cert.pem 
- Status: The certificate is NOT trusted. The certificate issuer is unknown. 
*** Verifying server certificate failed...
*** Fatal error: Error in the certificate.
*** Handshake has failed
GnuTLS error: Error in the certificate.

#using gnutls 3.3.x
$ ./gnutls-cli www.amazon.com --x509cafile pkcs11:
...
- Handshake was completed
- Simple Client Mode:


So indeed, there is an issue in ca-certificates-2014.2.1-1.0.fc20.noarch.rpm

Comment 5 Nikos Mavrogiannopoulos 2014-09-02 12:50:26 UTC
The issue is that "C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority" is missing from the trusted for TLS authorities.

However, it is present for the trusted for email authorities. That's why the version of gnutls which uses p11-kit works.

There are two issues:
1. the p11-kit trust module includes all authorities and relies on the user checking the key purpose extension for verification. Since the certificate in question doesn't set the key purpose it is considered trusted for TLS. Hence, the discrepancy between using the tls/cert.pem file and p11-kit trust module.

2. Amazon.com sends this certificate as its last: "Subject: C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=(c) 2006 VeriSign\, Inc. - For authorized use only,CN=VeriSign Class 3 Public Primary Certification Authority - G5"

That is signed by "C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority", which was removed.

GnuTLS in that case will check whether "Subject: C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=(c) 2006 VeriSign\, Inc. - For authorized use only,CN=VeriSign Class 3 Public Primary Certification Authority - G5" is in the trusted list and matches the certificate sent by amazon.

However our bundled, doesn't match the one sent by amazon. Amazon's sent G5 SHA1 fingerprint is: f4a80a0cd1e6cf190b8cbc6fbc991711d482c9d0, while our bundled G5 has SHA1: 4eb6d578499b1ccf5f581ead56be3d9b6744a5e5

For some reason we ship a newer version of G5 which is different than the one amazon sends. A fix could be to send the old version of G5 as well (the non-self-signed one).

Comment 6 Nikos Mavrogiannopoulos 2014-09-02 12:52:01 UTC
(In reply to Nikos Mavrogiannopoulos from comment #5)
> For some reason we ship a newer version of G5 which is different than the
> one amazon sends. A fix could be to send the old version of G5 as well (the
> non-self-signed one).

s/to send the old/to bundle the old/

Comment 7 Michael Catanzaro 2014-09-02 13:33:04 UTC
Thanks Nikos.  So the root certificate is valid for TLS, but is missing from tls/cert.pem? Am I correct in saying that applications are allowed to assume that all valid TLS certificates are available in tls/cert.pem? Is this a bug in ca-certificates or p11-kit?

I wonder why we have a different version of the G5 cert.

Comment 8 Nikos Mavrogiannopoulos 2014-09-02 14:55:09 UTC
(In reply to Michael Catanzaro from comment #7)
> Thanks Nikos.  So the root certificate is valid for TLS, but is missing from
> tls/cert.pem? 

Yes. It is one of the certificates that were removed because they were 1024 bits. But it was removed only from the trusted for TLS list, not the trusted for email list.

> Am I correct in saying that applications are allowed to assume
> that all valid TLS certificates are available in tls/cert.pem? Is this a bug
> in ca-certificates or p11-kit?

I'm not sure (adding Stef).

Comment 9 Michael Catanzaro 2014-09-02 15:53:32 UTC
(In reply to Nikos Mavrogiannopoulos from comment #8)
> Yes. It is one of the certificates that were removed because they were 1024
> bits. But it was removed only from the trusted for TLS list, not the trusted
> for email list.

Then it seems like Firefox should also not accept this cert for TLS?

(As a practical matter, my main concern is that Firefox can display amazon.com and Epiphany cannot.)

Comment 10 Nikos Mavrogiannopoulos 2014-09-02 18:25:29 UTC
(In reply to Michael Catanzaro from comment #9)
> (In reply to Nikos Mavrogiannopoulos from comment #8)
> > Yes. It is one of the certificates that were removed because they were 1024
> > bits. But it was removed only from the trusted for TLS list, not the trusted
> > for email list.
> 
> Then it seems like Firefox should also not accept this cert for TLS?

Why? Firefox uses NSS which does use a totally different verification strategy (and database). I just described what gnutls uses.

Comment 11 Stef Walter 2014-09-03 07:18:51 UTC
(In reply to Nikos Mavrogiannopoulos from comment #8)
> (In reply to Michael Catanzaro from comment #7)
> > Am I correct in saying that applications are allowed to assume
> > that all valid TLS certificates are available in tls/cert.pem? Is this a bug
> > in ca-certificates or p11-kit?
> 
> I'm not sure (adding Stef).

Not sure what "valid TLS certificates" means, exactly.

But tls/cert.pem is a symlink to /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

That file contains all root CA anchors trusted to verify TLS servers.

There is also intermediate certificate trust information that's not included in the extracted files. OpenSSL and GnuTLS have (at the current time at least) no way to consume intermediate certificate trust information from files.

Comment 12 Nikos Mavrogiannopoulos 2014-09-03 07:46:16 UTC
(In reply to Stef Walter from comment #11)
> (In reply to Nikos Mavrogiannopoulos from comment #8)
> > (In reply to Michael Catanzaro from comment #7)
> > > Am I correct in saying that applications are allowed to assume
> > > that all valid TLS certificates are available in tls/cert.pem? Is this a bug
> > > in ca-certificates or p11-kit?
> > 
> > I'm not sure (adding Stef).
> 
> Not sure what "valid TLS certificates" means, exactly.
> 
> But tls/cert.pem is a symlink to
> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
> 
> That file contains all root CA anchors trusted to verify TLS servers.

The point was that using p11-kit trust module both tls-ca-bundle is given to the application as well as the email-ca-bundle. The application at that point has no way to distinguish them. However maybe we should split the issues, as that is not directly related to the ca-certificates issue.

Comment 13 Stef Walter 2014-09-03 09:19:17 UTC
(In reply to Nikos Mavrogiannopoulos from comment #12)
> The point was that using p11-kit trust module both tls-ca-bundle is given to
> the application as well as the email-ca-bundle. The application at that
> point has no way to distinguish them. However maybe we should split the
> issues, as that is not directly related to the ca-certificates issue.

Older applications that don't support looking stuff up in the trust store directlty, should only use *one* of the bundle files, not both.

The one that it uses depends on what the application is doing. If the application is connecting to a TLS server, use tls-ca-bundle.pem. If the application is doing S/MIME, then it should use email-ca-bundle.pem.

Comment 14 Nikos Mavrogiannopoulos 2014-09-03 10:10:15 UTC
Let's separate the issues, to clean up the mess in this bug report. I'll fill the issue on p11-kit separately.

The issue in this report is that "C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority" is missing from the trusted for TLS authorities.

Amazon.com sends this certificate as its last: "Subject: C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=(c) 2006 VeriSign\, Inc. - For authorized use only,CN=VeriSign Class 3 Public Primary Certification Authority - G5"

That is signed by "C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority", which was removed.

GnuTLS in that case will check whether "Subject: C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=(c) 2006 VeriSign\, Inc. - For authorized use only,CN=VeriSign Class 3 Public Primary Certification Authority - G5" is in the trusted list and matches the certificate sent by amazon.

However our bundled, doesn't match the one sent by amazon. Amazon's sent G5 SHA1 fingerprint is: f4a80a0cd1e6cf190b8cbc6fbc991711d482c9d0, while our bundled G5 has SHA1: 4eb6d578499b1ccf5f581ead56be3d9b6744a5e5

For some reason we ship a newer version of G5 which is different than the one amazon sends. A fix could be to send the old version of G5 as well (the non-self-signed one).

Comment 15 Kai Engert (:kaie) (inactive account) 2014-09-06 00:44:04 UTC
(In reply to Nikos Mavrogiannopoulos from comment #5)
> 2. Amazon.com sends this certificate as its last: "Subject:
> C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=(c) 2006 VeriSign\, Inc.
> - For authorized use only,CN=VeriSign Class 3 Public Primary Certification
> Authority - G5"
> 
> That is signed by "C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
> Certification Authority", which was removed.
> 
> GnuTLS in that case will check whether "Subject: C=US,O=VeriSign\,
> Inc.,OU=VeriSign Trust Network,OU=(c) 2006 VeriSign\, Inc. - For authorized
> use only,CN=VeriSign Class 3 Public Primary Certification Authority - G5" is
> in the trusted list and matches the certificate sent by amazon.
> 
> However our bundled, doesn't match the one sent by amazon. Amazon's sent G5
> SHA1 fingerprint is: f4a80a0cd1e6cf190b8cbc6fbc991711d482c9d0, while our
> bundled G5 has SHA1: 4eb6d578499b1ccf5f581ead56be3d9b6744a5e5
> 
> For some reason we ship a newer version of G5 which is different than the
> one amazon sends. A fix could be to send the old version of G5 as well (the
> non-self-signed one).

It's easy to get confused here:

The certificate with subject G5 that is sent by the amazon server is an intermediate. The intermediate has a different issuer, pointing to the removed root.

Our bundled cert with same subject G5 is a self signed root CA, with identical subject and issuer.

They are two different certs, that's why they of course have different SHA1.

Comment 16 Kai Engert (:kaie) (inactive account) 2014-09-06 00:49:16 UTC
(In reply to Nikos Mavrogiannopoulos from comment #8)
> (In reply to Michael Catanzaro from comment #7)
> > Thanks Nikos.  So the root certificate is valid for TLS, but is missing from
> > tls/cert.pem? 
> 
> Yes. It is one of the certificates that were removed because they were 1024
> bits. But it was removed only from the trusted for TLS list, not the trusted
> for email list.

To clarify:

The old root is still shipped in our "master" (source) list.

Each shipped root may come with three independent trust flags. The old root had its trust flag for SSL/TLS removed. It's still trusted for email.

The intention is that update-ca-trust/p11-kit-trust reads the master/source list, and when it creates the "extracted" bundle files, it should omit the root from the tls bundle, but include it in the email bundle.

In my opinion, applications that use p11-kit-trust MUST look at the trust flags when making a decision about "trusted for SSL/TLS".

Comment 17 Kai Engert (:kaie) (inactive account) 2014-09-06 00:57:33 UTC
(In reply to Nikos Mavrogiannopoulos from comment #14)
> Let's separate the issues, to clean up the mess in this bug report. I'll
> fill the issue on p11-kit separately.
> 
> The issue in this report is that "C=US,O=VeriSign\, Inc.,OU=Class 3 Public
> Primary Certification Authority" is missing from the trusted for TLS
> authorities.
> 
> Amazon.com sends this certificate as its last: "Subject: C=US,O=VeriSign\,
> Inc.,OU=VeriSign Trust Network,OU=(c) 2006 VeriSign\, Inc. - For authorized
> use only,CN=VeriSign Class 3 Public Primary Certification Authority - G5"
> 
> That is signed by "C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
> Certification Authority", which was removed.

right, removed from the "list of certs trusted for SSL/TLS" (but still included as trusted for issued "email" certs.


> GnuTLS in that case will check whether "Subject: C=US,O=VeriSign\,
> Inc.,OU=VeriSign Trust Network,OU=(c) 2006 VeriSign\, Inc. - For authorized
> use only,CN=VeriSign Class 3 Public Primary Certification Authority - G5" is
> in the trusted list and matches the certificate sent by amazon.

There is a certificate with this subject in our trusted list.

Are you searching for a trust store certificate that is IDENTICAL to the certificate sent by the server? I think that would be wrong.

I think what you must do is:

Search the trust store for ANY certificate that matches exactly the given subject. If you find a certificate that is self-signed (same issuer) and marked as trusted, you should succeed.


> However our bundled, doesn't match the one sent by amazon. Amazon's sent G5
> SHA1 fingerprint is: f4a80a0cd1e6cf190b8cbc6fbc991711d482c9d0, while our
> bundled G5 has SHA1: 4eb6d578499b1ccf5f581ead56be3d9b6744a5e5

I think that should be irrelevant, as I explained in the previous comment.


> For some reason we ship a newer version of G5 which is different than the
> one amazon sends. A fix could be to send the old version of G5 as well (the
> non-self-signed one).

It's a common practice that a CA will issue multiple certificates with the same subject, but different issuers. A common scenario is "cross-signing", or for migration purposes (when introducing a new root, allow clients to temporarily find a chain to another pre-existing root).

Comment 18 Nikos Mavrogiannopoulos 2014-09-06 10:55:02 UTC
(In reply to Kai Engert (:kaie) from comment #16)
> In my opinion, applications that use p11-kit-trust MUST look at the trust
> flags when making a decision about "trusted for SSL/TLS".

They were not made available, so it is no possible to check them. As I understand there is on-going work, but as it is now in F20 the flags are not available.

Comment 19 Nikos Mavrogiannopoulos 2014-09-06 11:06:09 UTC
(In reply to Kai Engert (:kaie) from comment #17)

> I think what you must do is:
> Search the trust store for ANY certificate that matches exactly the given
> subject. If you find a certificate that is self-signed (same issuer) and
> marked as trusted, you should succeed.

There is no cryptographic binding of the key in the DN. At minimum the match of the key between the suggested by the server and the bundled CA should be performed, or in the end the provided by the user chain becomes irrelevant (and one may end up verifying ECDSA signature using an RSA key). When combined with key matching it looks reasonable and is already added in gnutls 3.3.x, but I'm not sure whether it should be backported to 3.1.x.
 
> > However our bundled, doesn't match the one sent by amazon. Amazon's sent G5
> > SHA1 fingerprint is: f4a80a0cd1e6cf190b8cbc6fbc991711d482c9d0, while our
> > bundled G5 has SHA1: 4eb6d578499b1ccf5f581ead56be3d9b6744a5e5
> I think that should be irrelevant, as I explained in the previous comment.

It could be, but by being irrelevant we accept that we will not be able to connect to amazon.com using "Basic Path Validation" as in http://tools.ietf.org/html/rfc5280#section-6

Comment 20 Nikos Mavrogiannopoulos 2014-09-06 11:30:08 UTC
(In reply to Kai Engert (:kaie) from comment #17)

> > That is signed by "C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
> > Certification Authority", which was removed.
> right, removed from the "list of certs trusted for SSL/TLS" (but still
> included as trusted for issued "email" certs.

A related issue, is why is that? Why does a 1024-bit CA certificate is considered trusted to certify e-mails but not web sites? We haven't set any requirements that set a higher bar for the web than for e-mail.

Comment 21 Nikos Mavrogiannopoulos 2014-10-31 19:23:05 UTC
Fixed in F21.

Comment 22 Nikos Mavrogiannopoulos 2014-10-31 19:28:50 UTC
(to clarify: the parts that were related to gnutls are fixed in F21)


Note You need to log in before you can comment on or make changes to this bug.