主页 / server / 问题 / 1034382
Accepted
lucasart
Asked: 2020-09-18 23:53:58 +0800 CST

Certbot — 握手后新会话票到达

  • 772

在协商开始时，Secure Renegotiation IS NOT supported发生。在最后一次Session Ticket（也可能是之前的一次）中，似乎 SSL 连接成功了。你能告诉我这里发生了什么吗？我应该担心这一点，还是可以以任何方式“改善”谈判？

另外，为什么会发生两次Session Ticket？这是正常的吗？

# openssl s_client -connect mail.domainname.com:993

CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = domainname.com
verify return:1
---
Certificate chain
 0 s:CN = domainname.com
   i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
 1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFfTCCBGWgAwIBAgISA3ypOrf4bJNOWeDv4Ie2YB9MMA0GCSqGSIb3DQEBCwUA
...
nqq9VzUEakWQsLfHhNVwUe8=
-----END CERTIFICATE-----
subject=CN = domainname.com

issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3148 bytes and written 401 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 2148B9B6ABD8587E0B0975A132BBAFD41F2FD476396BB26433165D3C
    Session-ID-ctx: 
    Resumption PSK: C5ACAAACC034516A9E7868D4666840A9B1DC7ADBD3CBD466B3A7889082677FB995B6013E7FA7CC2BF0757D2D
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 35 0c 32 9e 9f 21 39 fc-6c 4d ae 2c c8 cb d3 58   5.2..!9.lM.,...X
    ...
    00d0 - 54 76 45 9a a4 f0 dc e0-6d 2b 7d fa 9a 63 2e 12   TvE.....m+}..c..

    Start Time: 1600415053
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 957C17A0A528F7D53C47CE7C8FDAF0A78E725DBA498D3DF91D39AB54
    Session-ID-ctx: 
    Resumption PSK: 31EDFF053862FD02E7C85973084FA2F26FE8A021F9EDF1DB51100B18B21D2F8A7F5AB7A43899B1A0507DD2E2
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 35 0c 32 9e 9f 21 39 fc-6c 4d ae 2c c8 cb d3 58   5.2..!9.lM.,...X
    ...
    00d0 - 55 db 93 6b 34 96 9d 95-13 e1 67 c8 5b 27 1c 60   U..k4.....g.['.`

    Start Time: 1600415053
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
* OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ AUTH=PLAIN AUTH=LOGIN] Dovecot (Ubuntu) ready.
postfix dovecot openssl ubuntu-20.04 certbot

1 个回答

  1. Best Answer

    最终，经过一番痛苦，我意识到这里的问题与 certbot/Letsencrypt 无关（正如 Michael Hampton 在上面的评论中所说），而是与 Virtualmin 有关，它有“自己的方式”通过 Apache 提供证书.

    因此，在通过 手动颁发证书后certbot，这里的解决方案是通过 Virtualmin 本身更新/刷新证书。就我而言，我刚刚更新了 CA 证书：Virtualmin -> domain.com -> Server Configuration -> SSL Certificate -> CA Certificate (enter the full path of the ssl.ca cert) -> Save Certificate.

    我确信可以让 Virtualmin 处理 Letsencrypt 证书的整个证书创建/更新，但我还没有检查过。

    • 0

相关问题