Bug#640457: [openssl] some Verisign certificates fail to verify
On Friday 14 October 2011 07:28:00 Kyle Moffett wrote: So chain-0 can be verified by chain-1 and chain-1 can be verified by the system installed CAs. The problem is that VeriSign_Class_3_Public_Primary_Certification_Authority_-_G5.crt got updated in ca-certificates 20110421. And the last certificated sent by the server (chain-2) is the old version of this same certificate. $ openssl x509 -noout -subject -issuer -in /etc/ssl/certs/VeriSign_Class_3_Public_Primary_Certification_Authority_- _G5.pem 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=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 So it seems like openssl first uses the certificate that's send from the server, but then fails to verify it (as it can't find an appropriate root certificate). Instead it should ignore the sent certificate and use the one that is installed on the local system and thus trusted as root certificate. This behaviour is especially a problem for me since konqueror uses openssl to verify the certificates and there are quite some sites that deliver the old certificate in the chain. Also note that gnutls-cli --x509cafile /etc/ssl/certs/ca-certificates.crt -p 443 signin.ebay.de does verify the certificate just fine. This PHP bug-report seems basically identical: https://bugs.php.net/bug.php?id=49419 Based on my understanding of TLS and from that PHP bug-report... I'm actually pretty sure that this is not a bug. According to the TLS standard (RFC2246): certificate_list This is a sequence (chain) of X.509v3 certificates. The sender's certificate must come first in the list. Each following certificate must directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate which specifies the root certificate authority may optionally be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case. The certificates passed in the protocol must be a strict sequence. Any server sending out-of-order or bogus certificates in the chain is not complying with the TLS protocol requirements, and cannot reasonably expect to validate correctly. It's entirely possible that some implementations are much more lenient than others, but the standard itself seems very obvious as to the requirement. As far as I can tell, OpenSSL implements a very safe default for SSL certificate chain construction and requires the application to implement a more advanced model if desired. This is basically a server configuration problem, and at best this should be a feature request against konqueror to better handle broken server configurations. Please note that GnuTLS has historically been missing a number of the stricter checks that OpenSSL provides by default, and that those tend to get added to GnuTLS when their absence is identified. For example, OpenSSL has always checked certificate validity times by default, but prior to CVE-2009-1417, the GnuTLS library relied upon the application to perform those checks (and most did not). Let me know if you want me to reassign this bug to konqueror or close it as wontfix. Cheers, Kyle Moffett Hello Kyle, thanks for your detailed explanation. So this seems to be a Konqueror bug, perhaps even an upstream KDE bug. On the other hand this might also be a ca-certificates bug, since it doesn't ship the old Verisign root certificate anymore, but without that certificate openssl will fail to verify any chain that uses it (and it seems to be wildly used). I'm not really sure if it's a Konqueror or a ca-certificates bug, so feel free to reassign it to whatever you think fits best, perhaps Konqueror, as you did suggest in your last mail. I'm wondering how many other programs that use openssl experience the same problem. Greetings and thanks for you work, Maxi signature.asc Description: This is a digitally signed message part.
Bug#640457: [openssl] some Verisign certificates fail to verify
reassign 640457 konqueror thanks On Sun, Oct 16, 2011 at 11:54, Maximilian Engelhardt m...@daemonizer.de wrote: On Friday 14 October 2011 07:28:00 Kyle Moffett wrote: So chain-0 can be verified by chain-1 and chain-1 can be verified by the system installed CAs. The problem is that VeriSign_Class_3_Public_Primary_Certification_Authority_-_G5.crt got updated in ca-certificates 20110421. And the last certificated sent by the server (chain-2) is the old version of this same certificate. $ openssl x509 -noout -subject -issuer -in /etc/ssl/certs/VeriSign_Class_3_Public_Primary_Certification_Authority_- _G5.pem 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=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 So it seems like openssl first uses the certificate that's send from the server, but then fails to verify it (as it can't find an appropriate root certificate). Instead it should ignore the sent certificate and use the one that is installed on the local system and thus trusted as root certificate. This behaviour is especially a problem for me since konqueror uses openssl to verify the certificates and there are quite some sites that deliver the old certificate in the chain. Also note that gnutls-cli --x509cafile /etc/ssl/certs/ca-certificates.crt -p 443 signin.ebay.de does verify the certificate just fine. This PHP bug-report seems basically identical: https://bugs.php.net/bug.php?id=49419 Based on my understanding of TLS and from that PHP bug-report... I'm actually pretty sure that this is not a bug. According to the TLS standard (RFC2246): certificate_list This is a sequence (chain) of X.509v3 certificates. The sender's certificate must come first in the list. Each following certificate must directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate which specifies the root certificate authority may optionally be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case. The certificates passed in the protocol must be a strict sequence. Any server sending out-of-order or bogus certificates in the chain is not complying with the TLS protocol requirements, and cannot reasonably expect to validate correctly. It's entirely possible that some implementations are much more lenient than others, but the standard itself seems very obvious as to the requirement. As far as I can tell, OpenSSL implements a very safe default for SSL certificate chain construction and requires the application to implement a more advanced model if desired. This is basically a server configuration problem, and at best this should be a feature request against konqueror to better handle broken server configurations. Please note that GnuTLS has historically been missing a number of the stricter checks that OpenSSL provides by default, and that those tend to get added to GnuTLS when their absence is identified. For example, OpenSSL has always checked certificate validity times by default, but prior to CVE-2009-1417, the GnuTLS library relied upon the application to perform those checks (and most did not). Let me know if you want me to reassign this bug to konqueror or close it as wontfix. Hello Kyle, thanks for your detailed explanation. So this seems to be a Konqueror bug, perhaps even an upstream KDE bug. On the other hand this might also be a ca-certificates bug, since it doesn't ship the old Verisign root certificate anymore, but without that certificate openssl will fail to verify any chain that uses it (and it seems to be wildly used). No, ca-certificates still ships the old Verisign root certificate. What changed is that the website you were accessing upgraded from their old certificate (issued with the old Verisign root) to a new one (issued by the new Verisign root), but they did not fix their certificate chain file to match. I'm not really sure if it's a Konqueror or a ca-certificates bug, so feel free to reassign it to whatever you think fits best, perhaps Konqueror, as you did suggest in your last mail. I have reassigned this bug to konqueror. I'm wondering how many other programs that use openssl experience the same problem. This is an extremely common error among website operators, as most of the TLS implementations don't actually have very good diagnostics for identifying and fixing the issue. I have had this exact same issue myself with SMTP TLS, and the fix involved a configuration change on the server. In this case, it is very
Bug#640457: [openssl] some Verisign certificates fail to verify
So chain-0 can be verified by chain-1 and chain-1 can be verified by the system installed CAs. The problem is that VeriSign_Class_3_Public_Primary_Certification_Authority_-_G5.crt got updated in ca-certificates 20110421. And the last certificated sent by the server (chain-2) is the old version of this same certificate. $ openssl x509 -noout -subject -issuer -in /etc/ssl/certs/VeriSign_Class_3_Public_Primary_Certification_Authority_- _G5.pem 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=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 So it seems like openssl first uses the certificate that's send from the server, but then fails to verify it (as it can't find an appropriate root certificate). Instead it should ignore the sent certificate and use the one that is installed on the local system and thus trusted as root certificate. This behaviour is especially a problem for me since konqueror uses openssl to verify the certificates and there are quite some sites that deliver the old certificate in the chain. Also note that gnutls-cli --x509cafile /etc/ssl/certs/ca-certificates.crt -p 443 signin.ebay.de does verify the certificate just fine. This PHP bug-report seems basically identical: https://bugs.php.net/bug.php?id=49419 Based on my understanding of TLS and from that PHP bug-report... I'm actually pretty sure that this is not a bug. According to the TLS standard (RFC2246): certificate_list This is a sequence (chain) of X.509v3 certificates. The sender's certificate must come first in the list. Each following certificate must directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate which specifies the root certificate authority may optionally be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case. The certificates passed in the protocol must be a strict sequence. Any server sending out-of-order or bogus certificates in the chain is not complying with the TLS protocol requirements, and cannot reasonably expect to validate correctly. It's entirely possible that some implementations are much more lenient than others, but the standard itself seems very obvious as to the requirement. As far as I can tell, OpenSSL implements a very safe default for SSL certificate chain construction and requires the application to implement a more advanced model if desired. This is basically a server configuration problem, and at best this should be a feature request against konqueror to better handle broken server configurations. Please note that GnuTLS has historically been missing a number of the stricter checks that OpenSSL provides by default, and that those tend to get added to GnuTLS when their absence is identified. For example, OpenSSL has always checked certificate validity times by default, but prior to CVE-2009-1417, the GnuTLS library relied upon the application to perform those checks (and most did not). Let me know if you want me to reassign this bug to konqueror or close it as wontfix. Cheers, Kyle Moffett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640457: [openssl] some VeriSign certificates fail to verify
Package: openssl Version: 1.0.0d-3 Severity: important Hello, I'm having problems verifying some VeriSign certificates. As far as I traced this back I think this is a problem with openssl. But if you think this bug should be fixed elsewhere feel free to reassign the report. Here is a detailed description about the problem. I'm using signin.ebay.de as an example, but many other sites are also affected by this. $ openssl s_client -host signin.ebay.de -port 443 -CApath /etc/ssl/certs/ - showcerts CONNECTED(0003) depth=2 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 verify error:num=20:unable to get local issuer certificate verify return:0 --- Certificate chain 0 s:/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/businessCategory=Private Organization/serialNumber=2871352/C=US/postalCode=95125/ST=California/L=San Jose/street=2145 Hamilton Ave/O=eBay Inc./OU=Site Operations/CN=signin.ebay.com i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL CA -BEGIN CERTIFICATE- MIIIXjCCB0agAwIBAgIQPqLLa6xb3tYmpa6m2RTjDDANBgkqhkiG9w0BAQUFADCB ujELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNjE0MDIGA1UEAxMr VmVyaVNpZ24gQ2xhc3MgMyBFeHRlbmRlZCBWYWxpZGF0aW9uIFNTTCBDQTAeFw0x MTAxMTkwMDAwMDBaFw0xMzAxMjMyMzU5NTlaMIIBCjETMBEGCysGAQQBgjc8AgED EwJVUzEZMBcGCysGAQQBgjc8AgECEwhEZWxhd2FyZTEdMBsGA1UEDxMUUHJpdmF0 ZSBPcmdhbml6YXRpb24xEDAOBgNVBAUTBzI4NzEzNTIxCzAJBgNVBAYTAlVTMQ4w DAYDVQQRFAU5NTEyNTETMBEGA1UECBMKQ2FsaWZvcm5pYTERMA8GA1UEBxQIU2Fu IEpvc2UxGjAYBgNVBAkUETIxNDUgSGFtaWx0b24gQXZlMRIwEAYDVQQKFAllQmF5 IEluYy4xGDAWBgNVBAsUD1NpdGUgT3BlcmF0aW9uczEYMBYGA1UEAxQPc2lnbmlu LmViYXkuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3fF7qsUm ltnVU395Tlg8wEMITNv3X1hCXr4Engs3DLnta2LzDH2HR2hkAZhs7QwFADlCZ0/I 6LLQ6HChhF91HcrL3fbM9eQphBMrQ5QhqKqDZa2YMR2VJy3OaxqHjTlrgseES2CJ B0DJoQ31NxEpj4dETfkK2fDHhvFYj//RyneIFIkvaw0F2hOBYbKWBfMx0uK/VX9/ 4LYKQw6xBp/2T9MSXU0jP1pqwrtg8c0l6vB9ijF/SY5pLZZOYMmJ7QLpSRIflqLs P4Voz1c4RDmyhm/RS421SaUzlarPeMnof1HoTsO/hUXow0vhfYt4OklKV3T6gcZ2 +DR2jnUL6QjRdwIDAQABo4IECzCCBAcwggIUBgNVHREEggILMIICB4IPc2lnbmlu LmViYXkuY29tgg5zaWduaW4uZWJheS5hdIIOc2lnbmluLmViYXkuYmWCDnNpZ25p bi5lYmF5LmNhgg5zaWduaW4uZWJheS5jaIIOc2lnbmluLmViYXkuZGWCDnNpZ25p bi5lYmF5LmVzgg5zaWduaW4uZWJheS5mcoIOc2lnbmluLmViYXkuaWWCDnNpZ25p bi5lYmF5Lmlugg5zaWduaW4uZWJheS5pdIIOc2lnbmluLmViYXkubmyCDnNpZ25p bi5lYmF5LnBogg5zaWduaW4uZWJheS5wbIIRc2lnbmluLmViYXkuY28udWuCEnNp Z25pbi5lYmF5LmNvbS5hdYISc2lnbmluLmViYXkuY29tLmhrghJzaWduaW4uZWJh eS5jb20ubXmCEnNpZ25pbi5lYmF5LmNvbS5zZ4ITc2lnbmluLmJlZnIuZWJheS5i ZYITc2lnbmluLmJlbmwuZWJheS5iZYITc2lnbmluLmNhZnIuZWJheS5jYYIXc2ln bmluLmV4cHJlc3MuZWJheS5jb22CFHNpZ25pbi5oYWxmLmViYXkuY29tghxzaWdu aW4ubGl2ZWF1Y3Rpb25zLmViYXkuY29tghhzaWduaW4uc2hvcHBpbmcuZWJheS5j b22CG3NpZ25pbi53b3JsZG9mZ29vZC5lYmF5LmNvbTAJBgNVHRMEAjAAMB0GA1Ud DgQWBBTgXmYC0gjb9HFTji+RYF/OtcPJWTALBgNVHQ8EBAMCBaAwQgYDVR0fBDsw OTA3oDWgM4YxaHR0cDovL0VWU2VjdXJlLWNybC52ZXJpc2lnbi5jb20vRVZTZWN1 cmUyMDA2LmNybDBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcGMCowKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwHQYDVR0lBBYwFAYIKwYB BQUHAwEGCCsGAQUFBwMCMB8GA1UdIwQYMBaAFPyKULqeuSVae1WFT5UAY4/pWGtD MHwGCCsGAQUFBwEBBHAwbjAtBggrBgEFBQcwAYYhaHR0cDovL0VWU2VjdXJlLW9j c3AudmVyaXNpZ24uY29tMD0GCCsGAQUFBzAChjFodHRwOi8vRVZTZWN1cmUtYWlh LnZlcmlzaWduLmNvbS9FVlNlY3VyZTIwMDYuY2VyMG4GCCsGAQUFBwEMBGIwYKFe oFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4myms SweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAN BgkqhkiG9w0BAQUFAAOCAQEAOEmD2bGiV4C0ba2GKakTphtGPA7uIVn6b0TeSUIF 6YHzzNlxU/yxumI1ghdmqaLUARvLVdNoEk4m7HoWLEDRVTJO6/BDGUK4I06c8u20 F2oW7qJCSgQbtyg62n/NeSmN4zMJo8JLTXfyIeZ6kjRj1SdKupyI/DnQVWaQNBv7 4IMelo0yQNeeNEF4/INZxaLdc6o1x8A0FOvKaM+16MrnJSsNXO0sioufC22zRIPw o6rJ7sQx6ZhEefUgxBCgSJcpBkUUP6II0a/cQzMP5OUXkcKTnfoYAqSQmKRVSKCR CqXkeyEODiBRQyvG2jsFFpYWKSQlLR08qs1usFHkx363Cw== -END CERTIFICATE- 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL CA i:/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 -BEGIN CERTIFICATE- MIIF5DCCBMygAwIBAgIQW3dZxheE4V7HJ8AylSkoazANBgkqhkiG9w0BAQUFADCB yjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJp U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW ZXJpU2lnbiBDbGFzcyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IC0gRzUwHhcNMDYxMTA4MDAwMDAwWhcNMTYxMTA3MjM1OTU5WjCBujEL
