Enable CRL support

As of Direct-1.3.0.6-NET45 it is no longer required to install the partner Anchor in the Windows certificate store to activate certificate revocation checking. This feature only works on Windows 2012 R2 and newer. The documentation on this page for Windows versions prior to Windows 2012 R2 is still required for proper certificate revocation checks.

Overview

The .NET Reference Implementation supports CRL (content revocation list) checking in cooperation with Windows. Content revocation lists contain certificate serial numbers that have been revoked. The CRL is also signed by the CA. 
 
 

Setup

Setting the Trust Model Settings to Online mode is one half of the setup. Unfortunately the .NET security framework code is dependent on Windows's PKI process implementation to enabled the automatic checking and caching of certificate CRLs. What do I mean by dependent. We are using an object called X509Chain in the System.Security assembly. We set our policy on this object which can be overriden by the Trust Model Settings. We add anchors associated to the domain/owner we are sending from to the X509Chain object. Finally to activate the chaining checks we call the Build method passing in the public certificate. Send a message too [[1]] which is a test for CRL checking from a tool called Direct Certificate Discovery Testing Tool under the direction of the office of the National Coordinator (ONC) and National Institute of Standards and Technology (NIST). Assuming we have installed their Anchor we would expect to send a message using the CN=D17_valA certificate. Yet we fail by sending to D17_invB. Why is that? Note test D17 has published two revoked background certs along with one valid cert. But again why did Windows fail to look up the revoked certificates in the published CRL? It turns out the X509Chain object (backed by CryptoAPI) does not check CRLs unless we put the anchor in the Third-Party Root Certification Authorities machine store path. Below we installed DCDT's trust anchor, in the Local Computer store's "Third-Party Root Certification Authorities" folder. If you are writing tests such as TestD17 in DCDTTests.cs then place the anchor in the current user store's "Trusted Root Certification Authorities" folder.
 
 
 Third-Party Root Certification Authorities
 
 
 

Troubleshooting

So the X509Chain object is backed by the native Windows CryptoAPI. While we can see what is going on in the .NET Framework code we do not have the same insight into native components. But there is a tool that will allow you to see the CryptoAPI 2.0 diagnostics. To enabled go to Event Viewer (Local) | Applications and Services | logs | Microsoft | Windows | CAPI2 | Operational. Right click and click Enable Log. Now you can experiment. Check out the resources below for more info. 
 
  If you do not have the anchor installed in the machine store while testing then you will see entries in the logs like the following two entries in the TrustStatus section.
 
  CERT_TRUST_IS_REVOCATION_UNKNOWN
  CERT_TRUST_IS_OFFLINE_REVOCATION
 
  Those two statuses do not block sending of a message currently. It is not one of the problems we check for currently but we may expose the problem flags assertions in the future. Those two flags are a little misleading because the root of the problem the trust anchor is not installed in a trusted Windows store.
 
 
 

Implementation choices

So there are a few choices. We could write our own logic to pull the CRLs from certificate. Bellow is a simple example of a CRL entry in the certificates's CRL Distribution Points entry. This is the simple example. But this can contain more than one URL and it can contain both CRLs and OCSPs. This would be a lot of work and a complete understanding of RFC 5280 and RFC 6960. Another choice would be to switch to the Bouncy Castle library. We did not investigate this. We chose to stay with the .NET Framework code and installing the trust anchor in our trusted store as described above. 
 
 
 CRL Distribution Points Example
 
 

Syncing Anchors to Machine Store

Currently there is no anchor syncing between the config store and Windows machine store. One solution could be to adding a new Quartz .Net job to the Direct Monitor Service. But at this time we do not have a sync feature. Remember when syncing the anchors you would also need to sync the trust bundle anchors.
 
 

Resources

[2]
[3]