🎄 Happy Holidays! 🥳

Most of Solace is closed December 24–January 1 so our employees can spend time with their families. We will re-open Thursday, January 2, 2024. Please expect slower response times during this period and open a support ticket for anything needing immediate assistance.

Happy Holidays!

Please note: most of Solace is closed December 25–January 2, and will re-open Tuesday, January 3, 2023.

How to test TLS connection and server certificate

uherbst
uherbst Member, Employee Posts: 130 Solace Employee
in Tips and Tricks #1

If you use TLS to secure your connections (and you should use TLS as often as possible), you sometime have issues connecting to your TLS ports.
Here, I will describe a way to debug that.

Try to connect to a port

You're not sure, if your service / port is enabled or (most probably) if all your firewall rules are in place ?
From the client, try to connect to the server port.
Often telnet is recommended. I don't recommend that, because the handling of telnet is a little bit complicated, especially quitting telnet after connecting. I recommend ncfor that:

$ nc -vz 10.71.1.8 8883
Connection to 10.71.1.8 8883 port [tcp/*] succeeded!

Explanation:
-v: Be verbose, output, if connected
-z: Just try to connect and stop, don't send any data

Check TLS server certificate

To see details of the server certificate, use openssl:

[uherbst@umbp ~] $ openssl s_client -connect mr16jp1pl7tfu7.messaging.solace.cloud:55443
CONNECTED(00000005)
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, OU = www.digicert.com, CN = Thawte RSA CA 2018
verify return:1
depth=0 C = CA, ST = Ontario, L = Kanata, O = Solace Corporation, CN = *.messaging.solace.cloud
verify return:1
---
Certificate chain
 0 s:/C=CA/ST=Ontario/L=Kanata/O=Solace Corporation/CN=*.messaging.solace.cloud
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte RSA CA 2018
 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte RSA CA 2018
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGpzCCBY+gAwIBAgIQBpfhPEvol9Rx6KExmHCJ2TANBgkqhkiG9w0BAQsFADBc
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMRswGQYDVQQDExJUaGF3dGUgUlNBIENBIDIwMTgwHhcN
MTkwOTE5MDAwMDAwWhcNMjEwOTE4MTIwMDAwWjBwMQswCQYDVQQGEwJDQTEQMA4G
A1UECBMHT250YXJpbzEPMA0GA1UEBxMGS2FuYXRhMRswGQYDVQQKExJTb2xhY2Ug
...
DKszydaiybTA73m8w6YabN2BrpqvkaxA8zrbjeJ30cvgPM0ZzA2JRYnPvjxHQLyd
uyQBGQcGAr2U0rjbVixFyFYs2dlXfbAHf7A6
-----END CERTIFICATE-----
subject=/C=CA/ST=Ontario/L=Kanata/O=Solace Corporation/CN=*.messaging.solace.cloud
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte RSA CA 2018
---
No client certificate CA names sent
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3392 bytes and written 334 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:
    Session-ID-ctx:
    Master-Key: 59FE52516A3EA4A63FAA1EAB8045EE8A0F5813D6F9D83E6A02931BFFEFCA5C382D2C3670655169B097F104F9D8F75577
    Start Time: 1607409440
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

What can we see here:
1. Common name of your server:
subject=/C=CA/ST=Ontario/L=Kanata/O=Solace Corporation/CN=*.messaging.solace.cloud
2. certificate chain for your certificate:

Certificate chain
 0 s:/C=CA/ST=Ontario/L=Kanata/O=Solace Corporation/CN=*.messaging.solace.cloud
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte RSA CA 2018
 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte RSA CA 2018
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA

With this information, you know, that you need the certificates for DigiCert Global Root CA and Thawte RSA CA 2018 to validate your server certificate

Tagged:

Comments

  • TomF
    TomF Member, Employee Posts: 412 Solace Employee
    #2

    A handy tip, @uherbst !

  • soutchilin
    soutchilin Member Posts: 3 ✭
    #3

    Hi,

    maybe it is a bit unrelated question... I'm trying to create a session and establish a connection from c# using solclient to a pubsub+. Unfortunately I get an error like this: Session '(c0,s1)_[myVPN]' failed to load trust store: unspecified property 'SESSION_SSL_TRUST_STORE_DIR'

    I have only a default server certificate configuration, basically what was automatically pre-created by Solace PubSub+. What is the directory for that?

    One remark for configuring session properties:

    If I set SSLValidateCertificate to false, then no validation, no error.

    If i set SSLTrustStoreDir="certs", I get "Session '(c0,s1)_[myVPN]' cannot access 'SESSION_SSL_TRUST_STORE_DIR' : 'certs'

    If I set SSLTrustStoreDir = "/" the session is created, but connect fails with Session '(c0,s1)_[myVPN]': The peer certificate is not trusted, rc='unable to get local issuer certificate'


    Thoughts?

    Cheers,

    Alexander

  • TomF
    TomF Member, Employee Posts: 412 Solace Employee
    #4

    Hi @soutchilin,

    When you set SSLValidateCertificate to true, you're asking the API to check the server certificate - in other words, to first verify that the server is who they say they are, but next that this is a server you're happy to trust.

    To do this, you have to tell the API which servers you trust. This is done using the trust store, which stores which servers you are happy to trust. You'll need to set up a trust store that trusts the broker, which will be stored in a directory - you can then point SESSION_SSL_TRUST_STORE_DIR to this directory.

Categories

This Month's Leaders

This Week's Leaders