This server has an expired certificate, when accesing it using 2002092704 nightly the "Server Certificate Expired" dialog open and the OK button does nothing

-> PSM

This works with the in-house expired cert test - https://pki.mcom.com:9100/tests.html It may be because besides being expired, it has no "Issued to" or "Issued by" OU, plus its serial number is 00, plus it has a cert name mismatch - the CN is Plesk.com and the site is webmail.marcanoonline.com. The site could really use a new server cert. Marking new since IE6 and Navigator 4.7X can eventually reach the site.

Sure I notified this problem to my hosting provider

Regression. This works in the branch build.

This is a recent regression. Versions up to 1.2a work correctly. Giving a more detailed problem description, at least what I see on Linux is: When opening the above site, the "cert expired" warning appears. Clicking on OK closes the dialog, but the same warning immediately appears again. This happens again and again, even if you click about 20 times...

Bob, Nelson, are there any recent changes wrt to CERTCertificate member timeOK? If PSM has confirmation from the user, that a cert should be accepted despite it has expired, PSM sets member "timeOK" to PR_TRUE. But after having done so, trying to verify the certificate still fails with error SEC_ERROR_EXPIRED_CERTIFICATE.

I don't know of any recent changes. If it worked under NSS 3.4, I can't think of any changes in NSS 3.6 that would affect it, unless we took this field to be depricated and reused it, but then PSM wouldn't have compiled. bob

The member timeOK has not changed, and is well above the CERTCertificate fields that did change. When did the new CERT_VerifyCertificate function get added? 3.5 or 3.6?

Here's a speculative hypothesis about the problem. Beginning in NSS 3.4 (IINM) we now have several different places where cert info is stored. There's a temp cert store, and a cert cache, and some other places. I wonder if perhaps this timeOK field is not being copied into all the different places where the cert is stored. Could it be that the timeOK bit gets set in the CERTCertificate, but not in the cache, or not in the temp cert store. Suppose that the CERTCertificate goes away, and is recreated from a STANCertificate, but the recreated copy doesn't have the timeOK bit restored in it from the previous value.

Nope -- as long as there is any outstanding reference to a CERTCertificate, it exists uniquely in either the cache or temp store. It will never be destroyed and recreated from an NSSCertificate. There have never been multiple copies of the same cert in different places, period. Additionally, the changes you mention were made in NSS 3.4. This bug claims to be much more recent than that (more like NSS 3.6).

Ian, thanks for the clarification.

I belive CERT_VerifyCertificate() was added in NSS 3.5. It is supposed to allow a single call to verify the cert for more than one usage at a time. bob

CERT_VerifyCertificate was added in NSS 3.6 . See bug # 149832 .

Unless I am mistaken, i am having the same issue with Build 2002101612 on both Linux and Windows. When attempting to access a site with an expired certificate, I get the following dialog: "plesk.com" is a site that uses a security certificate to encrypt data during transmission, but it's certificate expired on 11/10/2001 06:24 PM. You should check to make sure your computer's time (currently set to Sat 19 Oct 2002 03:10:56 PM EDT) is correct. Would you like to continue anyway? When I click on OK, the dialog goes away and then it returns. It doesn't matter how may times I click OK, I always get another dialog. Mozilla 1.2 Alpha allowed me to continue.

Joseph: You are wright, this is the same problem. My hosting provider is using the default certificate provided by Plesk's software (http://www.plesk.com/html/products/index.htm)

*** Bug 175824 has been marked as a duplicate of this bug. ***

The common situation with this site, and https://lists.xcf.berkeley.edu/lists/advanced-java/1998-November/014068.html and https://lists.sistina.com/ is that when viewed in the cert viewer, they have identical "Issued to" and "Issued by" CN, OU, and O, (although each site has different CN, OU and O from the other sites). They all also have serial number 00.

Do we know what piece of software created all these certs that have serial number zero? Is it software from plesk? Do we have the program name? Is it possible to issue certs with non-zero serial numbers using that software?

I would guess that Plesk is distributing these server certs, since their own site is setup the same way - https://demo.plesk.com:8443 - Serial number 00, with the CN, OU, and O the same for Issuer and Issuee.

*** Bug 175225 has been marked as a duplicate of this bug. ***

*** Bug 176262 has been marked as a duplicate of this bug. ***

The problem is both the issuer and the user is expired. The CRL check for the issuer is failing because the new code checks to see if the the CRL can be checked before it looks up the CRL. In NSS 3.5 this check was only made when the CRL exists. The options are: 1) check if the CRL exists. If it doesn't allow the expired issuer. This will preserve 3.5 semantics. 2) allow the time override to override the check of the CRL: This is more dangerous because the CRL's are cached and it could lead to trusting the CRL for other cases. Currently the 'timeOK' is only valid when checking for SSL Authentication (it can't be overridden in other cases). 3) skip the CRL check if the 'timeOK' is set and the validation is for SSL. I think option 1 is the most correct option because 1) it preserves the current semantics, 2) Few installations load CRL's for the CA, so there is little problem not connecting to an expired site which you have a CRL loaded for, 3) Sites which do issue and maintain CA's depend more heavily on the accuracy of the validity time of the certificates it issues, particularly on the CA, so it's a feature that the user cannot override expiration on the CA itself in this case. bob

Hmm. I'm not sure if my bug (http://bugzilla.mozilla.org/show_bug.cgi?id=175225) is displaying quite the same problem. In both cases we have identical issued to/issued by lines, but in the imap server (mail8.nebula.fi) the certificate has not expired. I get a chance to "remember this certificate permanently" that comes right back at me if I choose to remember it. If I choose remember just for this session, things are OK for the duration.

If the issuer cert is expired, don't automatically fail the CRL check. Only fail it if CRLs for the issuer exist.

Comment on attachment 104076 [details] [diff] [review] proposed patch. New revision belongs in NSS bug 175115 . Only the patch to crl.c applies here. Please ignore the other patch to stanpcertdb.c that made its way into this one.

*** Bug 176908 has been marked as a duplicate of this bug. ***

*** Bug 177485 has been marked as a duplicate of this bug. ***

*** Bug 178275 has been marked as a duplicate of this bug. ***

This problem also affects the site https://mail.the-allens.net. I tested with Mozilla nightly build id: 2002110804

Upgrading to major. There are lots of self-signed Apache server certs out there, and some are expired. Those sites cannot be reached with recent trunk builds. There is no workaround.

I can confirm that this bug affects MacOSX builds as well. Build # 2002110803 Also, I have a site you can test: https://63.193.240.13 Hugh

Well, thanks for all your help, but we believe we already understand the problem. It's just that the fix has not yet arrived in Mozilla and it will take a couple of more days. In addition, we have not yet received approval from Mozilla.org's drivers to land this fix for Mozilla 1.2 release, hopefully they will approve it.

No workaround? I believe that deleting the old trusted cert from the DB will enable you to trust the new cert, will it not?

"No workaround? I believe that deleting the old trusted cert from the DB will enable you to trust the new cert, will it not?" No. At least for my case as I was using a brand new profile.

The patch for bug 175115 just has landed on the 1.2 branch. If you want, get a build from http://bugzilla.mozilla.org/attachment.cgi?id=104600&action=view *tomorrow*. If the problem is fixed on the branch for you, please comment in here. Please do not yet mark the bug as fixed, because we need to wait until the patch for 175115 lands on the trunk, too.

Tested on Mozilla 1.2 and worked fine at the site https://webmail.marcanoonline.com/

Marking fixed. Tested on Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021202 Netscape/7.0+

Fixed

Verified fixed.

(In reply to comment #39) > Verified fixed. I am still having this problem using release 1.0.6 (20050716). My service has an expired certificate. Thunderbird will not recognize the "Accept this certificate permanently" option. When selecting it, the dialog just continues to repeat.

Albert, if this bug is again reproducible, this bug should not be reopened, but a new regression bug should be filed. See also bug 175115. But before files a new bug, we need a reproducible test case. So, please give a URL here (or in a new bug) with which it can be reproduced. If you file a new bug, be sure to cite this one and bug 175115 in that new bug.