849833 - Basic Constraint Ext: Proposal: Remove old Entrust 2048 root, add equivalent 2048 intermediate

Status: RESOLVED DUPLICATE of bug 694536

(CA Program :: CA Certificate Root Program, task)

Description

[Kai Engert (:KaiE:)]

Mozilla's root CA store contains a certificate with the following properties:

Serial Number: 946059622 (0x3863b966)
Issuer: O=Entrust.net, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Certification Authority (2048)
Subject: O=Entrust.net, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Certification Authority (2048)
Not Before: Dec 24 17:50:51 1999 GMT
Not After : Dec 24 18:20:51 2019 GMT
SHA1 Fingerprint=80:1D:62:D0:7B:44:9D:5C:5C:03:5C:98:EA:61:FA:44:3C:2A:58:FE


Problem with above certificate: There's no "Basic Constraint Extension" (BCE)


Motivation: We're working on an application that consumes the Mozilla root CA list, and above certificate is causing problems.

AFAICT, above certificate is the only root in Mozilla's list that lacks the BCE.


I learned that Entrust had to work on this issue already, as can be seen in an article I found in the Entrust.net knowledge base:
http://www.entrust.net/knowledge-base/technote.cfm?tn=7869


The solution offered by Entrust:

Entrust has issued a replacement certificate with the same subject name, but which has been issued by another, newer Entrust root CA certificate. That replacement certificate, which is an intermediate CA certificate, contains a correct BCE. It has the following properties:

Serial Number: 1184796954 (0x469e911a)
Issuer: C=US, O=Entrust.net, OU=www.entrust.net/CPS incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Secure Server Certification Authority
Subject: O=Entrust.net, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Certification Authority (2048)
Not Before: Mar 23 15:18:27 2009 GMT
Not After : Mar 23 15:48:27 2019 GMT
SHA1 Fingerprint=B9:75:81:1D:DA:15:10:7E:F5:E0:DC:28:14:1C:7B:93:8E:BE:4C:26

The issuer certificate of this intermediate is contained (and trusted) in Mozilla's root CA list, too.


In order to fix the issue, I propose to:
- remove root certificate with serial 0x3863b966 from the Mozilla CA list
and
- add intermediate certificate with serial 0x469e911a to the Mozilla CA list


If I understand correctly, all certificates that were issued by the old root after Mar 23 15:18:27 2009 GMT will continue to be trusted.

However, all certificates issued before Mar 23 15:18:27 2009 GMT would no longer be trusted by Mozilla.


Would this be acceptbale to Entrust?

Has Entrust issued any certificates using above root which have been issued prior to Mar 23 15:18:27 2009 GMT, and which are still valid? If yes, for how long would Entrust require the old root to remain valid?

Comment 1

[Kai Engert (:KaiE:)]

> Would this be acceptbale to Entrust?
> 
> Has Entrust issued any certificates using above root which have been issued
> prior to Mar 23 15:18:27 2009 GMT, and which are still valid? If yes, for
> how long would Entrust require the old root to remain valid?


Dear Bruce, would you be able to comment on the proposal and in particular these questions?
Thank you in advance for your help.

Comment 2

[Bruce Morton]

Hi Kai,

We realized that we had a problem several years ago. The certificate without BCE worked for almost all browsers. We have re-issued the certificate. The updated certificate uses the same key, but now has the correct BCE. We have started the process to include this certificate in Mozilla, but the process has not been completed due to actions required by Entrust. The request is #694536.

I think that the action is the old certificate serial 0x3863b966, needs to be replaced with the updated certificate serial 0x‎3863def8. The updated certificate has a valid from date the same as the original which is Dec 24, 1999.

The certificate with serial 0x469e911a was issued from a 1024-bit RSA CA. This is a work around to the BCE issue, but I don't think we can count on that certificate being trusted long-term with the demise of 1024-bit RSA.

If trust is being dropped for certificates issued before Mar 23, 2009 comes into effect, I believe that this would be OK, if it is implemented 50 months after Mar 23, 2009. I don't believe that we have an issue with dates, if we trust the updated certificate serial 0x3863def8.

I hope that got the right serial nomenclature in my response. If something is confusing, please contact me.

Thanks, Bruce.

Comment 3

[Kathleen Wilson]

Kai, What is the time frame for this?

I think the correct approach is to include the replacement root and remove the old root.

Bug #694536 also includes a request for a new (unrelated) root certificate, and that new root seems to have delayed the bug.

I can separate the root replacement request and finish the discussion/approval process for it first, so we can get this issue resolved. Shall I do that?

Comment 4

[Kai Engert (:KaiE:)]

(In reply to Kathleen Wilson from comment #3)
> Kai, What is the time frame for this?

I'd prefer to have a fix for this issue for a product that is scheduled to be shipped in June 2013 (Fedora 19).


> I think the correct approach is to include the replacement root and remove
> the old root.

Thanks, I agree, I'm glad to hear this has been planned already.


> Bug #694536 also includes a request for a new (unrelated) root certificate,
> and that new root seems to have delayed the bug.
> 
> I can separate the root replacement request and finish the
> discussion/approval process for it first, so we can get this issue resolved.
> Shall I do that?

Yes, please, I'd appreciate that very much. It would be a great solution and would make it unnecessary to find workarounds in the consuming applications.

Thank you!

Comment 5

[Kai Engert (:KaiE:)]

Because of the proposal from bug 694536 to replace the old root with an equivalent one that contains the BCE, the proposal in this bug 849833 is unnecessary.

Resolving as a duplicate.