103698 - PSM allows 2 CA certificates with same subject, same serial no, but different key material

Status: VERIFIED INVALID

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

Description

[thomask]

During CMS testing, I encounter this problem a lot, and expect our users see the
same problem too.

Say, we setup CA1 and call it CN=Certificate Manager, O=mcom.com, and do
some testings. Then, we delete the CA, and setup CA2 and name it
CN=Certificate Manager, O=mcom.com (same thing as CA1). PSM will accept
it. The problem occurs when the user tries to access the agent of CA2. The
browser will return

 "SSL has received an error from the server indicating an incorrect
  Massage Authentication Code. This could indicate a network error,
  a bad server implementation, or a security violation."

One of the enhancement we can do in PSM is to pop up a dialog box to
confirm the deletion of the old CA certificate with the same 
subject name and same. 
serial no.

Comment 1

[thomask]

The problem is that PSM allows 2 certificates with same serial number, same name
but different key materials. So when it tries to do something with the
certificate, it has problems figuring out which certificate to use.

Comment 2

[Stephane Saux]

I think I was aware of that.
It's a perversion of the specs to issues certs with the same serial number from
the same CA with the same SN.

Another incorrect cert that confuses PSM was uncountered when a user filed a
bug. He had two https servers (a.ddd.com and b.ddd.com) and he issued two SSL
certs from an openSSL CA and although the SN were different, the serial numbers
were the same.  (but of course the key material was different.)

How much work should PSM (and NSS) do to detect these obviously wrong certs?

Comment 3

[thomask]

A certificate can be uniquely identified by using serial number, subject name,
and issuer name. So maybe PSM needs to check for existing certificates in PSM's
database that match the serial, subject name, and issuer name. If such
certificates are found, their key material (or the signature of the certificate)
should be the same as the one that is being used or examined. If it is
different, we should popup a dialog (if we are in a user-interaction session).
The dialog may ask the user to accept the new CA certificate. If user choose to
accept, the old certificate should be deleted, and the new certificate should be
imported

Comment 4

[Robert Relyea]

Actually certificates are uniquely identified by issuer/SN. If they have the
same issuer/SN number of different DER data then one (or both) are invalid.

Comment 5

[Stephane Saux]

So either the bug is to detect rogue CA certs (and reject them) or we mark it as
INVALID. I'm leaning toward the second.

Comment 6

[John Unruh]

Marking invalid.

Comment 7

[John Unruh]

Verified.