ISE 1.3: Endpoint Certificate Renewal

Share on:

Overview

Intro

One of the greatest things about ISE 1.3 is its internal Certificate Authority (CA) and it’s ability to issue certificates to clients. When you provision certificates, you always have an expiry date set, which is great until they expire and all your great ISE policies deny access to a perfectly valid device/user.

So how do you renew expiring certificates without getting an IT Administrator to visit each and every user, manually renewing certificates, which would be an administrative nightmare. In the remainder of this post, I will describe how to detect an expiring certificate and then send the user to a portal to verify who they are before allowing them access back onto the network with a new certificate.

The scenario I will focus on this post would be for a BYOD users device whose EAP-TLS certificate is nearing expiration or has already expired.

Lab Environment

  • Identity Services Engine 1.3
  • Active Directory Identity Store (Windows 2008 R2)
  • Cisco 2504 WLC running 7.6.120.0 AireOS
  • Apple iPad which will be our BYOD device
  • Authentication and Authorization Policies already configured to allow access to devices using EAP-TLS

Assumed Knowledge

  • ISE PKI Implementation
  • Basic ISE Implementation, including how authentication and authorization logic works

Steps

  1. The first thing we must verify is if the configured Allowed Services Protocol List used in the authentication policy is set to: Allow Authentication of expired certificates to allow certificate renewal in Authorization Policy

Policy > Policy Elements > Results > Authentication > Allowed Protocols > LIST_NAME

  • Once we have selected to Allow expired certificates, ISE will give you a warning:
  • Click OK to accept.
  1. Now that we are allowing ISE to accept expired certificates to be used for authentication we must create an Authorization Policy to capture any device/user connecting with an expired certificate and send them to a web portal where they must renew their certificate.

To do this we will first build the policy elements using conditions, this will ensure that the final Authorization Policy is clean and easy to understand.

  1. We must first configure a compound condition to check the validity of the certificate.

Policy > Policy Elements > Conditions > Authorization > Compound Conditions > Create New

We are testing on IF either off the following are true:

1CERTIFICATE: IS EXPIRED; OR
2CERTIFICATE: DAYS TO EXPIRY < 15

I actually create two simple conditions and used them in the compound condition above, either specifying the attributes in the compound condition or first creating the simple conditions would work.

  1. In the next step we need to create a Guest Portal to send the user to re-authenticate with their Active Directory before they are re-issued a new certificate. I typically create a separate portal for certificate renewal as this allows me to brand it with a new AUP and customize the web page so the user understands why they have been redirected to the portal.

Guest Access > Configure > Guest Portals > Create

Now as you can see I haven’t documented each and every part of the new Guest Portal, I will leave this to you as it’s fairly straight forward. The main thing to note is the Identity Source Sequence used contains a valid Identity Store to test if the user account is a part of, in this example Active Directory.

Policy > Policy Elements > Results> Authorization > Authorization Profiles > Add New

The main things to note, is that you must select: Display Certificates Renewal Message

  1. We also must have configured an ACL on the WLC to redirect traffic to our ISE CWA Portal, we achieve this using a pre-defined ACL on the controller similar to the one below (replace 192.168.96.203 with your ISE Policy Service Node IP Address, if you have multiple you may need to add additional rules, depending on your authorization Profile).
  1. We can now finally create the Authorization Policy that will capture all authentication requests by devices/users that either have an expired certificate or a certificate that will expire in less than 15 days. It’s important to note that this policy must be placed towards the top of your Authorization Policy list to avoid the request being permitted access in a less restricted policy above it.

The policy works by first testing if the Authentication Request Method is using an X509 certificate and if the certificate is expired OR near expiration. If this matches the user is sent to the Cert Renewal Port we created earlier to re-authenticate.

Testing out the Policy

So in this example, I already have an iPad provisioned with a certificate but my certificate has only three days left before it expires. So the screens as an end user and administrator will see are as follows:

  1. Administrator sees that our byoduser has connected to the network but has matched out Authorization Policy: AuthZ-Renew_Cert
  1. The End User sees the web page pop which is our CWA Portal that we created earlier. At this stage the user is asked to re-authenticate by providing the Active Directory credentials, it’s a good idea to get valid credentials here in case the device has been lost and wasn’t reported etc.
  1. Once we enter in our credentials IOS and ISE kick off the certificate provisioning process, as you will see in the following pictures sequentially.

After the process has been completed the user using the iPAD can connect back to the network as they did previously, they will bypass the certificate renewal authorization process and match one created earlier.

House Keeping

Although we have an Authorization Policy that will capture all certificates that have expired on near to expiration, I think it’s a good idea to ensure the other authorization Policies you have created should contain a check to ensure the certificate hasn’t expired. This I personally feel is a fail safe in the event that first rule is put into a different order, deleted or whatever, there is still one more check to ensure the certificate is valid. The check looks something as follows:

I hope this post has been helpful, please remember that this method above was executed in a lab environment and may not account of every scenario in your particular network topology.