Python TLS Connection Reset By Peer

I’m a bit at loss here, Solace shows everything is ready to accept TLS connections but it refuses with the following error on the client side:

solace.messaging.errors.pubsubplus_client_error.PubSubPlusCoreClientError: {'caller_description': 'do_connect', 'return_code': 'Not ready', 'sub_code': 'SOLCLIENT_SUBCODE_COMMUNICATION_ERROR', 'error_info_sub_code': 14, 'error_info_contents': 'TCP: Could not read from socket 8, error = Connection reset by peer (104)'}

Port 55443 is being listened to on the server, the port is open in the Firewall Security Group.

image.png

Solace TLS Status on VPN:

General TLS Settings:

And some python code:

broker_props = { "solace.messaging.transport.host": f"tcp://{host1}:55443,tcp://{host2}:55443", "solace.messaging.service.vpn-name": "default", "solace.messaging.authentication.scheme.basic.username": credentials_username, "solace.messaging.authentication.scheme.basic.password": credentials_password }

Same result with both security strategies:

#transport_security_strategy = TLS.create().with_certificate_validation(True, False, "/etc/ssl/certs/ca-certificates.crt") transport_security_strategy = TLS.create().without_certificate_validation()

And our connection:

messaging_service = MessagingService.builder().from_properties(broker_props).with_reconnection_retry_strategy(RetryStrategy.parametrized_retry(20,3)).with_transport_security_strategy(transport_security_strategy).build()

messaging_service.connect()

Just to add, connections via port 55555 work fine, messages are being accepted

You should be using tcps:// as the protocol, I believe.

That actually did the trick, now it says:

solace.messaging.errors.pubsubplus_client_error.PubSubPlusCoreClientError: SESSION CREATION UNSUCCESSFUL. Untrusted certificate. {'caller_description': 'do_connect', 'return_code': 'Not ready', 'sub_code': 'SOLCLIENT_SUBCODE_UNTRUSTED_CERTIFICATE', 'error_info_sub_code': 99, 'error_info_contents': "Session '(c0,s1)_default': The peer certificate is not trusted, rc='unable to get local issuer certificate'"}

There is a working Let’s Encrypt certificate active inside the broker.

I link to the default Ubuntu CA Trust Store

When I use without_certificate_validation() the connection works fine! So thank you for that at least :slight_smile:

Hi @MrSmart ,

Did you verify that LetsEncrypt is a valid certificate authority per your system? I tried a quick google but couldn’t find a default list for ubuntu. Maybe try something like this:

Hope that helps!

Hi @marc.dipasquale ,

This is what Let’s Encrypt mentions on their site:

This is what the Ubuntu server gives back when listing all certificate subjects:

So I guess this should be able to work somehow. But it doesn’t.

The 3rd parameter of the with_certificate_validation() method is trust_store_file_path. Have you tried passing /etc/ssl/certs?

Well, it gave me something:

2023-08-18 09:54:55,794 [WARNING] solace.messaging.core: [_solace_transport.py:84] [[SERVICE: 0x7f726dc14280] - [APP ID: eupq01/796/00000001/cyDP6jieow]] {‘caller_description’: ‘From service event callback’, ‘return_code’: ‘Ok’, ‘sub_code’: ‘SOLCLIENT_SUBCODE_FAILED_LOADING_TRUSTSTORE’, ‘error_info_sub_code’: 98, ‘error_info_contents’: “Session ‘(c0,s1)_default’: files in trust store ‘/etc/ssl/certs’ over the limit (64 files allowed)!”}

Guess this would be a dead end then. I’m a guest at this server and have no influence over the trust store.

Can you point to the certificate path directly? It would live at /etc/letsencrypt/live/domain_name.

the let’s encrypt certificate is on the broker server, this is the publisher server trying to push messages to the broker.

Oh right… so do you have some way of getting the public cert so you can put it on a folder with less files?

well no, not really, aside from doing it manually I guess, but I’m not looking forward to be doing that every 2 months. If only we could raise the limit of 64, that would make the most sense.