128641 - if user manually trusted server cert, lock icon / page info should mention it

Status: RESOLVED WORKSFORME

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

Description

[Bob Clary [:bc] (inactive)]

View https://secure.mercuryinsurance.com/FreeQuote/

You will see the dialog "Website Certified by an Unknown Authority"

Could not verify this certificate bcause the issuer is unknown.

Certificate Version 3
Serial Number 47:67:27:87:AA:C6:74:3B:57:E9:E6:E0:A9:58:9F:3B
Certificate Signature Algorithm: PKCS #1 MD5 With RSA Encryption
Issuer
OU = www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
OU = VeriSign International Server CA - Class 3
OU = VeriSign, Inc.
O = VeriSign Trust Network

Click continue on the dialog and then on the lock icon on the page and you will see

Web Site Identity Verified
The web site secure.mercuryinsurance.com supports authentication for the page
you are viewing. The identity of this web site has been verified by VeriSign
Trust Network, a certificate authority you trust for this purpose.

2002022703/win2k and winxp

Comment 1

[Wan-Teh Chang]

Bob, Ian,

Could you take a look at this problem?  Thanks.

Comment 2

[Robert Relyea]

Ian, is this sounds like the same problem I described to you.

bob

Comment 3

[Wan-Teh Chang]

Set target milestone 3.4, priority P1.

Comment 4

[Ian McGreer]

Bob, which problem?

I'm not sure this is an NSS bug.  The issuer of this certificate is an
intermediate, signed by a trusted root.  However, the server is not sending the
intermediate cert, so there is no way for NSS to ascertain to which root the
cert chains.  If I try this with 0.9.8, I receive the same warning.  I believe
the client is behaving properly.

Will attach ssltap output.  Note that the server is only sending the server cert.

Comment 5

[Ian McGreer]

Attachment: ssltap output from tstclnt

Comment 6

[Ian McGreer]

Attachment: ssltap output from moz 0.9.8

Comment 7

[Ian McGreer]

If you accept Mercury's SSL cert for the connection, you'll see it was issued by:

Issuer: OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign,
OU=VeriSign International Server CA - Class 3, OU="VeriSign, Inc.", O=VeriSign
Trust Network

Which itself was issued by:

Subject: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US

Without that cert, there is no way for NSS to chain.  Looks like a misconfigured
server to me.

Comment 8

[Ian McGreer]

Sorry, to be more clear.

The server's issuer cert is the one needed.  The root is a trusted root that NSS
already has in the builtins.

Comment 9

[Ian McGreer]

Another note: tstclnt fails in the same manner with NSS 3.3.2, so this is not a
3.4 regression (if it is even a bug).

Comment 10

[Bob Clary [:bc] (inactive)]

See also bug 121534.

I do think the warning dialog and the result of clicking the lock icon should be
consistent. Perhaps this is an evangelism issue on the misconfigured server but
perhaps also a bug on the alert/icon disagreement.

Comment 11

[Ian McGreer]

I agree with you, but that's a PSM issue, not an NSS one.  Wan-Teh, I'll let you
switch it over.

Comment 12

[Wan-Teh Chang]

Ian, thank you for investigating this problem.

Changing the product to PSM for the alert/icon disagreement
described in comment #10.

Comment 13

[Robert Relyea]

Sorry Ian, I thought it was the unknown issuer problem we ran into today (where
we werent' finding issuers in the database).

The problem described is a known issue. There is very little that PSM can do
because there is no way to know the difference between a missing intermediate
and a missing root (you can have arbitrary numbers of Certs between the server
cert and it's signer). This problem exists for clean installations of IE and
Communicator 4.x as well. On IE it's self healing because IE stuffs intermediate
certs into it's cert store as it sees them, which is why the mecuryinsurance has
gotten away with their misconfigured server.

The only issue may be the confusion when the lock icon is clicked on a cert that
is verified 'by user acceptance'. Our old UI said 'signed by'. We should either:
1) go back to 'signed by'.
2) go back to 'signed by' if the user clicked to explicitly trust the cert.
3) say 'Verified by user' if the user clicked to explicitly trust the cert.

I would vote for some combination of 2 & 3 as ideal, but I think all are acceptable.

bob

bob

Comment 14

[Stephane Saux]

created tech evangelism bug 128920 regarding the misconfigured server.

Changing the summary of this bug to address the issue of what should be the
behavior of the lock icon when it's set as a result of the user manually
accepting the ssl connection after an SSL warning.

Cases:

Missing Intermediate CA (Unrecognized CA)
Untrusted CA.
Mismatched names.
Expired cert.

We should remember the fact that the trust was manual.

Comment 15

[Kai Engert (:KaiE:)]

Both the lock icon and the information shown in page info security should
mention if the user decided to manually trust a server cert. Changing summary.

Comment 16

[Kai Engert (:KaiE:)]

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

Comment 17

[John G. Myers]

Mass reassign ssaux bugs to nobody

Comment 18

[Paul Rubin]

This problem is caused by the server not being configured to send the chaining cert for the Verisign international CA, which is used for their SGC certificates (the expensive certs that used to be needed to promote "export" browsers with 40 bit SSL to 128 bits).  While there's no general solution to figuring out when an arbitrary chaining cert is missing, the culprit is this specific cert often enough that it might worth putting in a special kludge to recognize when it happens with this specific cert.  Alternatively, add the cert to the trusted root list, since the 40 bit step-up issue has gone away and pretty much all browsers support 128 bits for every cert now.  (Better confirm with Verisign before adding that cert to the root list).

Comment 19

[Kai Engert (:KaiE:)]

changing obsolete psm* target to --- (unspecified)

Comment 20

[:Cykesiopka]

The URL in the description seems to have a valid cert now.

However, I tested the following scenarios and websites on a Firefox 22 Nightly:
  Untrusted CA (sec_error_untrusted_issuer)
  https://mikestoolbox.net

  Mismatched Name (ssl_error_bad_cert_domain)
  https://www.cracked.com/

  Expired Cert (sec_error_expired_certificate)
  https://codingteam.net

Adding an exception and clicking the lock icon in the address bar for each site now clearly states: "You have added a security exception for this site."

So I'm guessing this can be resolved?

Comment 21

[Bob Clary [:bc] (inactive)]

agreed. thanks, Cykesiopka. -> WFM