I have set up a variety of test domains over the years, and inevitably I need to set up Active Directory Certificate Services (ADCS) on them because I need to issue certificates of some kind for some purpose (e.g. VPN, Wi-Fi access, Windows Hello for Business, etc. – see https://oofhours.com/2020/04/05/intune-certificates-something-everyone-should-set-up/ for details on how to set up SCEP).  When using ADCS in a “pure” Active Directory environment where all devices are able to connect to an AD domain controller using LDAP, the default certificate revocation list configuration (CRL Distribution Point) works fine:

That means that information about revoked certs is written to a folder on the server, as well as into Active Directory, where clients that are able to make LDAP queries can find it.  Off the corporate network, that doesn’t work so well.

Publishing the CRL through other methods isn’t too hard, as you can take the folder location from the first line and set it up as an IIS web site on the same machine:

Make sure you also configure IIS to allow for “double-escaping” as the delta CRL files have a “+” in their names. (See this post or others like it for more information.)

And then you can check the box for that “http://<ServerCaName>” entry to include that URL in the certs that are issued.  But the problem with that is that it’s still not accessible when you are off the corporate network.  So we really want to add another entry:

Checking the boxes to include that in the certs themselves tells clients where to look.  But how do we set up http://crl.contosomn.com/CertEnroll on the internet?  Obviously we could set up a separate web server and copy the contents of the local C:\Windows\System32\CertSrv\CertEnroll folder to it, but then you need to keep it up to date. 

The next idea is to use an Azure AD app proxy to publish the internal CRL website externally.  It’s easy enough to install via the Azure portal (click the “download” link):

Then you need to set up an application:

But do you notice the problem there?  The external URL uses HTTPS for security.  But CRLs can’t use HTTPS.  So how do you publish an app using HTTP instead?  If the UI won’t let you do, the AzureAD PowerShell module will:

Now I have an external URL of “http://crl-contosomn.msappproxy.net” but that’s not quite the URL I wanted.  No matter, I can change the URL in Certificate Services to match:

The same process can be used for an OCSP:

That requires similar changes to the Certificate Authority settings, changing the “CRL Distribution Point (CDP)” drop-down to “Authority Information Access (AIA)”:

Add the new app proxy URL to the bottom of the list and include it in the OCSP extension.

The next step is the most painful:  Any certificates issued previously without that CRL URL will need to be re-enrolled.  Fortunately, I don’t have many yet so that’s pretty simple to do manually.  But once done, non-AD-joined devices (e.g. those joined to Azure AD) and those not able to query AD via LDAP (e.g. those joined to Azure AD or those not on the corporate network) will be able to validate that certificates are still valid.