Cert is unsigned - Fullchain issues

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: t-wirth.de / backprod.de

The operating system my web server runs on is (include version): Ubunu 20.04.2

I can login to a root shell on my machine (yes or no, or I don't know): Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): Webmin / Command Line

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 0.40.0

I have two domains both are using letsecrypt certificates. For one domain I'm getting the cert is unsigned message when running https://www.checktls.com/

Output for t-wirth.de:
[000.743] Connection converted to SSL
SSLVersion in use: TLSv1_3
Cipher in use: TLS_AES_256_GCM_SHA384
Perfect Forward Secrecy: yes
Certificate #1 of 4 (sent by MX):
Cert signed by: #2
Cert VALIDATED: ok
Cert Hostname VERIFIED (mail.t-wirth.de = .t-wirth.de | DNS:.t-wirth.de | DNS:t-wirth.de)
Not Valid Before: Jun 20 08:03:58 2021 GMT
Not Valid After: Sep 18 08:03:57 2021 GMT
subject= /CN=*.t-wirth.de
issuer= /C=US/O=Let's Encrypt/CN=R3
Certificate #2 of 4 (sent by MX):
Cert signed by: #3, #4
Cert VALIDATED: ok
Not Valid Before: Sep 4 00:00:00 2020 GMT
Not Valid After: Sep 15 16:00:00 2025 GMT
subject= /C=US/O=Let's Encrypt/CN=R3
issuer= /C=US/O=Internet Security Research Group/CN=ISRG Root X1
Certificate #3 of 4 (added from CA Root Store):
Cert signed by: #3, #4
Cert VALIDATED: ok
Not Valid Before: Jun 4 11:04:38 2015 GMT
Not Valid After: Jun 4 11:04:38 2035 GMT
subject= /C=US/O=Internet Security Research Group/CN=ISRG Root X1
issuer= /C=US/O=Internet Security Research Group/CN=ISRG Root X1
Certificate #4 of 4 (sent by MX):
Cert is unsigned
Cert VALIDATED:
Not Valid Before: Jan 20 19:14:03 2021 GMT
Not Valid After: Sep 30 18:14:03 2024 GMT
subject= /C=US/O=Internet Security Research Group/CN=ISRG Root X1
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3

When doing the same on backprod.de the output is:
[001.822] Connection converted to SSL
SSLVersion in use: TLSv1_3
Cipher in use: TLS_AES_256_GCM_SHA384
Perfect Forward Secrecy: yes
Certificate #1 of 3 (sent by MX):
Cert signed by: #2
Cert VALIDATED: ok
Cert Hostname VERIFIED (mail.backprod.de = .backprod.de | DNS:.backprod.de | DNS:backprod.de)
Not Valid Before: May 1 00:05:46 2021 GMT
Not Valid After: Jul 30 00:05:46 2021 GMT
subject= /CN=*.backprod.de
issuer= /C=US/O=Let's Encrypt/CN=R3
Certificate #2 of 3 (sent by MX):
Cert signed by: #3
Cert VALIDATED: ok
Not Valid Before: Oct 7 19:21:40 2020 GMT
Not Valid After: Sep 29 19:21:40 2021 GMT
subject= /C=US/O=Let's Encrypt/CN=R3
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3
Certificate #3 of 3 (added from CA Root Store):
Cert signed by: #3
Cert VALIDATED: ok
Not Valid Before: Sep 30 21:12:19 2000 GMT
Not Valid After: Sep 30 14:01:15 2021 GMT
subject= /O=Digital Signature Trust Co./CN=DST Root CA X3
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3

Which means the whole chain seems to be different.

When running the command
openssl s_client -connect mail.t-wirth.de:25 -starttls smtp

Certificate chain
0 s:CN = *.t-wirth.de
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

openssl s_client -connect mail.backprod.de:25 -starttls smtp
Certificate chain
0 s:CN = *.backprod.de
i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = R3
i:O = Digital Signature Trust Co., CN = DST Root CA X3

Any Ideas? I recreated the t-wirth certificate today but this did not change anything. The creation of the backprod.de was a while ago. I have checked the fullchain files and the old one (backprod.de) only includes two parts, whereas the new one contains 3 parts (t-wirth.de). Is this unsigned message something I should be worried about and which could be avoided? I don't see a difference in creating the certificates there are both created by the dehydrated script and at least currently the configuration files are identical. I'm also using the letsencrypt tool byself with another domain which is getting the same warning.

A second thing which I noticed is that:
t-wirth.de - TLS / STARTTLS Test · SSL-Tools is running into errors (no certificates found - which does not make sense at all) whereas
backprod.de - TLS / STARTTLS Test · SSL-Tools is running without problems.

Other test pages telling me SSL / DANE is good for both domains.

e.g. Hardenize Report: t-wirth.de

I have also checked older versions for the full chains from the same domains. In past they had two parts, now 3 and the warning seems to be connected to that change. The old files (without warning and two parts) are from April, the newer ones (with 3 parts and warning) from May. And it does not matter if they are created with dehydrated or letsencrypt. Seems to be that this changed happened in May. Could be an update on certbot in ubuntu repositories maybe. Have I missed a configurable change in behavior?

1 Like

I'm pretty sure that test site is erroneous. It mentions your mailserver is sending the ISRG Root X1 self-signed root certificate, but it isn't! As you've already shown yourself, your mail.t-wirth.de mailserver is sending the cross-signed ISRG Root X1 certificate, as shown by the "i:" with the DST Root CA X3 root certificate.

For some reason, the SSL test website thinks it has to build its own certificate chain somehow, in stead of using the certificates acutally send by the mailserver. This is very likely a bug in their software, not your mailserver.

2 Likes

Thanks for the feedback. And the change in the fullchain. Is this something which is documented somewhere? I have searched a bit but until now I have not found something connected to that.

openssl s_client -connect mail.t-wirth.de:25 -starttls smtp
Certificate chain
0 s:CN = *.t-wirth.de
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

openssl s_client -connect mail.backprod.de:25 -starttls smtp
Certificate chain
0 s:CN = *.backprod.de
i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = R3
i:O = Digital Signature Trust Co., CN = DST Root CA X3

If I I take a look in the older version of t-wirth.de is looks like the version of backprod.de.

1 Like

Please see the API Announcements category.

3 Likes

Thanks again. I got a feedback from checktls:
I believe the Osiris answer on the thread you referenced is wrong.

All tests you quote show that your t-wirth.de is sending an extra unsigned cert. The CheckTLS result says clearly "Sent my MX". And you yourself see an extra cert in t-wirth.de vs backprod.de.

Two thoughts: one, the extra cert is not a problem; two, you can just remove the last cert in the chain you send to eliminate the error.

Too bad the thread is closed -- you could post an obvious correction to Osiris.

--- removed name
CheckTLS Principal

After kicking out the last block in chain and fullchain the checktls result is ok. Furthermore the TLS / STARTLS Test is working again. No I'm little confused. Are both check pages wrong or is this new behaviour something which is not like it should be.

t-wirth.de - TLS / STARTTLS Test · SSL-Tools (good after throwing out the last block in chain and fullchain

And for the other check page also nor warning anymore:
Connection converted to SSL
SSLVersion in use: TLSv1_3
Cipher in use: TLS_AES_256_GCM_SHA384
Perfect Forward Secrecy: yes
Certificate #1 of 3 (sent by MX):
Cert signed by: #2
Cert VALIDATED: ok
Cert Hostname VERIFIED (mail.t-wirth.de = .t-wirth.de | DNS:.t-wirth.de | DNS:t-wirth.de)
Not Valid Before: Jun 20 08:03:58 2021 GMT
Not Valid After: Sep 18 08:03:57 2021 GMT
subject= /CN=*.t-wirth.de
issuer= /C=US/O=Let's Encrypt/CN=R3
Certificate #2 of 3 (sent by MX):
Cert signed by: #3
Cert VALIDATED: ok
Not Valid Before: Sep 4 00:00:00 2020 GMT
Not Valid After: Sep 15 16:00:00 2025 GMT
subject= /C=US/O=Let's Encrypt/CN=R3
issuer= /C=US/O=Internet Security Research Group/CN=ISRG Root X1
Certificate #3 of 3 (added from CA Root Store):
Cert signed by: #3
Cert VALIDATED: ok
Not Valid Before: Jun 4 11:04:38 2015 GMT
Not Valid After: Jun 4 11:04:38 2035 GMT
subject= /C=US/O=Internet Security Research Group/CN=ISRG Root X1
issuer= /C=US/O=Internet Security Research Group/CN=ISRG Root X1

And new result of
openssl s_client -connect mail.t-wirth.de:25 -starttls smtp
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = *.t-wirth.de
verify return:1
CONNECTED(00000003)

Certificate chain
0 s:CN = *.t-wirth.de
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

Server certificate
-----BEGIN CERTIFICATE-----
MIIEfDCCA2SgAwIBAgISBJyA6vmPRpOGMLVK1d0HT2WlMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMTA2MjAwODAzNThaFw0yMTA5MTgwODAzNTdaMBcxFTATBgNVBAMM
DCoudC13aXJ0aC5kZTB2MBAGByqGSM49AgEGBSuBBAAiA2IABIBbo1zoKSc9jP8K
CXll1iCv8dGSS9flpS45GeAEXbggUlDxQ/X80WTAjpgFIxWhyqMKQ8ptLSwGjpVH
Uo2a4DDifG5/1EUAXLwTVEQVX3V4oX6lehxurbhSmsbl5LREQqOCAlMwggJPMA4G
A1UdDwEB/wQEAwIHgDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYD
VR0TAQH/BAIwADAdBgNVHQ4EFgQUp16KOBVF+4FhTq99Av0fcS0qQBEwHwYDVR0j
BBgwFoAUFC6zF7dYVsuuUAlA5h+vnYsUwsYwVQYIKwYBBQUHAQEESTBHMCEGCCsG
AQUFBzABhhVodHRwOi8vcjMuby5sZW5jci5vcmcwIgYIKwYBBQUHMAKGFmh0dHA6
Ly9yMy5pLmxlbmNyLm9yZy8wIwYDVR0RBBwwGoIMKi50LXdpcnRoLmRlggp0LXdp
cnRoLmRlMEwGA1UdIARFMEMwCAYGZ4EMAQIBMDcGCysGAQQBgt8TAQEBMCgwJgYI
KwYBBQUHAgEWGmh0dHA6Ly9jcHMubGV0c2VuY3J5cHQub3JnMIIBBAYKKwYBBAHW
eQIEAgSB9QSB8gDwAHcAXNxDkv7mq0VEsV6a1FbmEDf71fpH3KFzlLJe5vbHDsoA
AAF6KKmNjgAABAMASDBGAiEA4l+HhKQYAk2dkbFAZr8we1ZxekQNQ8gJwyNF/wyz
r4kCIQDrhaSMGlGHeu6qYADGiuG8R7nTifUemQg9+cbE0rYhcgB1APZclC/RdzAi
FFQYCDCUVo7jTRMZM7/fDC8gC8xO8WTjAAABeiipjXoAAAQDAEYwRAIgGo2g9E82
XHJMDmxrGF+0VCt358Sx0Q4JaLhYrIvKTtgCID1QQEztz6nbD/+9dFOqOALSklru
WF3babjc11J6xX05MA0GCSqGSIb3DQEBCwUAA4IBAQCAxBuDkO+EDzFL05BHR1Q0
/0Y/d/WXr6HS4YD7csJCuBxKYIeRQ7Cgr4x1hdw+y7UHEVN/azwsu1FqrMdKvR8P
R76V6Pcm+ATt+TdUoBHBO80ht1BBQ63CfWJVakyKSW8HnqGj5BHRfKaDPy0I80b3
dJCw1o4pMnUKqnTcyz3NP1oKEwP7AeXb12u3AxEy5NUJY+RIbLnmLJK4OElyaV8o
iGppveqKSZ1daXrHfOIRlrqkExaE5Usdqez34r9BWCEeXmOOE8W3sCILYPw2iW1i
fs3bA9EBubuwRv8KNscLnEB6ZOGN252SF1R43BpPDc8aWhPEYD/MxBHa7TxnLxNX
-----END CERTIFICATE-----
subject=CN = *.t-wirth.de

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


No client certificate CA names sent
Peer signing digest: SHA384
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits

SSL handshake has read 3099 bytes and written 430 bytes
Verification: OK

New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 384 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)

250 CHUNKING
DONE

This cut down version is looking like the older versions of the certificate files which did not result in the problems with the check tools. And now both check pages are running well.

1 Like

The feedback would be laughable, if it wasn't that sad.. For a site build entirely about SSL, they are failing to understand some basics. If we look at the feedback piece by piece:

I assume he's talking about mail.t-wirth.de, as that's the hostname from the MX RR. In any case, the last certificate send by the MX server is not unsigned. Such a thing (an "unsigned certificate") doesn't even exist. Even untrusted self-signed certificates are, well, signed by itself. Also, if we look at cert #4 in their own output, we can clearly see:

issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3

So it's signed by DST Root CA X3, which is the IdenTrust root certificate which has provided the cross-signed ISRG Root X1.

In any case, it's true some clients will build their own chain if the client has more recent root certificates available in their root certificate store. For example, modern browsers have the self-signed root certificate "ISRG Root X1" available, so if they see an intermediate certificate signed by ISRG Root X1, they can terminate the chain with the ISRG Root X1 self-signed root certificate. No problem. But not every client has the ISRG Root X1 in their root certificate store! Therefore, Let's Encrypt uses a certificate chain with a cross-signed ISRG Root X1 which is signed by the Identrust DST Root CA X3 self-signed root certificate, which is more widely trusted.

You can see they aren't using the cross-signed ISRG Root X1 certificate, which is provided by your server, but they use the self-signed ISRG Root X1 from their own root certificate store:

Certificate #3 of 4 (added from CA Root Store):
(…)
subject= /C=US/O=Internet Security Research Group/CN=ISRG Root X1
issuer= /C=US/O=Internet Security Research Group/CN=ISRG Root X1

The fact the SSL Test site builds a different chain than the one your server is sending (which is allowed), does not make the chain send by your server invalid!

The extra certificate is indeed not a problem if a client decides to use a different valid chain.

Error in reasoning here: there is no error Removing the last certificate will remove compatibility with older clients which do not have the ISRG Root X1 root certificate in their root certificate store.

This thread has not been closed, so no idea where they got this idea from.

3 Likes

Thanks again.

I have searched a bit more. Basically the changes which are made are mentioned here (I basically hit almost the right day for the change time :wink: ):

This changes are made for android compatiblity. These changes seem to result in problems for some test pages. To avoid that problems it seems to be possible to switch back to the old short version of the chains but that will result in problems with android devices. If some mailsevers will act like the test pages that could be problematic because in this case sent mail is maybe not accepted (but this is just an assumption but if two test pages are working like that it could be possible that some mail servers will also react in the same way).

In certbot the --preferred-chain seems to be the option for getting the short version. I have not tried it but this is not really a good option if android compatibility is partially lost via doing this.

3 Likes

I think you got confused with all the different CA certs here :slight_smile: - There's no such thing as ISRG Root X3.

2 Likes

Thanks! Seems I've got confused a whopping three times :sob: I've corrected my post :slight_smile:

3 Likes

In a sense it does. The to-be-signed certificate or tbsCertificate is a document exactly like your certificate except without the signature. This document logically needs to exist during production of the certificate, otherwise, what are you signing? Not many tools are designed to examine tbsCertificates so for example Let's Encrypt actually takes the tbsCertificate and signs it with a bogus throwaway key, just to get a certificate they can show to common linting tools to check "Hey is this certificate sane?" before they sign your real certificate.

During SHA-1 deprecation, when some firms really wanted exceptions to be granted, the process Google and others agreed on was that the CA would construct a tbsCertificate and show everybody, and then maybe we'd critique it and iterate - then once there was a version we were happy wasn't an attempt to attack the Web PKI via collision, they could sign that one. In one case I asked, why is there gibberish in the OU (Organisational Unit) field of these certificates? Not enough gibberish that you could likely abuse it to construct a collision, but still it was weird. And they had a sort of crappy hand-wavy answer so they removed it instead of arguing.

4 Likes

Well, when I wrote that such a thing does not exist, I meant they don't exist "out there in the wild", i.e.: actually used on servers in the certificate chain. You're technically right of course that there has to be something to be signed, but for the purpose of the discussion about the chain, they didn't enter the picture, for me at least.

2 Likes

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