I often hear that PKI operators would like to see a new certificate revocation list issued immediately for revoked certificates.
Below, I would like to share some thoughts on why this approach is not ideal and propose a more elegant solution.
Someone recently approached me with an interesting problem.
A certification authority has been installed. Linux is used as the basis, i.e. (presumably) OpenSSL. The revocation lists work on Linux clients, but are not accepted by Windows systems. The following error message always appears when checking the revocation lists.
0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE) -- 2148081683 (-2146885613)
Text der Fehlermeldung: Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war.The error message reads as follows:
0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE) -- 2148081683 (-2146885613)
The revocation function was unable to check revocation because the revocation server was offline.Certificate revocation lists (CRLs) are used to remove issued certificates from circulation before the end of their validity period.
A CRL is a signed list of the serial numbers of certificates that have been revoked by the certification authority. The CRL has an expiration date (usually only a few days ahead) and is reissued and signed by the associated certification authority at regular intervals.
Certificate revocation lists can reach a considerable size if the volume of revoked certificates is high (as a rule of thumb, you can expect about 5 megabytes per 100,000 entries). The regular download of large certificate revocation lists by subscribers can generate a large network load. To address this problem, there is the concept of delta CRLs.
Understanding the roles involved is essential for designing a public key infrastructure.
The term "public key infrastructure" encompasses much more than the technical components and is often used in a misleading way.
In summary, a public key infrastructure is both an authentication technology and the totality of all the components involved.
Assume the following scenario:
There's a problem with one of your S/MIME encryption certificates. Contact your IT help desk for more info.Es gibt ein Problem mit einem ihrer S/MIME-Verschlüsselungszertifikate. Wenden Sie sich für weitere Informationen an Ihren IT-Helpdesk.Assume the following scenario:
Sign-in failed. Contact your system administrator and tell them that the KDC certificate could not be validated. Additional information may be available in the system event log.Certificates usually have a "CRL Distribution Points" extension that tells an application where the certificate's associated certificate revocation list (CRL) can be found.
This is like a telephone directory: It contains all the serial numbers of certificates that have been revoked by the certification authority (and are still within their validity period). Every application that checks the revocation status must download and evaluate the entire certificate revocation list.
As the size increases, this procedure becomes increasingly inefficient. As a rule of thumb, 100,000 revoked certificates already correspond to approx. 5 MB file size for the certificate revocation list.
The Online Certificate Status Protocol (OCSP) was developed for this purpose (under the leadership of ValiCert): It is similar to a directory assistance service where applications can request the revocation status for individual certificates, thus eliminating the need to download the entire CRL. OCSP is specified in RFC 6960 .
Continue reading "Basics: Online Responder (Online Certificate Status Protocol, OCSP)"
Assume the following scenario:
Type: Microsoft CRL-based revocation status provider
The revocation provider failed with the current configuration. The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE), 0x80092013Assume the following scenario:
Type: Microsoft CRL-based revocation status provider
The revocation provider failed with the current configuration. The object identifier does not represent a valid object. 0x800710d8 (WIN32: 4312 ERROR_OBJECT_NOT_FOUND), 0x800710d8Assume the following scenario:
ICertAdmin::RevokeCertificate: The data is invalid. 0x8007000d (WIN32: 13 ERROR_INVALID_DATA)By default, the Microsoft Certification Authority removes the serial numbers of expired certificates from the revocation lists it issues.
However, there are some exceptions to this.
Continue reading "Treatment of expired certificates when issuing certificate revocation lists"
More and more companies are using the Google Chrome browser or the new Chromium-based Microsoft Edge (codename Anaheim ) as the default browser on the Windows platform.
When distributing one of these two browsers, it should be noted that they sometimes behave differently from other browsers in terms of certificates.
Besides the fact that Chromium, unlike Internet Explorer and the previous Edge (codename Spartan ), enforces RFC 2818 , it also behaves differently when checking revocation information .
| Event Source: | Microsoft-Windows-CertificationAuthority |
| Event ID: | 131 (0x83) |
| Event log: | Application |
| Event type: | Warning |
| Event text (English): | An invalid OID has been detected in the EKUOIDsForPublishExpiredCertInCRL configuration setting. To resolve, run: "certutil -getreg ca\EKUOIDsForPublishExpiredCertInCRL" to identify the invalid OID and correct it. The default OIDs ("1.3.6.1.5.5.7.3.3" and "1.3.6.1.4.1.311.61.1.1") will be used. |
| Event text (German): | In der Konfigurationseinstellung "EKUOIDsForPublishExpiredCertInCRL" wurde eine ungültige OID festgestellt. Führen Sie zum Beheben den Befehl "certutil -getreg ca\EKUOIDsForPublishExpiredCertInCRL" aus, um die ungültige OID zu ermitteln und zu korrigieren. Die Standard-OIDs ("1.3.6.1.5.5.7.3.3" und "1.3.6.1.4.1.311.61.1.1") werden verwendet. |
| Event Source: | Microsoft-Windows-CertificationAuthority |
| Event ID: | 130 (0x82) |
| Event log: | Application |
| Event type: | Error |
| Symbolic Name: | MSG_E_CRL_CREATION |
| Event text (English): | Active Directory Certificate Services could not create a certificate revocation list. %1. This may cause applications that need to check the revocation status of certificates issued by this CA to fail. You can recreate the certificate revocation list manually by running the following command: "certutil -CRL". If the problem persists, restart Certificate Services. |
| Event text (German): | Von den Active Directory-Zertifikatdiensten konnte keine Zertifikatssperrliste erstellt werden. %1. Dies kann dazu führen, dass bei Anwendungen, bei denen eine Überprüfung des Sperrstatus der von dieser Zertifizierungsstelle ausgestellten Zertifikate erforderlich ist, ein Fehler auftritt. Durch Ausführen des folgenden Befehls kann die Zertifikatssperrliste manuell neu erstellt werden: "certutil -CRL". Sollte das Problem bestehen bleiben, führen Sie einen Neustart der Zertifikatdienste durch. |
| Event Source: | Microsoft-Windows-CertificationAuthority |
| Event ID: | 75 (0x4B) |
| Event log: | Application |
| Event type: | Error |
| Symbolic Name: | MSG_E_DELTA_CRL_PUBLICATION_HOST_NAME |
| Event text (English): | Active Directory Certificate Services could not publish a Delta CRL for key %1 to the following location on server %4: %2. %3.%5%6 |
| Event text (German): | Es konnte keine Delta-Zertifikatsperrliste für den Schlüssel %1 an folgendem Ort auf dem Server "%4" veröffentlicht werden: %2. %3.%5%6 |