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.
The following tables list configurations required for the CA and Certificate Profile respectively.
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.
|CRL Specific Data|
|Microsoft CA Compatibility Mode|
Must be enabled.
|Authority Key ID|
Must be enabled.
|Issuing Distribution Point on CRLs|
Must be enabled.
|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 ¶m=* 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.
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|
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".