OpenSSL 命令检查服务器是不是提供证书

Posted 2023-02-25

【中文标题】OpenSSL 命令检查服务器是不是提供证书

【英文标题】：OpenSSL Command to check if a server is presenting a certificateOpenSSL 命令检查服务器是否提供证书

【发布时间】：2014-08-18 21:26:29

【问题描述】：

我正在尝试运行 openssl 命令以缩小在尝试从我们的系统发送出站消息时可能出现的 SSL 问题。

我在另一个主题中找到了这个命令：Using openssl to get the certificate from a server

openssl s_client -connect ip:port -prexit

这个结果的输出

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:port 上尝试了其他系统，它们成功提供了证书。

相互身份验证是否会影响带有 -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)
---

【问题讨论】：

我们可以将其移至超级用户吗？我发现这个问题本身很有帮助，因为它已经提出了一种解决方法。

确保你使用的是apn证书，而不是ios开发证书。

【参考方案1】：

我今天正在调试一个 SSL 问题，导致同样的 write:errno=104 错误。最终我发现这种行为的原因是服务器需要 SNI（servername TLS 扩展）才能正常工作。向 openssl 提供 -servername 选项使其连接成功：

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

希望这会有所帮助。

【讨论】：

如果您的目标是查看 mysql 服务器提供的证书，请使用openssl s_client -starttls mysql -connect mysqlserver.mycorp.com:3306。这是因为 MySql 使用自定义的通信协议，不是 http 或 https，因此解释了为什么同一端口可用于加密和明文数据交换。 Ref. MySql client/server protocol.

【参考方案2】：

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

这是握手失败。另一端关闭连接而不发送任何数据（“读取 0 字节”）。可能是对方根本不会说 SSL。但是我在损坏的 SSL 实现中看到了类似的错误，这些错误不理解较新的 SSL 版本。尝试通过在 s_client 的命令行中添加 -ssl3 来获得 SSL 连接。

【讨论】：

对于较旧的实现，-ssl3 选项可能会有所帮助。相反，如果它是一个较新的实现，那么tls1_2 选项可能会有所帮助。但我会先确保该 IP/端口有一个 SSL/TLS 服务器。

@jww：如果你没有用 s_client 指定他的协议，它会尽力做到最好，所以不需要强制它使用更新的版本。但是，如果 Client Hello 要求 TLS 1.1 甚至 TLS 1.0，我已经看到几个主机只是关闭连接，因为它们只能理解 SSL 3.0。

感谢您的帮助！如果他们在服务器上正确实现 SSL，我会检查服务器（端点）

【参考方案3】：

我遇到了 write:errno=104 尝试使用 openssl s_client 测试连接到启用 SSL 的 RabbitMQ 代理端口。

问题只是因为运行 RabbitMQ 的用户没有证书文件的读取权限。 RabbitMQ 中几乎没有有用的日志记录。

【讨论】：

我遇到了同样的问题，感谢您提供解决方案。 RabbitMQ 日志记录（或更确切地说是缺少它）对于解决这个问题确实没有帮助 - 特别是考虑到在启动期间，它应该检查证书是否可读，但显然检查是不够的，即使 RMQ（我正在运行它在 docker 容器中）以 root 身份运行。每当我尝试连接时，我在客户端所得到的只是“对等方重置连接”。使用 s_client 终于把我带到了这里（由于write:errno=104 错误）

【参考方案4】：

在我的情况下，没有为所有站点配置 ssl 证书（仅适用于非 www 版本重定向到的 www 版本）。我正在使用 Laravel forge 和 nginx Boilerplate config

我的 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 版本指定键也是不够的！

【讨论】：

这到底是什么......这为我解决了它。为什么过去运行良好时突然发生这种情况？我是否在不知不觉中升级了某些软件？我知道我的 nginx 仍然是以前的版本。也许是 OpenSSL？

【参考方案5】：

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

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

在我的输出中还有：

协议：TLSv1.3

我添加了-tls1_2，它运行良好，现在我可以看到它在传出请求中使用的是哪个 CA。例如：openssl s_client -connect github.com:443 -tls1_2

【参考方案6】：

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