Bug#607616: libgnutls26: the GnuTLS searches CA certs by subject and stops on first? (fails on more CA with the same subj)
Hello, On Tue, Jan 25, 2011 at 10:57:37PM +0100, Nikos Mavrogiannopoulos wrote: On 01/20/2011 05:58 PM, Václav Ovsík wrote: On Thu, Jan 20, 2011 at 05:22:12PM +0100, Nikos Mavrogiannopoulos wrote: Hello, Indeed I'm mistaken. The reported problem is about order of certificates with the same subject DN in the repository during verifying certificate. I have server certificates issued by older and newer CA certificate both valid of course. GnuTLS must find the right certificate of CA from two or even more with the same subject DN. I tried to examine in the bug-report, that based on the order of two CA certificates with the same subject DN IN THE REPOSITORY the GnuTLS fails on newer or older server certificate. There was no change on server sides or so. I changed CA cert order only on the client side repository. Yes gnutls does stop on first match no matter if expired of not... Is there merit in supporting lists that contain duplicates of certificates? Changing subject DN on certificate renewals is maybe good practice, but AFAIK not required. Administrators of our company CA (Microsoft CA) simply did not change it. Their choice, OK. No don't take my point as being that changing the DN is recommended. I am not suggesting that. What I suggest is that the old certificate can be removed from the list once the renewed one is added. I mention this, because it could work-around the problem and I met this recommendation it the past (for example to append the year to CA subject DN). Renewed certificate of CA can't be removed immediately of course. A new CA certificate must be issued at least in the End_Of_Life(CA) - The_Longest_Life_Duration_CA_issued_Cert. For example you have CA with Not After 2012-01-01 and you are issuing certs with one year validity - the date you can issue the last cert with this CA is 2011-01-01. This CA must issue CRL till its end in 2012-01-01. You need a new CA for certs after 2011-01-01. You have two CA certs valid between 2011-01-01 - 2012-01-01 both must issue CRL, only newer is issuing certs. I solved my problem with LDAPS servers simply by pointing only to Root CA (not whole CA bundle). The LDAPS server gives the certificate chain with the right intermediate CA, so things works now on every server :). OpenSSL handles this smoothly and I think it is bug otherwise. When OpenSSL's c_rehash is called on directory of X.509 certificates, it numbers hashes with aabbccdd.n, where n is for resolution of the same Subjects. So when I look into my repository: I note it as an issue to the gnutls verification functionality, and I'll fix it together with some other issues, by adding a more advanced verification subsystem. Great! I think it will be worth either in my special case exists a work-around. Best Regards -- Zito -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607616: libgnutls26: the GnuTLS searches CA certs by subject and stops on first? (fails on more CA with the same subj)
On 01/20/2011 05:58 PM, Václav Ovsík wrote: On Thu, Jan 20, 2011 at 05:22:12PM +0100, Nikos Mavrogiannopoulos wrote: Hello, Indeed I'm mistaken. The reported problem is about order of certificates with the same subject DN in the repository during verifying certificate. I have server certificates issued by older and newer CA certificate both valid of course. GnuTLS must find the right certificate of CA from two or even more with the same subject DN. I tried to examine in the bug-report, that based on the order of two CA certificates with the same subject DN IN THE REPOSITORY the GnuTLS fails on newer or older server certificate. There was no change on server sides or so. I changed CA cert order only on the client side repository. Yes gnutls does stop on first match no matter if expired of not... Is there merit in supporting lists that contain duplicates of certificates? Changing subject DN on certificate renewals is maybe good practice, but AFAIK not required. Administrators of our company CA (Microsoft CA) simply did not change it. Their choice, OK. No don't take my point as being that changing the DN is recommended. I am not suggesting that. What I suggest is that the old certificate can be removed from the list once the renewed one is added. OpenSSL handles this smoothly and I think it is bug otherwise. When OpenSSL's c_rehash is called on directory of X.509 certificates, it numbers hashes with aabbccdd.n, where n is for resolution of the same Subjects. So when I look into my repository: I note it as an issue to the gnutls verification functionality, and I'll fix it together with some other issues, by adding a more advanced verification subsystem. regards, Nikos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607616: libgnutls26: the GnuTLS searches CA certs by subject and stops on first? (fails on more CA with the same subj)
Hi Nikos, On Mon, Dec 20, 2010 at 05:03:28PM +0100, Nikos Mavrogiannopoulos wrote: You cannot reorder certificates on will. For TLS/SSL the certificates have to be ordered (from RFC5246): This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. I'm not sure correctly understood, but I think your reply is not relevant to a problem I reported. The above citation is about order of certificates in the chain sent in the TLS protocol by server right? The reported problem is about order of certificates with the same subject DN in the repository during verifying certificate. I have server certificates issued by older and newer CA certificate both valid of course. GnuTLS must find the right certificate of CA from two or even more with the same subject DN. I tried to examine in the bug-report, that based on the order of two CA certificates with the same subject DN IN THE REPOSITORY the GnuTLS fails on newer or older server certificate. There was no change on server sides or so. I changed CA cert order only on the client side repository. Thanks for your time. Best Regards -- Zito -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607616: libgnutls26: the GnuTLS searches CA certs by subject and stops on first? (fails on more CA with the same subj)
On 01/20/2011 05:01 PM, Václav Ovsík wrote: Hi Nikos, On Mon, Dec 20, 2010 at 05:03:28PM +0100, Nikos Mavrogiannopoulos wrote: You cannot reorder certificates on will. For TLS/SSL the certificates have to be ordered (from RFC5246): This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. I'm not sure correctly understood, but I think your reply is not relevant to a problem I reported. The above citation is about order of certificates in the chain sent in the TLS protocol by server right? Hello, Indeed I'm mistaken. The reported problem is about order of certificates with the same subject DN in the repository during verifying certificate. I have server certificates issued by older and newer CA certificate both valid of course. GnuTLS must find the right certificate of CA from two or even more with the same subject DN. I tried to examine in the bug-report, that based on the order of two CA certificates with the same subject DN IN THE REPOSITORY the GnuTLS fails on newer or older server certificate. There was no change on server sides or so. I changed CA cert order only on the client side repository. Yes gnutls does stop on first match no matter if expired of not... Is there merit in supporting lists that contain duplicates of certificates? regards, Nikos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607616: libgnutls26: the GnuTLS searches CA certs by subject and stops on first? (fails on more CA with the same subj)
On Thu, Jan 20, 2011 at 05:22:12PM +0100, Nikos Mavrogiannopoulos wrote: Hello, Indeed I'm mistaken. The reported problem is about order of certificates with the same subject DN in the repository during verifying certificate. I have server certificates issued by older and newer CA certificate both valid of course. GnuTLS must find the right certificate of CA from two or even more with the same subject DN. I tried to examine in the bug-report, that based on the order of two CA certificates with the same subject DN IN THE REPOSITORY the GnuTLS fails on newer or older server certificate. There was no change on server sides or so. I changed CA cert order only on the client side repository. Yes gnutls does stop on first match no matter if expired of not... Is there merit in supporting lists that contain duplicates of certificates? Changing subject DN on certificate renewals is maybe good practice, but AFAIK not required. Administrators of our company CA (Microsoft CA) simply did not change it. Their choice, OK. OpenSSL handles this smoothly and I think it is bug otherwise. When OpenSSL's c_rehash is called on directory of X.509 certificates, it numbers hashes with aabbccdd.n, where n is for resolution of the same Subjects. So when I look into my repository: zito@bobek:~$ ls -la /etc/ssl/certs|grep ICZ lrwxrwxrwx 1 root root18 Jan 19 08:56 0e87c968.0 - ICZ-Issuing-CA.pem lrwxrwxrwx 1 root root20 Jan 19 08:56 0e87c968.1 - ICZ-Issuing-CA-1.pem lrwxrwxrwx 1 root root53 Jan 19 08:52 ICZ-Issuing-CA-1.pem - /usr/local/share/ca-certificates/ICZ-Issuing-CA-1.crt lrwxrwxrwx 1 root root51 Jan 19 08:52 ICZ-Issuing-CA.pem - /usr/local/share/ca-certificates/ICZ-Issuing-CA.crt lrwxrwxrwx 1 root root48 Jan 19 08:52 ICZ-Root-CA.pem - /usr/local/share/ca-certificates/ICZ-Root-CA.crt lrwxrwxrwx 1 root root15 Jan 19 08:56 d0d1f6f2.0 - ICZ-Root-CA.pem Certificates ICZ-Issuing-CA.pem and ICZ-Issuing-CA-1.pem (more recent) have the same hash, so symlinks 0e87c968.0 0e87c968.1 exists. I don't look into OpenSSLs internals how it implements this in its X509_STORE structures... The concurrence of two CA certs will remain until older and everything it issued will expire. Regards -- Zito -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607616: libgnutls26: the GnuTLS searches CA certs by subject and stops on first? (fails on more CA with the same subj)
Package: libgnutls26 Version: 2.8.6-1 Severity: normal Hi, after renewing intermediate CA certificate of our company CA I can't connect to some servers using ldaps. GnuTLS validation is broken. Renewed CA has the same subject as previous. The certs are accessible at http://www.i.cz/ca/ (Issued by MS CA). z...@bobek:/usr/share/ca-certificates/local$ openssl x509 -subject -dates -serial -noout -in ICZ-Issuing-CA.crt subject= /C=CZ/O=ICZ a.s./CN=ICZ Issuing CA notBefore=Oct 16 12:05:52 2007 GMT notAfter=Oct 16 12:15:52 2011 GMT serial=1101979C0002 z...@bobek:/usr/share/ca-certificates/local$ openssl x509 -subject -dates -serial -noout -in ICZ-Issuing-CA-1.crt subject= /C=CZ/O=ICZ a.s./CN=ICZ Issuing CA notBefore=Oct 15 11:06:03 2010 GMT notAfter=Oct 15 11:16:03 2014 GMT serial=6106B6F40003 z...@bobek:/usr/share/ca-certificates/local$ I think it is legal to have subject DN the same for successive certificates. z...@bobek:~$ grep ICZ /etc/ca-certificates.conf local/ICZ-Issuing-CA.crt local/ICZ-Issuing-CA-1.crt local/ICZ-Root-CA.crt z...@bobek:~$ sudo update-ca-certificates Updating certificates in /etc/ssl/certs... 0 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d updating keystore /etc/ssl/certs/java/cacerts... done. done. According the above the old Issuing CA cert is the first now. Connection to a server with a cert issued by the new CA: z...@bobek:~$ gnutls-cli --x509cafile /etc/ssl/certs/ca-certificates.crt -p 636 foo.i.cz Processed 146 CA certificate(s). Resolving 'foo.i.cz'... Connecting to '10.0.0.2:636'... - Successfully sent 0 certificate(s) to server. - Server has requested a certificate. - Certificate type: X.509 - Got a certificate list of 2 certificates. - Certificate[0] info: - subject `C=CZ,ST=Czech Republic,L=Prague,O=ICZ a.s.,CN=foo.i.cz', issuer `C=CZ,O=ICZ a.s.,CN=ICZ Issuing CA', RSA key 2048 bits, signed using RSA-SHA, activated `2010-12-17 15:10:36 UTC', expires `2011-12-17 15:10:36 UTC', SHA-1 fingerprint `b92db94bb3386f9906c154879a2b6c6390e3a5af' - Certificate[1] info: - subject `C=CZ,O=ICZ a.s.,CN=ICZ Issuing CA', issuer `C=CZ,O=ICZ a.s.,CN=ICZ Root CA', RSA key 2048 bits, signed using RSA-SHA, activated `2010-10-15 11:06:03 UTC', expires `2014-10-15 11:16:03 UTC', SHA-1 fingerprint `b95fb82d16fe06c316465ac087b335ad3d938e99' - The hostname in the certificate matches 'foo.i.cz'. - Peer's certificate is NOT trusted - Version: TLS1.0 - Key Exchange: RSA - Cipher: ARCFOUR-128 - MAC: MD5 - Compression: NULL *** Verifying server certificate failed... Connection to a server with a cert issued by the old CA: z...@bobek:~$ gnutls-cli --x509cafile /etc/ssl/certs/ca-certificates.crt bar.i.cz Processed 146 CA certificate(s). Resolving 'bar.i.cz'... Connecting to '10.0.0.1:443'... - Ephemeral Diffie-Hellman parameters - Using prime: 1024 bits - Secret key: 1022 bits - Peer's public key: 1024 bits - Certificate type: X.509 - Got a certificate list of 4 certificates. - Certificate[0] info: - subject `C=CZ,O=ICZ a.s.,OU=Machines,CN=bar.i.cz', issuer `C=CZ,O=ICZ a.s.,CN=ICZ Issuing CA', RSA key 1024 bits, signed using RSA-SHA, activated `2010-08-16 08:59:50 UTC', expires `2011-08-16 08:59:50 UTC', SHA-1 fingerprint `5a1d9f505fdc80e46b3e6594b1eed80a3b95a523' - Certificate[1] info: - subject `C=CZ,O=ICZ a.s.,CN=ICZ Root CA', issuer `C=CZ,O=ICZ a.s.,CN=ICZ Root CA', RSA key 2048 bits, signed using RSA-SHA, activated `2007-10-16 08:06:26 UTC', expires `2014-10-16 08:15:03 UTC', SHA-1 fingerprint `ea02ef9e4bc20f822a9bd2adb4dc263749f89241' - Certificate[2] info: - subject `C=CZ,O=ICZ a.s.,CN=ICZ Issuing CA', issuer `C=CZ,O=ICZ a.s.,CN=ICZ Root CA', RSA key 2048 bits, signed using RSA-SHA, activated `2007-10-16 12:05:52 UTC', expires `2011-10-16 12:15:52 UTC', SHA-1 fingerprint `daa9c584ba23020fc9c3d266a2ba65d739e9f5f4' - Certificate[3] info: - subject `C=CZ,O=ICZ a.s.,CN=ICZ Issuing CA', issuer `C=CZ,O=ICZ a.s.,CN=ICZ Root CA', RSA key 2048 bits, signed using RSA-SHA, activated `2010-10-15 11:06:03 UTC', expires `2014-10-15 11:16:03 UTC', SHA-1 fingerprint `b95fb82d16fe06c316465ac087b335ad3d938e99' - The hostname in the certificate matches 'bar.i.cz'. - Peer's certificate is trusted - Version: TLS1.0 - Key Exchange: DHE-RSA - Cipher: AES-128-CBC - MAC: SHA1 - Compression: NULL - Handshake was completed - Simple Client Mode: Reordering Issuing CA certs, so the new CA will be the first... z...@bobek:~$ grep ICZ /etc/ca-certificates.conf local/ICZ-Issuing-CA-1.crt local/ICZ-Issuing-CA.crt local/ICZ-Root-CA.crt z...@bobek:~$ sudo update-ca-certificates Updating certificates in /etc/ssl/certs... 0 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d updating keystore /etc/ssl/certs/java/cacerts... done. done. Connection to a
Bug#607616: libgnutls26: the GnuTLS searches CA certs by subject and stops on first? (fails on more CA with the same subj)
You cannot reorder certificates on will. For TLS/SSL the certificates have to be ordered (from RFC5246): This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Gnutls is strict with that. regards, Nikos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
