Working with Certificate Revocation Lists and Cisco ISE

Throughout my time working with Cisco ISE, I’ve come across a few different errors when configuring ISE to perform Certificate Revocation Lists (CRL) lookups using Microsoft’s Public Key Infrastructure (PKI). In this article I would like to show you how we can avoid CRL download issues that could ultimately stop an endpoint from authenticating onto a network when configured for Network Authentication Control (NAC).

CRL checking is useful for checking of expired certificates and when an environment has Cisco Identity Services Engine deployed for secure network access, this can be useful for ensuring revoked digital certificates are not reused when they’ve been revoked.

CRL lookups can be costly to your network because of the lookups that are performed and Online Certificate Status Protocol (OCSP) can be used as a more efficient way to check revoked certificates. However for the purpose of this article we will focus only on Certificate Revocation Lists.

In this article I will demonstrate how to configure Microsoft PKI and Internet Information Services (IIS) so that Cisco ISE can perform successful lookups when a user or machine authenticates to the network. As bugs sometimes affect the way services sometimes work, I have decided to list the software versions I’ll so that you can rule out any potential errors you may be seeing on your deployment of Cisco ISE.

Cisco ISE 2.4 Patch 6
Microsoft Server 2012 R2

Note: This article assumes that your environment is already configured to issue digital certificates.

Microsoft PKI

When ISE is configured to perform CRL lookups against a domain, a valid Certificate Revocation List Distribution Point URL (CRLDP) needs to be configured. The CRLDP should generally be configured for Issuing Certificate Authorities (CA) and this can either be in the form of an LDAP, HTTP or file share path. With that said, this demonstration attempts to keep configuration tasks simple by using the CA on the Domain Controller (DC).

When configured the PKI will publish revoked certificates to the Certificate Distribution Point (CDP). The CDP is in essence a file share that is configured to allow IIS communication with the CA for issuing CRL’s.

To configure a CDP for the CA follow these steps:

On the server that is running your CA, navigate to Server Manager > Tools > Certification Authority

In the details pane click, right click on the name of the CA and select Properties

Select the Extensions tab and click Add to add a new location. In the Location field enter the following: http://crl.domain.co.uk/crlist/ (where <domain.co.uk> it is your domain).

On the same page under the Variable section insert the following variables:

<CaName>
<CRLNameSuffix>
(Optional) <DeltaCRLAllowed>

Once inserted into your location path, finish off by entering .crl and press OK.

Select the URL that you just created and tick the following buttons:

Include in CRLs. Clients use this to find Delta CRL Locations.
Include in the CDP extension of issued certificates

Once selected, click Apply & Click No when asked if you want to restart certificate services.

Now we will configure the file share where the CRL’s will be shared. For the purpose of this demonstration, this is a file share location on the C: drive. Your file share location may be different.

On the same page click Add and enter the folder location of where the file share is located. We also want to add the following variables to the location too:

<CaName>
<CRLNameSuffix>
(Optional) <DeltaCRLAllowed>

Once inserted into your location path, finish off by entering .crl and press OK.

Select the file share that you just created and tick the following buttons:

Publish CRLs to this location
Publish Delta CRLs to this location

Once selected, click Apply & Click Yes when asked if you want to restart certificate services.

If the file share that your referenced doesn’t yet exist, go ahead and create that before continuing.

Now we’ve created a new URL, we need to create a DNS record so that it can be resolved.

Head over to Server Manger > Tools > DNS

Under your domain create a New Host (A or AAAA)… and enter the URL you created earlier: http://crl.domain.co.uk and add the IP address of the CA server.

Close the DNS Manager, we don’t need to do anything else in this section.

Now we need to create the HTTP CRL Distribution to the file share we referenced earlier. To do this we need to make sure that the IIS role is installed. If the IIS role is not yet installed, please proceed to install it by following the instructions on the following link before continuing: https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-8/installing-iis-8-on-windows-server-2012

Once the IIS role is installed, navigate to Server Manager > Tools > Internet Information Services (IIS) Manager

For the purpose of this demonstration we will used the default web site however if your requirements are different it might be worth creating a new site.

Navigate to your domain > Sites > Default Web Site and right-click Add Virtual Directory. Give your virtual directory an alias and then specify the physical path of your file share.

In the middle pane double-click Directory Browsing and click Enable

In the left pane highlight the Alias folder that you just created and double-click Configuration Editor.

Navigate to system.webServer\security\requestFiltering and change allowDoubleEscaping from False to True.

Click Apply and we are done with IIS.

We now need to enable sharing of the file share. To do this navigate to your file share. For demonstration purposes I will use a folder on the C: drive.

Once on the folder, enter the Properties of the folder and click Sharing > Advanced Sharing and select Share this folder.

Click Permissions > Add > Object Types and select Computers, Groups and Users. Enter the object name for your server and press OK. Under Groups or User names, highlight your server and change the permissions to allow Full Control.

Click Apply and OK and again in Advanced Sharing. Click on the Security tab and click Edit > Object Types and select Computers, Groups and Users. Enter the object name for your server and press OK. Under Groups or User names, highlight your server and change the permissions to allow Full Control.

Click Apply and OK and exit out of the folder properties.

We are pretty much done with the server configurations now but we need to make sure that CRL’s are published to the file share that we’ve configured before moving onto ISE.

To do this navigate to Server Manger > Tools > Certification Authority

Navigate to your domain and right-click on Revoked Certificates > All Tasks > Publish. When prompt to select which type of CRL you would like to publish, select New CRL and press OK.

Now if you head over to the shared folder you should be able to see the revoked certificates. Bare in mind that if your environment doesn’t have any revoked certificates you won’t have anything in your folder. Below is an example of the folder populated with the CRL.

Configuring Cisco ISE for CRL Lookups

When configuring ISE for EAP-TLS the endpoint must trust the ISE certificate and the likewise, the server much trust the client. It is best practice to ensure that the domain Root CA and any intermediate CA’s are stored within the ISE trust store and the ISE full trust chain is trusted by the domain.

With that being said ensure that your ISE PAN has the server Root CA any Issuing CA’s stored in the trust store. You can check this by navigating to Administration > Certificates > Trusted Certificates and comparing certificate serial numbers. If the relevant CA’s are not in the ISE trust store go ahead and import them by clicking Import. You can navigate to the relevant certificates and import them one by one.

When using certificate authentication select the following usage options:

Trust for authentication within ISE
Trust for client authentication and Syslog

Our final step before testing is to enable Certificate Status Validation for the certificate/s that we should run the CRL check against.

Under Certificate Revocation List Configuration select Download CRL and enter the CRL Distribution List URL that was configured earlier when creating the URL. If you’re not familiar with the extensions that were used above, the <CaName> is the name of your Certificate Authority and the other two are not that important in this case. With that being said the URL should be something like the following: http://crl.domain.crld/CaName.crl – You can enter this into your server browser and you should be able to download the CRL.

If you have a preference as to when ISE should retrieve the CRL and how long it should wait if retrieval has failed, make the relevant changes or leave the settings as is.

If you are performing this on a live environment and you encounter issues with the CRL retrieval, machines and users will fail to authenticate to the network if being checked against the distribution URL. You can view any issues in the RADIUS live logs and bypass CRL verification until troubleshooting has been carried out. To bypass CRL verification for a specific certificate, select Bypass CRL Verification if CRL is not Received.

When you are happy with the settings for your trusted certificate, click Save and you are done.

Notable Observations Made

If you decide to use port 443/HTTPS for the CRL URL and you want to issue a certificate ensure it is SHA-256. I’ve seen issues where SHA-1 certs don’t work properly with ISE (Probably a good thing as these are less secure).
Ensure that the domain, URL is bypassed if you employ a proxy in your network.

Testing

To ensure that the CRL verification is working authenticate a machine or user to the network. If successful and CRL bypass is not selected, the machine or user should be able to successfully authenticate (dependent on configured policies). The screenshot below shows a successful user authentication using EAP-TLS with CRL verification on the CA.

As an additional test we can also revoke the user certificate and see what happens when the user needs to re-authenticate. The expected result is that when the CRL is queried, the user should be denied access because the certificate is revoked. This is shown in the screenshot below.

ACCESS-SW1#show auth sessions int g0/23 details 
            Interface:  GigabitEthernet0/23
          MAC Address:  output omitted
         IPv6 Address:  Unknown
         IPv4 Address:  Unknown
            User-Name:  user@wizkid.co.uk
               Status:  Unauthorized
               Domain:  UNKNOWN
       Oper host mode:  multi-auth
     Oper control dir:  in
      Session timeout:  N/A
      Restart timeout:  N/A
Periodic Acct timeout:  N/A
    Common Session ID:  AC1000090000001901CC2DAD
      Acct Session ID:  Unknown
               Handle:  0xBD00000D
       Current Policy:  POLICY_Gi0/23

Method status list: 
       Method           State 

       mab              Stopped
       dot1x            Stopped

After running through this setup, it is possible that a lot of issues stem from the Microsoft server. If the full URL path isn’t specified then ISE won’t be able to verify the CRL. Another big issue could be the fact that the folder in which the CRL’s are sent to are not shared. I’ve yet to do more testing to find out how we could encounter more issues but if you’ve run into issues that you’ve fixed please comment below, I’d love to hear them.

Thank you for reading and I hope you find this useful.

Search This Blog

Network Wizkid's Technical Knowledge Base