Chain of trust NOT ok (expired) for Dino XMPP client

Help
1

Hi Friends!
This afternoon (in the morning this problem was not there), running Dino XMPP Linux client for connecting to my own Prosody server 0.11.5-1 hosted on Debian9, obtain the error:
"Unable to connect to server, TLS certificate not valid".

So deepening the issue, I check the certificate on server side and all seems ok, so I run the testssl.sh tool that tell me: "Chain of trust NOT ok".
I'm using "acme.sh" as Let's Encrypt client.

Here the output of testssl.sh:

 Testing protocols via sockets 

 SSLv2      not offered (OK)
 SSLv3      not offered (OK)
 TLS 1      offered (deprecated)
 TLS 1.1    offered (deprecated)
 TLS 1.2    offered (OK)
 TLS 1.3    offered (OK): final

 Testing cipher categories 

 NULL ciphers (no encryption)                  not offered (OK)
 Anonymous NULL Ciphers (no authentication)    not offered (OK)
 Export ciphers (w/o ADH+NULL)                 not offered (OK)
 LOW: 64 Bit + DES, RC[2,4] (w/o export)       not offered (OK)
 Triple DES Ciphers / IDEA                     not offered
 Obsolete CBC ciphers (AES, ARIA etc.)         offered
 Strong encryption (AEAD ciphers)              offered (OK)


 Testing robust (perfect) forward secrecy, (P)FS -- omitting Null Authentication/Encryption, 3DES, RC4 

 PFS is offered (OK)          TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES256-SHA
                              ECDHE-RSA-CHACHA20-POLY1305 ECDHE-RSA-CAMELLIA256-SHA384 ECDHE-ARIA256-GCM-SHA384 TLS_AES_128_GCM_SHA256
                              ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA ECDHE-RSA-CAMELLIA128-SHA256 ECDHE-ARIA128-GCM-SHA256 
 Elliptic curves offered:     prime256v1 secp384r1 secp521r1 


 Testing server preferences 

 Has server cipher order?     yes (OK) -- TLS 1.3 and below
 Negotiated protocol          TLSv1.3
 Negotiated cipher            TLS_AES_256_GCM_SHA384, 256 bit ECDH (P-256)
 Cipher order
    TLSv1:     ECDHE-RSA-AES256-SHA ECDHE-RSA-AES128-SHA AES256-SHA CAMELLIA256-SHA AES128-SHA CAMELLIA128-SHA 
    TLSv1.1:   ECDHE-RSA-AES256-SHA ECDHE-RSA-AES128-SHA AES256-SHA CAMELLIA256-SHA AES128-SHA CAMELLIA128-SHA 
    TLSv1.2:   ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-CHACHA20-POLY1305 ECDHE-ARIA256-GCM-SHA384 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ARIA128-GCM-SHA256
               ECDHE-RSA-AES256-SHA384 ECDHE-RSA-CAMELLIA256-SHA384 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-CAMELLIA128-SHA256 ECDHE-RSA-AES256-SHA
               ECDHE-RSA-AES128-SHA AES256-GCM-SHA384 AES256-CCM8 AES256-CCM ARIA256-GCM-SHA384 AES128-GCM-SHA256 AES128-CCM8 AES128-CCM ARIA128-GCM-SHA256
               AES256-SHA256 CAMELLIA256-SHA256 AES128-SHA256 CAMELLIA128-SHA256 AES256-SHA CAMELLIA256-SHA AES128-SHA CAMELLIA128-SHA 
    TLSv1.3:   TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 


 Testing server defaults (Server Hello) 

 TLS extensions (standard)    "renegotiation info/#65281" "EC point formats/#11" "supported versions/#43" "key share/#51" "supported_groups/#10"
                              "max fragment length/#1" "encrypt-then-mac/#22" "extended master secret/#23"
 Session Ticket RFC 5077 hint no -- no lifetime advertised
 SSL Session ID support       yes
 Session Resumption           Tickets no, ID: no
 TLS clock skew               Random values, no fingerprinting possible 
 Signature Algorithm          SHA256 with RSA
 Server key size              RSA 2048 bits
 Server key usage             Digital Signature, Key Encipherment
 Server extended key usage    TLS Web Server Authentication, TLS Web Client Authentication
 Serial / Fingerprints        0429AF3DA5AD9F545FB00FB3DD1815C89D28 / SHA1 3EDB59C827E973BF2148331F5955E45E9B9D671F
                              SHA256 D9022C2855CECB15EC2DD9C785FF4B6844426F2E94C1F5D4727616FF915AF20B
 Common Name (CN)             server.3x1t.org 
 subjectAltName (SAN)         3x1t.org attivazione.3x1t.org autoconfig.3x1t.org autodiscover.3x1t.org cloud.3x1t.org collabora.3x1t.org conference.3x1t.org
                              converse.3x1t.org lists.3x1t.org mail.3x1t.org server.3x1t.org smtp.3x1t.org turn.3x1t.org upload.3x1t.org upload.server.3x1t.org
                              www.3x1t.org www.converse.3x1t.org 
 Issuer                       R3 (Let's Encrypt from US)
 Trust (hostname)             Ok via SAN (same w/o SNI)
 Chain of trust               NOT ok (expired)
 EV cert (experimental)       no 
 ETS/"eTLS", visibility info  not present
 Certificate Validity (UTC)   88 >= 60 days (2021-09-28 23:23 --> 2021-12-27 22:23)
 # of certificates provided   3
 Certificate Revocation List  --
 OCSP URI                     http://r3.o.lencr.org
 OCSP stapling                not offered
 OCSP must staple extension   --
 DNS CAA RR (experimental)    not offered
 Certificate Transparency     yes (certificate extension)


 Testing vulnerabilities 

 Heartbleed (CVE-2014-0160)                not vulnerable (OK), no heartbeat extension
 CCS (CVE-2014-0224)                       not vulnerable (OK)
 ROBOT                                     not vulnerable (OK)
 Secure Renegotiation (RFC 5746)           supported (OK)
 Secure Client-Initiated Renegotiation     VULNERABLE (NOT ok), potential DoS threat
 CRIME, TLS (CVE-2012-4929)                not vulnerable (OK) (not using HTTP anyway)
 POODLE, SSL (CVE-2014-3566)               not vulnerable (OK), no SSLv3 support
 TLS_FALLBACK_SCSV (RFC 7507)              Downgrade attack prevention supported (OK)
 SWEET32 (CVE-2016-2183, CVE-2016-6329)    not vulnerable (OK)
 FREAK (CVE-2015-0204)                     not vulnerable (OK)
 DROWN (CVE-2016-0800, CVE-2016-0703)      not vulnerable on this host and port (OK)
                                           make sure you don't use this certificate elsewhere with SSLv2 enabled services
                                           https://censys.io/ipv4?q=D9022C2855CECB15EC2DD9C785FF4B6844426F2E94C1F5D4727616FF915AF20B could help you to find out
 LOGJAM (CVE-2015-4000), experimental      not vulnerable (OK): no DH EXPORT ciphers, no DH key detected with <= TLS 1.2
 BEAST (CVE-2011-3389)                     TLS1: ECDHE-RSA-AES256-SHA ECDHE-RSA-AES128-SHA AES256-SHA CAMELLIA256-SHA AES128-SHA CAMELLIA128-SHA 
                                           VULNERABLE -- but also supports higher protocols  TLSv1.1 TLSv1.2 (likely mitigated)
 LUCKY13 (CVE-2013-0169), experimental     potentially VULNERABLE, uses cipher block chaining (CBC) ciphers with TLS. Check patches
 RC4 (CVE-2013-2566, CVE-2015-2808)        no RC4 ciphers detected (OK)


 Testing 370 ciphers via OpenSSL plus sockets against the server, ordered by encryption strength 

Hexcode  Cipher Suite Name (OpenSSL)       KeyExch.   Encryption  Bits     Cipher Suite Name (IANA/RFC)
-----------------------------------------------------------------------------------------------------------------------------
 x1302   TLS_AES_256_GCM_SHA384            ECDH 256   AESGCM      256      TLS_AES_256_GCM_SHA384                             
 x1303   TLS_CHACHA20_POLY1305_SHA256      ECDH 256   ChaCha20    256      TLS_CHACHA20_POLY1305_SHA256                       
 xc030   ECDHE-RSA-AES256-GCM-SHA384       ECDH 384   AESGCM      256      TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384              
 xc028   ECDHE-RSA-AES256-SHA384           ECDH 384   AES         256      TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384              
 xc014   ECDHE-RSA-AES256-SHA              ECDH 384   AES         256      TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA                 
 xcca8   ECDHE-RSA-CHACHA20-POLY1305       ECDH 384   ChaCha20    256      TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256        
 xc077   ECDHE-RSA-CAMELLIA256-SHA384      ECDH 384   Camellia    256      TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384         
 x9d     AES256-GCM-SHA384                 RSA        AESGCM      256      TLS_RSA_WITH_AES_256_GCM_SHA384                    
 xc0a1   AES256-CCM8                       RSA        AESCCM8     256      TLS_RSA_WITH_AES_256_CCM_8                         
 xc09d   AES256-CCM                        RSA        AESCCM      256      TLS_RSA_WITH_AES_256_CCM                           
 x3d     AES256-SHA256                     RSA        AES         256      TLS_RSA_WITH_AES_256_CBC_SHA256                    
 x35     AES256-SHA                        RSA        AES         256      TLS_RSA_WITH_AES_256_CBC_SHA                       
 xc0     CAMELLIA256-SHA256                RSA        Camellia    256      TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256               
 x84     CAMELLIA256-SHA                   RSA        Camellia    256      TLS_RSA_WITH_CAMELLIA_256_CBC_SHA                  
 xc051   ARIA256-GCM-SHA384                RSA        ARIAGCM     256      TLS_RSA_WITH_ARIA_256_GCM_SHA384                   
 xc061   ECDHE-ARIA256-GCM-SHA384          ECDH 384   ARIAGCM     256      TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384             
 x1301   TLS_AES_128_GCM_SHA256            ECDH 256   AESGCM      128      TLS_AES_128_GCM_SHA256                             
 xc02f   ECDHE-RSA-AES128-GCM-SHA256       ECDH 384   AESGCM      128      TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256              
 xc027   ECDHE-RSA-AES128-SHA256           ECDH 384   AES         128      TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256              
 xc013   ECDHE-RSA-AES128-SHA              ECDH 384   AES         128      TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA                 
 xc0a0   AES128-CCM8                       RSA        AESCCM8     128      TLS_RSA_WITH_AES_128_CCM_8                         
 xc09c   AES128-CCM                        RSA        AESCCM      128      TLS_RSA_WITH_AES_128_CCM                           
 xc076   ECDHE-RSA-CAMELLIA128-SHA256      ECDH 384   Camellia    128      TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256         
 x9c     AES128-GCM-SHA256                 RSA        AESGCM      128      TLS_RSA_WITH_AES_128_GCM_SHA256                    
 x3c     AES128-SHA256                     RSA        AES         128      TLS_RSA_WITH_AES_128_CBC_SHA256                    
 x2f     AES128-SHA                        RSA        AES         128      TLS_RSA_WITH_AES_128_CBC_SHA                       
 xba     CAMELLIA128-SHA256                RSA        Camellia    128      TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256               
 x41     CAMELLIA128-SHA                   RSA        Camellia    128      TLS_RSA_WITH_CAMELLIA_128_CBC_SHA                  
 xc050   ARIA128-GCM-SHA256                RSA        ARIAGCM     128      TLS_RSA_WITH_ARIA_128_GCM_SHA256                   
 xc060   ECDHE-ARIA128-GCM-SHA256          ECDH 384   ARIAGCM     128      TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256             


 Running client simulations via sockets 

 Android 8.1 (native)         TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384)
 Android 9.0 (native)         TLSv1.3 TLS_AES_256_GCM_SHA384, 384 bit ECDH (P-384)
 Android 10.0 (native)        TLSv1.3 TLS_AES_256_GCM_SHA384, 384 bit ECDH (P-384)
 Java 6u45                    TLSv1.0 AES128-SHA, No FS
 Java 7u25                    TLSv1.0 ECDHE-RSA-AES128-SHA, 384 bit ECDH (P-384)
 Java 8u161                   TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384)
 Java 11.0.2 (OpenJDK)        TLSv1.3 TLS_AES_256_GCM_SHA384, 256 bit ECDH (P-256)
 Java 12.0.1 (OpenJDK)        TLSv1.3 TLS_AES_256_GCM_SHA384, 256 bit ECDH (P-256)
 OpenSSL 1.0.2e               TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384)
 OpenSSL 1.1.0l (Debian)      TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 384 bit ECDH (P-384)
 OpenSSL 1.1.1d (Debian)      TLSv1.3 TLS_AES_256_GCM_SHA384, 384 bit ECDH (P-384)

 Done 2021-09-30 17:51:12 [ 175s] -->> 3x1t.org:5222 (3x1t.org) <<--

Could you give me any suggestion about?

Many thanks!

davide

2

For further diagnosis we need the hostname to see what's going wrong. The testssl output doesn't show the certificate chain, which is what's important here.

Multiple CA certificates used by Let's Encrypt have expired very recently, which is probably why you're seeing errors.

1 Like
3

Taking the first name seen, I get:

---
Certificate chain
 0 s:/CN=server.3x1t.org
   i:/C=US/O=Let's Encrypt/CN=R3
 1 s:/C=US/O=Let's Encrypt/CN=R3
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
 2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---

If that is the FQDN, please confirm the port (presumed 443) that is giving trouble.
If that is NOT the FQDN, then please provide it and the port used.

If it is the FQDN and port that is giving trouble...
Then try removing the last cert from the fullchain.pem file.

4

Hi @rg305 and @Nummer378, yes FQDN is server.3x1t.org

Yes port 443 for https, but for Prosody/Dino:

|5000/tcp |File transfer proxy|
|5222/tcp |Client connections|
|5269/tcp |Server-to-server connections|
|5280/tcp |HTTP|
|5281/tcp |HTTPS|
|5347/tcp |External components|

Actually for Prosody, I'm using only ".key" and ".crt" should anyway to remove the last cert from "fullchain.pem"?

Thanks!

5

Please show the .crt file [or count the certs therein]
If only one cert inside, then that is not good.
[should be more like fullchain.pem]

1 Like
6

three certs on .crt and three into fullchain.cer between them perfectly corresponding.

Thanks!

1 Like
7

Well,
to continue troubleshooting the problem should I now remove the last cert from .crt?
And for future renewals how should it be managed? :-\

Thanks again!

1 Like
8

It depends on the ACME client used.
The setting is called --preferred-chain
and you would append the desired alternate, in this case use "ISRG Root X1"

--preferred-chain "ISRG Root X1"

1 Like
9

Sure, I was seen on official acme.sh github this issue where explain the same situation whom you describe,
where it is indicated to use as parameter:

"isrg"

If possible, what are the differences between two parameters "ISRG Root X1" and "isrg" ?

Thanks again!

10

That may be an ACME client side implementation.
Read the --help for the ACME client you use.
I know "ISRG Root X1" works with certbot 1.12+

EDIT: It seems "isrg" is used with the acme.sh client.

1 Like
11

For Letsencrypt.org Production server:There are 2 chains provided:

Name Default
DST Root CA X3 Yes
ISRG Root X1 No

You select the ca like:

acme.sh  --issue -d example.com .....  --server letsencrypt   --preferred-chain  "ISRG Root X1"

You can also use part of the name:

acme.sh  --issue -d example.com .....  --server letsencrypt   --preferred-chain  "ISRG"

It's also case-insensitive:

acme.sh  --issue -d example.com .....  --server letsencrypt    --preferred-chain  "isrg"

They all seem equivalent.

Many thanks for your patience!

I will soon apply the changes and I will update :wink:

1 Like
12

Have a look at:

2 Likes
13

Yes, confirm, for my situation this is the right way!

Thanks!

1 Like
14

Very interesting, but also very worrying for certbot users on CentOS 7!
I hope they solve :wink:

1 Like
15

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.