Forcing domain controllers (or other participants) to use an online responder (OCSP)

By default, Windows systems, even if an online responder (OCSP) is configured, will be sent to a certain number of OCSP requests fall back to a (if available) brevocation list, because this is usually more efficient in such a case. However, this behavior is not always desired.

For example, if one uses smart card logins, one might want to know if Logins were executed with unauthorized issued certificates. In conjunction with the deterministic good of the online responder you can thus create an (almost) seamless Audit trail create for all smartcard logins.

The Online Responder (Online Certificate Status Protocol, OCSP) is an alternative way of providing revocation status information for certificates. Entities that want to check the revocation status of a certificate do not have to download the complete list of all revoked certificates thanks to OCSP, but can make a specific request for the certificate in question to the online responder. For a more detailed description, see the article "Basics Online Responder (Online Certificate Status Protocol, OCSP)„.

There are the following ways to make sure that the online responder is definitely used.

Increase the Magic Number for the systems concerned, although this will not necessarily work reliably.
Issuing certificates that contain only OCSP and no CRL Distribution Point (CDP) as revocation information, although this cannot protect against tampering of issued certificates by an attacker.
Force the relevant systems to use an online responder (OCSP) via group policy.

Implementation

To force computers to use an online responder and ignore the revocation information entered in the certificate, a group policy can be used.

The relevant setting is located under "Computer Configuration", "Policies", "Windows Settings", "Security Settings", "Public Key Policies".

The certification authority certificate of the relevant certification authority must first be entered here.

For a root certification authority, it is imported into Trusted Root Certification Authorities.
For a subordinate certification authority, it is imported into "Intermediate Certification Authorities".

To do this, right-click in the respective certificate store and select "Import...".

Then the path to the certification authority certificate is entered.

The certificate store has already been determined and should not be changed.

After importing, right-click on the entry and select "Properties".

In the "OCSP" tab, the "Disable Certificate Revocation Lists (CRL)" option must be selected. The OCSP addresses are then entered in the list.

Please note that here we are talking about "additional OCSP download locations" is. Any OCSP addresses in the certificates to be checked may be used under certain circumstances. In the tests performed, however, this was only the case if the responders specified here could not be reached.

Function test

The following test cases are considered:

Test case: The online responders are not available. Does a fallback to the revocation list distribution points configured in the certificate take place?
Test case: Logon with an unknown certificate. Is it possible to log in with a certificate that contains an unknown serial number?

Test case: The online responders are not available

If the online responders are not available for the configured domain controllers, logon is not possible.

This means that there is no fallback to any revocation list paths that may exist in the certificate. A denial-of-service attack against the online responders is thus counteracted (with regard to a logon with a forged certificate with an unknown serial number).

In the event log of the domain controller against which the login was made, the event 21 of the source Kerberos-Key-Distribution-Center is logged.

Test case: Logon with an unknown certificate

If a user now logs in with a certificate whose certificate is not known to the online responder, he is also denied logon and the same event is logged on the domain controller.

Is the deterministic good configured for the online responder as well as the auditing of requested certificates, this is logged accordingly in the audit log of the online responder.

Disadvantages and limitations

Tests not complete

The option "Disable Certificate Revocation Lists (CRL)" is not officially documented by Microsoft, so no binding statement can be made as to whether the online responder is actually used in every situation. The statement made here is based on the tests described below on this topic, but they are far from complete. Pending test cases include:

How does the code behave when the Magic Number is exceeded?
Does the option to disable revocation lists possibly also affect certificates from other certification authorities?

No one hundred percent protection

If the certification authority is compromised, the attacker can write arbitrary serial numbers in his certificates. He could therefore also write an already existing serial number in such a certificate to cover his tracks. Thus, there is no 100% protection even with this method.

Although the use of blacklists can be deactivated, the dialog for the configuration speaks of "additional OCSP download locations" - if the attacker can break the connection between the online responders and the domain controllers, he could specify a different OCSP address in the certificate.

Dependence on the online responders

This solution relies on the continuous availability of the online responders. If they are not available or provide incorrect responses, registration is no longer possible.

Force domain controller (or other participants) to use an online responder (OCSP)