Mark untrusted certificates as such in Linux UI.

net/base/cert_database_nss.cc

Index: net/base/cert_database_nss.cc
diff --git a/net/base/cert_database_nss.cc b/net/base/cert_database_nss.cc
index 179ee82b9b584502014b42ecc0b48c09486b7a3a..f95538b629e5e2f8beec1b6e0e31fffa0abbcfc2 100644
--- a/net/base/cert_database_nss.cc
+++ b/net/base/cert_database_nss.cc
@@ -238,6 +238,19 @@ unsigned int CertDatabase::GetCertTrust(
   }
 }
 
+bool CertDatabase::IsUntrusted(const X509Certificate* cert) const {
+  CERTCertTrust nsstrust;
+  SECStatus rv = CERT_GetCertTrust(cert->os_cert_handle(), &nsstrust);
+  if (rv != SECSuccess) {
+    LOG(ERROR) << "CERT_GetCertTrust failed with error " << PORT_GetError();
+    return false;
+  }
+
+  return nsstrust.sslFlags == 0 &&
+         nsstrust.emailFlags == 0 &&
+         nsstrust.objectSigningFlags == 0;

[wtc, 2011/09/12 23:57:04]

agl: sorry for the very late reply.

I got the answers from Bob Relyea within two weeks, but I
forgot post them here.

Here is the code we need to write.

1. Some code to define CERTDB_TERMINAL_RECORD for
NSS <= 3.12.x.

// In NSS 3.13, CERTDB_VALID_PEER was renamed CERTDB_TERMINAL_RECORD.  So
// we use the new name of the macro.
#if !defined(CERTDB_TERMINAL_RECORD)
#define CERTDB_TERMINAL_RECORD CERTDB_VALID_PEER
#endif

2. The test on lines 249-251 should be replaced with the
following:

  unsigned int flags = SEC_GET_TRUST_FLAGS(&nsstrust, trustSSL);
  if ((flags & CERTDB_TERMINAL_RECORD) &&
      ((flags & (CERTDB_TRUSTED_CA | CERTDB_TRUSTED)) == 0)) {
    // In a terminal trust record, three bits may be set: CERTDB_VALID_CA,
    // CERTDB_TRUSTED_CA, and CERTDB_TRUSTED.  The CERTDB_VALID_CA bit is
    // irrelevant to distrust, so we don't test that bit.
    return true;
  }
  // Repeat for email and code signing.
  flags = SEC_GET_TRUST_FLAGS(&nsstrust, trustEmail);
  if ((flags & CERTDB_TERMINAL_RECORD) &&
      ((flags & (CERTDB_TRUSTED_CA | CERTDB_TRUSTED)) == 0)) {
    return true;
  }
  flags = SEC_GET_TRUST_FLAGS(&nsstrust, trustObjectSigning);
  if ((flags & CERTDB_TERMINAL_RECORD) &&
      ((flags & (CERTDB_TRUSTED_CA | CERTDB_TRUSTED)) == 0)) {
    return true;
  }
  return false;

Two Notes
- This handles the explicit distrust case, which is most
  important to show in the UI.  A test similar to your code
  would be necessary to handle a root CA that was added
  without any trust (as opposed to with explicit distrust).
  I omitted that test here because we don't have any such
  root CA cert in NSS.
- Since Chrome doesn't do email or code signing, we can
  omit the trustEmail and trustObjectSigning code.  The
  original NSS code uses a for loop to test the three
  kinds of trust, but C++ doesn't allow us to increment
  an enum variable, so I had to unroll the for loop.

[agl, 2011/09/13 16:53:50]

At least on my Ubuntu system I do have a distrusted CA: MD5 Collisions Inc. Can
you provide the code for detecting such a CA. At that point, I think the patch
will be ready.

Thanks. 

[wtc, 2011/09/14 22:00:53]

Yes.  Unfortunately the MD5 Collisions Inc. CA in the
NSS trusted CA file is *not* explicitly distrusted in
NSS 3.12.x.  It has "unknown" trust, which is mapped to
all 0 trust flags and means we must verify the cert as
usual.

I heard that certificate is a corrupted copy and is
meant to prevent the real MD5 Collisions Inc. CA cert
from being imported into NSS.  (NSS would reject it
because it has the same issuer and serial number as
the corrupted copy.)  The corrupted copy would fail
signature verification during certificate verification.
I need more time to verify the cert is indeed corrupted.

This is the code I have written so far (better than the
code I gave you yesterday):

// In NSS 3.13, CERTDB_VALID_PEER was renamed CERTDB_TERMINAL_RECORD.  So
// we use the new name of the macro.
#if !defined(CERTDB_TERMINAL_RECORD)
#define CERTDB_TERMINAL_RECORD CERTDB_VALID_PEER
#endif

...

  const unsigned int kTrusted = CERTDB_TRUSTED_CA | CERTDB_TRUSTED;

  // Handle explicitly distrusted certificates.
  unsigned int flags = SEC_GET_TRUST_FLAGS(&nsstrust, trustSSL);
  if ((flags & CERTDB_TERMINAL_RECORD) && (flags & kTrusted) == 0) {
    // In a terminal trust record, three bits may be set: CERTDB_VALID_CA,
    // CERTDB_TRUSTED_CA, and CERTDB_TRUSTED.  The CERTDB_VALID_CA bit is
    // irrelevant to distrust, so we don't test that bit.
    return true;
  }
  // Repeat for email and code signing.
  flags = SEC_GET_TRUST_FLAGS(&nsstrust, trustEmail);
  if ((flags & CERTDB_TERMINAL_RECORD) && (flags & kTrusted) == 0)
    return true;
  flags = SEC_GET_TRUST_FLAGS(&nsstrust, trustObjectSigning);
  if ((flags & CERTDB_TERMINAL_RECORD) && (flags & kTrusted) == 0)
    return true;

  // Self-signed certificates that don't have any trust bits set are
  // untrusted.  Other certificates that don't have any trust bits set
  // may still be trusted, if they chain up to a trust anchor.
  if (CERT_CompareName(&cert->os_cert_handle()->issuer,
                       &cert->os_cert_handle()->subject) == SECEqual) {
    return (nsstrust.sslFlags & kTrusted) == 0 &&
           (nsstrust.emailFlags & kTrusted) == 0 &&
           (nsstrust.objectSigningFlags & kTrusted) == 0;
  }
  return false;

You can simplify it further.  For example,
SEC_GET_TRUST_FLAGS(&nsstrust, trustSSL) is the fancy way
to say nsstrust.sslFlags.

I tested this patch with my code.  The only problem I see
is that it doesn't update the "Untrusted" badge as soon as
I change the trust bits in the Certificate Manager UI;
the new "Untrusted" status is only reflected after I restart
Chrome.  But you don't need to fix that bug in this CL.

[wtc, 2011/09/14 22:58:53]

I examined the MD5 Collisions Inc. CA certficate in NSS.
It differs from the real MD5 Collisions Inc. CA certficate
in two ways.

1. The serial number changed from 65 (0x41) to 66 (0x42).
So what I said earlier about preventing the real MD5
Collision Inc. CA certificate from being imported into
NSS was wrong.  The real certificate can be imported,
but NSS won't use it because of the next change.

2. The last digit in the not-before and not-after UTC
times changed from '0' (0x30) to '1' (0x31).  Given two
certificates with the same subject, NSS favors the newer
certificate.

So, NSS will use the newer (corrupted) cert, and certificate
verification will fail during signature verification.

So, the code I gave you is the best we can do.

In NSS 3.12.x, the (corrupted) MD5 Collisions Inc. CA
cert won't have the "Untrusted" badge.

In the upcoming NSS 3.13, we explicitly distrust the
(corrupted) MD5 Collisions Inc. CA cert, so it will have
the "Untrusted" badge.

The reason we don't explicitly distrust the MD5 CA cert
in NSS 3.12.x is that NSS 3.12.x cannot distrust intermediate
CA certs.  This bug is fixed in NSS 3.13.

+}
+
 bool CertDatabase::SetCertTrust(const X509Certificate* cert,
                                 CertType type,
                                 unsigned int trusted) {