Closed Bug 98193 Opened 23 years ago Closed 11 years ago

can't trust a CA when CRL next update is in the past.

Categories

(Core :: Security: PSM, enhancement, P5)

Product:
Core
Component:
Security: PSM
Type:
enhancement

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: cfu, Unassigned)

References

Details

(Whiteboard: [psm-crl]) 

I installed Netscape CMS 4.2 sp2 on Solaris 2.6.  I used Netscape6 Build
2001083003 to import the CA self-sign cert.  The import was successful, however,
"Manage Certificates" shows "Could not verify this certificate because the
issuer is not trusted" (yes, all three trust boxes are checked).  Switched to a
different profile, and the CA was imported and trusted successfully.

Import of the same CA cert into a Communicator 4.7 is successful and recognized
as trusted.

don't think it's related, but ibutton has been installed on this system and
logged in by both user profiles.

The following are info for this CA:

Certificate  0x01
 
Certificate contents

Certificate: 
        Data: 
            Version:  v3
            Serial Number: 0x1
            Signature Algorithm: SHA1withRSA - 1.2.840.113549.1.1.5
            Issuer: CN=Certificate Manager 422,O=mcom.com,ST=California,C=US
            Validity: 
                Not Before: Tuesday, August 28, 2001 11:00:00 PM GMT-08:00
                Not  After: Thursday, August 28, 2003 11:00:00 PM GMT-08:00
            Subject: CN=Certificate Manager 422,O=mcom.com,ST=California,C=US
            Subject Public Key Info: 
                Algorithm: RSA - 1.2.840.113549.1.1.1
                Public Key: 
                    Exponent: 65537
                    Public Key Modulus: (512 bits) :
                        BD:B9:D6:B0:FC:B0:A0:59:3C:29:8B:FE:53:E0:D6:80:
                        60:A9:B5:28:84:46:C9:1F:9A:1F:B0:86:7F:9A:16:96:
                        E8:AF:7B:36:67:DF:25:B8:78:A1:C5:30:8B:C5:E6:CE:
                        25:67:E0:CB:7D:FE:41:44:B9:7C:64:4B:BC:1A:A4:11
            Extensions: 
                Identifier: Netscape Certificate Type - 2.16.840.1.113730.1.1
                    Critical: no 
                    Certificate Usage: 
                        SSL CA 
                        Secure Email CA 
                        ObjectSigning CA 
                Identifier: Basic Constraints - 2.5.29.19
                    Critical: yes 
                    Is CA: yes 
                    Path Length Constraint: UNLIMITED
                Identifier: Subject Key Identifier - 2.5.29.14
                    Critical: no 
                    Key Identifier: 
                        D2:23:10:9E:42:41:F0:14:0D:5B:C2:B3:48:41:73:F1:
                        B5:5D:DE:EE
                Identifier: Authority Key Identifier - 2.5.29.35
                    Critical: no 
                    Key Identifier: 
                        D2:23:10:9E:42:41:F0:14:0D:5B:C2:B3:48:41:73:F1:
                        B5:5D:DE:EE
                Identifier: Key Usage: - 2.5.29.15
                    Critical: yes 
                    Key Usage: 
                        Digital Signature 
                        Key CertSign 
                        Crl Sign 
        Signature: 
            Algorithm: SHA1withRSA - 1.2.840.113549.1.1.5
            Signature: 
                1F:D6:22:09:7B:5A:A3:BA:B1:D9:54:93:AE:A9:63:77:
                CE:44:A8:BC:18:30:35:1A:97:18:E2:CA:4B:4D:BD:CF:
                ED:3E:0B:46:5F:54:B9:B6:29:6A:CB:A6:00:ED:98:6F:
                02:73:3D:DF:FE:FA:0D:4C:58:21:D4:9C:60:93:F8:88


Certificate fingerprints

MD2:   7D:3C:44:98:1D:29:B6:CB:86:AA:AC:5A:17:EB:83:58
    MD5:   D6:F1:95:D0:B2:32:0A:C0:82:B0:AC:12:42:2F:B4:FF
    SHA1:  4E:72:09:58:04:6F:10:8F:71:09:DA:5D:D0:1C:EC:E8:D7:5F:89:FB


Installing this certificate in a server

The following format can be used to install this certificate into a server.

Base 64 encoded certificate

-----BEGIN CERTIFICATE-----
MIICFTCCAb+gAwIBAgIBATANBgkqhkiG9w0BAQUFADBXMQswCQYDVQQGEwJVUzETMBEGA1UECBMK
Q2FsaWZvcm5pYTERMA8GA1UEChMIbWNvbS5jb20xIDAeBgNVBAMTF0NlcnRpZmljYXRlIE1hbmFn
ZXIgNDIyMB4XDTAxMDgyOTA3MDAwMFoXDTAzMDgyOTA3MDAwMFowVzELMAkGA1UEBhMCVVMxEzAR
BgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAoTCG1jb20uY29tMSAwHgYDVQQDExdDZXJ0aWZpY2F0
ZSBNYW5hZ2VyIDQyMjBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQC9udaw/LCgWTwpi/5T4NaAYKm1
KIRGyR+aH7CGf5oWluivezZn3yW4eKHFMIvF5s4lZ+DLff5BRLl8ZEu8GqQRAgMBAAGjdjB0MBEG
CWCGSAGG+EIBAQQEAwIABzAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTSIxCeQkHwFA1bwrNI
QXPxtV3e7jAfBgNVHSMEGDAWgBTSIxCeQkHwFA1bwrNIQXPxtV3e7jAOBgNVHQ8BAf8EBAMCAYYw
DQYJKoZIhvcNAQEFBQADQQAf1iIJe1qjurHZVJOuqWN3zkSovBgwNRqXGOLKS029z+0+C0ZfVLm2
KWrLpgDtmG8Ccz3f/voNTFgh1Jxgk/iI
-----END CERTIFICATE-----

Base 64 encoded certificate with CA certificate chain in pkcs7 format

-----BEGIN CERTIFICATE-----
MIICSAYJKoZIhvcNAQcCoIICOTCCAjUCAQExADAPBgkqhkiG9w0BBwGgAgQAoIIC
GTCCAhUwggG/oAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMCVVMx
EzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAoTCG1jb20uY29tMSAwHgYDVQQD
ExdDZXJ0aWZpY2F0ZSBNYW5hZ2VyIDQyMjAeFw0wMTA4MjkwNzAwMDBaFw0wMzA4
MjkwNzAwMDBaMFcxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMREw
DwYDVQQKEwhtY29tLmNvbTEgMB4GA1UEAxMXQ2VydGlmaWNhdGUgTWFuYWdlciA0
MjIwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAvbnWsPywoFk8KYv+U+DWgGCptSiE
Rskfmh+whn+aFpbor3s2Z98luHihxTCLxebOJWfgy33+QUS5fGRLvBqkEQIDAQAB
o3YwdDARBglghkgBhvhCAQEEBAMCAAcwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4E
FgQU0iMQnkJB8BQNW8KzSEFz8bVd3u4wHwYDVR0jBBgwFoAU0iMQnkJB8BQNW8Kz
SEFz8bVd3u4wDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBBQUAA0EAH9YiCXta
o7qx2VSTrqljd85EqLwYMDUalxjiyktNvc/tPgtGX1S5tilqy6YA7ZhvAnM93/76
DUxYIdScYJP4iDEA
-----END CERTIFICATE-----
forgot to mention that the uer profile that failed to trust the CA is a brand
new profile, while the one that succeeded was my own.
p1 t->2.1
->rangan
Assignee: ssaux → rangansen
Priority: -- → P1
Target Milestone: --- → 2.1
Christina, please post the url to import the ca root as a test case.
Keywords: nsenterprise
go to http://cfu, "Retrieval", then click on "Import CA Certificate Chain" and
select the default "Import the CA certificate chain into your browser" and submit.
I'd like to add that I have tried the following:
I did pkcs12 backup of a client cert signed by the CA from my "good" profile.
I then "restore" it from the "bad" profile.  It succeeded and the CA was loaded
and recognized (on the new profile).
Marking nsentreprise+
Keywords: nsenterprise → nsenterprise+
I spoke too soon.  After "restore," it had "a moment of trust".  After I quit
out and started N6 again, the trust of CA disappeared.
works for me. I was able to load the CA cert from both Christina CA and my CA.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
verified 20010917 build 
verified as per lgopal's comments.
Status: RESOLVED → VERIFIED
I know how to reproduce this now.  This has something to do with CRL's
nextUpdateTime.  If a profile has a CRL with nextUpdateTime older than the
current time, then the cert can not be verified.
To reproduce:
1. get a new profile
2. go to http://cfu [Retrieval][Import CRL][Import the latest CRL to your
browser][Submit], note your current time (T1)
3. go to http://cfu [Retrieval][Import CA Cert Chain], import into your browser
(make sure you trust it)
4. go to http://cfu [Enrollment][Directory], enter uid "test1" password "test1",
now you have a cert in your certdb.
5. go to "Manage Certificates" on you preference menu and you should see test1
"verified" is true.
6. wait until after time pass T1+(20 minutes), go to "Manage Certificates" on
you preference menu and you should see test1 "verified" is false. and if you
look under "Authorities", you'll see that your ca can not be verified for
"unknown reason".

It's not clear to me in rfc2459 how "nextUpdateTime" is to be handled by apps.
Can someone enlighten me regarding this issue.  From a usability point of view,
this CRL function, as provided by PSM, seems to be hindering at best.

I'll let the PSM team decide whether to reopen this bug, if it is a bug.
Group: netscapeconfidential?
Reopening.
Another checkmark to add when we provide a full CRL handling design.
This is related to the dialog we pop up when connecting to an SSL site
controlled by a CRL with a nextUpdate in the past.  Will add bug number when I
find it.
Status: VERIFIED → UNCONFIRMED
Resolution: WORKSFORME → ---
Summary: can't trust a CA → can't trust a CA when CRL next update is in the past.
Target Milestone: 2.1 → Future
QA Contact: bsharma → junruh
Status: UNCONFIRMED → NEW
Ever confirmed: true
Marking depends on bug# 108021
Depends on: 108021
setting target
Status: NEW → ASSIGNED
Target Milestone: Future → 2.2
Also, rather than just succeed when the date the past next update, we should be
able to define some kind of configurable window - like succeeds when the current
time is past, but not more than x days after next update. If it is x days after
next update, the validation should fail - implying that this crl is too old
The "depends on" bug is fixed. Can this bug be marked fixed?
Keywords: qawanted
Target Milestone: 2.2 → 2.4
Version: 2.0 → 2.4
The 'depends on' bug has fixed the original issue that validation used to fail 
when next update was in the past - now, possibly, it doesn't care about next 
update anymore. But, an additional requirement for this bug was to have a 
configurable time window for the next update field, only within which the CRL 
will be accepted [Pl ref my last comment].

However, IMO, this would be more of a RFE right now.
Enhancement, based on Rangan's last comment.
Severity: normal → enhancement
Keywords: qawanted
OS: Windows 2000 → All
Priority: P1 → P5
Hardware: PC → All
Target Milestone: 2.4 → Future
reassign former PSM engineers' bugs to nobody
Assignee: rangansen → nobody
Status: ASSIGNED → NEW
QA Contact: junruh → nobody
Target Milestone: Future → ---
Product: PSM → Core
QA Contact: nobody → ui
Version: psm2.4 → 1.0 Branch
bug 94013 comment 5 and bug 94013 comment 6 seem to indicate to me that this bug should live in NSS.
Assignee: nobody → nobody
Blocks: 94013
Component: Security: UI → Libraries
Product: Core → NSS
QA Contact: ui → libraries
Version: 1.0 Branch → unspecified
Timeless, This is a PSM issue. 
Please let the PSM + NSS folks decide if bugs need to be moved from one 
to the other.  Please don't make unwelcome work for us.
Assignee: nobody → kaie
Component: Libraries → Security: PSM
Product: NSS → Core
QA Contact: libraries → psm
Assignee: kaie → nobody
Whiteboard: [psm-crl]
The "Revocation Lists" feature was removed in bug 867465.
Status: NEW → RESOLVED
Closed: 23 years ago → 11 years ago
Depends on: 867465
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.