OCSP Stapling

dnsdist supports OCSP stapling for DNS over HTTPS and DNS over TLS since 1.4.0-rc1. OCSP, Online Certificate Status Protocol (:rfc:`RFC 6960`) is a protocol allowing a client to check the expiration status of a certificate from the certification authority (CA) that delivered it. Since the requirement for the client to first retrieve the certificate then do additional steps to gather an OCSP response is not very efficient, and also discloses to the CA which certificate is validated, a mechanism has been designed to allow the server to retrieve the OCSP response from the CA and provide it to the client during the TLS exchange. This mechanism is named the TLS Certificate Status Request extension (:rfc:`RFC 6066`), also known as OCSP stapling.

While OCSP stapling is a net win for the client, it means that the server needs to retrieve the OCSP response itself and update it at regular interval, since the OCSP response tends to be short-lived by design.

dnsdist, as for example haproxy, only supports loading the OCSP response from a file, and has no embedded HTTP client to retrieve the OCSP response and refresh it, leaving it to the administrator to regularly retrieve the OCSP response and feed it to dnsdist.

Local PKI

When a local PKI is used to issue the certificate, or for testing purposes, dnsdist provides the generateOCSPResponse() function to generate an OCSP response file for a certificate, using the certificate and private key of the certification authority that signed that certificate:

The resulting file can be directly used with the addDOHLocal() or the addTLSLocal() functions:

After starting dnsdist, it is possible to update the OCSP response by connecting to the console, generating a new OCSP response and calling reloadAllCertificates() so that dnsdist reloads the certificates, keys and OCSP responses associated to the DNS over TLS and DNS over HTTPS contexts.

Certificate signed by an external authority

When the certificate has been signed by an external certification authority, the process is a bit more complicated because the OCSP needs to be retrieved from that CA, and there are very few options available to do that at the moment.

One of those options is to the use the OpenSSL ocsp command-line tool, although it’s a bit cumbersome to use.

The first step is to retrieve the URL at which the CA provides an OCSP responder. This can be done via the OpenSSL x509 command:

It will output something like “http://ocsp.int-x3.letsencrypt.org”.

Now we can use the OCSP tool to request an OCSP response for this certificate from the CA, provided that we have the certificate of the CA at hand, but it’s usually needed to get a correct chain of certificates anyway:

If everything goes well, this results in an OCSP response for the server certificate being written to /path/to/write/the/OCSP/response. It seems that earlier versions of OpenSSL did not properly handle the URL, and one needed to split the host and path parts of the OCSP URL, and use the -header option of the ocsp command:

We can now use it directly with the addDOHLocal() or the addTLSLocal() functions:

Since this response will be only valid for a while, a script needs to be written to retrieve it regularly via cron or any other mechanism. Once the new response has been retrieved, it is possible to tell dnsdist to reload it by connecting to the console and calling reloadAllCertificates() so that it reloads the certificates, keys and OCSP responses associated to the DNS over TLS and DNS over HTTPS contexts.

Testing

Once a valid OCSP response has retrieved and loaded into dnsdist, it is possible to test that everything is working fine using the OpenSSL s_client command:

should return something like OCSP Response Status: successful (0x0), indicating that the client received a valid OCSP stapling response from the server.