1

I receive s/mime signed email. Signature for this email is generated with certificate that is issued from this authority: Sectigo RSA Client Authentication and Secure Email CA expiration 01.01.2031 09c0f2fc0bda94db5ffe2bdfa89942cfc9e0ad00 Above certificated is issued from root authority, that is trusted by Thunderbird. USERTrust RSA Certificateio Authority expiration 19.01.2038 5379bf5aaa2b4acf5480e1d89bc09df2b20366cb

Thunderbird and other email clients can't validate this email signature. If i open the same email using Thunderbird in windows everything is ok.

I download an intermediate certificate. Then imported that certificated without trusting it(trust check-boxes are unchecked). Then that email signature can be validated.

Why intermediate certificates are not downloaded automatically in Ubuntu like it is working in Windows?

Is this way to add intermediate certificate is secure? For me it seems to be a secured way, because i don't give a trust to a certificate myself(unchecking trust check-boxes) but intermediate certificate is validated by the root certificate that is installed with Ubuntu.

1 Answer 1

0

TL;DR; That is because OpenSSL by itself does not try to fetch intermediate certificates, but a lot of software expects it will.

OpenSSL

To my understanding, the reason for that is because many or maybe even most Ubuntu applications rely on OpenSSL to verify certificates. The problem lies in the fact that OpenSSL by itself does not fetch any certificates, it just relies on the local collection of trusted certificates, which contains ("by default") only (or mostly) ROOT CA certificates, or at least it expects the whole chain to be provided by the invoking side.

OpenSSL developers consider that fetching additional certificates is not the responsibility of OpenSSL, and must be done by the application itself. See this issue.

RFC

It is worth noting, that earlier RFC5246, which covered TLS 1.2 and is now obsolete, required that server MUST send the whole chain of certificates (7.4.2):

This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it.

But newer RFC8446 relaxes this (4.4.2). In particular, it says this:

For maximum compatibility, all implementations SHOULD be prepared to handle potentially extraneous certificates and arbitrary orderings from any TLS version

So, to my understanding of this RFC and the term "implementation" in particular, OpenSSL SHOULD be capable of handling extraneous certificates, but it is not.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .