Bug 884305

Summary: Openssl connect accepts untrusted certificate
Product: [Fedora] Fedora Reporter: Andrei Mituca <a.mituca>
Component: opensslAssignee: Tomas Mraz <tmraz>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17CC: a.mituca, holz, tmraz
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-08-01 18:10:12 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Andrei Mituca 2012-12-05 21:32:36 UTC
Description of problem:
running the command "openssl s_client -connect twitter.com:443" will in produce an "Verify return code: 0 (ok)" while the twitter certificate is untrusted. Providing the option -CAfile together with an empty file will still show no error.

Copying the intermediate (twitter) certificate to a file named "twitter" and running "openssl verify twitter" will display the error "error 20 at 0 depth lookup:unable to get local issuer certificate"

Version-Release number of selected component (if applicable):
OpenSSL: OpenSSL 1.0.0j-fips 10 May 2012
OS: Fedora release 17 (Beefy Miracle)

How reproducible:
run "openssl s_client -connect twitter.com:443"

Steps to Reproduce:
1.
2.
3.
  
Actual results:
openssl s_client -connect twitter.com:443
CONNECTED(00000003)
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 return:1
depth=1 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
verify return:1
depth=0 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 = 4337446, C = US, postalCode = 94107, ST = California, L = San Francisco, street = "795 Folsom St, Suite 600", O = "Twitter, Inc.", OU = Twitter Security, CN = twitter.com
verify return:1
---
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=4337446/C=US/postalCode=94107/ST=California/L=San Francisco/street=795 Folsom St, Suite 600/O=Twitter, Inc./OU=Twitter Security/CN=twitter.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
 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
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGfDCCBWSgAwIBAgIQHiLHN6ORXj+rZcS1pByuRjANBgkqhkiG9w0BAQUFADCB
ujELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNjE0MDIGA1UEAxMr
VmVyaVNpZ24gQ2xhc3MgMyBFeHRlbmRlZCBWYWxpZGF0aW9uIFNTTCBDQTAeFw0x
MjA0MTAwMDAwMDBaFw0xNDA1MTAyMzU5NTlaMIIBFzETMBEGCysGAQQBgjc8AgED
EwJVUzEZMBcGCysGAQQBgjc8AgECEwhEZWxhd2FyZTEdMBsGA1UEDxMUUHJpdmF0
ZSBPcmdhbml6YXRpb24xEDAOBgNVBAUTBzQzMzc0NDYxCzAJBgNVBAYTAlVTMQ4w
DAYDVQQRFAU5NDEwNzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxQNU2Fu
IEZyYW5jaXNjbzEhMB8GA1UECRQYNzk1IEZvbHNvbSBTdCwgU3VpdGUgNjAwMRYw
FAYDVQQKFA1Ud2l0dGVyLCBJbmMuMRkwFwYDVQQLFBBUd2l0dGVyIFNlY3VyaXR5
MRQwEgYDVQQDFAt0d2l0dGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAL7pd7TChZF0U21aCfxUIzdUHm4siWxcQ678xRerDI2hXmThiUyVKnHS
CeSB+gDBXG4qoRHSEcwq7J1YhFscsKz6o4ktsWLqVowGSWNbW92ZbtjOGkTD3xdp
O8Fqfgcs5Lq1yK517nrbtEp6OXEWcoWv15voP4wV7Z9HjCP6v5N1MmrPN187wDMH
W1meJqxQ/7LiULgVQMVV/U6qLOhUeNpl/06CqxScU1bfnbep5SohUG+z6d8CUaPX
55EhGtAPzXNJAHDSkiNgSKkPr1USJ9YiXusqmjcPChRfkT77kROjWnxgV+oucF+T
ja+Ist8acKy2sgCidhUyuXCWG44bIf8CAwEAAaOCAhwwggIYMCcGA1UdEQQgMB6C
D3d3dy50d2l0dGVyLmNvbYILdHdpdHRlci5jb20wCQYDVR0TBAIwADAdBgNVHQ4E
FgQUtXiQRnmvbuddQEjER8bw4CjBMYQwCwYDVR0PBAQDAgWgMEIGA1UdHwQ7MDkw
N6A1oDOGMWh0dHA6Ly9FVlNlY3VyZS1jcmwudmVyaXNpZ24uY29tL0VWU2VjdXJl
MjAwNi5jcmwwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXBjAqMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMB0GA1UdJQQWMBQGCCsGAQUF
BwMBBggrBgEFBQcDAjAfBgNVHSMEGDAWgBT8ilC6nrklWntVhU+VAGOP6VhrQzB8
BggrBgEFBQcBAQRwMG4wLQYIKwYBBQUHMAGGIWh0dHA6Ly9FVlNlY3VyZS1vY3Nw
LnZlcmlzaWduLmNvbTA9BggrBgEFBQcwAoYxaHR0cDovL0VWU2VjdXJlLWFpYS52
ZXJpc2lnbi5jb20vRVZTZWN1cmUyMDA2LmNlcjBuBggrBgEFBQcBDARiMGChXqBc
MFowWDBWFglpbWFnZS9naWYwITAfMAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsH
iyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5jb20vdnNsb2dvMS5naWYwDQYJ
KoZIhvcNAQEFBQADggEBAAqg81oADEdE+/Clm4Q43avFTkpuHkpYbu0bDvSVhoMS
n12b0CAtIgY7Sg+kI0/T0PaaDDxy6lEm8YAu/NLNvgXhIEYKxZQ7sUrKrfY+avdM
PumYGkWeQ0xEf0ZLbGCfp9DA+cwxGgZaxT0HdhLhSZOvlw3F3vWezUuriUYacRL6
AW1EzC3uU2zj6T0z2v75Xa8u6AwY6YqAoMJCyR12bc7sGkRoD0ak27DdvP56qh5N
0tjHHMI1d6IJs0TAO26/SVI7YlQXEstKHk9iJzappwZ/0HZJsepX7jIxvlxyKKGb
8MQGjSCwx8bY2PbYaLe0rkk2IjH0aMUlHW77DpNAK40=
-----END CERTIFICATE-----
subject=/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=4337446/C=US/postalCode=94107/ST=California/L=San Francisco/street=795 Folsom St, Suite 600/O=Twitter, Inc./OU=Twitter Security/CN=twitter.com
issuer=/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
---
No client certificate CA names sent
---
SSL handshake has read 3483 bytes and written 427 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-SHA
    Session-ID: 147E587AC45EA6BCB690D2B2AB6B42DF041BB8A851CF393564754E377ACA6AC8
    Session-ID-ctx: 
    Master-Key: 40B720FC8534298EB97FA1254D25FFBCC95480C4B1A98773697BDB9714ABA3F001C6640DB500FB59D58ECEDD41C69695
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    TLS session ticket lifetime hint: 14400 (seconds)
    TLS session ticket:
    0000 - af af 6b 03 32 8b fb 09-6d 71 d7 96 c1 77 33 0a   ..k.2...mq...w3.
    0010 - 81 25 4d 7b 34 b4 1f 16-3e ca a5 ea 1c 40 eb 44   .%M{4...>....@.D
    0020 - 72 cd ea 9b c2 b5 07 60-cd 54 58 ac fb e5 61 df   r......`.TX...a.
    0030 - 13 aa bf 37 cc 65 e5 1e-3a 26 64 25 84 c1 42 1f   ...7.e..:&d%..B.
    0040 - b6 5f 44 f9 b0 52 cc 78-e5 13 c4 a9 1f fd 97 e9   ._D..R.x........
    0050 - 9d 27 1b a5 46 b4 5f c5-b7 7a 54 6b 6d 7e fa c9   .'..F._..zTkm~..
    0060 - 01 12 b6 41 13 cc 3b bd-0b e1 ee c9 aa a1 b9 e5   ...A..;.........
    0070 - 41 5f 80 77 22 ff dc e3-51 cb 9c 08 c3 84 c0 39   A_.w"...Q......9
    0080 - ed b5 a9 0a 38 84 bb 2b-d7 e6 a4 67 00 14 f2 b4   ....8..+...g....
    0090 - e9 1e d6 7b f1 2a b3 ec-1b 5a 89 9a 50 fd 37 5b   ...{.*...Z..P.7[

    Start Time: 1354718783
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
closed

Expected results:
an error that the intermediate certificate is not trusted.

Additional info:
output of openssl verify on intermediate certificate:
twitter: 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 = 4337446, C = US, postalCode = 94107, ST = California, L = San Francisco, street = "795 Folsom St, Suite 600", O = "Twitter, Inc.", OU = Twitter Security, CN = twitter.com
error 20 at 0 depth lookup:unable to get local issuer certificate

Comment 1 Tomas Mraz 2012-12-05 22:06:31 UTC
This is not a bug. The intermediate certificates are sent by the server and are verified by chain that ends on the primary certificate that is trusted. In the openssl verify call you provide just the server certificate and the intermediate certificates are missing.

Comment 2 Ralph Holz 2012-12-05 22:33:07 UTC
I would like to chime in here. The reporter issues the command

openssl s_client -connect twitter.com:443

*without* using -CAfile to indicate trusted root certs.

So to which root certificate does Fedora's version of openssl chain up? Do you chain to a default root store shipped with Fedora?

Because on an Ubuntu, the reporter is absolutely correct in stating that openssl returns:

Verify return code: 20 (unable to get local issuer certificate)

IMO this is the correct and expected behaviour as openssl has no clue how to complete the cert chain nor is it able to identify a root cert as trusted. The error code reflects exactly that.

So, before we ultimately close this bug, can you please at least state if openssl on Fedora behaves differently than on Ubuntu in that it assumes a default root store shipped with the OS?

Thanks!

Comment 3 Tomas Mraz 2012-12-05 22:38:12 UTC
I misunderstood the report, yes you're right that this is bug - if -CAfile or -CApath is explicitly specified, the default ca bundle should not be loaded.

Comment 4 Ralph Holz 2012-12-05 22:43:38 UTC
OK. Thanks for the quick reply, much appreciated!

Comment 5 Tomas Mraz 2012-12-14 09:03:11 UTC
Fixed on Rawhide in openssl-1.0.1c-10.fc19.

Comment 6 Fedora End Of Life 2013-07-04 06:35:03 UTC
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 7 Fedora End Of Life 2013-08-01 18:10:18 UTC
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.