Closed Bug 171219 Opened 22 years ago Closed 22 years ago

Unable to access this SSL site with expired Certificate

Categories

(Core Graveyard :: Security: UI, defect, P2)

Product:
Core Graveyard
Component:
Security: UI
Version:
1.0 Branch
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
psm2.4

People

(Reporter: robmv, Assigned: KaiE)

References

(
URL
)

Details

(Keywords: regression)

Attachments

(1 obsolete file) 

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
Assignee: darin → ssaux
Component: Networking: HTTP → Client Library
Product: Browser → PSM
QA Contact: httpqa → junruh
Version: other → unspecified
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P4
Version: unspecified → 2.4
Sure I notified this problem to my hosting provider
Severity: normal → major
Priority: P4 → P3
Summary: Unable to access SSL site with expired Certificate → Unable to access this SSL site with expired Certificate
Severity: major → minor
Target Milestone: --- → Future
Regression. This works in the branch build.
Keywords: nsbeta1, regression
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...
Assignee: ssaux → kaie
Keywords: nsbeta1 → nsbeta1+
OS: Windows XP → All
Hardware: PC → All
Target Milestone: Future → 2.4
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 .
Depends on: 175115
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. ***
Attachment #104076 - Attachment description: proposed patch → proposed patch. New revision belongs in NSS bug 175115 .
Attachment #104076 - Attachment is obsolete: true
Blocks: 175225
*** 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.
Severity: minor → major
Keywords: patch
Priority: P3 → P2
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.
No longer blocks: 175225
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
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Verified fixed.
Status: RESOLVED → VERIFIED
Product: PSM → Core
(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.
Version: psm2.4 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: