Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I am quite new to running my own mail server but I feel like I did a good job setting it up. It receives mail fluently but sending mail causes some issues.
tail -f /var/log/mail.log
SSL_accept error from 5354D677.cm-6-5d.dynamic.ziggo.nl
And:
openssl s_client -connect mail.challenge-all.com:587 -debug
result: SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:749
Thunderbird mail client (on send mail) (translated freely from dutch to english):
Sending of the message failed. Message can not be sent via
SMTP-server smtp.challenge-all.com for an unknown reason.
I would be quite willing to supply more information, if you guys would be so kind to assist this eager but green mail server owner/maintainer :-)
Additional info edit:
I am using a setup of postfix/dovecot with spamassassin and clamav
I got my signed certs from startssl.com and https://www.startssl.com/ did chain with their intermediate CA
Sending of the message failed. Message can not be sent via
SMTP-server smtp.challenge-all.com for an unknown reason.
According to nslookup (below), your mail server is mail.challenge-all.com, not smtp.challenge-all.com.
openssl s_client -connect mail.challenge-all.com:587 -debug
result: SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:749
Here's what I am seeing (below). The chain verifies OK when using ca-pem from Index of Certs, dated 07-May-2008 03:49.
It looks like you are using Client Certificates. I've never configured mail to use client certs, so I probably cannot help any further.
I'm also suspicious that you would trust all certificates from the CA Zoo (rather than just your organization's PKI). That might be a configuration issue. Is this a Microsoft server? Didn't Microsoft servers start sending them due to a recent patch? See SSL/TLS communication problems after you install KB 931125.
Finally, TÜRKTRUST (CN=T\xC3\x9CRKTRUST Elektronik Sertifika...) should probably not be trusted. They (or one of the subs) were caught issuing certificates for domains like google.com. See Deal with TURKTRUST mis-issued certificates. I think they were also certifying public keys that were too small (like 512-bits).
$ nslookup
> set q=MX
> challenge-all.com
Server: 172.16.1.10
Address: 172.16.1.10#53
Non-authoritative answer:
challenge-all.com mail exchanger = 10 mail.challenge-all.com.
Authoritative answers can be found from:
mail.challenge-all.com internet address = 128.204.195.123
$ openssl s_client -starttls smtp -connect mail.challenge-all.com:587 -CAfile startcom-ca.pem -showcerts
CONNECTED(00000003)
depth=2 C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN = StartCom Certification Authority
verify return:1
depth=1 C = IL, O = StartCom Ltd., OU = Secure Digital Certificate Signing, CN = StartCom Class 1 Primary Intermediate Server CA
verify return:1
depth=0 C = NL, CN = mail.challenge-all.com, emailAddress = djvanderburgt#gmail.com
verify return:1
---
Certificate chain
0 s:/C=NL/CN=mail.challenge-all.com/emailAddress=djvanderburgt#gmail.com
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
-----BEGIN CERTIFICATE-----
MIIHUDCCBjigAwIBAgIDD/esMA0GCSqGSIb3DQEBCwUAMIGMMQswCQYDVQQGEwJJ
TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0
YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3Mg
MSBQcmltYXJ5IEludGVybWVkaWF0ZSBTZXJ2ZXIgQ0EwHhcNMTQwNDE5MDI0NzAz
WhcNMTUwNDE5MjIyNDUyWjBWMQswCQYDVQQGEwJOTDEfMB0GA1UEAxMWbWFpbC5j
aGFsbGVuZ2UtYWxsLmNvbTEmMCQGCSqGSIb3DQEJARYXZGp2YW5kZXJidXJndEBn
bWFpbC5jb20wggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDc8S5wGeRa
YOAF82w+0pEVzSmlIBT46UdQ5IYDeTfzPK0RCnOHtiZR++/yVMl+qb1D1sQryldt
O4MEtwvzUrWwzlOHKmmURCRebe08Wll1c9D0zvWHko6/BpyX+jebKXZMUIGqbNk4
2yG0BhbaQv/3s1eG8UoB9KZ150kF9bJ2j3KG73SlcpKavlA9070mDn+8+KLfVlKK
pqNMnjyVd9iVj1ItaaPmXnRuSdz2wNjrV69zCey9bU1+oR9hxDFYdC91L3PyZs8h
an+dPbil4zO0D/WwcvIDvD7Cs/85z+zXXJJhodukVPJ78hSg32Z/ILTHFeLk+nDW
+cbrkX3XbimWOhEXexCz9QgzN/MmjFNgyVIQc7xygd6D13YccoV1+vHPercjk9OB
1z0E4jUqBiNDbQ/naAMBBPyUGmXop1rTrad10z7yL+fFbHrVLYPAb8oju9XzQ0dM
l+z81UybyiBXvd/kCb2ynVfgUTX/IzsIGL56aqr/MeU3XXfUFGt4znBHlMBbV4cv
Jru1kZECf2rwXzqfYNQNHrxnbL4cj4gx5MwdL+mOWZLNhH0pYGKrUb60CLZe1JoI
qptXr4qjY97wAsF4wCHtXH/X9dhW/Ogts+k5+UFLURlIHR7M+BlMTYPzZ7XM185C
Msuq/n6J5WyN5Dpnyhe+gMaRWClU3Mf8FwIDAQABo4IC7jCCAuowCQYDVR0TBAIw
ADALBgNVHQ8EBAMCA6gwEwYDVR0lBAwwCgYIKwYBBQUHAwEwHQYDVR0OBBYEFMGq
djcHTBtMwTZkCWzcwEDHVN5BMB8GA1UdIwQYMBaAFOtCNNCYsKuf9BtrCPfMZC7v
DixFMDQGA1UdEQQtMCuCFm1haWwuY2hhbGxlbmdlLWFsbC5jb22CEWNoYWxsZW5n
ZS1hbGwuY29tMIIBVgYDVR0gBIIBTTCCAUkwCAYGZ4EMAQIBMIIBOwYLKwYBBAGB
tTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9w
b2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0
aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVk
IGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50
cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0
aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA1BgNVHR8ELjAsMCqgKKAmhiRodHRwOi8vY3Js
LnN0YXJ0c3NsLmNvbS9jcnQxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYI
KwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL3Nl
cnZlci9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy
dHMvc3ViLmNsYXNzMS5zZXJ2ZXIuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQsFAAOCAQEAmEeeY7cRqAtfmTGI
jHHJMxPsn+6GQz1r4exOXGwSVCQuiphWPVn6ABunV0Oee3vG037rSYb1NtDN1sFf
UD/5JslEglo/skm0nt082FMCwlpUcEYILy074Dz2f7/Pov4nK3m844fY0qmu5nxB
+xVE9GLs1/V7SPgiZZqPSZMhoLZGcPbc+TgarNZ9JzYYHe9+Mj13LL0b1sBA/XqW
09yVntPVnnysxilr/WwDVfIQ5ItoF3zeAn808FhsM3pLVbyndjXQB64GzceNXCVt
cFpGz0Q0AP4Xd5vvBMTmMSDMzAmMC8Tt1xiY2pA7UOT2qJN0eFvMQ8EPiBNJIBiN
z55IyQ==
-----END CERTIFICATE-----
1 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
-----BEGIN CERTIFICATE-----
MIIGNDCCBBygAwIBAgIBGDANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEW
MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg
Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjA1NDE3WhcNMTcxMDI0MjA1NDE3WjCB
jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT
IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0
YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgU2VydmVyIENBMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtonGrO8JUngHrJJj0PREGBiE
gFYfka7hh/oyULTTRwbw5gdfcA4Q9x3AzhA2NIVaD5Ksg8asWFI/ujjo/OenJOJA
pgh2wJJuniptTT9uYSAK21ne0n1jsz5G/vohURjXzTCm7QduO3CHtPn66+6CPAVv
kvek3AowHpNz/gfK11+AnSJYUq4G2ouHI2mw5CrY6oPSvfNx23BaKA+vWjhwRRI/
ME3NO68X5Q/LoKldSKqxYVDLNM08XMML6BDAjJvwAwNi/rJsPnIO7hxDKslIDlc5
xDEhyBDBLIf+VJVSH1I8MRKbf+fAoKVZ1eKPPvDVqOHXcDGpxLPPr21TLwb0pwID
AQABo4IBrTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYD
VR0OBBYEFOtCNNCYsKuf9BtrCPfMZC7vDixFMB8GA1UdIwQYMBaAFE4L7xqkQFul
F2mHMMo0aEPQQa7yMGYGCCsGAQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDov
L29jc3Auc3RhcnRzc2wuY29tL2NhMC0GCCsGAQUFBzAChiFodHRwOi8vd3d3LnN0
YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQwUjAnoCWgI4YhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0
c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcBAgEwZjAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0
BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRl
LnBkZjANBgkqhkiG9w0BAQUFAAOCAgEAIQlJPqWIbuALi0jaMU2P91ZXouHTYlfp
tVbzhUV1O+VQHwSL5qBaPucAroXQ+/8gA2TLrQLhxpFy+KNN1t7ozD+hiqLjfDen
xk+PNdb01m4Ge90h2c9W/8swIkn+iQTzheWq8ecf6HWQTd35RvdCNPdFWAwRDYSw
xtpdPvkBnufh2lWVvnQce/xNFE+sflVHfXv0pQ1JHpXo9xLBzP92piVH0PN1Nb6X
t1gW66pceG/sUzCv6gRNzKkC4/C2BBL2MLERPZBOVmTX3DxDX3M570uvh+v2/miI
RHLq0gfGabDBoYvvF0nXYbFFSF87ICHpW7LM9NfpMfULFWE7epTj69m8f5SuauNi
YpaoZHy4h/OZMn6SolK+u/hlz8nyMPyLwcKmltdfieFcNID1j0cHL7SRv7Gifl9L
WtBbnySGBVFaaQNlQ0lxxeBvlDRr9hvYqbBMflPrj0jfyjO1SPo2ShpTpjMM0InN
SRXNiTE8kMBy12VLUjWKRhFEuT2OKGWmPnmeXAhEKa2wNREuIU640ucQPl2Eg7PD
wuTSxv0JS3QJ3fGz0xk+gA2iCxnwOOfFwq/iI9th4p1cbiCJSS4jarJiwUW0n6+L
p/EiO/h94pDQehn7Skzj0n1fSoMD7SfWI55rjbRZotnvbIIp3XUZPD9MEI3vu3Un
0q6Dp6jOW6c=
-----END CERTIFICATE-----
---
Server certificate
subject=/C=NL/CN=mail.challenge-all.com/emailAddress=djvanderburgt#gmail.com
issuer=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
---
Acceptable client certificate CA names
/C=AT/O=A-Trust Ges. f. Sicherheitssysteme im elektr. Datenverkehr GmbH/OU=A-Trust-nQual-03/CN=A-Trust-nQual-03
/CN=ACEDICOM Root/OU=PKI/O=EDICOM/C=ES
/C=CO/O=Sociedad Cameral de Certificaci\xC3\xB3n Digital - Certic\xC3\xA1mara S.A./CN=AC Ra\xC3\xADz Certic\xC3\xA1mara S.A.
/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
/C=SE/O=AddTrust AB/OU=AddTrust TTP Network/CN=AddTrust Class 1 CA Root
/C=SE/O=AddTrust AB/OU=AddTrust TTP Network/CN=AddTrust Public CA Root
/C=SE/O=AddTrust AB/OU=AddTrust TTP Network/CN=AddTrust Qualified CA Root
/C=US/O=AffirmTrust/CN=AffirmTrust Commercial
/C=US/O=AffirmTrust/CN=AffirmTrust Networking
/C=US/O=AffirmTrust/CN=AffirmTrust Premium
/C=US/O=AffirmTrust/CN=AffirmTrust Premium ECC
/C=US/O=America Online Inc./CN=America Online Root Certification Authority 1
/C=US/O=America Online Inc./CN=America Online Root Certification Authority 2
/C=JP/O=Japanese Government/OU=ApplicationCA
/C=ES/CN=Autoridad de Certificacion Firmaprofesional CIF A62634068
/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root
/C=NO/O=Buypass AS-983163327/CN=Buypass Class 2 CA 1
/C=NO/O=Buypass AS-983163327/CN=Buypass Class 3 CA 1
/C=SK/L=Bratislava/O=Disig a.s./CN=CA Disig
/C=CN/O=CNNIC/CN=CNNIC ROOT
/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO Certification Authority
/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO ECC Certification Authority
/C=EU/O=AC Camerfirma SA CIF A82743287/OU=http://www.chambersign.org/CN=Chambers of Commerce Root
/C=EU/O=AC Camerfirma SA CIF A82743287/OU=http://www.chambersign.org/CN=Global Chambersign Root
/C=FR/O=Dhimyotis/CN=Certigna
/C=FR/O=Certinomis/OU=0002 433998903/CN=Certinomis - Autorit\xC3\xA9 Racine
/C=FR/O=Certplus/CN=Class 2 Primary CA
/C=PL/O=Unizeto Sp. z o.o./CN=Certum CA
/C=PL/O=Unizeto Technologies S.A./OU=Certum Certification Authority/CN=Certum Trusted Network CA
/C=EU/L=Madrid (see current address at www.camerfirma.com/address)/serialNumber=A82743287/O=AC Camerfirma S.A./CN=Chambers of Commerce Root - 2008
/CN=ComSign CA/O=ComSign/C=IL
/CN=ComSign Secured CA/O=ComSign/C=IL
/C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=AAA Certificate Services
/C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=Secure Certificate Services
/C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CN=Trusted Certificate Services
/O=Cybertrust, Inc/CN=Cybertrust Global Root
/C=US/O=Digital Signature Trust/OU=DST ACES/CN=DST ACES CA X6
/O=Digital Signature Trust Co./CN=DST Root CA X3
/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2
/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root CA
/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
/C=US/O=Digital Signature Trust Co./OU=DSTCA E1
/C=US/O=Digital Signature Trust Co./OU=DSTCA E2
/C=TR/O=Elektronik Bilgi Guvenligi A.S./CN=e-Guven Kok Elektronik Sertifika Hizmet Saglayicisi
/CN=EBG Elektronik Sertifika Hizmet Sa\xC4\x9Flay\xC4\xB1c\xC4\xB1s\xC4\xB1/O=EBG Bili\xC5\x9Fim Teknolojileri ve Hizmetleri A.\xC5\x9E./C=TR
/O=Entrust.net/OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Certification Authority (2048)
/C=US/O=Entrust.net/OU=www.entrust.net/CPS incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Secure Server Certification Authority
/C=US/O=Entrust, Inc./OU=www.entrust.net/CPS is incorporated by reference/OU=(c) 2006 Entrust, Inc./CN=Entrust Root Certification Authority
/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
/C=US/O=Equifax Secure Inc./CN=Equifax Secure Global eBusiness CA-1
/C=US/O=Equifax Secure Inc./CN=Equifax Secure eBusiness CA-1
/C=ES/L=C/ Muntaner 244 Barcelona/CN=Autoridad de Certificacion Firmaprofesional CIF A62634068/emailAddress=ca#firmaprofesional.com
/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2
/C=US/O=GeoTrust Inc./CN=GeoTrust Primary Certification Authority
/C=US/O=GeoTrust Inc./OU=(c) 2007 GeoTrust Inc. - For authorized use only/CN=GeoTrust Primary Certification Authority - G2
/C=US/O=GeoTrust Inc./OU=(c) 2008 GeoTrust Inc. - For authorized use only/CN=GeoTrust Primary Certification Authority - G3
/C=US/O=GeoTrust Inc./CN=GeoTrust Universal CA
/C=US/O=GeoTrust Inc./CN=GeoTrust Universal CA 2
/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
/OU=GlobalSign Root CA - R3/O=GlobalSign/CN=GlobalSign
/C=EU/L=Madrid (see current address at www.camerfirma.com/address)/serialNumber=A82743287/O=AC Camerfirma S.A./CN=Global Chambersign Root - 2008
/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
/C=HK/O=Hongkong Post/CN=Hongkong Post Root CA 1
/C=FR/ST=France/L=Paris/O=PM/SGDN/OU=DCSSI/CN=IGC/A/emailAddress=igca#sgdn.pm.gouv.fr
/C=ES/O=IZENPE S.A./CN=Izenpe.com
/emailAddress=pki#sk.ee/C=EE/O=AS Sertifitseerimiskeskus/CN=Juur-SK
/C=HU/L=Budapest/O=Microsec Ltd./OU=e-Szigno CA/CN=Microsec e-Szigno Root CA
/C=HU/L=Budapest/O=Microsec Ltd./CN=Microsec e-Szigno Root CA 2009/emailAddress=info#e-szigno.hu
/C=HU/L=Budapest/O=NetLock Kft./OU=Tan\xC3\xBAs\xC3\xADtv\xC3\xA1nykiad\xC3\xB3k (Certification Services)/CN=NetLock Arany (Class Gold) F\xC5\x91tan\xC3\xBAs\xC3\xADtv\xC3\xA1ny
/C=HU/L=Budapest/O=NetLock Halozatbiztonsagi Kft./OU=Tanusitvanykiadok/CN=NetLock Uzleti (Class B) Tanusitvanykiado
/C=HU/L=Budapest/O=NetLock Halozatbiztonsagi Kft./OU=Tanusitvanykiadok/CN=NetLock Expressz (Class C) Tanusitvanykiado
/C=HU/ST=Hungary/L=Budapest/O=NetLock Halozatbiztonsagi Kft./OU=Tanusitvanykiadok/CN=NetLock Kozjegyzoi (Class A) Tanusitvanykiado
/C=HU/L=Budapest/O=NetLock Halozatbiztonsagi Kft./OU=Tanusitvanykiadok/CN=NetLock Minositett Kozjegyzoi (Class QA) Tanusitvanykiado/emailAddress=info#netlock.hu
/C=US/O=Network Solutions L.L.C./CN=Network Solutions Certificate Authority
/C=CH/O=WISeKey/OU=Copyright (c) 2005/OU=OISTE Foundation Endorsed/CN=OISTE WISeKey Global Root GA CA
/C=BM/O=QuoVadis Limited/OU=Root Certification Authority/CN=QuoVadis Root Certification Authority
/C=BM/O=QuoVadis Limited/CN=QuoVadis Root CA 2
/C=BM/O=QuoVadis Limited/CN=QuoVadis Root CA 3
/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 3 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=info#valicert.com
/O=RSA Security Inc/OU=RSA Security 2048 V3
/C=ES/O=Generalitat Valenciana/OU=PKIGVA/CN=Root CA Generalitat Valenciana
/C=DE/ST=Baden-Wuerttemberg (BW)/L=Stuttgart/O=Deutscher Sparkassen Verlag GmbH/CN=S-TRUST Authentication and Encryption Root CA 2005:PN
/C=JP/O=Japan Certification Services, Inc./CN=SecureSign RootCA11
/C=US/O=SecureTrust Corporation/CN=SecureTrust CA
/C=US/O=SecureTrust Corporation/CN=Secure Global CA
/C=JP/O=SECOM Trust Systems CO.,LTD./OU=Security Communication EV RootCA1
/C=JP/O=SECOM Trust.net/OU=Security Communication RootCA1
/C=FI/O=Sonera/CN=Sonera Class1 CA
/C=FI/O=Sonera/CN=Sonera Class2 CA
/C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden Root CA
/C=NL/O=Staat der Nederlanden/CN=Staat der Nederlanden Root CA - G2
/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority
/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Root Certificate Authority - G2
/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2
/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
/C=CH/O=SwissSign AG/CN=SwissSign Gold CA - G2
/C=CH/O=SwissSign AG/CN=SwissSign Platinum CA - G2
/C=CH/O=SwissSign AG/CN=SwissSign Silver CA - G2
/C=ch/O=Swisscom/OU=Digital Certificate Services/CN=Swisscom Root CA 1
/C=DE/O=TC TrustCenter GmbH/OU=TC TrustCenter Class 2 CA/CN=TC TrustCenter Class 2 CA II
/C=DE/O=TC TrustCenter GmbH/OU=TC TrustCenter Class 3 CA/CN=TC TrustCenter Class 3 CA II
/C=DE/O=TC TrustCenter GmbH/OU=TC TrustCenter Universal CA/CN=TC TrustCenter Universal CA I
/C=DK/O=TDC Internet/OU=TDC Internet Root CA
/C=DK/O=TDC/CN=TDC OCES CA
/CN=T\xC3\x9CRKTRUST Elektronik Sertifika Hizmet Sa\xC4\x9Flay\xC4\xB1c\xC4\xB1s\xC4\xB1/C=TR/L=ANKARA/O=(c) 2005 T\xC3\x9CRKTRUST Bilgi \xC4\xB0leti\xC5\x9Fim ve Bili\xC5\x9Fim G\xC3\xBCvenli\xC4\x9Fi Hizmetleri A.\xC5\x9E.
/CN=T\xC3\x9CRKTRUST Elektronik Sertifika Hizmet Sa\xC4\x9Flay\xC4\xB1c\xC4\xB1s\xC4\xB1/C=TR/L=Ankara/O=T\xC3\x9CRKTRUST Bilgi \xC4\xB0leti\xC5\x9Fim ve Bili\xC5\x9Fim G\xC3\xBCvenli\xC4\x9Fi Hizmetleri A.\xC5\x9E. (c) Kas\xC4\xB1m 2005
/C=TW/O=TAIWAN-CA/OU=Root CA/CN=TWCA Root Certification Authority
/C=TW/O=Government Root Certification Authority
/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailAddress=premium-server#thawte.com
/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Server CA/emailAddress=server-certs#thawte.com
/C=TR/L=Gebze - Kocaeli/O=T\xC3\xBCrkiye Bilimsel ve Teknolojik Ara\xC5\x9Ft\xC4\xB1rma Kurumu - T\xC3\x9CB\xC4\xB0TAK/OU=Ulusal Elektronik ve Kriptoloji Ara\xC5\x9Ft\xC4\xB1rma Enstit\xC3\xBCs\xC3\xBC - UEKAE/OU=Kamu Sertifikasyon Merkezi/CN=T\xC3\x9CB\xC4\xB0TAK UEKAE K\xC3\xB6k Sertifika Hizmet Sa\xC4\x9Flay\xC4\xB1c\xC4\xB1s\xC4\xB1 - S\xC3\xBCr\xC3\xBCm 3
/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN - DATACorp SGC
/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Client Authentication and Email
/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 1 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=info#valicert.com
/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=info#valicert.com
/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2007 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G4
/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
/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2008 VeriSign, Inc. - For authorized use only/CN=VeriSign Universal Root Certification Authority
/C=US/O=VeriSign, Inc./OU=Class 1 Public Primary Certification Authority
/C=US/O=VeriSign, Inc./OU=Class 1 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network
/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 1999 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 1 Public Primary Certification Authority - G3
/C=US/O=VeriSign, Inc./OU=Class 2 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network
/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 1999 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 2 Public Primary Certification Authority - G3
/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network
/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 1999 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G3
/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 1999 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 4 Public Primary Certification Authority - G3
/C=US/O=VISA/OU=Visa International Service Association/CN=Visa eCommerce Root
/C=US/O=Wells Fargo WellsSecure/OU=Wells Fargo Bank NA/CN=WellsSecure Public Root Certificate Authority
/C=US/O=Wells Fargo/OU=Wells Fargo Certification Authority/CN=Wells Fargo Root Certificate Authority
/C=US/OU=www.xrampsecurity.com/O=XRamp Security Services Inc/CN=XRamp Global Certification Authority
/C=RO/O=certSIGN/OU=certSIGN ROOT CA
/C=TW/O=Chunghwa Telecom Co., Ltd./OU=ePKI Root Certification Authority
/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA
/C=US/O=thawte, Inc./OU=(c) 2007 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA - G2
/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2008 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA - G3
/C=US/ST=Indiana/L=Indianapolis/O=Software in the Public Interest/OU=hostmaster/CN=Certificate Authority/emailAddress=hostmaster#spi-inc.org
/C=IT/L=Milan/O=Actalis S.p.A./03358520967/CN=Actalis Authentication Root CA
/C=NO/O=Buypass AS-983163327/CN=Buypass Class 2 Root CA
/C=NO/O=Buypass AS-983163327/CN=Buypass Class 3 Root CA
/C=SK/L=Bratislava/O=Disig a.s./CN=CA Disig Root R1
/C=SK/L=Bratislava/O=Disig a.s./CN=CA Disig Root R2
/C=CN/O=China Internet Network Information Center/CN=China Internet Network Information Center EV Certificates Root
/C=DE/O=D-Trust GmbH/CN=D-TRUST Root Class 3 CA 2 2009
/C=DE/O=D-Trust GmbH/CN=D-TRUST Root Class 3 CA 2 EV 2009
/C=ES/O=Agencia Catalana de Certificacio (NIF Q-0801176-I)/OU=Serveis Publics de Certificacio/OU=Vegeu https://www.catcert.net/verarrel (c)03/OU=Jerarquia Entitats de Certificacio Catalanes/CN=EC-ACC
/C=EE/O=AS Sertifitseerimiskeskus/CN=EE Certification Centre Root CA/emailAddress=pki#sk.ee
/C=GR/O=Hellenic Academic and Research Institutions Cert. Authority/CN=Hellenic Academic and Research Institutions RootCA 2011
/emailAddress=contacto#procert.net.ve/L=Chacao/ST=Miranda/OU=Proveedor de Certificados PROCERT/O=Sistema Nacional de Certificacion Electronica/C=VE/CN=PSCProcert
/C=JP/O=SECOM Trust Systems CO.,LTD./OU=Security Communication RootCA2
/C=IL/O=StartCom Ltd./CN=StartCom Certification Authority G2
/C=ch/O=Swisscom/OU=Digital Certificate Services/CN=Swisscom Root CA 2
/C=ch/O=Swisscom/OU=Digital Certificate Services/CN=Swisscom Root EV CA 2
/C=GB/O=Trustis Limited/OU=Trustis FPS Root CA
/C=DE/O=T-Systems Enterprise Services GmbH/OU=T-Systems Trust Center/CN=T-TeleSec GlobalRoot Class 3
/CN=T\xC3\x9CRKTRUST Elektronik Sertifika Hizmet Sa\xC4\x9Flay\xC4\xB1c\xC4\xB1s\xC4\xB1/C=TR/L=Ankara/O=T\xC3\x9CRKTRUST Bilgi \xC4\xB0leti\xC5\x9Fim ve Bili\xC5\x9Fim G\xC3\xBCvenli\xC4\x9Fi Hizmetleri A.\xC5\x9E. (c) Aral\xC4\xB1k 2007
---
SSL handshake has read 24299 bytes and written 690 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: A7E1172CFFA1062B7B63C09F59ED67D457609FABD002E4973503E32ACDAD0561
Session-ID-ctx:
Master-Key: AC02EFCACCF44A4ED343F99B23D049B177C2046051B16901CB7DC74A72D6C88B6286E17DC5CDDD7A949B5B38D43EEFF3
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 3600 (seconds)
TLS session ticket:
0000 - d6 3f 77 72 67 25 71 e5-18 3a 60 d2 3f 80 f3 7b .?wrg%q..:`.?..{
0010 - 97 76 d7 ad b8 5f 10 b0-2e 8b ca 60 b3 b1 a6 24 .v..._.....`...$
0020 - 80 66 77 0a 13 c1 87 67-b4 ba d6 e6 17 99 76 3c .fw....g......v<
0030 - a2 d1 5b e5 93 2c 99 43-2b d2 fb ae 0d 51 13 4c ..[..,.C+....Q.L
0040 - 83 2a 13 e3 f6 56 b4 28-74 12 05 2a 6a 61 cc 51 .*...V.(t..*ja.Q
0050 - 29 7f a5 c2 d5 a9 63 e6-62 bd 42 2d ed 5c 36 df ).....c.b.B-.\6.
0060 - eb c8 10 c5 f7 ea 48 04-a9 e2 4c 49 3c 7b 92 56 ......H...LI<{.V
0070 - 77 bc 72 6f e0 d4 85 11-dd 8b d5 35 e8 82 6e 9f w.ro.......5..n.
0080 - 0d a9 74 a5 ea 70 a8 e7-8e a0 0b 2a 8d f6 4f 22 ..t..p.....*..O"
0090 - 1d 92 f0 ad 73 13 d0 4c-85 be 5b 5a 60 28 e5 ce ....s..L..[Z`(..
Start Time: 1398160360
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
Related
ok, this familiar question, not sure what I am missing to still get the local issuer certificate as when I ran the check with openssl I got success. I was under the impression all I needed was the Global CA certificate (the openssl shows that it is all valid and acceptable)
Thanks!
running fetchmail with:
fetchmail -v -v -d 473 --syslog --nobounce --sslcertpath /home/bloggs/certs -f /home/bloggs/fetchmailrc
/home/bloggs/certs contains
lrwxrwxrwx 1 10 Aug 8 12:57 3513523f.0 -> CAROOT.pem
-rw------- 1 1338 Aug 8 08:51 CAROOT.pem
With openssl:
/usr/local/ssl/bin/openssl s_client -CApath /home/bloggs/certs -connect outlook.office365.com:995
outputs this:
CONNECTED(00000003)
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert Cloud Services CA-1
verify return:1
depth=0 C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = outlook.com
verify return:1
---
Certificate chain
0 s:/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=outlook.com
i:/C=US/O=DigiCert Inc/CN=DigiCert Cloud Services CA-1
1 s:/C=US/O=DigiCert Inc/CN=DigiCert Cloud Services CA-1
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
...snip...
etc, etc, etc
...snip...
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1533743966
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
However, Fetchmail writes this to the mail log
Old UID list from outlook.office365.com: <empty>
Scratch list of UIDs: <empty>
6.3.26 querying outlook.office365.com (protocol POP3) at Wed Aug 08 13:03:16 2018:poll started
Trying to connect to 180.163.18.8/995...connected.
Certificate chain, from root to peer, starting at depth 1:
Issuer Organization: DigiCert Inc
Issuer CommonName: DigiCert Global Root CA
Subject CommonName: DigiCert Cloud Services CA-1
Server certificate verification error: unable to get local issuer certificate
Broken certification chain at: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
This could mean that the server did not provide the intermediate CA's certificate(s), which is nothing fetchmail could do anything about. For details, please see the README.SSL-SERVER document that ships with fetchmail.
This could mean that the root CA's signing certificate is not in the trusted CA certificate location, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of --sslcertpath and --sslcertfile in the manual page.
Certificate at depth 1:
Issuer Organization: DigiCert Inc
Issuer CommonName: DigiCert Global Root CA
Subject CommonName: DigiCert Cloud Services CA-1
Server certificate verification error: certificate not trusted
Server certificate:
Issuer Organization: DigiCert Inc
Issuer CommonName: DigiCert Cloud Services CA-1
Subject CommonName: outlook.com
Subject Alternative Name: *.clo.footprintdns.com
I believe the problem was that fetchmail had been built against a differnt set of SSL library to the one I ran the openssl test with. I have rebuilt fetchmail against that same library 1.0.2n and everything works as expected:
Old UID list from outlook.office365.com: <empty>
Scratch list of UIDs: <empty>
6.3.26 querying outlook.office365.com (protocol POP3) at Sun Aug 12 14:12:56 2018: poll started
Trying to connect to 36.165.28.8/995...connected.
Certificate chain, from root to peer, starting at depth 2:
Issuer Organization: DigiCert Inc
Issuer CommonName: DigiCert Global Root CA
Subject CommonName: DigiCert Global Root CA
Certificate at depth 1:
Issuer Organization: DigiCert Inc
Issuer CommonName: DigiCert Global Root CA
Subject CommonName: DigiCert Cloud Services CA-1
Server certificate:
Issuer Organization: DigiCert Inc
Issuer CommonName: DigiCert Cloud Services CA-1
Subject CommonName: outlook.com
Subject Alternative Name: *.clo.footprintdns.com
Subject Alternative Name: *.nrb.footprintdns.com
Subject Alternative Name: *.hotmail.com
Subject Alternative Name: *.internal.outlook.com
Subject Alternative Name: *.live.com
Subject Alternative Name: *.office.com
Subject Alternative Name: *.office365.com
Subject Alternative Name: *.outlook.com
Subject Alternative Name: *.outlook.office365.com
Subject Alternative Name: attachment.outlook.live.net
Subject Alternative Name: attachment.outlook.office.net
Subject Alternative Name: attachment.outlook.officeppe.net
Subject Alternative Name: ccs.login.microsoftonline.com
Subject Alternative Name: ccs-sdf.login.microsoftonline.com
Subject Alternative Name: hotmail.com
Subject Alternative Name: mail.services.live.com
Subject Alternative Name: office365.com
Subject Alternative Name: outlook.com
Subject Alternative Name: outlook.office.com
Subject Alternative Name: substrate.office.com
Subject Alternative Name: substrate-sdf.office.com
outlook.office365.com key fingerprint: ###################################################
POP3< +OK The Microsoft Exchange POP3 service is ready. [###########################################################]
POP3> CAPA
POP3< +OK
POP3< TOP
POP3< UIDL
POP3< SASL PLAIN
POP3< USER
POP3< .
POP3> USER ########################
POP3< +OK
POP3> PASS *
POP3< +OK User successfully logged on.
selecting or re-polling default folder
POP3> STAT
POP3< +OK 0 0
No mail for ##################at outlook.office365.com
POP3> QUIT
POP3< +OK Microsoft Exchange Server POP3 server signing off.
6.3.26 querying outlook.office365.com (protocol POP3) at Sun Aug 12 14:12:58 2018: poll completed
New UID list from outlook.office365.com: <empty>
not swapping UID lists, no UIDs seen this query
Query status=1 (NOMAIL)
sleeping at Sun Aug 12 14:12:58 2018 for 473 seconds
Do you know why using a Let's Encrypt cert for TLS would result in a client failing at the SSL handshake point with error 19 (self signed cert in chain)? I am developing an app in C that uses the Mosquitto libraries to open the connection (and fails at the handshake) but to simplify this question I'm going to demonstrate the problem using the mosquitto_sub command (which we know works).
I am using Centos 6.2 with Let's Encrypt certificates for my website without any issues (because they're free, automated, and open). I now want to use the same certificate issued by Let's Encrypt to secure a TLS connection between my server and any remote client. TLS is being used for connections to the Mosquitto MQTT broker in fact, on port 8881. The mosquitto.conf file on my server contains:
...
user mosquitto
listener 8883 example.com
cafile /etc/mosquitto/certs/chain-ca.pem # These 3 from Let's Encrypt
certfile /etc/mosquitto/certs/cert.pem
keyfile /etc/mosquitto/certs/privkey.pem
require_certificate false
...
I have several network interfaces on my CentOS server and my domain, "example.com" resolves with the dig command to the IP of interface eth0:1:
[root#spiff mosquitto]# dig example.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.47.rc1.el6_8.2 <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 804
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 300 IN A 158.234.234.24
;; AUTHORITY SECTION:
example.com. 300 IN NS dns0.ns.co.uk.
example.com. 300 IN NS dns1.ns.co.uk.
;; Query time: 41 msec
;; SERVER: 151.236.220.5#535(11.226.220.5)
;; WHEN: Sun Oct 30 19:21:07 2016
;; MSG SIZE rcvd: 101
I believe this is significant because the certificate for 'example.com' that I've created with Let's Encrypt has a CN which has to resolve with DNS to the IP address of the NIC that the Mosquitto listener is bound to, otherwise from the perspective of OpenSSL I'm serving the wrong certificate to any clients.
The server doesn't have any issues on startup.
After a lot of Googling, I understand (maybe wrongly) that the client needs to be handed as a parameter the certificate of the CA (certification authority) that signed the cert for 'example.com' when it makes a connection to the server, because it will check that the CA used to sign example.com's certificate is trusted, and so we use the --cafile [certificate-authority-cert.crt] parameter to pass this. I appreciate that this is specific to TLS connections and that web clients don't use this feature.
When a client on the same Centos 6.2 server (which could be my program but to simplify things is the out-of-the-box mosquitto_sub command) connects with these parameters I see this error:
mosquitto_sub -h example.com -p 8883 -t test -u mr-user -P P#55W0rD --cafile /etc/pki/tls/certs/lets-encrypt-x3-cross-signed.pem -d
Error: A TLS error occurred
Because the Mosquitto broker is not very specific about the value of errno on a failure, I try again using the s_client feature of openSSL instead:
[root#spiff certs]# openssl s_client -connect example.com:8883 -CAfile lets-encrypt-x3-cross-signed.pem
CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
0 s:/CN=www.example.com
i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
2 s:/O=Digital Signature Trust Co./CN=DST Root CA X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFDjCCA/agAwIBAgISA12o6mO9oS364BF5UVgSAD7TMA0GCSqGSIb3DQEBCwUA
[... lines removed for brevity ...]
A+q6hf00nJJsEvGmhVzQG5zAn6ojcWgT3EhurPien7Y16+kIS5tdz9xbeCgLTOrJ
BXA=
-----END CERTIFICATE-----
subject=/CN=www.example.com
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 3999 bytes and written 373 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: E8D32590BAB26FF5811D39D775B3F455CAC3E8747866FA251DDA2032FA88E349
Session-ID-ctx:
Master-Key: 1B45DF54D11BC44D96AEAC940291B4D3BBAE56D6431E746873DC4F15DC1219F02019F4D903CAA6E8B23AF83CE291F4A6
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - d9 fb 28 9f c9 7c ba b3-26 ff dd 75 53 d1 12 65 ..(..|..&..uS..e
0010 - 91 76 91 2b f8 a2 b4 4b-0a e2 97 eb ce 8e a1 af .v.+...K........
[ ... lines ommitted for brevity ... ]
00a0 - 71 c3 a9 f3 16 c4 04 17-d1 e8 b0 75 e8 80 e9 fb q..........u....
Start Time: 1477857075
Timeout : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
---
Why does Verify think that I'm using a self-signed certificate? Is there something else that I need to do, for instance does OpenSSL check the certificate store in /etc/pki/tls for a certificate for the root authority that signed Let's Encrypt's certificate and not find it perhaps when you link in the OpenSSL libs? Is it possible that the trust store under /etc/pki doesn't know about the root authority used by Let's Encrypt already? I got lets-encrypt-x3-cross-signed.pem after reading instructions on the Let's Encrypt Chain Of Trust page, is this the wrong file completely?
Short version: I'm seeing an SSL certificate chain that's different based on how I access the https server. What's going on, and how do I verify the certificate under these circumstances?
Slightly longer version:
I'm trying to use libcurl to verify the certificate of an SSL connection. The server I'm connecting to is Amazon S3.
When I access Amazon S3 in Firefox, I get this certificate chain:
VeriSign Class 3 Public Primary Certification Authority - G5
Serial Number: 18:DA:D1:9E:26:7D:E8:BB:4A:21:58:CD:CC:6B:3B:4A
VeriSign Class 3 Secure Server CA - G3
Serial Number: 6E:CC:7A:A5:A7:03:20:09:B8:CE:BC:F4:E9:52:D4:91
*.s3.amazonaws.com
Serial Number: 43:FB:BA:C2:66:27:E0:97:1E:1C:11:E0:30:C3:6B:66
When I access the same URL via the OpenSSL command line tool, I get this certificate chain:
*.s3.amazonaws.com
Serial number: 43fbbac26627e0971e1c11e030c36b66
VeriSign Class 3 Secure Server CA - G3
Serial number: 6ecc7aa5a7032009b8cebcf4e952d491
VeriSign Class 3 Public Primary Certification Authority - G5
Serial number: 35973187f3873a07327ece580c9b7eda
The "*.s3.amazonaws.com" and "VeriSign Class 3 Secure Server CA - G3" certificates appear to be the same, but the one after that is different! It's named "VeriSign Class 3 Public Primary Certification Authority - G5" in both chains, but the certificate serial number is different. (Other information is different as well; let me know if you want a longer dump.)
I believe that this difference is the reason that I can't get libcurl to verify the SSL certificate. The certificate with serial number "18:DA:D1..." is in my CACERT.PEM file, but the certificate with serial number "35:97:31..." is not.
Obviously, the simple fix would be to add certificate "35:97:31..." to my CACERT.PEM file, but I want to make the right change here, not just a quick fix.
What does this difference in certificate chains signify?
Is it even possible for a SSL server to return different certificate chains based on the client (Firefox vs. OpenSSL/libcurl)?
How should I get libcurl to verify this SSL certificate?
Really long version and background information:
I'm using libcurl with OpenSSL to download from Amazon S3. Libcurl is returning "SSL certificate problem: unable to get local issuer certificate", which I know means that the root certificate isn't listed in my CACERT.PEM file. (I'm using the one downloaded from curl's website, which is converted from Mozilla's certificate store.) I am able to verify certificates on other SSL connections, so I know my libcurl setup is correct.
To see what was going on, and why the certificate didn't verify, I pulled up the same URL in Firefox. Firefox didn't show any SSL certificate warnings. Here's the certification path Firefox shows. The root certificate, "VeriSign Class 3 Public Primary Certification Authority - G5", is listed in my CACERT.PEM file, and the serial number of the certificate matches what's shown in the screenshot.
Here's the serial numbers of all three certificates in the chain:
VeriSign Class 3 Public Primary Certification Authority - G5
Serial Number: 18:DA:D1:9E:26:7D:E8:BB:4A:21:58:CD:CC:6B:3B:4A
VeriSign Class 3 Secure Server CA - G3
Serial Number: 6E:CC:7A:A5:A7:03:20:09:B8:CE:BC:F4:E9:52:D4:91
*.s3.amazonaws.com
Serial Number: 43:FB:BA:C2:66:27:E0:97:1E:1C:11:E0:30:C3:6B:66
On a different platform (different OS, different version of OpenSSL, etc.), I tried accessing the same URL using the OpenSSL command line tool, and I got a different certification path!
$ openssl s_client -showcerts -connect stackoverflowtest.s3.amazonaws.com:443
CONNECTED(00000003)
depth=3 C = US, O = "VeriSign, Inc.", OU = Class 3 Public Primary Certification Authority
verify return:1
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)10, CN = VeriSign Class 3 Secure Server CA - G3
verify return:1
depth=0 C = US, ST = Washington, L = Seattle, O = Amazon.com Inc., OU = S3-A, CN = *.s3.amazonaws.com
verify return:1
---
Certificate chain
0 s:/C=US/ST=Washington/L=Seattle/O=Amazon.com Inc./OU=S3-A/CN=*.s3.amazonaws.com
i:/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
-----BEGIN CERTIFICATE-----
MIIFOTCCBCGgAwIBAgIQQ/u6wmYn4JceHBHgMMNrZjANBgkqhkiG9w0BAQUFADCB
tTELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykxMDEvMC0GA1UEAxMm
VmVyaVNpZ24gQ2xhc3MgMyBTZWN1cmUgU2VydmVyIENBIC0gRzMwHhcNMTQwNjI1
MDAwMDAwWhcNMTUwNjA1MjM1OTU5WjB6MQswCQYDVQQGEwJVUzETMBEGA1UECBMK
V2FzaGluZ3RvbjEQMA4GA1UEBxQHU2VhdHRsZTEYMBYGA1UEChQPQW1hem9uLmNv
bSBJbmMuMQ0wCwYDVQQLFARTMy1BMRswGQYDVQQDFBIqLnMzLmFtYXpvbmF3cy5j
b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+mjGH4PrN0TDNmTsF
my2fHpHpTuySRwBMe/nuGIkL3cvKIxFKLHvkK9kx1UpO0skdQTdCY55LywhubLNO
fD19IzJdoRGdlqgkDAYC8vz3LRYj8WWsGnROfS/YFtgj25YaHPnsNp6lWrff4/qi
ctbojJpMxm+9Q0A4nTzrZymHEUkRbx6AVVUBVKH3uZi/w0aV+i4cp2bs+CYIK3DL
Qp584DJ9bOImgUhDfz19+Wtv64zIezE0Uz9eOkqgQ1X//XumyZWyD6N6+h/XqTnc
YTvIer/s83T/IngGMbfPRqjpQCay6ySXCNbJ5izMgo+gwN84t7JhaI+EYcxf1dDN
w0mXAgMBAAGjggF9MIIBeTAJBgNVHRMEAjAAMA4GA1UdDwEB/wQEAwIFoDAdBgNV
HSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwZQYDVR0gBF4wXDBaBgpghkgBhvhF
AQc2MEwwIwYIKwYBBQUHAgEWF2h0dHBzOi8vZC5zeW1jYi5jb20vY3BzMCUGCCsG
AQUFBwICMBkaF2h0dHBzOi8vZC5zeW1jYi5jb20vcnBhMB8GA1UdIwQYMBaAFA1E
XBZTRMGCfh0gqyX0AWPYvnmlMCsGA1UdHwQkMCIwIKAeoByGGmh0dHA6Ly9zZC5z
eW1jYi5jb20vc2QuY3JsMFcGCCsGAQUFBwEBBEswSTAfBggrBgEFBQcwAYYTaHR0
cDovL3NkLnN5bWNkLmNvbTAmBggrBgEFBQcwAoYaaHR0cDovL3NkLnN5bWNiLmNv
bS9zZC5jcnQwLwYDVR0RBCgwJoISKi5zMy5hbWF6b25hd3MuY29tghBzMy5hbWF6
b25hd3MuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQBlXrn1FTPjVIFbcuQNbBesrAMI
NV4L7jS1mobEwFrb7UrqZ7kHvuvoR/BpDygATyqLvPihs7nUc2TUHsw/41EAHKoq
QBVfRTOH0yWaTC6SYSx7fiElL+k55Pvrz4+7gLRy5zUlVX3iUw93zr95ka/LPuCL
7PQOFPeQDOgveDjcSNVtLcTfQfvog/rMSu/4XPFHu7zaZwUEurt9CzLeVbdB6O25
bHuHTaZLP0wmjCIbwgXu8bFWqOTnAjG70EtYrbIiQhl/ISJU6HioFzLiy5Ibp07r
RbV4ir5EI2EPKxIy30YDvpCQ0WQvYLWFV0qQOuOXkMC2M2IsBmVn2/9GQ7eP
-----END CERTIFICATE-----
1 s:/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
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-----
MIIF7DCCBNSgAwIBAgIQbsx6pacDIAm4zrz06VLUkTANBgkqhkiG9w0BAQUFADCB
yjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJp
U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW
ZXJpU2lnbiBDbGFzcyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzUwHhcNMTAwMjA4MDAwMDAwWhcNMjAwMjA3MjM1OTU5WjCBtTEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW
ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg
aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykxMDEvMC0GA1UEAxMmVmVy
aVNpZ24gQ2xhc3MgMyBTZWN1cmUgU2VydmVyIENBIC0gRzMwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQCxh4QfwgxF9byrJZenraI+nLr2wTm4i8rCrFbG
5btljkRPTc5v7QlK1K9OEJxoiy6Ve4mbE8riNDTB81vzSXtig0iBdNGIeGwCU/m8
f0MmV1gzgzszChew0E6RJK2GfWQS3HRKNKEdCuqWHQsV/KNLO85jiND4LQyUhhDK
tpo9yus3nABINYYpUHjoRWPNGUFP9ZXse5jUxHGzUL4os4+guVOc9cosI6n9FAbo
GLSa6Dxugf3kzTU2s1HTaewSulZub5tXxYsU5w7HnO1KVGrJTcW/EbGuHGeBy0RV
M5l/JJs/U0V/hhrzPPptf4H1uErT9YU3HLWm0AnkGHs4TvoPAgMBAAGjggHfMIIB
2zA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlz
aWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4
RQEHFwMwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL2Nw
czAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQG
A1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTMtZzUu
Y3JsMA4GA1UdDwEB/wQEAwIBBjBtBggrBgEFBQcBDARhMF+hXaBbMFkwVzBVFglp
bWFnZS9naWYwITAfMAcGBSsOAwIaBBSP5dMahqyNjmvDz4Bq1EgYLHsZLjAlFiNo
dHRwOi8vbG9nby52ZXJpc2lnbi5jb20vdnNsb2dvLmdpZjAoBgNVHREEITAfpB0w
GzEZMBcGA1UEAxMQVmVyaVNpZ25NUEtJLTItNjAdBgNVHQ4EFgQUDURcFlNEwYJ+
HSCrJfQBY9i+eaUwHwYDVR0jBBgwFoAUf9Nlp8Ld7LvwMAnzQzn6Aq8zMTMwDQYJ
KoZIhvcNAQEFBQADggEBAAyDJO/dwwzZWJz+NrbrioBL0aP3nfPMU++CnqOh5pfB
WJ11bOAdG0z60cEtBcDqbrIicFXZIDNAMwfCZYP6j0M3m+oOmmxw7vacgDvZN/R6
bezQGH1JSsqZxxkoor7YdyT3hSaGbYcFQEFn0Sc67dxIHSLNCwuLvPSxe/20majp
dirhGi2HbnTTiN0eIsbfFrYrghQKlFzyUOyvzv9iNw2tZdMGQVPtAhTItVgooazg
W+yzf5VK+wPIrSbb5mZ4EkrZn0L74ZjmQoObj49nJOhhGbXdzbULJgWOw27EyHW4
Rs/iGAZeqa6ogZpHFt4MKGwlJ7net4RYxh84HqTEy2Y=
-----END CERTIFICATE-----
2 s:/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
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
-----BEGIN CERTIFICATE-----
MIIExjCCBC+gAwIBAgIQNZcxh/OHOgcyfs5YDJt+2jANBgkqhkiG9w0BAQUFADBf
MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsT
LkNsYXNzIDMgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkw
HhcNMDYxMTA4MDAwMDAwWhcNMjExMTA3MjM1OTU5WjCByjELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJpU2lnbiwgSW5jLiAtIEZv
ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAz
IFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzUwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvJAgIKXo1nmAMqudLO07cfLw8
RRy7K+D+KQL5VwijZIUVJ/XxrcgxiV0i6CqqpkKzj/i5Vbext0uz/o9+B1fs70Pb
ZmIVYc9gDaTY3vjgw2IIPVQT60nKWVSFJuUrjxuf6/WhkcIzSdhDY2pSS9KP6HBR
TdGJaXvHcPaz3BJ023tdS1bTlr8Vd6Gw9KIl8q8ckmcY5fQGBO+QueQA5N06tRn/
Arr0PO7gi+s3i+z016zy9vA9r911kTMZHRxAy3QkGSGT2RT+rCpSx4/VBEnkjWNH
iDxpg8v+R70rfk/Fla4OndTRQ8Bnc+MUCH7lP59zuDMKz10/NIeWiu5T6CUVAgMB
AAGjggGRMIIBjTAPBgNVHRMBAf8EBTADAQH/MDEGA1UdHwQqMCgwJqAkoCKGIGh0
dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTMuY3JsMA4GA1UdDwEB/wQEAwIBBjA9
BgNVHSAENjA0MDIGBFUdIAAwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVy
aXNpZ24uY29tL2NwczAdBgNVHQ4EFgQUf9Nlp8Ld7LvwMAnzQzn6Aq8zMTMwNAYD
VR0lBC0wKwYJYIZIAYb4QgQBBgpghkgBhvhFAQgBBggrBgEFBQcDAQYIKwYBBQUH
AwIwbQYIKwYBBQUHAQwEYTBfoV2gWzBZMFcwVRYJaW1hZ2UvZ2lmMCEwHzAHBgUr
DgMCGgQUj+XTGoasjY5rw8+AatRIGCx7GS4wJRYjaHR0cDovL2xvZ28udmVyaXNp
Z24uY29tL3ZzbG9nby5naWYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhho
dHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wDQYJKoZIhvcNAQEFBQADgYEADyWuSO0b
M4VMDLXC1/5N1oMoTEFlYAALd0hxgv5/21oOIMzS6ke8ZEJhRDR0MIGBJopK90Rd
fjSAqLiD4gnXbSPdie0oCL1jWhFXCMSe2uJoKK/dUDzsgiHYAMJVRFBwQa2DF3m6
CPMr3u00HUSe0gST9MsFFy0JLS1j7/YmC3s=
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/ST=Washington/L=Seattle/O=Amazon.com Inc./OU=S3-A/CN=*.s3.amazonaws.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
---
No client certificate CA names sent
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 4624 bytes and written 399 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-SHA
Session-ID: B642ED1E6FE32F7A374B5A62847DEC63C2F37DCA7A18FD669B8F0FCDC98C49BF
Session-ID-ctx:
Master-Key: EE2D31F43D341A0895B36E0BCCE7557B221F1469AC1B7B0BA22D843C75F25F949822B0D0E22E967A1F373F034E9624E4
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1430871883
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
closed
When I decode the certificates it lists, I get a different certificate chain than Firefox gave me.
*.s3.amazonaws.com
Serial number: 43fbbac26627e0971e1c11e030c36b66
VeriSign Class 3 Secure Server CA - G3
Serial number: 6ecc7aa5a7032009b8cebcf4e952d491
VeriSign Class 3 Public Primary Certification Authority - G5
Serial number: 35973187f3873a07327ece580c9b7eda
The cert in use, and its immediate parent cert are the same, but the next one up has the same name, but a different serial number.
Here's my version information:
> curld --version
curl 7.40.0 (i386-pc-win32ce) libcurl/7.40.0 OpenSSL/1.0.1e
Protocols: dict ftp ftps gopher http https imap imaps pop3 pop3s rtsp smb smbs smtp smtps tftp
Features: NTLM SSL
> curld --version
curl 7.40.0 (i386-pc-win32) libcurl/7.40.0 OpenSSL/1.0.1c
Protocols: dict ftp ftps gopher http https imap imaps pop3 pop3s rtsp smb smbs smtp smtps tftp
Features: AsynchDNS Largefile NTLM SSL
$ cat /etc/redhat-release
CentOS release 6.6 (Final)
$ openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013
$ yum list openssl
Installed Packages
openssl.x86_64 1.0.1e-30.el6.8 #updates
Firefox: 37.0.2, running on Windows 7 x64.
I did review this question: SSL Certificate - Certification Path in browser different from Certificate Chain File, but my problem appears to be different: In that case, the certificate chain in the OpenSSL command line tool went 1 - 2 - 3 - 4, and in IE it was 1 - 2 - 3. Because IE considered "3" to be a root certificate, the chain stopped early. In my case, Firefox is reporting 1 - 2 - 3, and OpenSSL is reporting 1 - 2 - 4; The chain is different.
The server sends the same chain certificates to firefox and s_client:
CN=.s3.amazonaws.com SAN=DNS:.s3.amazonaws.com,DNS:s3.amazonaws.com
CN=VeriSign Class 3 Secure Server CA - G3
CN=VeriSign Class 3 Public Primary Certification Authority - G5
But the way the certificates will be verified differs depending on the SSL stack and the trusted root certificates of the client. And in case of curl you run into an old OpenSSL validation problem. Details:
Firefox has a trusted root certificate similar to the certificate#3 send by the client. This means that it is a different certificate but it contains the same public key, so that the signature for certificate#2 is still valid. Since Firefox underlying TLS stack (NSS) thus has found a usable trust anchor it will consider the chain as verified and ignore the certificate#3 sent by the server.
But the version of curl you have uses OpenSSL as the TLS library. OpenSSL tries to get the longest match, that it it will try to find a trusted root certificate which signed certificate#3. If it fails it will not try with a shorter trust chain but simply fail. This is a long-standing bug which is the cause of many many strange problems like this and it looks like the issue is for now only fixed in the latest development branch (not released).
The solution is probably to use a CA store for curl which still includes the old deprecated 1024bit CA's so that it contains the trust anchor "/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority"
For even more details about this problem see
more detailed writeup
OpenSSL bug #2732 from 2012
workarounds with patch
newer Bug reports which indicate a bug fix for current development branch (after 1.0.2)
I have been trying this authentication method for the last 3 days without any success, I am totally new to the field MVC and Identity. I required to do an external authentication for my site with Facebook, Microsoft and Twitter, so I am using Identity 2.0 with MVC 5.
Facebook and Microsoft are already done, but I have trouble doing the same for twitter, because they change their authentication policy last December, so now I require an HTTPS site (which is not the problem) with a Twitter SSL certificate (I have problems with this one).
I am using IIS Express to run my website in development mode.
I already created my app on twitter's developer site, I got my API key, API Secret, Access Token and Access Secret.
I already change my Startup.Auth.cs, to uncomment app.UseTwitterAuthentication with my consumerKey (ApiKey) and consumerSecret (ApiSecret). But when I run my site and try to sign-in with Twitter I keep receiving this error: the remote certificate is invalid according to the validation procedure.
See these discussion issues:
https://dev.twitter.com/discussions/24239
https://dev.twitter.com/docs/security/using-ssl
Reading a little bit about this issue, I know require a Twitter SSL certificate, which I got, but cannot figure out how to use it.
Please, I am desperate and I need a solution to this problem, can anyone enlighten me on how to make this work with VS 2013 and IIS Express? I have no idea what to do.
... now I require an HTTPS site (which is not the problem) with a Twitter SSL certificate (I have problems with this one)
According to Twitter is updating its SSL certificates for api.twitter.com, the signing root is changing to VeriSign Class 3 Public Primary Certification Authority - G5.
It appears it has already changed:
$ openssl s_client -connect api.twitter.com:443
CONNECTED(00000003)
depth=1 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
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=US/ST=California/L=San Francisco/O=Twitter, Inc./OU=Twitter Security/CN=api.twitter.com
i:/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
1 s:/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
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
...
Go to Download Verisign Root Certificates and download VeriSign Class 3 Primary CA - G5. It has thumbprint 4e b6 d5 78 49 9b 1c cf 5f 58 1e ad 56 be 3d 9b 67 44 a5 e5.
After downloading the certificate, import it into the Computer's Root Certificate Authority Store. For instuctions, see Manage Trusted Root Certificates on TechNet. Be sure to follow Adding certificates to the Trusted Root Certification Authorities store for a local computer. You want the local computer, and you want Trusted Root Certification Authorities store.
Once you use the downloaded certificate as a trust anchor, the chain will verify. Notice the -CAfile option, and the Verify return code: 0 (ok) at the end:
$ openssl s_client -connect api.twitter.com:443 -CAfile VeriSign-Class\ 3-Public-Primary-Certification-Authority-G5.pem
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)10, CN = VeriSign Class 3 Secure Server CA - G3
verify return:1
depth=0 C = US, ST = California, L = San Francisco, O = "Twitter, Inc.", OU = Twitter Security, CN = api.twitter.com
verify return:1
---
Certificate chain
0 s:/C=US/ST=California/L=San Francisco/O=Twitter, Inc./OU=Twitter Security/CN=api.twitter.com
i:/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
1 s:/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
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
---
...
Start Time: 1407206791
Timeout : 300 (sec)
Verify return code: 0 (ok)
I am trying to upload some cookbooks on the chef-server. I am using my laptop as workstation, using hosted chef at opscode.com as chef-server. Now, when I try to upload cookbooks from my workstation to the chef-server, I get the following error:
ERROR: SSL Validation failure connecting to host: s3-external-1.amazonaws.com - SSL_connect returned=6 errno=0 state=SSLv3 read finished A
ERROR: OpenSSL::SSL::SSLError: SSL_connect returned=6 errno=0 state=SSLv3 read finished A
I am using the cookbooks from rackspace private cloud: http://www.rackspace.com/knowledge_center/article/installing-openstack-with-rackspace-private-cloud-tools
I am using v4.2.1 of cookbooks. Please help me figure out the problem.
Thanks.
ERROR: SSL Validation failure connecting to host:
s3-external-1.amazonaws.com - SSL_connect returned=6 errno=0
state=SSLv3 read finished A ERROR: OpenSSL::SSL::SSLError: SSL_connect
returned=6 errno=0 state=SSLv3 read finished A
Works for me.
Be sure you have and are trusting Class 3 Public Primary Certification Authority. You can get Class 3 Public Primary Certification Authority from Symantec's Licensing and Use of Root Certificates. In particular, fetch Root 3 VeriSign Class 3 Primary CA - G5.
Then, test it with OpenSSL's s_client. The root you downloaded and trusted is PCA-3G5.pem, and you supply it to OpenSSL via the -CAfile option:
$ openssl s_client -CAfile PCA-3G5.pem -connect s3-external-1.amazonaws.com:443
CONNECTED(00000003)
depth=3 C = US, O = "VeriSign, Inc.", OU = Class 3 Public Primary Certification Authority
verify return:1
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)10, CN = VeriSign Class 3 Secure Server CA - G3
verify return:1
depth=0 C = US, ST = Washington, L = Seattle, O = Amazon.com Inc., CN = *.s3-external-1.amazonaws.com
verify return:1
---
Certificate chain
0 s:/C=US/ST=Washington/L=Seattle/O=Amazon.com Inc./CN=*.s3-external-1.amazonaws.com
i:/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
1 s:/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
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
2 s:/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
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
---
Server certificate
...
Start Time: 1392896325
Timeout : 300 (sec)
Verify return code: 0 (ok)
If you're merely doing a temporary test, you can disable the SSL verification by adding the 2 following lines in your knife.rb file:
verify_api_cert false
ssl_verify_mode :verify_none
But again, if you're setting up a real server, you should get a real certificate :)