fail to validate existing mails signed by a valid cert with renewed CA cert

RESOLVED INVALID

Status

NSS
Libraries
RESOLVED INVALID
9 years ago
9 years ago

People

(Reporter: Kent Tong, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(8 attachments)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8
Build Identifier: Thunderbird version 2.0.0.17 (20080914)

I have existing mails signed by a valid personal certificate signed
by your internal CA. Now, the CA cert has expired so we renewed it.
After installing the new CA cert as a trusted authority, the digital 
signatures with theexisting mails are now considered broken by 
Thunderbird. However, Thunderbird can indeed establish a valid certificate 
chain from the renewed CA cert to that personal cert.

It means even though the CA cert is trusted and the personal cert is 
validated by the CA cert, Thunderbird still fail to validate the 
signature.

I've compared the old and the renewed CA certs. Their only differences are
the "validity" and the "signature algorithm". All other fields are 
identical.

Reproducible: Always

Steps to Reproduce:
Verify that a mail has a valid signature with the old CA cert:
1) Change the system clock to, say, Jan 1, 2009.
2) Import the now expired CA cert (attached). Check "can identify mail users".
3) Import the attached mail.
4) Note that the digital signature should be validated properly.

Verify that signature is considered invalid with the renewed CA cert:
1) Change the system clock back to now.
2) Delete the expired CA cert and import the renewed CA cert. Check "can 
identify mail users".
3) Note that now the digital signature of the mail is considered 
invalid by thunderbird. Double click the signature, it will say 
"Could not verify this certificate for unknown reasons" in the
window.
4) Click the Details tab. You should see that there is indeed a 
valid cert chain from the CA to the personal cert. So, the renewed
CA cert is really validating the personal cert.


Actual Results:  
Signature is broken.

Expected Results:  
Signature should be shown as valid.

Used openssl to generate all the certs.
(Reporter)

Comment 1

9 years ago
Created attachment 377316 [details]
the signed mail

the signed mail.
(Reporter)

Comment 2

9 years ago
Created attachment 377317 [details]
the renewed CA cert (PEM)
(Reporter)

Comment 3

9 years ago
Created attachment 377318 [details]
the old CA cert (PEM)
Attachment #377317 - Attachment description: the renewed CA cert → the renewed CA cert (PEM)
Attachment #377317 - Attachment mime type: application/octet-stream → text/plain
Attachment #377318 - Attachment description: the old CA cert → the old CA cert (PEM)
Attachment #377318 - Attachment mime type: application/octet-stream → text/plain
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b5pre) Gecko/20090514 SeaMonkey/2.0b1pre - Build ID: 20090514000550

I confirm that "CA Cert Signing Authority" is not currently regarded by Mozilla apps as a "trusted" certificate signing agency.

Example: when browsing https://bugs.freedesktops.org/ which is signed by a CA Cert certificate valid "not before 2008-11-24 00:19:12 GMT, not after 2009-05-23 00:19:12 GMT", which includes today, a XUL error page appears (certificate alert for "untrusted certificate issuer" IIRC) and I cannot see any page from the freedesktop bugzilla until or unless I permanently import this certificate.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: x86 → All
Oops: there is a typo in the URL in comment #4. Please use https://bugs.freedesktop.org/ as shown on top of this bug.
Tony, this bug has nothing to do with certs issued by the CA named "CA Cert".

This bug has to do with a self-signed root that was issued (I gather) by the
reported of this bug.  He then attempted to "re-issue" the root CA cert, but
the reissued root CA cert has several problems.  

This bug is invalid.  I will discuss why in a following comment.
Assignee: kaie → nobody
Component: CA Certificates → Libraries
QA Contact: root-certs → libraries
The set of certs attached to this bug show many of the most common problems 
seen with certs generated with the OpenSSL program according to any of the
popular (if misguided) "cook books" available on the internet.  

Among the problems they exhibit are:
a) using serial number 0 for root CA certificates
b) re-using the same serial number in multiple certificates from the same
issuer
c) putting the issuer's issuer name and issuer's serial number into the 
Authority Key Identifier extension.  
d) creating a re-issued root CA cert with the same key material as an 
earlier root CA cert, but whose validity dates do not encompass the original
validity dates.  

Here are my suggestions to the issuer of these certs for all certs issued
in future.

1. Never use the same serial number twice, not even in re-issued root CA
certs.  NEVER.  There is NO NEED for a reissued cert to have the same 
serial number as a previous cert.

2. Do NOT put the issuer's issuer name and issuer's serial number in any
cert's Authority Key Identifier extension.  Just the the Key ID of the 
issuer's public key in the Authority Key Identifier extension.  

3. Do not put Authority Key Identifier extensions in root certificates.

4. When issuing a new cert for an existing CA, where the new cert has the 
same subject name and the same public key as a previous cert, make sure
that the validity period of the new cert retroactively covers the entire
validity period of the previous cert(s) for that subject name and public 
key, and make sure it has the same Subject Key ID as the previous cert(s)
with that public key.  Again, DO NOT reuse the old serial numbers.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INVALID
(Reporter)

Comment 8

9 years ago
Thanks. I've generated a new cert according to your suggestions. However, after
importing it into Thunderbird, its details can't be displayed: the "Issued by" section and the "validity" section are both blank (see attached figure). Nothing is listed in the "Certificate fields" section (see attached figure).
(Reporter)

Comment 9

9 years ago
Created attachment 383618 [details]
CA cert generated according to the guideline
(Reporter)

Comment 10

9 years ago
Created attachment 383619 [details]
Screenshot showing details are blank
(Reporter)

Comment 11

9 years ago
Created attachment 383620 [details]
Screenshot showing that no fields are listed
Attachment #383618 - Attachment mime type: application/octet-stream → text/plain
Comment on attachment 383618 [details]
CA cert generated according to the guideline

The validity periods in this certificate have invalid encoding. 
That are NOT, in fact, the values shown below.
They are missing time zone information.

>        Validity
>            Not Before: May 11 09:28:37 2004
>            Not After : May 11 09:28:37 2019
(Reporter)

Comment 13

9 years ago
Thanks. I've fixed this problem and now the CA cert can be displayed in Thunderbird. However, when viewing my personal cert, Thunderbird says "it cannot verify this certificate for unknown reasons". I am uploading both the CA cert and my personal cert...
(Reporter)

Comment 14

9 years ago
Created attachment 383663 [details]
CA cert that can be imported properly
(Reporter)

Comment 15

9 years ago
Created attachment 383664 [details]
personal cert that can't be validated
(Reporter)

Comment 16

9 years ago
I've found the problem: the locality was not set in the renewed CA cert. Adding it back fixes the problem.

The renewed CA cert and renewed personal cert seem to work fine. However, old mails signed by the now-expired personal cert are shown as broken in Thunderbird. I guess this is the by-designed behavior. I wonder if there is any indicator showing that the signature has expired instead of being simply broken?
You need to log in before you can comment on or make changes to this bug.