OpenSSL Command to check if a server is presenting a certificate

Question

I'm trying to run an openssl command to narrow down what the SSL issue might be when trying to send an outbound message from our system.

I found this command in another topic: Using openssl to get the certificate from a server

openssl s_client -connect ip:port -prexit

The output of this results in

CONNECTED(00000003)
15841:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 121 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

Does this mean the server isn't presenting any certificate? I tried other systems on a different ip:port and they present a certificate successfully.

Does mutual authentication affect this command with -prexit?

--Update--

I ran the command again

openssl s_client -connect ip:port -prexit

And I get this response now

CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 121 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

I added -ssl3 to the command

openssl s_client -connect ip:port -prexit -ssl3

Response:

CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : SSLv3
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    Key-Arg   : None
    Krb5 Principal: None
    Start Time: 1403907236
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

Also trying -tls1

CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    Key-Arg   : None
    Krb5 Principal: None
    Start Time: 1403907267
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

Can we move this to superuser? I found the question itself helpful as it already poses a workaround. — dannyman, Nov 19 '14 at 21:22
Be sure that you have used apn certificate, not ios development certificate. — Dharmik, Apr 17 '15 at 14:50

score 104 · Answer 1 · edited Dec 24 '22 at 02:57

104

I was debugging an SSL issue today which resulted in the same write:errno=104 error. Eventually I found out that the reason for this behaviour was that the server required SNI (servername TLS extensions) to work correctly. Supplying the -servername option to openssl made it connect successfully:

openssl s_client -connect domain.tld:443 -servername domain.tld

edited Dec 24 '22 at 02:57

starball

20,030
7
43
238

answered Mar 23 '15 at 16:32

piit79

1,256
1
8
13

1

If your goal is to see the certificate presented by a **MySql** server, then use `openssl s_client -starttls mysql -connect mysqlserver.mycorp.com:3306`. This is because MySql uses a custom communication protocol which is **not** http or https thus explaining why the same port can be used for both encrypted and clear data exchange. [Ref. MySql client/server protocol](https://dev.mysql.com/doc/dev/mysql-server/latest/PAGE_PROTOCOL.html). – Pierre C Mar 03 '22 at 16:58

score 13 · Answer 2 · answered Jun 27 '14 at 18:38

13

15841:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:
...
SSL handshake has read 0 bytes and written 121 bytes

This is a handshake failure. The other side closes the connection without sending any data ("read 0 bytes"). It might be, that the other side does not speak SSL at all. But I've seen similar errors on broken SSL implementation, which do not understand newer SSL version. Try if you get a SSL connection by adding -ssl3 to the command line of s_client.

answered Jun 27 '14 at 18:38

Steffen Ullrich

114,247
10
131
172

2

In the case of an older implementation, the `-ssl3` option might help. Conversely, if its a newer implementation, then the `tls1_2` option might help. But I would ensure there's an SSL/TLS server at that IP/Port first. – jww Jun 27 '14 at 20:28
2

@jww: if you don't specify he protocol with s_client it will try to do the best it can, so there should be no need to force it to use a newer version. But, I've seen several hosts which just close the connection if the Client Hello asks for TLS 1.1 or even TLS 1.0 because they only can understand SSL 3.0. – Steffen Ullrich Jun 27 '14 at 20:36
Thanks for the help! I'll check with the server (endpoint) if they are correctly implementing SSL on the server – R Zeal Jun 27 '14 at 22:16

score 8 · Answer 3 · answered Jun 15 '20 at 16:49

8

I encountered the write:errno=104 attempting to test connecting to an SSL-enabled RabbitMQ broker port with openssl s_client.

The issue turned out to be simply that the user RabbitMQ was running as did not have read permissions on the certificate file. There was little-to-no useful logging in RabbitMQ.

answered Jun 15 '20 at 16:49

em_bo

624
7
13

2

I ran into this very same issue, thanks for providing a solution. RabbitMQ logging (or rather the lack of it) was really not helpful for solving this issue - especially considering that during startup, it's supposed to check whether the ceritficates are readable, but apparently that check is not sufficient, even when RMQ (i was running it in a docker container) is running as root. All I ever got on the client side was a "connection reset by peer" whenever I tried to connect. Using s_client finally led me here (due to the `write:errno=104` error) – RobinFood Nov 25 '20 at 11:23

score 3 · Answer 4 · answered Apr 12 '20 at 00:05

3

I had a similar issue. The root cause was that the sending IP was not in the range of white-listed IPs on the receiving server. So, all requests for communication were killed by the receiving site.

answered Apr 12 '20 at 00:05

Sygyzmundovych

93
1
6

Thank you! I got the same case where an internal AWS load balancer was not configured to accept traffic from a set of our servers. Things work just fine after adjusting the firewall rules. – Tung Nguyen Mar 21 '23 at 04:55

score 2 · Answer 5 · answered Oct 23 '14 at 18:39

In my case the ssl certificate was not configured for all sites (only for the www version which the non-www version redirected to). I am using Laravel forge and the Nginx Boilerplate config

I had the following config for my nginx site:

/etc/nginx/sites-available/timtimer.at

server {
    listen [::]:80;
    listen 80;
    server_name timtimer.at www.timtimer.at;

    include h5bp/directive-only/ssl.conf;

    # and redirect to the https host (declared below)
    # avoiding http://www -> https://www -> https:// chain.
    return 301 https://www.timtimer.at$request_uri;
}

server {
    listen [::]:443 ssl spdy;
    listen 443 ssl spdy;

    # listen on the wrong host
    server_name timtimer.at;

    ### ERROR IS HERE ###
    # You eighter have to include the .crt and .key here also (like below)
    # or include it in the below included ssl.conf like suggested by H5BP

    include h5bp/directive-only/ssl.conf;

    # and redirect to the www host (declared below)
    return 301 https://www.timtimer.at$request_uri;
}

server {
    listen [::]:443 ssl spdy;
    listen 443 ssl spdy;

    server_name www.timtimer.at;

    include h5bp/directive-only/ssl.conf;

    # Path for static files
    root /home/forge/default/public;

    # FORGE SSL (DO NOT REMOVE!)
    ssl_certificate /etc/nginx/ssl/default/2658/server.crt;
    ssl_certificate_key /etc/nginx/ssl/default/2658/server.key;

    # ...

    # Include the basic h5bp config set
    include h5bp/basic.conf;
}

So after moving (cutting & pasting) the following part to the /etc/nginx/h5bp/directive-only/ssl.conf file everything worked as expected:

# FORGE SSL (DO NOT REMOVE!)
ssl_certificate /etc/nginx/ssl/default/2658/server.crt;
ssl_certificate_key /etc/nginx/ssl/default/2658/server.key;

So it is not enough to have the keys specified only for the www version even, if you only call the www version directly!

What the heck... this solved it for me. Why was this happening suddenly when it worked fine in the past? Did I upgrade some software without realizing? I know my nginx is still the same version from before. OpenSSL maybe? — RaisinBranCrunch, Jan 08 '19 at 23:59

score 1 · Answer 6 · answered Jun 25 '19 at 00:59

I was getting the below as well trying to get out to github.com as our proxy re-writes the HTTPS connection with their self-signed cert:

no peer certificate available No client certificate CA names sent

In my output there was also:

Protocol : TLSv1.3

I added -tls1_2 and it worked fine and now I can see which CA it is using on the outgoing request. e.g.:
openssl s_client -connect github.com:443 -tls1_2

score 0 · Answer 7 · answered Aug 17 '22 at 06:24

0

I have met the same problem . but use IP fine; I specify ip host in /etc/hosts

use IP work fine, but host can't

answered Aug 17 '22 at 06:24

Miller Qb

9
2

score 0 · Answer 8 · answered May 29 '23 at 12:40

0

I have had the same issue with rabbitmq tls , and I had to add the password to the rabbitmq config ssl_options.password = password123

answered May 29 '23 at 12:40

Stas

1

OpenSSL Command to check if a server is presenting a certificate

8 Answers8

Linked