5

I'm troubleshooting making a TLS connection, and using openssl to do it. I'm unable to get the ARM computer (w/ Debian8) to connect to my server in GCP (mqtt:8883 to be exact). I generated self signed certificates on the server and installed them on the ARM computer, but it won't connect, clearly due to a certificate issue:

write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 0 bytes

On a windows machine I install certificates and openssl connects (openssl from MinGW/msys) and also my Debian 8 VM on that windows machine. So I'm confident the server is setup correctly, and I do get the concept of installing the certificates. (oddly, when I delete the certificate files I added, it STILL works... must be some caching, would like to know to clear that)

On the ARM machine that won't work, I've tried manually specifying the path (-CApath) or file (-CAfile).

How do I verify what certificates openssl is trying? Does it look in subfolders?

Could it be because the certs are self signed? (why would it work on the other machines then?)

More information: I tried openssl verify on the certificates on the ARM machine (the self signed, and the server certificate):

:/etc/ssl# openssl verify ca_certificates/ca.crt
ca_certificates/ca.crt: CN = An MQTT broker, O = OwnTracks.org, OU = generate-CA, emailAddress = [email protected]
error 18 at 0 depth lookup:self signed certificate
OK

:/etc/ssl# openssl verify ca_certificates/server.crt
ca_certificates/server.crt: CN = ########.com, O = OwnTracks.org, OU = generate-CA, emailAddress = [email protected]
error 20 at 0 depth lookup:unable to get local issuer certificate
Improve this question

1 Answer 1

Reset to default
4

clearly due to a certificate issue:

write:errno=104
...
SSL handshake has read 0 bytes and written 0 bytes

This is definitely not an issue of certificate validation. As you can see, it has send 0 bytes and got 0 bytes. This means the SSL handshake was not even started and therefore the client could have not received any certificates and therefore it can not be a problem with certificate validation.

In fact, errno 104 is ECONNRESET. This means that either the server closed the connection maybe due to problems with the setup or that the server was not even started or that there is some firewall between client and server blocking access. Given that the ECONNRESET happens before any data where sent I would suggest that the TCP handshake already failed, either because server was not started or a firewall.

Improve this answer
3
  • Thanks a bunch. I actually tried a nc -l -p 8883 (after stopping the real service on 8883 of course). A "nc" from the client went through ok... I guess I could also try TLS to the nc -l -p 8883 and see what comes through.
    – Michael
    Apr 25, 2017 at 21:45
  • yup. openssl from the ARM sends no data on the port. From the x86 I see correctly the SSL handshake binary content.
    – Michael
    Apr 25, 2017 at 22:48
  • 1
    Ended up being a firewall issue I think, check out this question: security.stackexchange.com/questions/158135/… (Am I facing an active firewall?)
    – Michael
    Apr 26, 2017 at 0:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .