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?
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+
I need to connect to some https://website.com. So, the site is available via VPN. I'm connected to the VPN and I can open the site in browser.
I've downloaded certificates from browser:
Then I cat both file into one certificate.pem
But when I'm trying to execute command
openssl s_client -connect website.com:443 -CAfile /path/to/certificate.pem
When I execute it in a terminal I have an error.
CONNECTED(00000003)
depth=1 /C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA
verify error:num=2:unable to get issuer certificate
issuer= /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
verify return:0
---
Certificate chain
0 s:/C=AU/ST=Wales/L=Place/O=Company
Ltd/OU=D&D/CN=website.com
i:/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA
---
Server certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
subject=/C=AU/ST=Wales/L=Place/O=Company
Ltd/OU=D&D/CN=website.com
issuer=/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA
---
No client certificate CA names sent
---
SSL handshake has read 2034 bytes and written 328 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES128-SHA
Session-ID: 1533BA958D51B9FEAE4C3534F4A417A5896ED17DCAAE83E89E6C2A7F615A583A
Session-ID-ctx:
Master-Key: 5CF D4ACA242B602AAFSDF1234X23E99BD4C62862888947FACFF0E7503BA34C2DD0EC193FA525204A539
Key-Arg : None
Start Time: 1509781851
Timeout : 300 (sec)
Verify return code: 0 (ok)
openssl historically and by default validates a certificate chain only if it ends at a root. Having the server aka end-entity or leaf cert in the truststore is useless, and the intermediate(s) should not be needed because RFCs require the server to send it(them), but your server is apparently defective or misconfigured because it does not. Thus for your server having the intermediate and root, but not the server cert, in the file used for -CAfile will work, assuming they are in PEM format.
Alternatively, recent (and supported) releases 1.0.2 and 1.1.0 add an option -partial_chain. If specified, this validates if the truststore has any anchor, not just a root. For your server, having either the server cert or the intermediate in the file used for -CAfile is sufficient, again in PEM format.
These cases are described on the man page for verify(1) which is referenced from the man page for s_client(1). Some systems may make the section 1ssl or similar, and if your system is not properly installed or is Windows, they are on the web here.
Remember that openssl historically and by default does not check the server name in the cert. 1.1.0 has new options -verify_name and -verify_hostname that do so. These are described on the man page for verify and referenced on that for s_client.
Also remember that many servers, though apparently not yours, now use Server Name Indication (SNI) extension to support multiple 'virtual' hosts with different certificates, and will either give a wrong cert or reject or fail the connection if SNI is missing. openssl s_client does not send SNI by default, but the option -servername does so; this is described on the man page. Update: OpenSSL 1.1.1 in 2018 s_client now does send SNI by default.
In general looking at the man pages for a program tells you useful information about how the program works and how to use it, and is recommended.
Especially since this is not a programming or development question, and really off-topic for StackOverflow; I would try to propose migration to SuperUser or ServerFault, but they already have numerous dupes.
This error means that openssl is looking for the issuer certificate with the subject "/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA" but it is not provided in the file /path/to/certificate.pem. Suggest to run "openssl x509 -in /path/to/certificate.pem -text" to see the subject of the certificate in this file - should be different from the requested one.
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>
...
This has me stumped, hoping someone could help me out. I had a working rabbitmq cluster until the SSL certificate expired.
After installing a new signed certificate, i'm getting the following errors for all connections:
=INFO REPORT==== 19-Oct-2016::21:39:27 ===
accepting AMQP connection <0.3532.0> (x.x.x.x:43958 -> x.x.x.x:5671)
=ERROR REPORT==== 19-Oct-2016::21:39:33 ===
Error on AMQP connection <0.3536.0>:
{ssl_upgrade_error,{certfile,{badmatch,[]}}}
Trying an openssl s_client connection
openssl s_client -connect x.x.x.x:5671 -cert ssl.crt -key ssl.key -CAfile intermediate.crt
Results in this:
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 295 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
But running the SSL key checker with s_server/s_client from https://www.rabbitmq.com/troubleshooting-ssl.html#troubleshooting works via localhost and port 8443.
No files have been moved, the old certificates were simply replaced with the same name in the same dirs. The CSR was generated with the same key, so the only things that were replaced were the certificate and intermediate certificate taken directly from the SSL issuer.
If I revert back to the old certificates, the {ssl_upgrade_error,{certfile,{badmatch,[]}}} doesnt appear and I can s_client without issues (apart from the ssl is expired error)
Turns out the issue was with the certfile itself, went directly to the ssl issuer to download them and move them into the server
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.