Tag: CryptoAPI

The Simple Certificate Enrollment Protocol (SCEP) is an ancient protocol from the early 2000s. It does not use Transport Layer Security (TLS). Therefore, the protocol messages are encrypted at the transport layer.

When sending the certificate request to the NDES server, the client will encrypt the certificate request with the NDES server's CEP Encryption certificate (which was previously communicated to it via the GetCACert message).

When the issued certificate is received, the NDES server will encrypt the response with a self-signed certificate temporarily created by the SCEP client.

In both cases, a symmetric encryption algorithm is used.

Continue reading "Cryptographic Hardening of SCEP Transactions for the Network Device Enrollment Service (NDES)"

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.

Continue reading "Revocation lists are not recognized as valid (only) on Windows (CRYPT_E_REVOCATION_OFFLINE)"

Since Windows NT 4.0, Cryptographic Service Providers (CSP) have been part of the CryptoAPI.

The idea is that an application does not have to worry about the specific implementation of key management, but can leave this to generic operating system interfaces. This also prevents cryptographic keys from being loaded into the working memory in the security context of the user/application used (a fatal security incident based precisely on this problem was the Heartbleed incident ).

For example, it makes no technical difference to the certification authority software how its private key is protected - whether in software or with a hardware security module (HSM), for example. The call of the private key is always identical for the certification authority.

With Windows Vista and the introduction of Cryptography Next Generation (CNG) as a replacement for CryptoAPI, Key Storage Providers (KSP) were introduced.

Continue reading "Basics: Cryptographic Service Provider (CSP) and Key Storage Provider (KSP)"

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)"

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 .

Continue reading "Google Chrome and Microsoft Edge do not check the revocation status of certificates"

In order to determine whether a certificate has been issued by a certification authority that has been classified as trustworthy, a trust chain must be built. To do this, all certificates in the chain must be determined and checked. Microsoft CryptoAPI builds all possible certificate chains and returns those with the highest quality to the requesting application.

Continue reading "Basics: Finding certificates and validating the certification path"

If a valid, unexpired certificate is to be withdrawn from circulation, it must be revoked. For this purpose, the certification authorities maintain corresponding certificate revocation lists in which the digital fingerprints of the revoked certificates are listed. They must be queried during the validity check.

Continue reading "Basics: Checking the revocation status of certificates"

OCSP responses from a Microsoft OCSP responder are valid for exactly as long as the underlying certificate revocation list (CRL). In some scenarios, you may want to reduce OCSP validity times by using delta CRLs. At the same time, however, no delta CRL should be used for the CRLs entered in the CDP paths in order to enable a fallback to a CRL with a longer validity.

Continue reading "Combining Online Responder (OCSP) with delta CRL and CRL distribution point (CDP) without delta CRL for increased resilience"

The following section examines how the revocation status check behaves if the Online Responder should fail. Depending on the configuration of the certificates issued, the behavior can vary considerably.

Continue reading "Effects of the failure of the Online Responder (OCSP) on the verification of the revocation status of a certificate"

Unfortunately, in practice it happens from time to time that the certificate revocation list (CRL) of a higher-level certification authority expires and a renewal does not take place. This can also happen as planned, for example when an old hierarchy is decommissioned.

Continue reading "What impact does the expiry of the CRL of one of the higher-level certification authorities have on the certification authority?"

All applications that use the Microsoft Cryptographic Application Programming Interface Version 2 (Crypto API Version 2, CAPI2) have a mechanism for caching certificate revocation information (certificate revocation lists and OCSP responses).

Thus, there is no guarantee that, for example, a newly published CRL will be used by participants before the previous CRL, which is still in the cache, has expired.

The following describes how to view and influence the CRL cache.

Continue reading "View and clear the address cache for certificate revocation lists (CRL URL Cache)"

A public key infrastructure comprises all components (hardware, software, people and processes) required for the use of digital certificates. A PKI consists of one or more certification authorities (CA). The tasks of a PKI include:

• Ensuring the authenticity of keys, i.e. establishing a traceable link between a key and its origin to prevent misuse.
• Revocation of certificates, i.e., ensuring that decommissioned or compromised (e.g., stolen) keys can no longer be used.
• Ensuring accountability (non-repudiation), i.e., for example, that the owner of a key cannot deny that it belongs to him.
• Enforcement of policies, i.e. standardized procedures for the use of certificates.

Continue reading "Basics: Public Key Infrastructures (PKI)"

Anyone who wants to use the smart card logon feature in their company would be well advised to ensure that their certification authority has the strongest possible security hardening. This includes some essential measures:

• Removing all unnecessary certification authority certificates from the NTAuthCertificates object in Active Directory : Each certification authority located in this store is authorized to issue smart card logon certificates in Active Directory for the complete forest.
• Use qualified subordination : Restricting the certification authority certificates so that they are only trusted for the Extended Key Usages actually issued. In the event of a compromise of the certification authority, the damage is then limited to these Extended Key Usages. The "Smart Card Logon" Extended Key Usage would then only be present in the certification authority certificate of the certification authority that actually issues such certificates.

What is interesting about these thoughts, however, is that the domain controllers do not check the Extended Key Usages at all when logging on via smart card.

Continue reading "Domain controllers do not check Extended Key Usage on smart card logon"