I have created a private mail server using iRedMail & Nginx. I have installed SSL certificates and keys into Nginx and iRedMail itself at the below locations. The server runs great and everything works via web mail. The browser agrees that the SSL certificate is valid and HTTPS works.
The issue is when I add the mail account to my email client, I get an invalid certificate error, and the same issue when using CalDav. It still works, but this makes me think that I'm missing some certificate install somewhere. Any suggestions? Thank you!
/etc/ssl/certs/iRedMail.crt
/etc/ssl/private/iRedMail.key
Here is the output of openssl s_client -showcerts -connect mail.bragsdale.dev:993
CONNECTED(00000003)
depth=0 CN = bragsdale.dev
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = bragsdale.dev
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/CN=bragsdale.dev
i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
-----BEGIN CERTIFICATE-----
...CERTIFICATE HERE...
-----END CERTIFICATE-----
---
Server certificate
subject=/CN=bragsdale.dev
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2064 bytes and written 431 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
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 3DD2E8B607CF5B4ACECDB995078FDAE80C210097372B80CD1409E90A0A523E0A
Session-ID-ctx:
Master-Key: F1953ABEAC1024279DA6D0E17D26E3305E7C2A9589976FDFD2DBF22E4B6280415BC271E5228045B7D0C5E8A0B3921B11
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
....DATA HERE...
Start Time: 1551664367
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN AUTH=LOGIN] Dovecot ready
Fixed it. The problem was I wasn't using my intermediary certificate. See this answer for details.
A note, when I cat'ed the certificates together it was malformed, with the END CERTIFICATE/BEGIN CERTIFICATE being on one line. Easily fixed with a text editor.
Related
When I do openssl s_client -CApath ~/cacert.pem -crlf -connect getcomposer.org:443 -servername getcomposer.org I get the following output:
CONNECTED(00000003)
depth=1 C = US, O = Let's Encrypt, CN = R3
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/CN=getcomposer.org
i:/C=US/O=Let's Encrypt/CN=R3
1 s:/C=US/O=Let's Encrypt/CN=R3
i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFTzCCBDegAwIBAgISA4wAKXUPtnZXoYnne5MGiWlHMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMTA5MzAxMDI5MDlaFw0yMTEyMjkxMDI5MDhaMBoxGDAWBgNVBAMT
D2dldGNvbXBvc2VyLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMSpt0JoJU7PJQYHYWV5FRTheIQSFi3SM/qyt2RDwKG4g7QssLjmsAXKQ5ZgGNc2
0JOaJ6NS3LgckijVOBOgBpywXTBJ0XOF6JJpjmuivdHXw0tssD+7BD+9Z30M9vCV
i5OU2dw6VmPi7M/J9haO+/ONuMpojmPTI2IKQl7w13y+AN+EqOVn5tWKgMpKxY9y
dydsbqgGffa7aSuN4Rc6UXZ4ix4mfSdjrAxFsKeOAmVh8NfQ49PoEpNAIce7ZQkF
hzq1AZmBtpe76LYrNEO55bPbg5Z9NPBReBpVG4tpLVWPUrarxdhCLD+F5b3s7Ko/
SzAWf/mX/K89Zdd3G8q52gECAwEAAaOCAnUwggJxMA4GA1UdDwEB/wQEAwIFoDAd
BgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAdBgNV
HQ4EFgQU6Z7XW6cbc9xNki5IDKUmJEgZrJ8wHwYDVR0jBBgwFoAUFC6zF7dYVsuu
UAlA5h+vnYsUwsYwVQYIKwYBBQUHAQEESTBHMCEGCCsGAQUFBzABhhVodHRwOi8v
cjMuby5sZW5jci5vcmcwIgYIKwYBBQUHMAKGFmh0dHA6Ly9yMy5pLmxlbmNyLm9y
Zy8wQwYDVR0RBDwwOoISY2EuZ2V0Y29tcG9zZXIub3Jngg9nZXRjb21wb3Nlci5v
cmeCE3d3dy5nZXRjb21wb3Nlci5vcmcwTAYDVR0gBEUwQzAIBgZngQwBAgEwNwYL
KwYBBAGC3xMBAQEwKDAmBggrBgEFBQcCARYaaHR0cDovL2Nwcy5sZXRzZW5jcnlw
dC5vcmcwggEGBgorBgEEAdZ5AgQCBIH3BIH0APIAdwBc3EOS/uarRUSxXprUVuYQ
N/vV+kfcoXOUsl7m9scOygAAAXw2dyOHAAAEAwBIMEYCIQCOGcPZTl5eD4E03Ted
RabOF+lXzyXOPBT3xDtrIYmgxgIhAJAJJzdWzyzX8f6TdbIzGr7xQFhQAIHn/3+1
8ffWn/FjAHcAfT7y+I//iFVoJMLAyp5SiXkrxQ54CX8uapdomX4i8NcAAAF8Nncj
ywAABAMASDBGAiEA97oAvcGhneZl1n+meqzcb6OK5SJoUxYmdlz5LO15BpICIQCL
jrrvGdWMIV/ujHDMAvQ4QUn25GBjf6kps6d6SO6xADANBgkqhkiG9w0BAQsFAAOC
AQEAciXzEuFF5zwYpwv65AkhD1yYGvsqjRNCAe+AqvBVPEfqES/kCBCKeM5UDpAV
+TuJq7OQAGyUHbSAf0JK9DGTN0chTJVShaJEAXgIvnykolab/eNwpxrEOG5wTpRz
p5bJQfR+kVVIyjg0BknDQZMopH1MtWny8LT3jqhBV9eAFaaBh/X46liDACe2VmRv
/MHYGZtMtVnYIcm4iqPMZShMrWkPB7mO6PrUo0QzAUhMpb/KCRb/2XIf+H2I9zzJ
Y5MhKksA3NqDLFW3dD/KrnLKkqtKiOsUGgG1yDR9+S64lNS+IswcsodirXyrtbac
pZAfDeIuhhZ8uGqZhfcdC2OONw==
-----END CERTIFICATE-----
subject=/CN=getcomposer.org
issuer=/C=US/O=Let's Encrypt/CN=R3
---
No client certificate CA names sent
---
SSL handshake has read 3183 bytes and written 455 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: 222874F43D8C5CD5C5EBCE9519D767FC0847D4BCE75261020AEDA2337E84CE87
Session-ID-ctx:
Master-Key: 4C7B19187830AF58A6D03B37163A5C2CEF3222F6BC048D569B122DF372DFCA4CB7FAA0103AAE0C87B5C008E0692C48AD
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1634183395
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
closed
I don't understand this error. I just got cacert.pem by doing wget --no-check-certificate -O ~/cacert.pem https://curl.se/ca/cacert.pem and doing vim ~cacert.pem verifies that the newly created file is non-empty.
Since the community seems to have accepted this as ontopic:
As I commented, to use in openssl commandline a 'bundle' file in the format supplied by https://curl.se/ca/cacert.pem you must use -CAfile not -CApath.
-CApath works instead with a directory containing a separate file for each cert named by its subject hash, as described in man 1 verify on older versions or man 1 openssl-verification-options on 3.0 also here on the web and which you can use c_rehash to help create if that is really wanted for some reason.
This is a stab in the dark, as I don't understand that openssl output much, but judging by the timing and the keywords 'openssl' and 'Lets Encrypt' this has a reasonably high chance of success.
On September 30, 2021 Let's Encrypt's old Root Certificate has expired. This had a major implication that now they have started to use their own root cert which should be trusted by most devices. 'Most' part was troublesome as there are some devices alive which did not receive updates in years. So the people at Let's Encrypt found a way to still remain supported/trusted on those devices, just under one condition - its openssl version must be 1.1.0+ (which is already 4+ years old). Another important detail is that this openssl version requirement also applies to systems that would have otherwise trusted LE's new cert.
So I've seen numerous people over October scrambling to get LE issued certificates to be trusted again by their systems and the answer was always as simple as: Get your openssl / libopenssl updated to v1.1.0+
To reach a target file, I must put specific Host Header in request, because server is using SNI.
My server's ip is 172.1.1.61 and mydomain.com is target host which can give me a file.
I tried to use a curl like that with no success:
curl -I --resolve mydomain.com:443:172.1.1.61 https://172.1.1.61:443/FederationMetadata/2007-06/FederationMetadata.xml -v
* Added mydomain.com:443:172.1.1.61 to DNS cache
* About to connect() to 172.1.1.61 port 443 (#0)
* Trying 172.1.1.61...
* Connected to 172.1.1.61 (172.1.1.61) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* NSS error -5961 (PR_CONNECT_RESET_ERROR)
* TCP connection reset by peer
* Closing connection 0
curl: (35) TCP connection reset by peer
Also I tried to use an openssl client:
openssl s_client -connect 172.1.1.61:443 -servername mydomain.com
And it has showed me a valid certificate, related to mydomain.com:
CONNECTED(00000003)
depth=3 C = US, O = "The Go Daddy Group, Inc.", OU = Go Daddy Class 2 Certification Authority
verify return:1
depth=2 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", CN = Go Daddy Root Certificate Authority - G2
verify return:1
depth=1 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", OU = http://certs.godaddy.com/repository/, CN = Go Daddy Secure Certificate Authority - G2
verify return:1
depth=0 OU = Domain Control Validated, CN = mydomain.com
verify return:1
---
Certificate chain
0 s:/OU=Domain Control Validated/CN=mydomain.com
i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
2 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
LmdvZGFkZHkuY29tL3JlcG9zaXRvcnkvMTMwMQYDVQQDEypHbyBEYWRkeSBTZWN1
some moar strings
cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5IC0gRzIwHhcNMTkwNDAzMDQyODE3Wh==
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/CN=mydomain.com
issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
---
No client certificate CA names sent
Peer signing digest: SHA256
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 4609 bytes and written 438 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
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 9B020000BE0E627BF16F61C924ED4B90FF698F1868168A0467E0F359F98DE1FA
Session-ID-ctx:
Master-Key: (hidden)
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1602236714
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
read:errno=104
But the last string is read:errno=104 what is equal to Connection Reset error.
As my last hope I'd installed a Modify Header Value plugin on my Chrome browser and made settings like that:
But still no connection:
What I did wrong?
openssl s_client -connect 172.1.1.61:443 -servername mydomain.com
...
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
...
But the last string is read:errno=104 what is equal to Connection Reset error.
The error you see here means that the connection reset happens in the final stages or directly after the TLS handshake. In this stage SNI is already used to select the certificate and the HTTP request with the Host header is not yet sent. This means that neither SNI nor the Host header are the actual problem here.
This means one can exclude wrong SNI and Host header as the possible reasons for the connection reset. A shared cipher is also found so this is also not a problem. It might be for example a missing client certificate or something else. Maybe the server logs will show.
TIBCO version - TIBCO ActiveMatrix BusinessWorks 5.7.2
Problem:
I am the consumer of the TIBCO server, getting SSL handshake failure. I have tried the following openssl commands to see if it can accept connections. Below are my results:
openssl s_client -showcerts -connect tibco-server:port -verify 3 -tls1 -state
verify depth is 3
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv3 write client hello A
SSL3 alert read:fatal:unexpected_message
SSL_connect:failed in error
139827261306768:error:140943F2:SSL routines:ssl3_read_bytes:sslv3 alert unexpected message:s3_pkt.c:1493:SSL alert number 10
139827261306768:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:659:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1581402078
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
However the same is working when I hit with ssl3 option
openssl s_client -showcerts -connect tibco-server:port -verify 3 -ssl3 -state
verify depth is 3
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=0 C = AU, ST = <state>, L = <location>, O = <org>, OU = <unit>, CN = <cn>
verify error:num=18:self signed certificate
verify return:1
depth=0 C = AU, ST = <state>, L = <location>, O = <org>, OU = <unit>, CN = <cn>
verify return:1
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server key exchange A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read finished A
---
Certificate chain
-----BEGIN CERTIFICATE-----
.....
.....
-----END CERTIFICATE-----
---
Server certificate
subject=...
issuer=...
---
No client certificate CA names sent
Server Temp Key: DH, 1024 bits
---
SSL handshake has read 1779 bytes and written 362 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : SSLv3
Cipher : DHE-RSA-AES128-SHA
Session-ID: 8BCEAEADC85613876FFF0E2EAB590A92
Session-ID-ctx:
Master-Key: <master-key-here>
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1581402661
Timeout : 7200 (sec)
Verify return code: 18 (self signed certificate)
---
I have masked some of the output data.
Any help on why, openssl can connect TIBCO via ssl3 but not tls1.0 ?
This issue got resolved after the security configuration changes in TIBCO server. Now the clients can successfully negotiate TLS1.0 connections with TIBCO server.
FIX
Changed security to be j2se instead of entrust
java.property.TIBCO_SECURITY_VENDOR=j2se
References
https://support.tibco.com/s/article/Tibco-KnowledgeArticle-Article-38616
https://community.tibco.com/questions/tls-compatibility-tibco-bw
I am trying to connect to my server SMTP on Windows 2012 R2 server on which is installed a RapidSSL 256 bit certificate. I need to test if the SMTP server can send email to one of our customers which seems to have problem with the certificate. This is the command I launch:
openssl s_client -starttls smtp -connect www.omniservice2.it:25 -crlf
and I get this:
CONNECTED(00000003)
depth=1 /C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/CN=www.omniservice2.it
i:/C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA
1 s:/C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
---
Server certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject=/CN=www.omniservice2.it
issuer=/C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA
---
No client certificate CA names sent
---
SSL handshake has read 3697 bytes and written 363 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: ...
Session-ID-ctx:
Master-Key: ...
Key-Arg : None
Start Time: 1487243991
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
250 OK
Then I go with:
HELO
AUTH LOGIN
and I enter username/password encoded in base64. Credentials are correct and they are normal Windows authentication username/password and they are correctly used by all our .NET application to access the SMTP server.
So, credentials encoded in base64 are surely correct but after entering them, I am prompted DONE and the connection is closed and the shell returns.
What does this mean?
UPDATE
Here's the sequence of my commands:
>HELO
250 www.omniservice2.it Hello [37.159.171.6]
>AUTH LOGIN
>334 VNXlcm5hbWU6
(my Windows username encoded in base64)
>334 UGFzc3dvcmQ6
(my Windows password encoded in base 64)
>DONE
>prompt returned here
If, after HELO, I send a STARTTLS command, it tells me there is an already started TLS Session
AUTH LOGIN or any AUTH command is not valid after HELO, you must connect with EHLO for AUTH to work.
If either your username or password in base64 format start with a capital "Q" open ssl will return DONE.
Similarly if they start with an "R" the connection will be RENEGOTIATED.
To avoid this try using the AUTH PLAIN and pass your credentials on the same line:
EHLO <example.org>
AUTH PLAIN <base64>
...
I am working with the example apps in the "Networking Security with OpenSSL" book and up until now have been able to get client/server examples 1,2,3 to work. But now I'm trying to connect to an in-house tool but I'm getting the error "error 18:self signed certificate". Despite this error when I run my app (essentially client3), when I use s_client with the very same credentials...it works.
I suspect that it has something to do with the ssl/tls api combination that I use in my 'client3' app.
Here's the command and output for s_client that connects to the in-house tool which works:
~/tls/client$ openssl s_client -connect 192.168.1.99:16001 -CAfile ../_security/SipInspector/certificate.pem -key ../_security/client.pem
Enter pass phrase for ../_security/client.pem:
CONNECTED(00000003)
depth=0 C = CA, ST = Ontario, L = Ottawa, O = SIP Inspector Ltd, OU = Development, CN = 192.168.1.99
verify return:1
---
Certificate chain
0 s:/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector Ltd/OU=Development/CN=192.168.1.99
i:/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector Ltd/OU=Development/CN=192.168.1.99
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFxTCCA62gAwIBAgIJALKQ3J5SEyjPMA0GCSqGSIb3DQEBCwUAMHkxCzAJBgNV
BAYTAkNBMRAwDgYDVQQIDAdPbnRhcmlvMQ8wDQYDVQQHDAZPdHRhd2ExGjAYBgNV
BAoMEVNJUCBJbnNwZWN0b3IgTHRkMRQwEgYDVQQLDAtEZXZlbG9wbWVudDEVMBMG
A1UEAwwMMTkyLjE2OC4xLjk5MB4XDTE2MDUyNzE4NDEyM1oXDTE3MDUyNzE4NDEy
M1oweTELMAkGA1UEBhMCQ0ExEDAOBgNVBAgMB09udGFyaW8xDzANBgNVBAcMBk90
dGF3YTEaMBgGA1UECgwRU0lQIEluc3BlY3RvciBMdGQxFDASBgNVBAsMC0RldmVs
b3BtZW50MRUwEwYDVQQDDAwxOTIuMTY4LjEuOTkwggIiMA0GCSqGSIb3DQEBAQUA
A4ICDwAwggIKAoICAQC2iZxPwl3McyfpNqhsNX6yqccHjBMvr6hVwnYI8jokmUJq
/X6nUEiamvQmMR9EaO4VgY7pMZSiDYAOEnWT6y8KiKES1AQu1d6Yzi+GJwbQYcyt
Mr8h+YkmW091F/xPB4RLABHqmZWC3QCoZ6yP4UGkKpJnvGSWvgKjG2OJGi8gaKkp
WlOscWQRlHq85i+ekaha127q4f8YkWXjt5fyU7BH8xk4E/OQ5zJyFrD/GL5LM/wh
XlPBrxB+A3Nm570EzhVFNjaG8PRIKnPpcoMUbslgZX6veEgYq3JcEUh+qIHTZqBB
ebiU5XsIwsKfdO1GZ6mFwnysRWrGymA6cTGVrhTtrsV1knWuV9citwaurysyW9S3
KMr5Ubj6uXQoWkt+yk2l9jtcxr/K0swXSxqvvhKSu8WaZd09SLyfkYA/wJ+LB//u
gE7bXVI2LRr8N4C1mVm3vFETcW1wjxCRSfLFSDsryhGp+6fXKI28KRQCU4ZZe53P
GFREj0VQfjsuSKDJX0M0PC9eNLNYTkPWsLCCcohEIuUgIaiQcILW/3bsgHyxQRz9
ljVkjQV0r5YBLIBXMbV4dH8ZKs/2A/oFXQ6UhH0oAm7o9ti65NdaG5/k904bhvOx
XFJzmYgSaN8KXZg30vE35ouA34DEVkb6pHY2qLxokKG5pacAb35+5aVu/AaH0QID
AQABo1AwTjAdBgNVHQ4EFgQUZ78GCtQa4uhoka8uC0hPdw8/I1AwHwYDVR0jBBgw
FoAUZ78GCtQa4uhoka8uC0hPdw8/I1AwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0B
AQsFAAOCAgEAViIHJNe36qRjb/gOWdaqJtvPv3wAx/y7fZuMZhYQQVs7EKuKpPoI
nD+n6lluLn/cMQxN2qSLSsaGh2e3I4TThWu4D6pQkz+4DVCvAkKK5BfLpzAhbPla
ojSwPmu5ekl754FhJuiDy6WSRtWyKhReCF6tlbwRE2/DsWXeDnn08XtwGE27gwiR
I69wygaQFMXppXrQGWFmHobHYuVBJ1xHj4+i3TdmKli0PobASu3ley8KT6sKvx8F
VKJt8a+cVWj+6ctGPSWvFVJsNNdS8al/7GPnRdMFr+KSC9htjvM9orWV+YrOMPzb
YFauf3FHV23btZxD7OcXFdxLSFxTG3VHV4utKGmDd8IJ/JF4Z7Kkfci+7qbCDxaf
520p531E9H4C0UkccqRavvBsfBJbX0u6Ry/l4glaJSAA2vnGjjh7gMYJnmL1mOKy
BOLYvCkbMqrX/BQBXI44zI0BCeMyXngvvhE+aE3XFmfSYDaMWqma8KsKSxSHUbrK
CacCgoJJbXSqv/Clu5KEM4n2/GPFE9ZhXVJt3MKvTEC0rf3mBQnU6S+NpwLvqBKg
pt/q5/gKqRFbjyL0LDNz49vaSUYvbu3mgF2480Or4X+GPwemwdxJaF1pQw4C1WaF
RyfVjDrLNhTvv+zKCbEPyrjXCweNVRVcp8lZ8R0HmXwfgevlCNz/GQo=
-----END CERTIFICATE-----
subject=/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector Ltd/OU=Development/CN=192.168.1.99
issuer=/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector Ltd/OU=Development/CN=192.168.1.99
---
No client certificate CA names sent
---
SSL handshake has read 2309 bytes and written 509 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-DES-CBC3-SHA
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-DES-CBC3-SHA
Session-ID: 5755C781D91CF3177DF624EA3599EE430DAB4790F325FAD9378FEAE7731C4497
Session-ID-ctx:
Master-Key: D149008E43E29D658D29418C9F770B3D6018B1D7CA2F493027B0AC7C3BA8E53B572B68C371153568B8988A1E5F351839
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1465239425
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
Here's the command and output when I run my app that tries to connect to the same in-house tool which fails:
carl#ubuntu:~/tls/client$ ./client3 192.168.1.99
Enter PEM pass phrase:
connecting to 192.168.1.99:16001
-Error with certificate at depth: 0
issuer = /C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector Ltd/OU=Development /CN=192.168.1.99
subject = /C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector Ltd/OU=Development/CN=192.168.1.99
err 18:self signed certificate
** client3.c:94 Error connecting SSL object
139788992993088:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:s3_clnt.c:1180:
carl#ubuntu:~/tls/client$
Here are the api's I call in the my app that utilize the same credentials used by the s_client command:
SSL_CTX_new(SSLv23_method());
SSL_CTX_load_verify_locations(ctx, "../_security/SipInspector/certificate.pem", NULL)
SSL_CTX_use_PrivateKey_file(ctx, "../_security/client.pem", SSL_FILETYPE_PEM)
SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, verify_callback);
SSL_CTX_set_verify_depth(ctx, 4);
SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2);
And also I used the openssl verify command to double check the certificate against itself (not sure if this really does anything).
Any help would be appreciated.
Problem solved. Turned out to be the certificate check routine was checking against incorrect information in the received certificate.