Score:0

SSL certificate is not valid when the server is connecting itself

in flag

I have a local network where the [server] server's ip address is: 192.168.88.201, host: local.mydomain.com. This server is Ubuntu 18.04.6 LTS running Apache+PHP. Also this server has Let's encrypt SSL installed using certbot.

When using another computer on the local network the SSL works fine accessing https://local.mydomain.com -> Chrome shows that certification is valid.

The problem comes when the server connect itself and it thinks that the certification is not valid.

I'm stuck here as I'm not sure where the problem might be. Do you have any suggestion?

For example: In [SERVER]'s terminal, when:

root@server:/tmp# wget https://local.mydomain.com
--2022-01-07 07:47:18--  https://local.mydomain.com/
Resolving local.mydomain.com (local.mydomain.com)... 192.168.88.201
Connecting to local.mydomain.com (local.mydomain.com)|192.168.88.201|:443... connected.
ERROR: cannot verify local.mydomain.com's certificate, issued by ‘CN=R3,O=Let's Encrypt,C=US’:
  Unable to locally verify the issuer's authority.
To connect to local.mydomain.com insecurely, use `--no-check-certificate'.
root@server:/tmp# openssl s_client -connect local.mydomain.com:443 -prexit > a.txt
CONNECTED(00000005)
---
Certificate chain
 0 s:CN = local.mydomain.com
   i:C = US, O = Let's Encrypt, CN = R3
---
Server certificate
-----BEGIN CERTIFICATE-----
***
-----END CERTIFICATE-----
subject=CN = local.mydomain.com

issuer=C = US, O = Let's Encrypt, CN = R3

---
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 2005 bytes and written 402 bytes
Verification error: unable to verify the first certificate
---
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: 21 (unable to verify the first certificate)
---
HTTP/1.1 400 Bad Request
Date: Fri, 07 Jan 2022 06:53:07 GMT
Server: Apache/2.4.29 (Ubuntu)
Content-Length: 313
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
<hr>
<address>Apache/2.4.29 (Ubuntu) Server at local.mydomain.com Port 443</address>
</body></html>
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: E5F662F909BA717C5FA0D6DBBDA777CA284E164FACC4784915D7E08DF39B63DB
    Session-ID-ctx:
    Resumption PSK: FFA7F4A4502316545E4147887CE4A7D552DDF54A92A8C2B5D87601BEA01B8DDEC2292004635AC152E71188CEDEF099CE
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 ****

    Start Time: 1641538382
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
    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: BABB13C496B291A43F4FDDCD20FE5568574F79ACA2D06203A53D9072FBE3A2C8
    Session-ID-ctx:
    Resumption PSK: 90F330C4D3B9BA54DB4CA687400E692CC7AF250F7E6A58493D579A9DD6C3DBA3E5B1F2BA94DA7AEA8CF483C2FB19211B
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - ***

    Start Time: 1641538382
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
---
Certificate chain
 0 s:CN = local.mydomain.com
   i:C = US, O = Let's Encrypt, CN = R3
---
Server certificate
-----BEGIN CERTIFICATE-----
***
-----END CERTIFICATE-----
subject=CN = local.mydomain.com

issuer=C = US, O = Let's Encrypt, CN = R3

---
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 3152 bytes and written 450 bytes
Verification error: unable to verify the first certificate
---
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: 21 (unable to verify the first certificate)
---
Score:2
se flag
Certificate chain
 0 s:CN = local.mydomain.com
   i:C = US, O = Let's Encrypt, CN = R3

The server is misconfigured and only sends an incomplete chain, missing the intermediate certificates. A properly configured site should instead return an additional intermediate certificate, leading to ISRG Root X1. Let's Encrypt has an example server for this:

$ openssl s_client -connect valid-isrgrootx1.letsencrypt.org:443
...
Certificate chain
 0 s:CN = valid-isrgrootx1.letsencrypt.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

When using another computer ... Chrome shows that certification is valid.

Browser will usually successfully work around such misconfiguration by downloading the missing intermediate certificates or using cached copies. Other clients will not. So it's not a good idea to only check if it works with the browser. Use instead sites like SSL Labs which would report "chain issues" as problem in your case.

in flag
Thank you, you were right! It turned out in the apache config I have to use fullchain.pem instead of cert.pem. SSLCertificateFile /etc/letsencrypt/live/local.mydomain.com/cert.pem -> SSLCertificateFile /etc/letsencrypt/live/local.mydomain.com/fullchain.pem
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.