Implement LoadTemporaryRoot for Windows

net/base/test_root_certs_win.cc

+// Copyright (c) 2010 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "net/base/test_root_certs.h"
+
+#include "base/logging.h"
+#include "net/base/x509_certificate.h"
+
+namespace net {
+
+namespace {
+
+// Creates a new temporary memory store.
+HCERTSTORE CreateMemoryStore() {
+  return CertOpenStore(CERT_STORE_PROV_MEMORY, 0, NULL,
+                       CERT_STORE_DEFER_CLOSE_UNTIL_LAST_FREE_FLAG, NULL);
+}
+
+}  // namespace
+
+bool TestRootCerts::Add(X509Certificate* certificate) {
+  BOOL ok = CertAddCertificateContextToStore(
+      temporary_roots_, certificate->os_cert_handle(),
+      CERT_STORE_ADD_NEW, NULL);
+  if (!ok) {
+    // If the certificate is already added, return successfully.
+    return GetLastError() == CRYPT_E_EXISTS;
+  }
+
+  empty_ = false;
+  return true;
+}
+
+void TestRootCerts::Clear() {
+  CertCloseStore(temporary_roots_, 0);
+  temporary_roots_ = CreateMemoryStore();
+  DCHECK(temporary_roots_);
+  empty_ = true;
+}
+
+bool TestRootCerts::IsEmpty() const {
+  return empty_;
+}
+
+void TestRootCerts::UpdateChainContext(
+    PCERT_CHAIN_CONTEXT chain_context) const {
+  if ((chain_context->TrustStatus.dwErrorStatus &
+       CERT_TRUST_IS_UNTRUSTED_ROOT) == 0)
+    return;  // Trusted certificate - nothing to fix.
+
+  if (IsEmpty())
+    return;  // No need to scan - no temporary trusted certificates.
+
+  // Windows does not support application-level trusts until Win 7, via
+  // CERT_CHAIN_ENGINE_CONFIG.hExclusiveRoot. Because of this, a messy,
+  // manual, brute-force method is used for unit tests. Look through every

[wtc, 2010/11/17 19:44:39]

Could you please add a short version of your description of
the algorithm in
http://code.google.com/p/chromium/issues/detail?id=8470#c3 ?
In particular, that our solution is inspired by the way
Outlook and EFS uses the Trusted People” store as described in
http://technet.microsoft.com/en-us/library/bb457027.aspx.

[Ryan Sleevi, 2010/11/18 05:31:58]

Sure. There are still differences in how we're doing it, judging by how the
Windows Communication Framework implements
System.IdentityModel.Selectors.X509CertificateValidator.PeerOrChainTrustValidator.

Namely, *no* chain building happens (EFS, Outlook, WCF) when checking for peer
trust - it's simply checked that the cert fingerprint appears in "TrustedPeople"
and not in "Disallowed" - CAPI traces and Reflector confirm.

+  // chain on |chain_context|, looking for a chain which contains one of the
+  // trusted certificates. If a matching certificate is found, unset the
+  // three status-bits that Windows sets when an untrusted root is found.
+  // Any other failure states are left unmodified, so that situations like
+  // name or date mismatches are properly reported.
+  for (DWORD chain_index = 0; chain_index < chain_context->cChain;
+       ++chain_index) {
+    PCERT_SIMPLE_CHAIN chain = chain_context->rgpChain[chain_index];
+    // Scan through all the certificates, rather than just the root, since
+    // an RFC 3280/5280 trust anchor may be any certificate in the chain, not
+    // just the root certificate.
+    for (DWORD element_index = 0; element_index < chain->cElement;
+         ++element_index) {
+      PCERT_CHAIN_ELEMENT element = chain->rgpElement[element_index];
+      PCCERT_CONTEXT cert = CertFindCertificateInStore(
+          temporary_roots_, X509_ASN_ENCODING | PKCS_7_ASN_ENCODING, 0,
+          CERT_FIND_EXISTING, element->pCertContext, NULL);
+      if (cert != NULL) {
+        // Successfully located the certificate in the temporary roots.
+        // Free the returned certificate - it is not used.
+        CertFreeCertificateContext(cert);
+
+        // Unset both the element status and the overall chain status, in the
+        // event a Windows function drills down into the chain results.
+        if (element->TrustStatus.dwErrorStatus &
+            CERT_TRUST_IS_UNTRUSTED_ROOT) {
+          element->TrustStatus.dwErrorStatus &=
+              ~(CERT_TRUST_IS_UNTRUSTED_ROOT |
+                CERT_TRUST_REVOCATION_STATUS_UNKNOWN |

[wtc, 2010/11/17 19:44:39]

Two comments about the revocation error flags.

1. I think we should not clear CERT_TRUST_REVOCATION_STATUS_UNKNOWN
and CERT_TRUST_IS_OFFLINE_REVOCATION.  I believe
CERT_TRUST_REVOCATION_STATUS_UNKNOWN is set not because
the test root cert is untrusted, but because the test
server cert doesn't have a CRL distribution point and
AIA extension with OCSP responder URL.
(CERT_TRUST_IS_OFFLINE_REVOCATION is always set if
CERT_TRUST_REVOCATION_STATUS_UNKNOWN is set, in my experience.)

2. I believe our hack of using an untrusted test root cert
and ignoring CERT_TRUST_IS_UNTRUSTED_ROOT will work for
most unit tests, but won't work for a unit test on
revocation, because CryptoAPI won't be able to verify a
CRL or OCSP response signed by the test root CA.

Do you agree?

[Ryan Sleevi, 2010/11/18 05:31:58]

No, I believe the issue is directly related to the fact that the certificate
doesn't appear in the list. The revocation checking process is described at
http://technet.microsoft.com/en-us/library/bb457027.aspx#EKAA . Under item #3,
the relevant section I've marked up with ***

When a root certificate—a certificate that contains the same DN for both the
Subject and Issuer attributes—is encountered, a revocation check may or may not
occur. If the certificate chaining engine behavior will depend on whether the
application enables the CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT flag,
which is the default, the root CA’s certificate is not checked for revocation.
***If the flag is not enabled, the root CA certificate is checked for revocation
if the root CA certificate includes the CDP extension. If the CDP extension is
not included, no revocation check is performed.***

However, this only applies when it appears in the "Trusted Root", as described
below. Because it does not, no revocation checking is even considered, hence the
STATUS_UNKNOWN. AFAICT, the _OFFLINE_REVOCATION is set for the same reason: Not
enough information was available (by means of appearing in the "Trusted Roots"),
so the absence of the CDP is non-authoritative and thus didn't happen.
Yes, I believe you're right. The general process of revocation checking under
Vista+ is described at
http://technet.microsoft.com/en-us/library/ee619754(WS.10).aspx#BKMK_BC

Only Evaluate Chains that Terminate in a Trusted Root Certificate
After CryptoAPI builds a certificate chain up to a trusted root authority
certificate, it will check for certificate revocation. The validation will
continue from the root CA certificate to the entity certificate presented to the
application. If there are multiple certificate chains that terminate in a
trusted root authority certificate, then CryptoAPI will validate each chain
until it finds a chain that is not revoked.

Under the section "Building the OCSP Signing Certificate Chain", the following
is stated: "If a certificate chain from the OCSP signing certificate to a
trusted root CA cannot be validated, then CryptoAPI 2.0 will return an error
message that the revocation server was offline."

+                CERT_TRUST_IS_OFFLINE_REVOCATION);
+          chain_context->TrustStatus.dwErrorStatus &=
+              ~(CERT_TRUST_IS_UNTRUSTED_ROOT |
+                CERT_TRUST_REVOCATION_STATUS_UNKNOWN |
+                CERT_TRUST_IS_OFFLINE_REVOCATION);
+          return;
+        }
+      }
+    }
+  }
+}
+
+TestRootCerts::TestRootCerts()
+    : temporary_roots_(CreateMemoryStore()),
+      empty_(true) {
+  DCHECK(temporary_roots_);
+}
+
+TestRootCerts::~TestRootCerts() {
+  CertCloseStore(temporary_roots_, 0);
+}
+
+}  // namespace net