Closed
Bug 171765
Opened 23 years ago
Closed 23 years ago
notify when an application's own certificate cannot be path-validated
Categories
(NSS :: Libraries, defect, P1)
NSS
Libraries
Tracking
(Not tracked)
RESOLVED
INVALID
3.7
People
(Reporter: Bill.Burns, Assigned: nelson)
Details
scenario:
A webserver gets an SSL server certificate from verisign's Onsite program.
These certificates are issued by an intermediate CA, not the VeriSign top-level
root CAs.
Web masters install the server's certificate but frequently fail to add the
intermediate CA certificate into the server's certificate database. When
clients connect to the SSL port of the webserver they are presented with a
security error/warning alerting the user to the fact that the certificate is not
trusted (because certificate path validation failed). For legitimate websites
this is a problem because it trains users to ignore (serious) security dialog boxes.
if possible, NSS should log an error whenever a certificate's path cannot be
validated. (I suppose it's up to the application to make the detemination
whether or not to continue, but currently admins are able to misconfigure their
server and never know it's setup incorrectly.)
Updated•23 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: MacOS X → All
Priority: -- → P1
Hardware: Macintosh → All
Target Milestone: --- → 3.7
Comment 1•23 years ago
|
||
Do you think NSS should validate the SSL server certificate
in the SSL_ConfigSecureServer function or it is the application's
responsibility to validate the certificate?
Assignee: wtc → nelsonb
| Assignee | ||
Comment 2•23 years ago
|
||
The NSS API to do path validation already exists.
It is the application's responsibility to use it on its own cert chain
and to decide whether or not to proceed if it fails.
What else would you propose?
Should SSL_ConfigSecureServer fail if the cert chain doesn't validate?
That would implement a policy that I don't think it's NSS's place to implement.
When the infamous V2k incident (not Y2k) happened a few years ago, server
users were able to work around it simply by removing their expired root CA
certs from their cert DBs. This worked precisely because the server WAS
willing to continue to work even though it could no longer validate its
own cert chain because the root CA cert was missing. If NSS had implemented
the policy of refusing to configure the SSL socket when the cert chain didn't
validate, those servers would have been dead in the water.
| Assignee | ||
Comment 3•23 years ago
|
||
Having received no objections, I am marking this bug invalid.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•