# Locked-Down Networks Certificate Revocation

- Link: https://www.agilicus.com/anyx-guide/locked-down-networks-certificate-revocation/
- Published: 2024-05-14T00:25:44+00:00
- Author: Don Bowman

1. [Home](https://www.agilicus.com/)
 2. Locked-Down Networks Certificate Revocation

![Disconnected OCSP and CRL validation setup. This diagram illustrates an example
configuration for systems operating in disconnected or air-gapped environments needing
to validate certificates using OCSP and CRL. The diagram shows the flow of OCSP 
and CRL data to allow for certificate validation without direct internet access,
enhancing security in isolated networks. Agilicus solution for secure, offline certificate
validation.](https://www.agilicus.com/www/b23044be-ocsp-crl-disconnected-1024x536.
png)

CRL, OCSP, NO OUTBOUND

---

## Locked-Down Networks Certificate Revocation

Highly secure networks control the outbound (egress) traffic. Modern software can
be signed requiring looking up certificate revocation. Agilicus can bridge this 
gap.

[CONTACT](https://www.agilicus.com/contact-us/)

## Locked-Down Networks Certificate Revocation

It is common in high-security networks to restrict Internet access to solely those
services required. Imagine you have an industrial control system, it publishes statistics
to a single public cloud service. You want to configure your firewall to block everything
that is not that API endpoint. However, doing so breaks the TLS encryption since
it needs to periodically check revocation.

There are two primary methods of checking certificate revocation: Online Certificate
Status Protocol ([OCSP](https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol))
and Certificate Revocation List ([CRL](https://en.wikipedia.org/wiki/Certificate_revocation_list)).
Both of these are encoded in your certificate chain.

Let’s [examine](https://www.ssllabs.com/ssltest/analyze.html?d=api.agilicus.com)
the Agilicus api (api.agilicus.com):

OCSP: http://r3.o.lencr.org. This is the ‘Leaf’ certificate, the last one in the
chain. Let’s Encrypt has more information [here](https://letsencrypt.org/docs/lencr.org/).
Now, let’s take a look at the DNS resolution:

    ```wp-block-code
    $ dig +noall +answer @8.8.8.8 r3.o.lencr.org
    r3.o.lencr.org.		120	IN	CNAME	o.lencr.edgesuite.net.
    o.lencr.edgesuite.net.	857	IN	CNAME	a1887.dscq.akamai.net.
    a1887.dscq.akamai.net.	20	IN	A	72.136.197.57
    a1887.dscq.akamai.net.	20	IN	A	72.136.197.65
    ```

And this is where the problem arises. There is a CDN, the IP list is large and constantly
changing. We cannot allow outbound connections by IP to achieve our objective.

To work around this, Agilicus implements a transparent proxy with a fixed IP, the
same IP our API uses:

    ```wp-block-code
    $ dig +noall +answer @8.8.8.8 api.agilicus.com
    api.agilicus.com.	3600	IN	A	35.203.36.11
    ```

We can test this:

    ```wp-block-code
    $ curl  --resolve r3.o.lencr.org:80:35.203.36.11 -v -H "Host: r3.o.lencr.org" http://r3.o.lencr.org//MFMwUTBPME0wSzAJBgUrDgMCGgUABBRI2smg%2ByvTLU%2Fw3mjS9We3NfmzxAQUFC6zF7dYVsuuUAlA5h%2BvnYsUwsYCEgMUzps0GUA4tjrONIqrju8GDw%3D%3D
    ```

Here we are simulating a Let’s Encrypt OCSP lookup of a specific certificate to 
r3.0.lencr.org. We are overriding the IP address of the DNS resolution to 35.203.36.11.
Thus if we allow this IP in the firewall, the Agilicus API, and Let’s Encrypt OCSP
will both function.

Depending on your host architecture you might also have intermediate Certificate
Revocation or Windows CTDL updates. These function in a similar fashion, overriding**
crl.verisign.com** and **ctldl.windowsupdate.com**.

### Additional IP for Agilicus Specifically

In addition to the OCSP and CRL which are part of the SSL ecosystem, Agilicus requires
2 outbound IP connectivity points:

 1. API. To find the IP address, run ‘nslookup api.agilicus.com’ (35.203.36.11)
 2. Auth. To find the IP address, run ‘nslookup auth.__MYDOMAIN__’ (this will be the
    same IP address for https://admin.__MYDOMAIN__ as you sign-in to the Administrative
    API). 34.95.12.47. This will be the same IP you have set your CNAME wildcard to.

## Implementation

The implementation is simple:

 1. Add alias in either /etc/hosts or your local DNS for r3.0.lencr.org, crl.verisign.
    com, ctldl.windowsupdate.com pointing to api.agilicus.com
 2. Allow api.agilicus.com IP in your firewall on port 443 (for all API access) and
    port 80 (for OCSP and CRL access)
 3. Allow the IP of your Agilicus Authentication service (auth.__MYDOMAIN__) port 443

At this stage your air-gapped system will be able to function in the limited way
you intend, but securely with proper TLS encryption.

---