I'm trying to access an url which has SSL certification and use https using php curl. The curl options are set as follows.
$url = 'https://example.com';
$curl = curl_init();
curl_setopt_array($curl, [
CURLOPT_URL => $url,
CURLOPT_RETURNTRANSFER => true,
CURLOPT_SSL_VERIFYPEER => true,
CURLOPT_SSL_VERIFYHOST => 2,
CURLOPT_POST => true,
]);
$curlResponce = curl_exec($curl);
$curlError = curl_error($curl);
curl_close($curl);
The above curl code returns the following error.
SSL certificate problem: unable to get local issuer certificate
But when I visit the same url using a browser, it displays the web page correctly without any issue in the SSL certificate. If I use the same to code to access https://www.google.com, Google page is displayed without any errors.
The web site "https://example.com" is hosted in AWS and uses a SSL certificate issued by RapidSSL RSA CA 2018. The certificate is not expired.
When I use openssl in command line to test "https://example.com" following verify errors are occurred.
Hasanta:~ hsumudupriya$ openssl s_client -connect example.com:443
CONNECTED(00000003)
depth=0 /CN=www.example.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /CN=www.example.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /CN=www.example.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/CN=www.example.com
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=RapidSSL RSA CA 2018
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFwjCCBKqgAwIBAgIQAd3vbVFjNnIlyEHjmZChmzANBgkqhkiG9w0BAQsFADBe
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMR0wGwYDVQQDExRSYXBpZFNTTCBSU0EgQ0EgMjAxODAe
Fw0xOTAxMjEwMDAwMDBaFw0yMDAxMjExMjAwMDBaMB0xGzAZBgNVBAMTEnd3dy5w
ZXdlbGRiYW5rLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO4z
N+NKUcPlq2awP7+DWPHuE8zoD339v3c8ge1dxHh4XtMsxhDrP03etDCjZjr04AKS
/eTFdFrpATX8zbhxrUj7w0mbXTWgS2ruxQgYeQGRCwvXHCyGcBREXzIsNRh39fZw
x+kAby+bUymAeQ3ixI2ChCNH9PU5IBZ9WiLHI9d5nW8SkhO7ThcsHItamOEqPIQ7
vbu9b/gYvx0FQ+u24gZYazpWDDxqtYhJzGMLT9WEA35oD94CsRUXdvPv7TjjsTb9
Y9qLy/7SDGMmP6S/PIa2Wp2TaIW5UvgBUEDmRMMzHOePREeyGTC8KtSHYxtbMJyd
RkA3PIVbEM28PLnuoCMCAwEAAaOCArswggK3MB8GA1UdIwQYMBaAFFPKF1n8a8AD
IS8aruSqqByCVtp1MB0GA1UdDgQWBBRx/2R+46KD96n1weCytLRP74jGgDAtBgNV
HREEJjAkghJ3d3cucGV3ZWxkYmFuay5jb22CDnBld2VsZGJhbmsuY29tMA4GA1Ud
DwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwPgYDVR0f
BDcwNTAzoDGgL4YtaHR0cDovL2NkcC5yYXBpZHNzbC5jb20vUmFwaWRTU0xSU0FD
QTIwMTguY3JsMEwGA1UdIARFMEMwNwYJYIZIAYb9bAECMCowKAYIKwYBBQUHAgEW
HGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwCAYGZ4EMAQIBMHUGCCsGAQUF
BwEBBGkwZzAmBggrBgEFBQcwAYYaaHR0cDovL3N0YXR1cy5yYXBpZHNzbC5jb20w
PQYIKwYBBQUHMAKGMWh0dHA6Ly9jYWNlcnRzLnJhcGlkc3NsLmNvbS9SYXBpZFNT
TFJTQUNBMjAxOC5jcnQwCQYDVR0TBAIwADCCAQUGCisGAQQB1nkCBAIEgfYEgfMA
8QB2ALIeBcyLos2KIE6HZvkruYolIGdr2vpw57JJUy3vi5BeAAABaG9eTHsAAAQD
AEcwRQIgKUDoVrCW5gkmC196ffInmfoV6t0vQ+Ue9EfZ+e+IidUCIQC03XtAQMzg
tDlW1n2MPbdVjqRtDpnOW9rVgJx9M1uOcgB3AId1v+dZfPiMQ5lfvfNu/1aNR1Y2
/0q1YMG06v9eoIMPAAABaG9eTTUAAAQDAEgwRgIhAL5YulISvgf3uwXwrFKhTomC
HJa+FUhDxNjDKGDRhcqSAiEAp+Mb4qu4Fejh9GgphGn02B2HqndO0KFJvDjSvyfj
yBkwDQYJKoZIhvcNAQELBQADggEBAMfnhpeKWKV36+TuS+aTuzynr9qKQdnPhL2s
gjEo+NHK48Z/RYiVLf6Ua5Sq4rn9RTGqi7aQaoCcXwb90j3t5NONOMnw3PexbLfH
xr6qR0Z9ybJsLi326AVNfSMmbuy+RGqbHiNi9+y15yce+ozw+LK0eN3ZDvnuQPP2
CrwevWZhCuAGQ2PQc5rPilIbe/sE0C9Nf7wu78g7zowMRHf4TOsP/VZE/xC1MlIn
I9mm652488zO4WH3c7WnssEbUDqoGnIZ4v/3V3nckriEI+EM1ZNtguGYSAMeUsny
Odh738FbIJ1muWvwj3xCOOjSgrzRZ0EA1HhhO230ek/Zc7KEbD0=
-----END CERTIFICATE-----
subject=/CN=www.example.com
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=RapidSSL RSA CA 2018
---
No client certificate CA names sent
---
SSL handshake has read 2433 bytes and written 456 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: 5C2759394B4EC8B2F37EEF89ACBC01B5EF6B6F76CA809C6C2823BAD01AE368D5
Session-ID-ctx:
Master-Key: 6FE824F4F83B4205288D3DC23EE0FA0817A265FC818EDA37071A5DD21E088A74DD7DD19F69CB9A1A226BF43124CCD1FE
Key-Arg : None
Start Time: 1555058725
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
read:errno=0
Most of the answers about "php curl - SSL certificate problem: unable to get local issuer certificate" says about configuring php curl settings in localhost / mamp and adding cacert.pem and ca-bundle.crt manually. But in my case this is not a problem with php curl in my localhost as I can access other sites over https.
The problem was solved when the existing Intermediate-CA certificate file was replaced wth the latest version. The issue was the existing Intermediate-CA certificate file being an outdated version.
Related
I currently have a domain named "rabbitmq.<server>.com". I wan't to add SSL certificates to do a AMQPS connection.
I took my nginx certificates generated by certbot (let's encrypt) for the rabbitmq dashboard and i put them into rabbitmq configurations:
#listeners.tcp = none
listeners.ssl.default = 5671
ssl_options.cacertfile = /etc/rabbitmq/certs/fullchain.pem
ssl_options.certfile = /etc/rabbitmq/certs/cert.pem
ssl_options.keyfile = /etc/rabbitmq/certs/privkey.pem
ssl_options.verify = verify_peer
ssl_options.fail_if_no_peer_cert = true
After a restart rabbitmq work and i can diagnostic my connection with openssl on my client computer:
openssl s_client -connect rabbitmq.<server>.com:5671 -cert cert.pem -key privkey.pem -CAfile fullchain.pem -verify 8 -verify_hostname rabbitmq.<server>.com
But openssl raise an error:
00864C1001000000:error:0A000418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca:ssl/record/rec_layer_s3.c:1588:SSL alert number 48
I tried to change the verify_peer by verify_none and the SSL client work:
...
SSL handshake has read 4579 bytes and written 405 bytes
Verification error: unable to get issuer certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 2 (unable to get issuer certificate)
---
...
AMQP closed
But i don't appreciate to remove security. And my python pika client doesn't work.
My first question is i am doing the job well ? Do i need to take the server certificates (ca, cert, key) or i need to regenerate another for the client ?
SSL alert number 48 means "unknown_ca". The server cannot verify the client certificate you've sent because it does not find any path to the CA's trusted by the server. You might be missing the root CA for cert the signer of your cert?
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.
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.
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.