Microsoft Compatible CA Key Updates

EJBCA's Microsoft CA Compatibility Mode enables CA key updates in EJBCA to support Microsoft environments.

Due to differences in how Microsoft Windows handles CRL and OCSP verification, Microsoft CA Compatibility Mode can be enabled for CAs to change the CA's behavior when the CA is rekeyed. Generally, the expected behavior when a CA is rekeyed is that all future CRLs and OCSP responder certificates are signed by the new key pair after the rollover. Instead, Microsoft environments expect each generation of CA key pairs to continue signing CRLs for the certificates issued by that particular key pair. Likewise, OCSP responses are expected to be continued to be signed with an OCSP responder certificate signed by the original key pair.

Microsoft CA Compatibility Mode

When Microsoft CA Compatibility Mode is enabled and the CA is rekeyed, a new CRL partition is created and signed with the latest CA CRL signing key. Any following CRL generations will result in the creation of a new CRL for each partition, signed by its corresponding CRL signing key. Certificates issued by the CA will have their CRL Distribution Point, pointing to the partition signed by the same key as the certificate itself.

OCSP responses issued by a CA in Microsoft CA Compatibility Mode are signed by the same key as the requested certificate was signed by, or the OCSP responder signed by the corresponding key pair.

Microsoft CA Compatibility Mode enables the following to support Microsoft environments:

The CA will produce as many CRLs as there are generations of CA keys. Every CRL will be signed by its original key.
OCSP responses will have different signing keys, depending on which generation of CA keys signed the relevant certificate.

Note that the Microsoft CA Compatibility Mode comes with the following caveats:

You cannot switch between the two modes. Thus, Microsoft CA Compatibility Mode must be enabled when the CA is created. For more information, see the Certificate Authority configuration field Microsoft CA Compatibility Mode in CA Fields.
Microsoft Compatibility Mode is mutually exclusive with the use of Partitioned CRLs.

Configuration

The following tables list configurations required for the CA and Certificate Profile respectively.

CA Configuration

To use Microsoft CA Compatibility Mode, the CA must be configured according to the following. For information on all available CA fields, see CA Fields.

CA Setting	Requirements
CRL Specific Data
Microsoft CA Compatibility Mode	Must be enabled. Ensures that CRLs and OCSP responses are signed with the key expected by Microsoft Windows clients after CA rekeying.
Authority Key ID	Must be enabled. Extension needed for EJBCA to determine which CA key to use for CRL signing.
Issuing Distribution Point on CRLs	Must be enabled. Extension needed so that the client can check that a CRL belongs to the correct partition. Without this extension (or if non-critical, and not understood by the client), it would be possible to send the wrong CRL to a client, which would then consider all certificates to be not revoked.
Default CA defined validation data
Default CRL Distribution Point	Certificates must have a CRL Distribution Point (DP) URL which points to the correct partition. The CRL DP URL affects the CRL scope (see RFC 5280, section 5), and must match exactly between the certificate and the CRL. *Asterisks "" are replaced with the partition number** (except for partition 0, where the asterisks are removed without replacing). The URL must contain at least one asterisk. If you use the built-in "certdist" URL, all you need to do is to add &param=* to the URL. This is done automatically if you click Generate after enabling Microsoft CA Compatibility Mode.
Default Freshest CRL Distribution Point	If using Delta CRLs (also known as the "Freshest CRL" extension), specify an URL with an asterisk for the partition number, in the same way as in the Default CRL Distribution Point field.

Certificate Profile Configuration

The Certificate Profile for issued certificates must be configured according to the following.

For information on all available Certificate Profile fields, see Certificate Profile Fields.

Certificate Profile Setting	Requirements
CRL Distribution Points	Must be enabled.
Use CA defined CRL Distribution Point (displays when CRL Distribution Points is enabled).	Must be enabled.

Certificates that are issued with certificate profiles not configured as above, and any pre-existing certificates prior to activating Microsoft CA Compatibility Mode, will have partition number 0.

CRL Generation

After a CA has been configured with Microsoft CA Compatibility Mode, then requesting creation of a new CRL will generate CRLs for all partitions.

This applies to the CRL Update Worker, CLI, the WebService, the AdminWeb, as well as all operations that indirectly trigger CRL generation, such as CA import or renewal.

Fetching CRL Partitions

EJBCA supports fetching CRL partitions by specifying a parameter in the URL. By default, if no parameter is given, it will return CRL partition 0 (which will contain any existing certificates, see Configuration).

The following servlets support retrieving CRL partitions. In the example URLs, the partition number is 1.

Servlet name	Parameter name	Example URL
certdist	partition	http://ejbca.example.com:8080/ejbca/publicweb/webdist/certdist?cmd=crl&issuer=CN%3DExample&partition=1
search.cgi (RFC 4387)	partition (non-standard)	http://ejbca.example.com:8080/crls/search.cgi?iHash=A0LJKitIFOPr%2BpXooZ7b3EWNyu0&partition=1
AdminWeb getcrl	partition	https://ejbca.example.com:8443/ejbca/adminweb/ca/getcrl/getcrl?cmd=crl&issuer=CN=Example&partition=1 Requires client certificate.

Non-existing partitions are handled the same way as a non-existing CA would be handled. For example, search.cgi will give the HTTP response "204 No Content".