OCSP – How Does OCSP Handle Deleted Certificates?

ad-certificate-servicescertificatecertificate-authoritycrlocsp

We have a Microsoft Certificate Authority running on Windows Server 2019. We are issuing certificates to Android devices via a MDM. The Android device users browse to a web application (hosted by Apache, implemented in PHP 8) using the Chrome web browser (on Android) that requires a client certificate.

We are installing a separate Windows Server 2019 instance with the Microsoft OCSP Responder role to validate/verify that the client certificates presented to the Apache web server are valid. Apache has several directives to handle OCSP validation. We'd also like to validate the certificates in PHP for further security.

From my research reading several RFCs and Microsoft technical documents, it seeems like the Microsoft OCSP Responder validates certificates by referencing against a CRL for revocation status.

How does the Microsoft OCSP Responder validate certificates if they have been deleted from the CA instead of revoked? If deleted and not revoked, they will not show up in the CRL.

Am I missing something here? Will the Microsoft OCSP Responder validate the serial number against the CA database as well as its revocation status?

Best Answer

Will the Microsoft OCSP Responder validate the serial number against the CA database as well as its revocation status?

by default, Microsoft OCSP will report such serial number as "Good". Starting with Windows Server 2008 R2, a deterministic OCSP response functionality is added to Microsoft OCSP. In short, CA publish all serial numbers of ever issued certificates and OCSP is configured to look into this directory as well. New behavior does the following:

if serial number does not exist in the folder, OCSP responds with UNKNOWN status. This means that requested serial number was never issued by CA
if serial number exist in the folder, a CRL is checked
if serial is listed in CRL, respond with REVOKED status and respond with GOOD otherwise.

More details on Microsoft KB: The Online Responder service does not return a deterministic GOOD for all certificates not included in the CRL

The KB contains a script which dumps all serial numbers of issued certificates into configured folder. However the script is a bit flawed. It exports only serials that exist in CA database at script execution time. CA database is maintained and old entries are deleted to prevent CA database overgrow. This will lead to false-positive UNKNOWN status on deleted certs although the cert was issued and exist somewhere in the wild. I prefer to keep everything issued regardless of CA maintenance and respond with GOOD even if cert was deleted from CA. To address this flaw, I would recommend to remove these lines from the script:

dir | foreach {
    remove-item $_ -force
}

this will keep serial numbers that no longer exist on CA between script runs.

Related Solutions

Certificate – What is a PEM File and How Does it Differ from Other OpenSSL Key Formats?

SSL has been around for long enough you'd think that there would be agreed upon container formats. And you're right, there are. Too many standards as it happens. In the end, all of these are different ways to encode Abstract Syntax Notation 1 (ASN.1) formatted data — which happens to be the format x509 certificates are defined in — in machine-readable ways.

.csr - This is a Certificate Signing Request. Some applications can generate these for submission to certificate-authorities. The actual format is PKCS10 which is defined in RFC 2986. It includes some/all of the key details of the requested certificate such as subject, organization, state, whatnot, as well as the public key of the certificate to get signed. These get signed by the CA and a certificate is returned. The returned certificate is the public certificate (which includes the public key but not the private key), which itself can be in a couple of formats.
.pem - Defined in RFC 1422 (part of a series from 1421 through 1424) this is a container format that may include just the public certificate (such as with Apache installs, and CA certificate files /etc/ssl/certs), or may include an entire certificate chain including public key, private key, and root certificates. Confusingly, it may also encode a CSR (e.g. as used here) as the PKCS10 format can be translated into PEM. The name is from Privacy Enhanced Mail (PEM), a failed method for secure email but the container format it used lives on, and is a base64 translation of the x509 ASN.1 keys.
.key - This is a (usually) PEM formatted file containing just the private-key of a specific certificate and is merely a conventional name and not a standardized one. In Apache installs, this frequently resides in /etc/ssl/private. The rights on these files are very important, and some programs will refuse to load these certificates if they are set wrong.
.pkcs12 .pfx .p12 - Originally defined by RSA in the Public-Key Cryptography Standards (abbreviated PKCS), the "12" variant was originally enhanced by Microsoft, and later submitted as RFC 7292. This is a password-protected container format that contains both public and private certificate pairs. Unlike .pem files, this container is fully encrypted. Openssl can turn this into a .pem file with both public and private keys: openssl pkcs12 -in file-to-convert.p12 -out converted-file.pem -nodes

A few other formats that show up from time to time:

.der - A way to encode ASN.1 syntax in binary, a .pem file is just a Base64 encoded .der file. OpenSSL can convert these to .pem (openssl x509 -inform der -in to-convert.der -out converted.pem). Windows sees these as Certificate files. By default, Windows will export certificates as .DER formatted files with a different extension. Like...
.cert .cer .crt - A .pem (or rarely .der) formatted file with a different extension, one that is recognized by Windows Explorer as a certificate, which .pem is not.
.p7b .keystore - Defined in RFC 2315 as PKCS number 7, this is a format used by Windows for certificate interchange. Java understands these natively, and often uses .keystore as an extension instead. Unlike .pem style certificates, this format has a defined way to include certification-path certificates.
.crl - A certificate revocation list. Certificate Authorities produce these as a way to de-authorize certificates before expiration. You can sometimes download them from CA websites.

In summary, there are four different ways to present certificates and their components:

PEM - Governed by RFCs, used preferentially by open-source software because it is text-based and therefore less prone to translation/transmission errors. It can have a variety of extensions (.pem, .key, .cer, .cert, more)
PKCS7 - An open standard used by Java and supported by Windows. Does not contain private key material.
PKCS12 - A Microsoft private standard that was later defined in an RFC that provides enhanced security versus the plain-text PEM format. This can contain private key and certificate chain material. Its used preferentially by Windows systems, and can be freely converted to PEM format through use of openssl.
DER - The parent format of PEM. It's useful to think of it as a binary version of the base64-encoded PEM file. Not routinely used very much outside of Windows.

I hope this helps.

Check SSL Certificate Revocation – How to Verify

Get the ocsp url from your cert:

$ openssl x509 -noout -ocsp_uri -in /etc/letsencrypt/archive/31337.it/cert1.pem
http://ocsp.int-x1.letsencrypt.org/
$

Send a request to the ocsp server to check if the cert is revoked or not:

$ openssl ocsp -issuer /etc/letsencrypt/archive/31337.it/chain4.pem -cert /etc/letsencrypt/archive/31337.it/cert4.pem -text -url http://ocsp.int-x1.letsencrypt.org/ -header "HOST" "ocsp.int-x1.letsencrypt.org"
...
        This Update: Oct 29 10:00:00 2015 GMT
        Next Update: Nov  5 10:00:00 2015 GMT
$

this is a good cert.

This is a revoked cert:

$  openssl ocsp -issuer /etc/letsencrypt/archive/31337.it/chain3.pem -cert /etc/letsencrypt/archive/31337.it/cert3.pem -text -url http://ocsp.int-x1.letsencrypt.org/ -header "HOST" "ocsp.int-x1.letsencrypt.org"
...
        This Update: Oct 29 12:00:00 2015 GMT
        Next Update: Nov  5 12:00:00 2015 GMT
        Revocation Time: Oct 29 12:33:57 2015 GMT
$

Best Answer

Related Solutions

Certificate – What is a PEM File and How Does it Differ from Other OpenSSL Key Formats?

Check SSL Certificate Revocation – How to Verify

Related Topic