Can't import or verify peer certificate for S/MIME

RESOLVED WONTFIX

Status

MailNews Core
Security: S/MIME
RESOLVED WONTFIX
2 years ago
2 years ago

People

(Reporter: Gerd v. Egidy, Unassigned)

Tracking

({regression})

regression

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

2 years ago
Created attachment 8657041 [details]
CA_DATEV_STD_02.cer

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150828094228

Steps to reproduce:

1. Edit > Preferences > Advanced > Certificates > View Certificates > Authorities > Import
2. Import the attached CA_DATEV_STD_02.cer
3. Select the just imported DATEV eG > CA DATEV STD 02
4. Edit Trust, Trust it for websites and mail users.
5. Open tab "People", Import
6. Import the attached ESECURE8134739568656754096.cer




Actual results:

Alert popup with this messages:

This certificate can't be verified and will not be imported. The certificate issuer might be unknown or untrusted, the certificate might have expired or been revoked, or the certificate might not have been approved.


Expected results:

Imported the certificate and being able to verify it.
(Reporter)

Comment 1

2 years ago
Created attachment 8657043 [details]
ESECURE8134739568656754096.cer
(Reporter)

Comment 2

2 years ago
The problem appeared with Thunderbird 38.0.1 and is still present in 38.2.0 and 40.0b1. With Thunderbird 37.0b1 and earlier you can import and verify this certificate without problems.

When you import it with 37.0b1, it doesn't verify in the later versions anymore, so you can't use it for S/MIME encryption.

I can reproduce the problem on Windows (7 64bit) and Linux (Fedora 22).

I can reproduce the problem with or without OCSP.

I ran Thunderbird with debugging enabled:
export NSPR_LOG_MODULES=all:5
export NSPR_LOG_FILE=/tmp/thunderbird.log
export NSS_DEBUG_PKCS11_MODULE="NSS Internal PKCS #11 Module"

I shortened the output to the relevant section and attached it, but I don't see much of the certificate verification details.
(Reporter)

Comment 3

2 years ago
Created attachment 8657048 [details]
thunderbird.log

Updated

2 years ago
Component: Untriaged → Security

Comment 4

2 years ago
My guess is that it's the improperly encoded exponent of the RSA public key in the end entity certificate which is the culprit. In ESECURE8134739568656754096.cer, it's the octets "02 04 00 01 00 01", which isn't the correct DER encoding for the integer 65537 - it must be "02 03 01 00 01". In CA_DATEV_STD_02.cer, it's correctly encoded.

One of the differences between Tb 37.0b1 and 38.0.1 in the ASN.1 parsing code is this commit here:

https://hg.mozilla.org/mozilla-central/rev/75c440d6b2ff

which seems a likely candidate for explaining the difference in the behavior seen with the two versions.
(Reporter)

Comment 5

2 years ago
Hi Kaspar,

thank you very much for your analysis.

I don't know why the key isn't encoded correctly. Datev is a big German CA, I don't know why they output their certificates like that and didn't notice the problem in their code.

This certificate can be imported into the old Thunderbird and the native Windows certificate store. I can also use it with openssl. So my guess is that all other software out there is a bit more relaxed regarding the ASN.1 decoding.

Would it be possible to relax the ASN.1 decoding in Thunderbird a bit so that encoding mistakes like that are ignored and the certificate can still be used?

Comment 6

2 years ago
(In reply to Gerd v. Egidy from comment #5)
> Would it be possible to relax the ASN.1 decoding in Thunderbird a bit so
> that encoding mistakes like that are ignored and the certificate can still
> be used?

That's a question David Keeler (the module owner for security/pkix, AFAICT) should answer, I think.

The difference between Tb 37.0b1 and 38.0.1 is that in the latter case, mozilla::pkix also parses - and checks - the public key (https://hg.mozilla.org/mozilla-central/rev/3fe8d7d7f9f7#l12.234), and it rejects the "02 04 00 01 00 01" DER encoding with this check here (in pkixder.cpp:IntegralBytes):

    if ((firstByte & 0x80) == (nextByte & 0x80)) {
      return Result::ERROR_BAD_DER;
    }
Status: UNCONFIRMED → NEW
Component: Security → Security: S/MIME
Ever confirmed: true
Flags: needinfo?(dkeeler)
Keywords: regression
OS: Unspecified → All
Product: Thunderbird → MailNews Core
Hardware: Unspecified → All
(In reply to Gerd v. Egidy from comment #5)
> Would it be possible to relax the ASN.1 decoding in Thunderbird a bit so
> that encoding mistakes like that are ignored and the certificate can still
> be used?

In short, no. That's not a security trade-off we're going to make. As to why, see bug 1064670.
I would contact Datev to let them know they're issuing certificates with improper encodings. Also, have you checked the csr that the certificate was generated from? The encoding issue might have started with whatever software generated it.
Flags: needinfo?(dkeeler)

Comment 8

2 years ago
Marking WONTFIX then.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.