The certificate from IdenTrust to the FBCA was revoked on February 17th, yet this certificate path remains valid through Mozilla Firefox:

As well as Chrome 48.0.2564.95 on Android 6.0.1:

To my knowledge, from it's inception, the FBCA (or "FBCA 2013"), was never intended to be a "Trust Anchor" for the federal government. The intended Trust Anchor for the federal government is the Federal Common Policy Root CA, which is currently distributed via Microsoft.

This is in reference to Test #2, which is documented in the README.md of this repository.

Creating this issue due to problems observed in Issue 2.

Example: openssl s_client -connect test1.fpki.18f.gov:443 -servername test1.fpki.18f.gov

Re: Requests for CRLs and OCSP responses appear to yield different results if using IPv6 -vs- IPv4

@konklone Assuming the hostname test1 is intended to demonstrate the path to the Common Policy Root CA? (distributed via Microsoft, not Mozilla)

https://test3.fpki.18f.gov

The above host uses a FPKI TOCA-issued certificate, with an installed 7-certificate chain (including the EE cert) that proceeds up to Identrust's DST ACES CA X6 root.

This root cross-signed the Federal Common Policy CA, as discussed on Bugzilla, and Identrust has said they will revoke the cross-signature by February 19th.

However, I believe the Federal Common Policy CA in this chain has an x.509 Policy Constraints extension of inhibitPolicyMapping (skipCerts=1).

   If the inhibitPolicyMapping field is present, the value indicates the
   number of additional certificates that may appear in the path before
   policy mapping is no longer permitted.  For example, a value of one
   indicates that policy mapping may be processed in certificates issued
   by the subject of this certificate, but not in additional
   certificates in the path.

I've validated that libcurl, Chrome, and Firefox all successfully validate the chain at https://test3.fpki.18f.gov as chaining to a trusted root. Should this be the case?