We host a website in azure. The service we host has 6 instances. On that service we have added a certificate that covers the site, and has an authentication chain that looks like:
our certificate
Comodo RDAOrganisation Validation Secure Server CA (2014 - 2029)
Comodo RSA certification Authority (2000 - 2020)
USERTrust (2000 - 2020)
We can see in the browser, with any requests that we have made, that this chain seems to be present properly and the SSL handshake can complete.
We have a customer who has reported that they are having some issues connecting to us remotely. They have been using openssl to try to verify where this originates.
Where my knowledge breaks down is in interpreting this output, and I wondered if you can help either spot the difference or to identify a next step - either for us or our client.
The command that was run was
$ openssl s_client -CApath /etc/ssl/certs/ -connect <our service uri>
The output in a successful case:
CONNECTED(00000003)
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root verify return:1
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Organization Validation Secure Server CA verify return:1
depth=0 C = DK, <certificate information pertianing to our company >
---
Certificate chain
0 s:/C=DK/<certificate information pertianing to our company >
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Organization Validation Secure Server CA
1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Organization Validation Secure Server CA
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
---
Server certificate
-----BEGIN CERTIFICATE-----
Key is the same between both requests
-----END CERTIFICATE-----
subject=/C=DK/<certificate information pertianing to our company >
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Organization Validation Secure Server CA
---
No client certificate CA names sent
---
SSL handshake has read 5052 bytes and written 509 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-SHA384
Session-ID: <session id hidden>
Session-ID-ctx:
Master-Key: <key hidden>
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1436543517
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
And in an unsuccessful case:
CONNECTED(00000003)
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Organization Validation Secure Server CA verify error:num=20:unable to get local issuer certificate verify return:0
---
Certificate chain
0 s:/C=DK/<certificate information pertianing to our company >
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Organization Validation Secure Server CA
1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Organization Validation Secure Server CA
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
Key is the same between both requests
-----END CERTIFICATE-----
subject=/C=DK/<certificate information pertianing to our company >
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Organization Validation Secure Server CA
---
No client certificate CA names sent
---
SSL handshake has read 3649 bytes and written 509 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-SHA384
Session-ID: <session id hidden>
Session-ID-ctx:
Master-Key: <key hidden>
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1436543605
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
I can see that these are different, I can see that the depth fields are different, (I'm unsure of what this means, but supposing that this is an indication of how far up the authentication chain openssl got). I can also see that the chain itself seems to be different in the successful case as opposed to the unsuccessful case, with the addition of
2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
The question I have is what can cause this to happen, is this a server or a user issue (especially bearing in mind that for most requests for most users, this seems to work just fine), and do we need to take any next steps to identify an issue?
Thanks for your time :)
It turns out that this had to do with our service definition and service configuration files. In them, we had included the certificate that we wanted to present, but not it's authentication chain.
MS Support suggested that we try http://blogs.msdn.com/b/azuredevsupport/archive/2010/02/24/how-to-install-a-chained-ssl-certificate.aspx as an alternative to manually configuring our server instances.
/J R