用于检查服务器是否正在提供证书的OpenSSL命令

我正在尝试运行openssl命令，以缩小试图从系统发送出站消息时SSL问题的范围

我在另一个主题中找到此命令：

这个结果的输出是

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
---

这是否意味着服务器没有提供任何证书？我在不同的ip:端口上尝试了其他系统，它们成功地提供了证书

相互身份验证是否影响使用-prexit的此命令

--更新--

我再次执行命令

openssl s_client -connect ip:port -prexit

我现在得到了这个回应

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
---

我在命令中添加了-ssl3

openssl s_client -connect ip:port -prexit -ssl3

答复：

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)
---

也在尝试-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)
---

---

这是一次握手失败。另一端关闭连接而不发送任何数据（“读取0字节”）。另一方可能根本不讲SSL。但我在损坏的SSL实现上也看到过类似的错误，它们不理解较新的SSL版本。如果您通过将

-ssl3

添加到s_客户端的命令行来获得SSL连接，请重试。

在我的情况下，SSL证书没有为所有站点配置（仅针对非www版本重定向到的www版本）。我使用的是拉威尔锻造厂和

我的nginx站点有以下配置：

/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;
}

因此，在将以下部分移动（剪切和粘贴）到/etc/nginx/h5bp/directive only/ssl.conf文件后，一切都正常工作：

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

---

因此，仅为www版本指定密钥是不够的，即使您仅直接调用www版本也是如此

我今天调试了一个SSL问题，导致了相同的

write:errno=104

错误。最终我发现，这种行为的原因是服务器需要SNI（

servername

TLS扩展）才能正常工作。将

-servername

选项提供给openssl使其连接成功：

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

---

希望这能有所帮助。

当我们的代理用他们的自签名证书重新写入HTTPS连接时，我也尝试访问github.com，获得了以下信息：

没有可用的对等证书 未发送客户端证书CA名称

在我的输出中，还有：

协议：TLSv1.3

我添加了

-tls1_2

，它工作得很好，现在我可以看到它在传出请求中使用了哪个CA。e、 g.：

---

openssl s_客户端-connect github.com:443-tls1_2

我遇到了类似的问题。根本原因是发送IP不在接收服务器上的白名单IP范围内。因此，所有通信请求都被接收站点终止。

我遇到了试图使用openssl s_客户端测试连接到启用SSL的RabbitMQ代理端口的

write:errno=104

---

问题很简单，用户RabbitMQ正在运行，因为它对证书文件没有读取权限。RabbitMQ中几乎没有有用的日志记录

对于较旧的实现，

-ssl3

选项可能会有所帮助。相反，如果是较新的实现，那么

tls1_2

选项可能会有所帮助。但我会首先确保在该IP/端口上有SSL/TLS服务器。@jww:如果您不指定s_客户端的协议，它将尽力做到最好，因此不需要强制它使用更新的版本。但是，我见过一些主机，如果客户机Hello要求TLS 1.1甚至TLS 1.0，它们会关闭连接，因为它们只能理解SSL 3.0。感谢您的帮助！我将与服务器（端点）检查他们是否在服务器上正确实现了SSL。我们可以将此移到超级用户吗？我发现这个问题本身很有帮助，因为它已经提出了一个解决办法。请确保您使用的是apn证书，而不是ios开发证书。见鬼。。。这为我解决了问题。为什么它在过去运行良好时突然发生这种情况？我升级了一些软件而没有意识到吗？我知道我的nginx还是以前的版本。也许是OpenSSL？我遇到了同样的问题，谢谢你提供了一个解决方案。RabbitMQ日志记录（或者更确切地说是缺少日志记录）对解决这个问题没有帮助——特别是考虑到在启动期间，它应该检查CertFactes是否可读，但显然，即使RMQ（我在docker容器中运行它）作为根运行，检查仍然不够。每当我尝试连接时，我在客户端得到的只是一个“对等重设连接”。使用s_客户端最终将我带到了这里（由于

write:errno=104

错误）

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

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