0

At the start of the negociation, Secure Renegotiation IS NOT supported occurs. During the last Session Ticket (and perhaps the one before), it seems that the SSL connection succeeded. Could you let me know what is happening here? Should I worry about this, or can the negociation be 'improved' in any way?

Also, why are there two Session Ticket taking place? Is this normal?

# 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.
lucasart
  • 123
  • 1
  • 9
  • Why is this tagged certbot? It has nothing to do with certbot. You should use appropriate tags, such as something for the mail server software you are connecting to. – Michael Hampton Sep 18 '20 at 17:06
  • @MichaelHampton, perhaps you could tell me why it has nothing to do with certbot? How could I have known that? — I added new tags – lucasart Sep 19 '20 at 02:59
  • Because how you got the certificate has no relevance to the problem you're experiencing. – Michael Hampton Sep 19 '20 at 03:15
  • @MichaelHampton, any further detail or explanation would be highly appreciated. – lucasart Sep 19 '20 at 09:04
  • 1
    You are using a server that supports TLS 1.3, and testing with OpenSSL 1.1.1 which also does so. The secure-renegotiation extension (RFC5756) is no longer used or needed in 1.3 because it no longer does any renegotiation, or even resumption with prior secret. Yes there may be multiple 'tickets' in 1.3; the protocol is changed so that they aren't really tickets, just saved PSKs. This is all explained in the 1.3 spec, RFC8446. – dave_thompson_085 Oct 07 '20 at 08:16

1 Answers1

0

Eventually, after much pain, I realized that the issue here had nothing to do with certbot/Letsencrypt (as stated by Michael Hampton in the comments above), but was related to Virtualmin, which has "its own way" to present certificates through Apache.

So, after manually issuing certs via certbot, the solution here was to update/refresh certs via Virtualmin itself. In my case, I just updated the CA cert: Virtualmin -> domain.com -> Server Configuration -> SSL Certificate -> CA Certificate (enter the full path of the ssl.ca cert) -> Save Certificate.

I'm sure it's possible to have Virtualmin handle the whole certificate creation/renewal of the Letsencrypt certs, but I have not checked that out just yet.

lucasart
  • 123
  • 1
  • 9