Cisco ISE API for Certificate Provisioning

When we added a certificate authority (CA) to Cisco’s ISE in version 1.3, there was a tremendous interest level from the field.  Companies were looking for this functionality to make BYOD and secure network access from endpoints more secure and there was a LOT of buzz about this functionality.

As the guy who flew all over the world carrying the “flag” for a built-in CA in ISE – forcing my message onto all the executives I could find why it was so important, I was naturally ecstatic to see the success of something I championed and fostered since inception.

However, as with everything, there is always a need for more!  ISE admins all over the world felt it was great for the devices that are capable of onboarding, but they needed to issue endpoint certificates to devices that couldn’t go through the automated onboarding process such as: Medical Devices, Point of Sale systems, Linux, etc).

“Make it So” – Jean-Luc Picard

In ISE 1.4, we added a RESTful (REpresentational State Transfer) API for the CA to issue private key + public certificate pairs.  This blog post is dedicated to showing you how to leverage that RESTful API and generate your own certificates for devices that cannot use the automatic provisioning capabilities of the BYOD onboarding process.

Major call out to Victor Ashe, one of the key team members on our small group of Rock-Stars who are responsible for this CA.  Victor is the original author of what I am going to show you in this blog.  Thanks, Victor!


You could (of course) build a full-blown web portal that leverages this API to generate certificates for folks in your organization.  However, I’m going to show you how to do this with a simple script on any Linux or MAC device using CURL.  You can probably get this to work with a Windows device with CURL for Windows, but I don’t feel like doing that – so it won’t be part of the blog 🙂

Let’s Get Started

There are many tools available for REST so please bear in mind, there’s a reason we are using curl instead of a browser based REST Client, like Poster, Postman, etc. The browser based clients just spit back the response body as text, and aren’t smart enough to treat this as a file and let you download it.

You will create two files on your Linux / MAC workstation.  One we will call and the other will be called payload. The script contains the CURL command that puts the information into the API to retrieve the certificate pair.  The payload file contains the details for the certificate that you are trying to generate.
curl -X PUT -H “Authorization: Basic YXBpdXNlcjpoaXNwYXNzd29yZA==” -H “Accept: application/; charset=utf-8” -H “Content-Type: application/; charset=utf-8” –data @payload -v –insecure https://<Your_ISE_Node>:9060/ers/config/endpointcert/certRequest >

<?xml version=”1.0″ encoding=”UTF-8″ standalone=”yes”?>
<ns3:endpointcert description=”Created in ERS” xmlns:ns2=”” xmlns:ns3=””>

The resulting zip files (or any error messages upon failure) will appear in a file called So, if the response status isn’t a 200 ok (perhaps a 400 bad request) then the file will just be a text file, so open it in a text editor to see the error message.

The Accept and Content-Type headers are needed in the request (shown above) and they have the same value. This is shown on the documentation page (described below). The Authorization header is a Basic Access Authorization header. The value for this header should be:

Basic <base 64 encoding of ‘username:password’>

For the base 64 encoding, you can go to a site like this  (shown in Figure 2) and go to the “Encode” tab at the top. Type in your username and password, separated by a colon (eg. apiuser:hispassword) and then hit the encode button. You’ll get something like YXBpdXNlcjpoaXNwYXNzd29yZA==. Your value for the “Authorization” header would then be “Basic YXBpdXNlcjpoaXNwYXNzd29yZA==” This is seen above in the curl command.


Before you can use the script, you’ll need to enable ERS on your ISE deployment.  Navigate to: Administration > System > Settings > ERS Settings.  Enable ERS on the Primary Administrative Node as seen in Figure 2.  Don’t forget to click Save.


This page will also show a URL to the ERS documentation. The URL should be https://<your_ise_node>:9060/ers/sdk

This documentation page has a lot of information. The most useful pages should be:
Quick Reference > Setting up
Quick Reference > Request Headers
API Documentation > End Point Certificates

In addition to enabling the ERS API, you will also need a ERS Admin level user.  Navigate to: Administration > System > Admin Access > Administrators > Admin Users.  Click Add and setup an ERS Admin user similar to the one in Figure 3.  Don’t forget to click Save.  This is the username and password that needs to be converted to BASE64 and inserted into the script.


You also need a Certificate Template for the CA to use.  There is a built-in certificate template to all ISE 1.3 installs named “EAP_Authentication_Certificate_Template” that you can use, or you may want to create your own brand-new template for your environment.

Figure 4 shows a custom template that I’m using for this blog post.  You must specify the template name in the payload file in the certTemplateName section.


Let’s go through an example

I created a file named  The contents of this file are shown in Figure 5.


I also created a file named payload.  The contents are shown in Figure 6.


I now run the file, as seen in Figure 7.


Figure 8 shows the resulting zip file and the extracted certificate chain (p12 file).

resulting KeyChain

Again, I want to thank Val Kilmer, err… I mean Victor Ashe for the script and the brilliant ISE CA team for all their continued hard work and top-notch delivery.

Give me my Attribute mapping back for Sponsor Groups

In ISE 1.0 Cisco introduced an integrated Guest solution with a next-generation RADIUS-based policy server.  That policy server was game-changing, certainly.  Other companies responded to this market changing model by making some very strategic moves with their chess pieces to be similarly positioned.

Figure 1 shows an example of the ISE 1.2.x (and below) Sponsor Group Policy.

ISE 1.2 Sponsor Policy

While ISE 1.0 was and is an extremely powerful policy server, it was also viewed as being overly complex and not flexible enough in the areas of Guest life-cycle management.  This was especially true when comparing ISE with it’s closest competitors in the guest access management space.

So, let this be said: the gauntlet has been thrown down, but [Cisco] have answered, and answered with vigor.”  -Gerald Lambeau, Good Will Hunting

ISE 1.3 introduced a completely re-written Guest solution that greatly simplifies the deployment and allows for high-levels of customization.  Things have been simplified GREATLY, but unfortunately some of the power got lost at the same time.

This blog will focus on one specific piece of functionality that was lost, and a brilliant work around that one of my colleagues, Craig Hyps, has devised.

The Missing Functionality:

The ISE Guest solution uses Sponsor Groups to dictate the permissions the employee will have.  In other words, the Sponsor Group determines which types of guest users that can be created, how long those accounts can be active, if the sponsor is allowed to create random/bulk accounts, etc…  From ISE 1.0 through ISE 1.2.x, the ISE administrator had the ability to build very complex IF..THEN..  type of policies to determine which Sponsor Group the employee should be mapped to.  To provide some more clarity of my statement, let’s put that into an IF… Then… format:

IF the LDAP/AD attribute named Manager is Yes
THEN assign them to the Manage_All_Accounts Sponsor Group in ISE.

ElseIF the LDAP/AD attribute named Manager is No
THEN assign them to the Manage_Own_Accounts Sponsor Group in ISE.

In ISE 1.3, it was simplified tremendously because (while it was powerful) it was also very complex for admins to figure out.  However, during the simplification process, come of the power was also removed.

After extensive customer interviews and planning, the design decision was made to simplify Sponsor Group membership for external users (i.e.: user accounts that exist in Active Directory (AD) or LDAP) by mapping to groups in that external identity store.  To provide some more clarity on my statement, let’s put that into an IF… Then… format:

IF sponsor is a member of the AD group named “SponsorALL”
THEN assign them to the Manage_All_Accounts Sponsor Group in ISE.

ElseIF sponsor is member of the AD group named “SponsorOwn”
THEN assign them to the Manage_Own_Accounts Sponsor Group in ISE.

Figure 2 shows the new, simplified sponsor model in ISE 1.3 & 1.4.

ISE 1.3 Sponsor Mapping

So you can see the logic behind the mapping of the external identity that exists very commonly in Active Directory & the local Sponsor Group that dictates the employee’s permissions for creating guest accounts.  For 90-95% of environments, this type of mapping is perfect.  However, there are a few instances where that extra power of looking at attributes instead of or in addition to groups is needed.

Simplicity is the Key”  -Ritchie Blackmore

Well if simplicity is the key to be one of the greatest musicians of all time, maybe that makes Craig Hyps the “Ritchie Blackmore of network access” 🙂  In my 10 years of working with him, he never fails to amaze me with some of the creative workarounds that he is able to come up with, and this blog is detailing one of those brilliant-yet-simple workarounds.

 Craig’s Brilliant Yet Simple Work Around

Basically, the answer to the puzzle is to “Lie to ISE”.  Configure a new LDAP Identity Source that points to your LDAP server, but configure the group string to be the LDAP attribute that you want to use, instead of an actual group.  Think about it, it will see the attribute as the group name & the value of the attribute as the “members”.

Using the example from above, it means the IF… Then… Logic would look like:

IF sponsor’s group has a member named “Yes”
THEN assign them to the Manage_All_Accounts Sponsor Group in ISE.

ElseIF sponsor’s group has a member named “No”
THEN assign them to the Manage_Own_Accounts Sponsor Group in ISE.

This way, ISE thinks there are groups named Yes and No, and that will be the choices in the ISE GUI.

Let’s configure this:

For simplicity sake, I added a value of Yes or No to an existing attribute in my LDAP server (Active Directory).  I used the Job Title field, which translates to the “title” attribute via LDAP.  Figure 3 shows the graphical Job Title field that I am using.


Of course most organizations would have a custom attribute to use, such as “Manager”, or “isManager”, or something like that.  However, for purposes of keeping this example easy, I am just re-using the existing attribute of “title”.

Now, we need to create a new LDAP Identity Store within ISE, just for use with the sponsor portal login.

Navigate to: Administration > Identity Management > External Identity Sources > LDAP.  Click Add.

Provide a name that will help you identify this later as being used just for Sponsor portal login.  You will see in Figure 4 that I used “SecurityDemo_Sponsor”, where the _Sponsor suffix is helping me to document why this Identity Store exists.

Choose the base schema to start with (I used Active Directory), as seen in Figure 4.  Then modify the Group Objectclass and the Group Map Attribute fields to be the LDAP attribute that you are mapping to.  It’s very important to choose Subject Objects Contain References To Groups.  This is the option that will tell the LDAP connector to look for the Group within the subject (the user’s account).


You must fill-in the Connection tab with the correct IP Address(es) and credentials for the LDAP bind.  That is no different in this scenario, so I will skip that tab..  However, the Directory Organization tab is required before you can save the connection.  Figure 5 shows you the example Directory Organization tab.


The Groups Tab is next.  Normally, you can search the directory for the groups & add them.  That will not work in this case.  You have to manually type the values (Yes, No) instead.  Click Add.

Add each value (one at a time) for the attribute that you are mapping to and click Ok.  In our example, the value of title can only be Yes or No, where Yes means they get full sponsorship and No means they will get limited sponsorship capabilities.  Figure 6 shows the Groups tab where the “Yes” group has already been added, and the “No” group is being added.


The LDAP portion is complete.  Don’t forget to click Save when you are done!  Now you need to configure the Sponsor portal to use the new LDAP connection.  By default the Sponsor Portal will use the Identity Source Sequence (ISS) named “Sponsor_Portal_Sequence”.  You need to ensure the new LDAP Identity Source that you just created is used within in this sequence.

Navigate to: Administration > Identity Management > Identity Source Sequences and click on Sponsor_Portal_Sequence to edit it.   Ensure that the new _Sponsor identity source is in the list, and the original LDAP join is not.  Figure 7 shows the ISS.


Don’t forget to click Save when you’re done!  Now you need to assign the correct sponsor users to the Sponsor Groups.  Navigate to Guest Access > Configure and select  Sponsor Groups on the left-hand side.

Select the Sponsor group you are configuring, or create a new one.  Click the Members button.  Choose the new “group” based on the LDAP attribute.  In this example, I have selected SecurityDemo_LDAP:Yes because this is the All_Accounts sponsor group & I want managers to be part of this sponsor group. Figure 8 shows the “Yes” group being added to the Sponsor Group.


Don’t forget to click Save when you’re done!  Repeat this process for each Sponsor group that you need to add members to.

Th-Th-Th-That’s all Folks!   -Porky Pig

Standards for Secure-Network-Access

I’m amused at how often I hear negative comments about proprietary enhancements from Cisco.  I am one of many (many, many, many) employees of Cisco who is actively involved in standards body organizations, including the IETF.  Many of today’s networking standards have started out as proprietary solutions that are available years prior to the standard being complete.

As someone who is not only passionate about innovation in security but also in the standardization of those innovations, I thought I’d point a few of the recent ones out that I’ve either been involved in, or am just very interested in.

Tunneled EAP (TEAP):

In May of this year, the Tunneled EAP (TEAP) specification has officially been published as RFC-7170.  This RFC officially makes Cisco’s innovative of EAP-Chaining in EAP-FASTv2 a standard that may be implemented in any 802.1X supplicant or authentication server.  Note that, as with all EAP communication in a Dot1X environment, the EAP-Type is completely transparent to the authenticator (switch | wireless | etc.).  This means that it does not require Cisco switches or wireless controllers to use TEAP, just a supplicant and authentication that both support the protocol.

TEAP has some unique advantages over other authentication protocols.  It has the capability to do TLS version negotiation, it may use any inner-method supported by both the supplicant and authentication server (EAP-MSChapV2, EAP-GTC, EAP-TLS) along with the ability to chain the credentials of the machine and the user together in the single EAP-Transaction.

This meets a tremendous industry demand, with a standard way to authenticate and authorize that it is an authorized asset AND an authorized user, with a mixture of identity sources:  Certificates / Username & PWD / One-Time-Passwords / other 2-factor authentication mechanisms.


  • Device authentication with a Certificate (EAP-TLS), showing that the computer belongs to the company PLUS a username/password authentication to Active Directory (EAP-MSChapV2).
  • Device authentication using the Active Directory account & password (EAP-MSChapV2), which validates the machine is a domain member and is active PLUS a username/password authentication to Active Directory (EAP-MSChapV2).
  • Device authentication using a Certificate (EAP-TLS), showing the computer (laptop, desktop, tablet, phone, etc.) belongs to the company PLUS a username/password authentication to Active Directory (EAP-MSChapV2).

By using BOTH the machine and user authentications in a single Authorization, you are able to validate that it is an Authorized User AND an Authorized Machine.  Not just one or the other.

Other Advantages of TEAP:

  1. TEAP uses TLS Session Resumption without maintaining server state (similar to EAP-FAST) –  this allows servers to scale to handle much larger numbers of clients.
  2. Provisioning of Certificates within the tunnel.  This would allow certificate renewals within the TEAP channel, it could be an alternate way to provision initial certificates using BYOD if you first authenticate with an inner method (like username/password).  TEAP is essentially running Enrollment over Secure Transport (EST) inside of the TEAP channel.
  3. TEAP has EAP Channel Bindings to bind the context in which TEAP is used (wired, wireless, IKEv2, L3, etc.) into the TEAP exchange. << HOW Valuable is this???  Awesome!
  4. TEAP has an extensible Type Length Value (TLV) format that can be used to carry data for other purposes within the TEAP tunnel.  Such as PT-EAP (Posture Transport) for providing posture check data transport through the TEAP channel.  << Theoretically a real method for transporting this posture data within the EAP protocol (finally).

As with all standards, this one was written and contributed to by many individuals from many different companies, including but not limited to: Cisco, Juniper, Infineon and others.  I’d like to call out the efforts of my friends and colleagues, people I look up to and admire: Nancy Cam-Winget, Joe Salowey, Hao Zhou and Steve Hanna.

The next steps are for the customers who want TEAP and EAP-Chaining to call their sales reps from Cisco, Microsoft, Apple, Google, Juniper (soon to be Pulse), etc. (pick your flavor of endpoint and authentication server).  Tell your sales team(s) how much this functionality is needed and get it committed to their roadmaps.

Security Group Tagging (SGT) & Security group eXchange Protocol (SXP)

I’ve talked about this innovative technology on my blog in the past, see:  Security Group Tagging Basics.

Earlier this year, Cisco submitted an informational draft on SGT eXchange Protocol (SXP), opening the use of SGT’s to non-Cisco network and security application vendors.  Since then, they updated the submission with a new informational draft comprising the SGT eXchange Protocol (SXP) and the SGT Ethernet Frame Format. 

This used to be 100% Cisco proprietary, and required all Cisco networking infrastructure, security appliances and policy servers.  These submissions allow other vendors to implement inline tagging and exchange tags with Cisco products, either on the wire or through the peering protocol.

Many, many, many thanks to Kevin Regan, Mitsunori Sagae, Darrin Miller, Joe Salowey, Michael Smith, Sue Thomson & Rakesh Kandula for getting this incredible innovation published as an informational draft.



Quite some time ago Cisco’s SVP, Chris Young, announced a new innovation to share contextual security data between security applications, called pxGrid.

In July of this year, pxGrid was published as an internet draft, and presented at the IETF (and VERY well-received) at IETF 90 in Toronto.

pxGrid is a Cisco innovation and the world’s first scalable mechanism for multi-directional sharing of security-related data between security applications, who’s uses are extensible beyond security and into other management realms.

As with any proposed standard, there are more cooks in the kitchen than just Cisco.  The proposed standard is being jointly shaped by Cisco, Juniper (soon to be Pulse), McAfee, Boeing, NIST, and others. The proposal is moving forward and it’s looking quite possible that pxGrid will be a major contributor for the IETF standard around Security Automation and Continuous Monitoring (SACM).

Special thanks on this standards work belong to: Nancy Cam-Winget, Scott Pope, Lisa Lorensin, Cliff Kahn, Steve Venema, Steve Hanna, David Waltemire, and many many many others!!  It’s been an honor and a privilege to work along side such a talented group.

MAB with Non-Cisco Devices

I’m sure Cisco would love to be the only network device that its customer have, and to be honest, there are many companies where that is true. However, it is just not the reality of 100% of companies that deploy Cisco ISE or ACS.

One item in particular that I am asked about frequently is MAC Authentication Bypass (MAB).  This is the process of a non-authenticating device (a device without an 802.1X supplicant running on it) connecting to a network with 802.1X enabled.  Since there is no supplicant to answer the EAP identity requests from the authenticator (switch, wireless controller, etc) the authenticator will generate the authentication request FOR the endpoint using the endpoint’s MAC address as the username/password for the Access-Request message.

Background on MAB

Take a look at Figure-1.  This graphic is displaying a printer w/ a mac address of which is connected to a switch that has 802.1X enabled on its ports and sends the authentication requests to a RADIUS server.

MAB Example
Figure-1:  MAB Example

In Figure-1, the printer did not have a supplicant, and therefore is unable to participate in the 802.1X identity exchange.  Therefore the switch sends a RADIUS Access-Request to the RADIUS server, which determines if the device is allowed on the network.  Assuming it is allowed on the network, the server sends a RADIUS Access-Accept message to the switch, allowing the printer to participate on the network.

It is important to note that while 802.1X is a standard, MAB is not. MAB is something that each vendor could implement differently if they so choose, just as long as the RADIUS communication complies with the standard for RADIUS.

How does a switch (authenticator) know when the endpoint that is plugged into it does not have a supplicant? Following the 802.1X standard, the method is simply a timeout. The authenticator is meant to send EAP over LAN identity request frames every 30 seconds by default. After 3 timeouts (a period of 90 seconds by default) it is assumed that the endpoint must not have a supplicant. As with most Cisco switch features, timers are adjustable. Figure-2 shows the timeouts occurring three times before MAB begins.

802.1X Timeouts
Figure-2:  802.1X Timeouts

Keep in mind that MAB is inherently not a secure technology. When implementing MAB you are bypassing the stronger security of 802.1X by allowing specific MAC addresses to gain access without authentication. When using MAB, always follow a defense-in-depth approach. This means a device that has been authorized to use the network from a MAB request should be granted access to the networks and services that device is required to speak to only.

In other words: don’t provide full access to devices that have been MAB’d, instead provided them with an authorization that is more limited. Since MAB is a standard RADIUS authentication and the authorization decision is being sent from the authentication server (ISE), there really are no limitations to the type of authorization results that can be sent to the authenticator.

Examples are:

  • Downloadable ACLs (dACLs)
  • Dynamic VLAN assignment (dVLAN)
  • URL-redirection
  • Security Group Tag (SGT)
  • Smart port macros
  • Many more

Keep in mind that if an endpoint does not have a supplicant, it is never recommended to change its VLAN. When changing a VLAN assigned to an endpoint, that endpoint must know (somehow) to renew its IP Address. The best solution is to not use VLAN changes on open networks, because there is nothing on the client to detect the VLAN change & trigger the DHCP renewal. When the network uses 802.1X, there is a supplicant on the endpoint to do the VLAN change detection (is gateway reachable, etc.) & trigger the DHCP renewal.

If you still choose to change the VLAN on open networks, then you have only a few choices (none are considered a best-practice). You can set the DHCP lease time to something VERY low, so it will renew the address frequently. There is also an option to use an ActiveX or Java Applet on the portal that will do the VLAN change detection in lieu of a supplicant.

Cisco and non-Cisco MAB

As mentioned previously: there is no standard for MAB. Different vendors will implement MAB in different ways, using different RADIUS values.  There is a key RADIUS attribute that is used to determine what type of authentication request is being sent:  Service-Type.  Some common values for Service-Type with Cisco network access devices are listed here:

  • Service-Type=Framed (signals an 802.1X authentication)
  • Service-Type=Login (signals WebAuth)
  • Service-Type=Call-Check (signals MAB)

Since MAB is not a standard, some vendors will send a RADIUS service-type of “Login” with MAB, some will send a RADIUS service-type of “framed”.  So, why would Cisco use service-type of “Call-Check” if no other vendor does? Why does Cisco perform MAB differently than everyone else? Quick answer: security.

Many years ago, before Cisco released Cisco ISE or the Cisco ACS 5.x server, there was a possible security vulnerability with MAB. That security vulnerability is still possible with other solutions and other network devices. The issue was/is the lack of differentiation between a MAC Authentication Bypass request and a Local Web Authentication request. Both requests will come from the network device with the same service-type and the same format. There was no database separation of user-id’s from endpoint-id’s (mac-addresses). As displayed in Figure-3, a malicious user could enter a mac-address into the username and password fields of a web authentication or maybe even into the endpoint supplicant, and gain access to the network.

Security Issue without Call-Check
Figure-3:  Security Issue without Call-Check

In an effort to close this security hole, and make MAB a bit more secure, Cisco changed the way it does MAB. The Key Differences are listed here:

  • For authentication requests to be processed as MAB (by default), service-type must be Call-Check
  • RADIUS Servers (ACS & ISE) maintain a separate Endpoint Database
  • The calling-station-id is the value that will be compared to the Endpoint Database, ignoring the username and password fields of the MAB request

Figure-4 illustrates the concept of a Cisco compliant MAB.  A packet capture is listed on the left side to highlight the fields of importance.

Cisco MAB
Figure-4: Cisco MAB

All supported Cisco Network Access Devices will use a service-type of “call-check” for MAB requests. They will also ensure the calling-station-id is populated with the mac-address of endpoint. Lastly, Cisco ISE uses a simple check-box within the allowed-protocols configuration as another method to permit or deny the access into the endpoint database for the MAB request, as seen in Figure-5.

Allowing Non-Cisco MAB
Figure-5: Allowing Non-Cisco MAB

Configuring Cisco ISE for 3rd Party MAB

While Cisco ISE allows for the acceptance of non-Cisco MAB, it is not typically something you should or would want to do for all incoming requests, only where absolutely necessary.  I recommend that you separate this out by using a different policy set for non-Cisco switches. I normally do this by creating a Network Device Group (NDG) for all NADs that are non-Cisco, as seen in Figure-6.

NDG's for Non-Cisco
Figure-6: NDG’s for Non-Cisco













Once you have your NDG’s setup and the non-Cisco NADs added to those NDG’s; you can then build the new policy set.  Figure-7 shows the policy set, and the rule that matches the policy set, which is translated as: “if NDG starts-with ThirdParty then use the ThirdParty policy set”.

3rd Party Policy Set
Figure-7: ThirdParty Policy Set

Each network device may have different capabilities with sending usernames/passwords and even filling in the calling-station-id field with the MAC address of the endpoint.  In my personal tests I have found the following:

  • Juniper EX Switch:  Leave both Calling-Station-ID and Password options checked.
  • HP (H3C) Switch:  Uncheck Calling-Station-ID.  Leave Password option checked.
  • RuggedCom Switch:  Uncheck Calling-Station-ID.  Leave Password option checked.
  • Avaya (Nortel) Switch:  Uncheck BOTH Calling-Station-ID and Password options.
  • Alcatel Switch:  Uncheck BOTH Calling-Station-ID and Password options.

Next, you will need to have an “Allowed Protocols” set that is configured for the 3rd party product you are using.  You may need to create one for each vendor, which would be the most explicit and secure way to configure the options. Figure-8 shows an example 3rd Party Allowed Protocol set that would work for Juniper EX switches (in my testing).

Least Secure Allowed Protocols set
Figure-8: Example Allowed Protocols set

Once you have created all the “Allowed Protocol” sets that you need, you will then create the authentication rule(s) for each one.  Figure-9 illustrates an authentication rule that would work for both Nortel and Alcatel switches, based on my testing.

Nortel & Alcatel AuthC Rules
Figure-9: Nortel & Alcatel AuthC Rules


Figure-10 illustrates an authentication rule that would work for Juniper EX Switches, based on my testing results.  It also includes the new default rule at the bottom of the ThirdParty policy set that deny’s all non-matching traffic.

 Juniper EX Switch AuthC Rules
Figure-10: Juniper EX Switch AuthC Rules

Well that about covers MAB with 3rd Party devices.  I hope you found this blog post useful!  As always, I look forward to reading & responding to any comments you may have.

Simply Put: How Does Certificate-Based Authentication Work?

I find a few universal truths when mentioning certificates to people. Most people I speak with consider them to be a very secure concept almost without fail. However upon mentioning that I want to talk about certificates: that person’s face turns a slightly lighter shade, their eyes get a bit wider, and they have this immediate fight or flight instinct kick in 🙂

I can tell you, this is a subject that does not have to be scary, there are just a few misunderstandings.  One such example of a common misunderstanding:

“Since the Certificate was issued by Active Directory’s Certificate Authority, then authenticating that certificate is the same as an Active Directory authentication”

I realize how and why that assumption was made, it gets awfully confusing to try and separate out Active Directory from a Certificate Authority when they are so tightly integrated.  However, let me assure you, standard Certificate Authentication is the same, regardless of whether the CA is built by Microsoft, Cisco, Symantec, Entrust, etc.

Let’s take some time & review how Certificate-Based Authentications actually work.  When presented with a certificate, an authentication server will do the following (at a minimum):

  1. Has the Digital Certificate been issued/signed by a Trusted CA?
  2. Is the Certificate Expired – checks both the start and end dates
  3. Has the Certificate been revoked?  (Could be OCSP or CRL check)
  4. Has the client provided proof of possession?

Let’s examine the above 4 items one at a time:

Has the Digital Certificate Been Signed by a Trusted CA?

The signing of the certificate really has two parts.  The first part is the certificate must have been signed correctly (following the correct format, etc).  If it is not, it will be discarded immediately.  Next, The signing CA’s public key must be in a Trusted Certificates store, and that certificate must be trusted for purposes of authentication.  Using Cisco ISE as an example, the trusted certificate will need to have the “Trust for client authentication” use-case selected (as seen below).

Trust for Client Authentication


So not only does ISE “trust” certificates that have been signed by this CA, it trusts those for a specific use-case (client authentication).  If a client presents a certificate, and that certificate has not been signed by a CA that is trusted for client authentication, then the authentication will fail.  It’s exactly like someone entering in the wrong password.

Has the certificate expired?

Just like a drivers license or a passport, a certificate will have 2 dates listed in it: a date issued, and date it is valid to (when does it expire). Fun story:  I was in Las Vegas for a conference.  I was out drinking with my girlfriend at the time and a few friends and we went into the ICE bar at Mandalay Bay to sample some very cold Vodka.  When we presented our ID’s, my North-Carolina issued Drivers license was expired.  The picture was still a valid picture of me, the name was still mine, and my birth date showed that I was of legal drinking age – yet I was refused service because the license expired and was therefore no longer a valid source of identity.  “Access-Reject” 😛

An authentication server does the same sort of check.  Is the certificate valid for the date and time that the authentication request comes in.  This is one reason why Network Time Protocol (NTP) is so important when working with certificates.  Many of us have seen problems where time was out of sync.  For example: a certificate was presented on January 10th 2014 at 11:11am, but its “valid-from” value started on January 10th at 11:30am.  This was because of a time sync issue where the Certificate Authority thought it was 20 minutes later than the authentication server, and the brand-new certificate was not valid yet!  🙂  This is so common you would laugh (or cry).  See in the following image that the certificate has a valid-from and valid-to attribute.

Valid Date Range

Has the cert been revoked?

You are driving down the road, and you are pulled over by a policeman.  The policeman asks for your drivers license and proof of insurance.  You hand the officer a driver’s license, which is immediately checked for evidence of authenticity, i.e.: does it look like a valid driver’s license or a forgery.  Ok, it’s not fake, Check.  Next, expiration: it is not expired.  Check.  Now the policeman asks you to wait there, while he goes back to his squad car.

While in the squad car, the officer will perform some authorization checks (are you a registered owner of the car you were driving, etc.).  Those are not important for this conversation, though.  What is important is that the policeman must make sure your VALID drivers license was not revoked by the DMV.  A quick look-up on the computer into the DMV records shows that your drivers license was revoked for too many DWI’s.  The cold steel of the handcuffs and the rough shove into the back seat of the Squad car as you are hauled off to jail make you re-evaluate your life choices.

Certificate Authentication has the same capability (not the handcuffs, I’m talking about the look-up into the DMV to revocation status).  Every certificate authority should also have a service to publish a list of certificates that have been revoked.  There are 2 main ways to do this today:

  • Certificate Revocation List (CRL).  This is basically a signed list that the CA publishes on a website that can be read by authentication servers.  The file is periodically downloaded and stored locally on the authentication server, and when a certificate is being authenticated the server examines the CRL to see if the client’s cert was revoked already.   CRL could be compared to the policeman having a list of suspended drivers in his squad car.
  • Online Certificate Status Protocol (OCSP).  This is the preferred method for revocation checks in most environments today, because it provides near real-time updates.  OCSP allows the authentication server to send a real-time request (like a http web request) to the  service running on the CA or another device and checking the status of the certificate right then & there.  OCSP could be compared to the policeman using the computer in the squad car & doing a look-up into the DMV’s database.

If the certificate has been revoked, then access is denied.  Enjoy the lights and sirens on the way to jail.  🙂

Here is an example of the configuration screen for Certificate Authority in Cisco ISE.  You have the ability to configure where to check for OCSP and/or CRL, when a certificate is signed by this particular root (or it’s subordinates).

Certificate Validation Services

I feel it’s very important for you to understand that checking for certificate revocation is an option.  You’ll notice neither CRL or OCSP are on by default, they require the admin to configure the URL or the service location.  It is also critical to understand what behavior will happen if the service is not available or the status of the certificate is unknown.  I.e.: how does the authentication policy handle exceptions?  Is it configured to “fail-open” or “fail-closed”?

The client’s certificate itself will have an extension called CRL Distribution Points, which can be populated with the URI where the authentication server may locate the CRL.  You can see that in the image listed below.

CRL URI in Cert














Another interesting factoid about managing revocation lists: in the previous section where we discussed the certificate expiration, we looked at the fields “Valid-From” and “Valid to”.  These fields form the “validity period”.  That defines the period of time that the signing CA warrants it will maintain revocation information regarding that certificate.  This helps keep CRL and OCSP lists at manageable sizes.

Has the client provided proof of possession?

This is a way for an authentication server to be sure the client truly owns the certificate.  Think of it this way, if you are pulled over by a policeman for speeding.  You hand the policeman a drivers license:

  • It’s a valid Drivers License, issued by a trusted root (the state DMV)
  • It has not expired yet, so that is no problem
  • The policeman calls into the DMV and the drivers license has not been revoked.

But, the picture on the drivers license is a picture of a woman with long flowing brown hair and hazel eyes; yet you yourself are a bald elderly man.  OOPS.  This “valid” drivers license was not issued to you – the proof of possession has failed!  Again – jail time!  🙂

Certificate authentications do something similar.  There will be some throw away piece of data that must be encrypted and decrypted.  Successfully encrypting and decrypting that data ensures that the client has both the public and private keys, and therefore it is the proof of possession.  This ensures that someone did not just grab the client’s public key & try to present that as being their own.  If the client cannot provide proof of possession, then the authentication will fail – Access-Reject.

So, What did any of this have to do with Active Directory?

Aaron, you started this Blog off discussing people’s misconceptions about certificates and AD, where were you going with that point?

Thanks for bringing me back on topic.  What can often confuse people with regard to AAA is the difference between authentication and authorization.  They often blend so much.  A certificate issued by Active Directory Certificate Services is still just an x.509 certificate.  It will go through all the authentication validation listed above, regardless of the fact that the CA was integrated into AD.

What is possible, is to examine a field of the Certificate & then to do a separate look-up into AD based on that field during the authorization phase.  For example, a certificate with a subject of Aaron is sent via EAP-TLS.  The certificate is validated through the four functions that I discussed, and it passes.  Now it’s time for the authorization.  The RADIUS server (ISE in my examples) will take the certificate subject (Aaron) and do a look-up into AD for that username.  This is where group membership and other policy conditions will be examined, and the specific authorization result will be issued.

Cisco ISE uses something called a Certificate Authentication Profile (CAP) to examine a specific field and map it to a user-name for authorization.  The image below shows that CAP.  If you are using a different RADIUS server, consult the administrative guide for that solution for a similar function.  Note:  Cisco ISE will also do a courtesy-check to validate if the machine or account has been disabled in AD.  If the account were disabled in AD, then the authorization will be to deny-access.

Mapping Cert Field to Username

Please note, this is a very different process than an Active Directory authentication, which uses Kerberos, and therefore AD logs will be recorded differently.  There are solutions on the market that examine AD log files and use that information to help tie-together usernames and ip addresses for single-sign-on to Web Proxy servers and identity-enabled firewalls, and other services.  If the authentication was a certificate-based authentication (EAP-TLS) but the user was authorized from an AD look-up; that process will most-likely not provide the right types of logging for those identity-enabled firewalls or Web Proxies, etc.

Well, I hope this provided you with a nice, and easy to follow overview of Certificate Authentication.  As always, your comments are more than welcome!

Realm Stripping

I am often asked about support for “Realm Stripping”, albeit mostly by those in the University Space.  It’s an interesting concept, certainly.  The idea is that someone will issue an identity that includes some “routing” information within the identity.  For example, a user may issue a username of:  From that username, the RADIUS server should be able to strip out the username “johndoe” and use the “” to specify the identity store to query for the username & password.

Think about it.  It would allow federation of identity in a pretty clean way, because my domain name is included as part of my username, and therefore your RADIUS server would be capable of asking my identity store to validate the user or not.

Eduroam ( is one of the most popular services for this type of routing.  This service allows students to roam from University 1 to travel to University 2’s campus for the day and authenticate to University 2’s wireless network using their credentials from their actual university’s credentials.

A requirement to support the Eduroam service is that a RADIUS server must be able to strip off the routing data (called a “realm”).  So authenticates to University2’s network, the identity request is routed to the Eduroam service which sends the request to University1’s RADIUS server.  That RADIUS server must be capable of stripping the from the identity, so the true username of “johndoe” is used in the query against their identity store (AD, PeopleSoft, whatever may hold the actual credentials).

Pretty cool, huh?  I always thought so, but it was something that Cisco ISE only had VERY limited support for until recently.  ISE always had the ability to strip realms when using RADIUS-Proxy servers for the identity store – but only the “outer-identity” (sometimes called the “anonymous identity”, which is total oxymoron) was stripped off, leaving the inner-identity alone.  This was problematic, because trying to teach 1,000,000 students who “just want network access” how to configure their outer identity with so many supplicant variations in their devices was not exactly administratively lightweight.

ISE also supported this for LDAP connections, which had the capability to strip both the inner & outer identities.  But that often times was not adequate.

There was a “hidden gem” released in ISE 1.2 patch 5 that includes Real Stripping natively!  Wahoo!  Thank you Cisco ISE Network Access team, and (of course) the ever persistent Serviceability Product Owner who keeps pushing these great ideas (inside joke, sorry for those of you who don’t get it).

To top it all off, ISE even has the ability leverage the information that was stripped out as an attribute that factors into the Authorization Policy, so that information may still provide value with the access decision..  Plus it’s all pretty easy to configure.  Let’s take a look at an example:

Realm Stripping Configuration Example

In the example above, I’ve shown the stripping of some prefixes, as well as suffixes.  Multiple entries are separated by commas.   Note:  In ISE 1.2 patch 6 the product will also strip out erroneous spaces between the entries, but with patch 5 you must ensure you do not have spaces included.

In the figure above, we are stripping the following Prefixes: “dom1\,dom2$,dom3” which will yield the following results:
dom1\brad becomes brad
dom2$brad becomes brad
dom3brad becomes brad

We are also stripping out the following Suffixes:  “,@domain2 becomes suzy becomes suzy

There are a number of use cases for Realm Stripping.  You could use it to separate lines of business, or possibly just to replace an older legacy FreeRADIUS system that used Realms to allow the end-user to influence their authorization results.  What the latter is not a design I would ever recommend, I have had to work with companies that require the functionality in order to upgrade their legacy systems to a more modern policy server, like Cisco’s ISE.

Well that’s it for now, keep checking back for more!


Using the DogTag CA with ISE 1.2

What is DogTag and Why Use It?

Dog Tag is an Enterprise-class open source Certificate Authority that Red Hat purchased from AOL back in 2004.  Red Hat opened it up to the open source community in 2008.  Dog Tag supports all aspects of certificate lifecycle management, including key archival, OCSP and smartcard management, and much more.

Most importantly, it is an available CA that has been tested for use with Cisco’s BYOD solution using Cisco’s Identity Services Engine 1.2 & newer.

Note:  There is also an Enterprise level version of DogTag known as the Red Hat Certificate System.

Before we go any further, I need to send a huge call-out to Vivek Santuka who prototyped & pioneered this initiative at work.  Also a call-out to Brian Sak for updating the work that Vivek did.


Dog Tag will run on most Red Hat variants. For the purposes of this document, we will focus on Fedora Core 15 (32-bit).  This is the version that is known to work and has been tested with ISE 1.2.  This version of Fedora can be installed with the minimum option and will leverage the Apache web server, PHP, and the open source directory server.

Install 32-bit Fedora 15

Step 1 Boot the machine with the 32-bit Fedora 15 ISO file or DVD available here:

Step 2 Select “Install system with basic video driver”

The “Minimal” installation type is all that you need for this use-case.

Accept the default choices for the remainder of the installation

Configure Networking

The Certificate Authority should have a static IP Address to ensure that communication is always optimal.  There is a component of the setup wizard that will allow you to configure the network prior to the installation finishing.  However, the majority of the time those settings do not seem to be maintained and when the Fedora operating system is fully installed there is no assigned IP Address, as seen in figure 3.

Note:  It is assumed that you are logged in as “root” to perform the activities in this document.  If not, use the “su –“ command to change your login context to the superuser (root).

After the installation, verify if there is an IP Address.  Use the ifconfig eth0 command.  Figure 3 shows the result when no IP Address has been configured.

Using your favorite editor, edit the ifcfg-eth0 file to setup the network stack for the interface.

Example-1:  Edit the ifcfg-eth0 file

[root@atw-dogtag01 ~]# vi /etc/sysconfig/network-scripts/ifcfg-eth0

  • With the ifcfg-eth0 file open, ensure that the ONBOOT option is set to “yes”.  This is ensuring the interface will be on when the system reboots.
  • Ensure the BOOTPROTO option is set to “none”.  This configures the interface to use a static IP address.
  • Set the IPADDR option to be the desired IP address of the server, and the NETMASK to be the subnet mask for that IP address.
  • The DNS1 and DNS2 options may be used to point the server to the correct DNS server(s).
  • Use the GATEWAY option to specify the IP Address of the default-gateway.

Example-2 below shows the details of a configured ifcfg-eth0 file:

Example-2:  Configured ifcfg-eth0 file

[root@atw-dogtag01 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0












 Ensure the network starts at boot with the “chkconfig network on” command.

Example-3:  Ensuring network starts at boot, and restarting the service

[root@atw-dogtag01 ~]# chkconfig network on

[root@atw-dogtag01 ~]# service network restart

Install Packages with yum

Fedora uses a software package manager called “yum” to manage the installed packages within the operating system.  yum provides the advantage of identifying dependencies and helping to manage the installation of the application and all of that applications dependencies.  See for more on yum.

We will use yum to update this Fedora 15 server to the latest packages, as well as install needed applications such as NTP.

Configure Proxy (if needed)

The setup used to write this document required a proxy server to access the Internet.  Therefore this procedure was included.  If your environment does not require a proxy to access the Internet, please go to Procedure 2.

Step 1 Use your favorite text editor to edit the yum configuration file located at /etc/yum.conf

Example 4 – Editing the yum configuration file

[root@atw-dogtag01 ~]# vi /etc/yum.conf

Step 2 Add a line for with a field of “proxy=” followed by the URL and Port for your proxy server

Example 5 – Complete yum.conf file

[root@atw-dogtag01 ~]# cat /etc/yum.conf












Update system with yum

Step 1 Add a yum plugin to choose the fastest location to download from.  This plugin saved hours during the writing of this paper.

Example 6 – Installing the fastest mirror plugin

[root@atw-dogtag01 ~]# yum install yum-plugin-fastestmirror


Step 2 Update all installed packages with the “yum update” command

Example 7 – Updating all installed packages with yum

[root@atw-dogtag01 ~]# yum update

Loaded plugins: fastestmirror

Determining fastest mirrors


Transaction Summary


Install       4 Package(s)

Upgrade     104 Package(s)

Total download size: 89 M

Is this ok [y/N]:

Install and Configure the NTP Service

Certificates require strict time synchronization.  It’s recommended to use the network time protocol (NTP) to ensure the time is accurate on the Certificate Authority.  The NTP service (aka: NTP daemon) is not installed by default with the minimal installation of Fedora 15, so we will use yum to install it.

  1. Install the NTP Service with the “yum install ntp” command
  2. Use the “chkconfig ntpd on” command to ensure ntp daemon starts at boot
  3. Use the ntpdate ntp_server_ip_address command to sync to an NTP source
  4. Ensure the service is started with the “ntpd start” command

Example 8 – Installing, syncing and starting NTP

[root@atw-dogtag01 ~]# yum install ntp

[root@atw-dogtag01 ~]# chkconfig ntpd on

[root@atw-dogtag01 ~]# ntpdate

31 Jul 13:47:44 ntpdate[11361]: step time server offset 64.503042 sec

[root@atw-dogtag01 ~]# /etc/init.d/ntpd start

Starting ntpd (via systemctl):                             [  OK  ]

[root@atw-dogtag01 ~]#


Install the LDAP server

Dog Tag uses an open source LDAP server called “Directory Server” to store its data.  Before you can install Dog Tag, Directory Server must be installed and prepared. 

Step 1 Install the LDAP server package with the “yum install 389-ds” command

Step 2 Create a new user named “ds389” to be used by the Directory Server

Example 9 – Installing Directory Server and creating the service account

[root@atw-dogtag01 ~]# yum install 389-ds

[root@atw-dogtag01 ~]# useradd ds389


Step 3 Launch the Directory Server configuration wizard using the script located in /usr/sbing/

Example 10 – Launching the setup script

[root@atw-dogtag01 ~]#  /usr/sbin/

Step 4 Accept the defaults.  Once you reach the portion where the wizard is asking for a System User, you will need to change the default (nobody) to the ds389 user.  Use the ds389 for the group as well, as seen in Example – 11

Example 11 – Setting the System User and Group to ds389


The server must run as a specific user in a specific group.

It is strongly recommended that this user should have no privileges

on the computer (i.e. a non-root user).  The setup procedure

will give this user/group some permissions in specific paths/files

to perform server-specific operations.

If you have not yet created a user and group for the server,

create this user and group using your native operating

system utilities.

System User [nobody]: ds389

System Group [nobody]: ds389

Step 5 Set the password for the Directory Manager

Example 12 – Setting the Directory Manager password and successs message

Directory Manager DN [cn=Directory Manager]:


Password (confirm):

Your new DS instance ‘atw-dogtag01’ was successfully created.

Exiting . . .

Log file is ‘/tmp/setupo0Vx6g.log’

Install the PHP services

Step 1 Use yum to install php as seen in example 13

Example 13 – installing php with yum

[root@atw-dogtag01 ~]# yum install php

Setting up Install Process

Resolving Dependencies

–> Running transaction check

—> Package php.i686 0:5.3.13-1.fc15 will be installed

–> Processing Dependency: php-common(x86-32) = 5.3.13-1.fc15 for package: php-5.3.13-1.fc15.i686

–> Processing Dependency: php-cli(x86-32) = 5.3.13-1.fc15 for package: php-5.3.13-1.fc15.i686

–> Running transaction check

—> Package php-cli.i686 0:5.3.13-1.fc15 will be installed

—> Package php-common.i686 0:5.3.13-1.fc15 will be installed

–> Finished Dependency Resolution

Dependencies Resolved


 Package            Arch         Version                  Repository       Size



 php                i686         5.3.13-1.fc15            updates         1.1 M

Installing for dependencies:

 php-cli            i686         5.3.13-1.fc15            updates         2.2 M

 php-common         i686         5.3.13-1.fc15            updates         547 k

Transaction Summary


Install       3 Package(s)

Total download size: 3.9 M

Installed size: 13 M

Is this ok [y/N]: y

Downloading Packages:

Running Transaction

  Installing : php-common-5.3.13-1.fc15.i686                                1/3

  Installing : php-cli-5.3.13-1.fc15.i686                                   2/3

  Installing : php-5.3.13-1.fc15.i686                                       3/3


  php.i686 0:5.3.13-1.fc15                                                     

Dependency Installed:

  php-cli.i686 0:5.3.13-1.fc15          php-common.i686 0:5.3.13-1.fc15        


[root@atw-dogtag01 ~]#

Step 2 Start the apache (httpd) and Directory Server (dirsrv) services and configure them to start on bootup as seen in example 4

Example 14 – Starting the apache and directory server services

[root@atw-dogtag01 ~]# service httpd start

Starting httpd (via systemctl):                            [  OK  ]

[root@atw-dogtag01 ~]# service dirsrv start

Starting dirsrv:

    atw-dogtag01… already running                        [  OK  ]

[root@atw-dogtag01 ~]# chkconfig dirsrv on

[root@atw-dogtag01 ~]# chkconfig httpd on

[root@atw-dogtag01 ~]#

Install DogTag

Step 1 Install DogTag with the yum install pki-ca command as seen in Example 15

Example 15 – installing DogTag

[root@atw-dogtag01 ~]# yum install pki-ca

Setting up Install Process

Resolving Dependencies

–> Running transaction check

—> Package pki-ca.noarch 0:9.0.20-1.fc15 will be installed

–> Processing Dependency: pki-selinux = 9.0.20-1.fc15 for package: pki-ca-9.0.20-1.fc15.noarch

–> Processing Dependency: pki-common = 9.0.20-1.fc15 for package: pki-ca-9.0.20-1.fc15.noarch

–> Processing Dependency: pki-ca-theme >= 9.0.0 for package: pki-ca-9.0.20-1.fc15.noarch

–> Running transaction check

—> Package dogtag-pki-ca-theme.noarch 0:9.0.11-1.fc15 will be installed

–> Processing Dependency: dogtag-pki-common-theme = 9.0.11-1.fc15 for package: dogtag-pki-ca-theme-9.0.11-1.fc15.noarch

—> Package pki-common.noarch 0:9.0.20-1.fc15 will be installed 

Modify the Firewall Rules (IPTables)

In order to connect to the DogTag service on the ports used in procedure 3, you must modify the Linux server’s host-firewall (iptables) to allow the connections.  Since this is not an iptables document, and in order to keep this simple, let’s just turn off iptables.

Step 1 Stop the firewall service with the “service iptables stop” command

Step 2 Keep the firewall from starting when the server is booted with the “chkconfig iptables off” command.

Example 16 – Shutting off the Firewall

[root@atw-dogtag01 ~]# service iptables stop

Stopping iptables (via systemctl):                         [  OK  ]

[root@atw-dogtag01 ~]# chkconfig iptables off

[root@atw-dogtag01 ~]#

Create a new CA Instance

Now that DogDag is installed, you need to create a new Certificate Authority instance. The following is using ports that we have preferred to use.  You may change any of the parameters in the following section to suite the needs of your organization.

Step 1 Create a pki instance using the pkicreate command with the following options:

·       pki_instance_root=/var/lib

#This is setting the root location to store the pki instance.  Based on the settings used in example 17, it will be placed in the following directory: /var/lib/ise-ca.

·       pki_instance_name=ise-ca 

#This is naming the new CA instance “ise-ca”.  you may replace this with another name, to suit the needs of your organization.

·       subsystem_type=ca 

#Sets the subsystem to be a certificate authority.  Other possible sub-systems are not applicable to this guide.

·       agent_secure_port=9443 

# Agent Services are where an administrator can see what certificate has been provisioned, revoke them, etc.

·       ee_secure_port=9444 

# Sets the SSL port for End-Entities web services. 

·       ee_secure_client_auth_port=9446  

# Sets the SSL port for End-Entities authentication.

·       admin_secure_port=9447 

# This is the default port to use to access the CA Services Page as the administrator.

·       unsecure_port=9180 

# Sets the regular port number. When not specified, it will be randomly generated.

·       tomcat_server_port=9701  #

·       user=pkiuser  #

·       group=pkiuser  #

·       redirect conf=/etc/ise-ca  

# configures the configuration data to be stored in /etc/ise-ca

·       redirect logs=/var/log/ise-ca 

# configures the logs to be in the /var/log/ise-ca directory.

·       verbose 

# sets the install to be in verbose mode, to provide you with as much detail as possible.

Example 17 – Creating the pki instance

pkicreate    -pki_instance_root=/var/lib -pki_instance_name=ise-ca -subsystem_type=ca -agent_secure_port=9443 -ee_secure_port=9444 -ee_secure_client_auth_port=9446 -admin_secure_port=9447 -unsecure_port=9180 -tomcat_server_port=9701 -user=pkiuser -group=pkiuser -redirect conf=/etc/ise-ca -redirect logs=/var/log/ise-ca -verbose

Step 2  Proceed with the Graphical Configuration of the DogTag CA

Once the setup script complete running, a message will be displayed with a unique URL to access the DogTag GUI and complete the CA installation, as seen in example 18.

Example 18 – Example of Unique URL to DogTag GUI

Installation information recorded in /var/log/ise-ca-install.log.

[debug] run_command(/sbin/service pki-cad restart ise-ca)

Before proceeding with the configuration, make sure

the firewall settings of this machine permit proper

access to this subsystem.

Please start the configuration by accessing:


After configuration, the server can be operated by the command:

    /sbin/service pki-cad restart ise-ca

Step 3 Click Next from the Welcome Screen

Step 4 Create a “New Security Domain”.  Name it “ISE BYOD Domain” & click Next


Step 5 Name the Subsystem “Certificate Authority” & click Next

Certificate Authority

Step 6 Make this a Self-Signed Root CA within this new PKI Hierarchy.  Of course this could become a subordinate CA of an existing CA.  However, that is not the focus of this post.

Self-Signed Root

Step 7 The Internal Database is the Directory Server (ds389) that we installed earlier.  All settings should be filled in correctly.  Please add the Directory Manager password created earlier in Example 12.

Directory Manager password from Example 12

Step 8 Generate the Keypairs.  The default of RSA w/ SHA256 and a key size of 2048 bits will work fine, then click next.

Default Values + 2048 bit

Step 9 The certificate subject lines can be left at their default values, and click next

Subject Names

Step 10 If there are actions needed, they will be in red.  If not, click Next

Actions will be in Red, if any

Step 11 Provide a password, and export the CA’s key pair.  Store the key pair in a secure location.

Export the Keys and Store in safe location

Step 12 The new root CA certificate will be imported into your browser or your local certificate store, to ensure your system trusts certificates signed by this new CA.

Trusting your new CA

Step 13  You should now be asked to install an Administrative Certification.  This is a personal certificate to identify you (the admin) to the CA for administrative tasks.  Please ensure you backup and store this key in a secure location, as you will not be able to administer the CA without this identity certificate.

Import the admin cert
You are finished with the GUI-Based configuration.
Note:  while the GUI Configuration is complete, we are not ready to begin using the CA just yet.  We still need to add a custom script and modify some more configuration files.

Enable and Configure SCEP

Here you will be enabling and configuring Simple Certificate Enrollment Protocol (SCEP) by directly modifying the CS.cfg file.

Step 1 Backup the CS.cfg file before making any changes.

 Example 20 – Backup of the CS.cfg file

[root@atw-dogtag01 ~]# cp /etc/ise-ca/CS.cfg /etc/ise-ca/CS.cfg.bak

Step 2 Open up the CS.cfg file in a text editor.

Example 21 – Edit the CS.cfg file

[root@atw-dogtag01 ~]# vi /etc/ise-ca/CS.cfg

Step 3 Add the following lines to the bottom of the CS.cfg file and save the changes.







Step 4 Backup the caRouterCert.cfg file before making any changes.

Example 22 – Backing up the caRouterCert.cfg file

[root@atw-dogtag01 ~]# cp /var/lib/ise-ca/profiles/ca/caRouterCert.cfg /var/lib/ise-ca/profiles/ca/caRouterCert.cfg.bak

Step 5 Edit the caRouterCert.cfg file using a text editor.  Delete the value for the variable auth.instance_id and save your changes.  The end result should look like Example 24.

Example 23 – Edit the caRouterCert.cfg file

[root@atw-dogtag01 ~]# vi /var/lib/ise-ca/profiles/ca/caRouterCert.cfg

Example 24 – The final setting for auth.instance_id= field in the caRouterCert.cfg file

[root@atw-dogtag01 ise-ca]# cat /var/lib/ise-ca/profiles/ca/caRouterCert.cfg

desc=This certificate profile is for enrolling router certificates.





name=One Time Pin Router Certificate Enrollment






Step 6 Restart the CA services with the “service pki-cad restart“command

Example 25 – Restart the CA Services

[root@atw-dogtag01 ise-ca]# service pki-cad restart

Stopping ise-ca:                                           [  OK  ]

Starting ise-ca:                                           [  OK  ] 

Prepare Apache

Step 1 Move the Apache Welcome.conf file to disable the default installation

Example 26 – Move the welcome.conf file

[root@atw-dogtag01 ise-ca]# mv /etc/httpd/conf.d/welcome.conf /etc/httpd/conf.d/welcome.conf.bak

Step 2 Create a new file called scepproxy.php at /var/www/html.

Example 27 – Creating the scepproxy.php file

[root@atw-dogtag01 ise-ca]# vi /var/www/html/scepproxy.php

Step 3 Populate the file with the following PHP script and save the file when completed.


$ops = $_GET[‘operation’];

$msg= $_GET[‘message’];

$order   = array(“\r\n”, “\n”, “\r”, ” “);

$msg = str_replace($order, “”, $msg);

$msg = rawurldecode($msg);


if ($ops == “GetCACaps”)


echo “”;




$url =$ops.“&message=”.$msg;

$ch = curl_init();

curl_setopt($ch, CURLOPT_PORT, 9180);

curl_setopt($ch, CURLOPT_URL, $url);

curl_setopt($ch, CURLOPT_HEADER, 0);

curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);

//curl_setopt($ch, CURLOPT_POST, 1);

$body = curl_exec($ch);


if ($ops==“PKIOperation”)


header(“Content-Type: application/x-pki-message”);




header(“Content-Type: application/x-x509-ca-cert”);


echo $body;




Step 4 Restart the Apache service to reflect your changes with the “service httpd restart” command

[root@atw-dogtag01 ise-ca]# service httpd restart

Restarting httpd (via systemctl):                          [  OK  ]

[root@atw-dogtag01 ise-ca]#

The DogTag installation is complete.  You are ready to add this CA to ISE for BYOD certificate provisioning.

Configure ISE to use the new DogTag CA

This document is assuming your already have your BYOD policies ready, or you will create them afterwards.  In this section, we will focus on the simple task of adding the new DogTag CA to ISE for purposes of SCEP provisioning the BYOD certificates.

For more on configuring ISE for BYOD, please see the BYOD How-To Guides here:

Add DogTag to the SCEP RA Profiles

From the ISE administrative GUI, we will add the DogTag server to the SCEP RA Profiles

Step 1 Navigate to Administration >> System >> Certificates >> SCEP RA Profiles & Click Add

Step 2 Name the RA “DogTag” & Enter a Description

Step 3 Enter the DogTag Server URL of http://<server_name>/scepproxy.php

Step 4 Click “Test Connectivity”

SCEP RA Profile

Click Submit.  You are finished & ready to onboard.

Thanks so much for taking the time to read my boring blog posts.  I hope they are useful.  Please feel free to send your comments.






Using VNC for Console Access to ISE (and other) VM’s

A little less than 1/2 of all Identity Service Engine installations are on VMWare.  Yes it’s true.  About 45% of all ISE nodes deployed in this world are Virtual.  What I don’t know is:  how many are in production and how many are in a lab.

Let me give you another statistic (my own).  When I work with a company that is using VMWare in production, 90% of the time the VMWare infrastructure is managed by a completely different team than the one who owns ISE & the management of the appliances (virtual and physical).

One more statistic.  Of that 90% who do not manage VMWare, 80% of those are not permitted to access the console of their ISE nodes.  That’s right, a security team that has a security appliance installed on a VMWare ESX server & is not permitted to access the console; only SSH / Web into the device.

Whether you suffer from the same affliction of not having rights/permissions to access the console, or you are just looking for a way to simplify console access without having to first launch VMWare VSphere:  I have a solution for you!  VNC!

That’s right, VMWare had the forethought to build VNC into the ESX server, they just don’t make it obvious on how to enable it.  That’s (hopefully) where I come in.  Now you just have to get your VMWare administrator to follow this blog post.  Let’s get started.

Configure your Virtual Machine for VNC to the Console.

I typically add these changes to my standard procedure when building a new ISE VM.  I make the changes before I complete the Virtual Machine creation (use the “Edit the virtual machine settings before completion” check box to make it even easier).  However, you can also edit the settings of an existing VM & add the VNC configuration to that VM, too.

Note:  the VM must be powered off to make this change.

Edit before complete check box

If your VM is already created, simply edit the settings:

Edit Settings on existing VM

Either way, you end up with this screen.  From here Click on OPTIONS.

Click the Options Tab

Now under Advanced, click on General >> and then click on “Configuration Parameters”

Click Configuration Parameters

This screen may be empty (if a new VM) or it may have a bunch of stuff in it if the VM was already existing (modifying an existing VM).  Either way, click Add Row:

Click Add Row

Fix the Keyboard Delay.  We are doing this because often when working remotely with VMWare consoles, the keyboard repeat rate is too sensitive and you will sssssooooooommmmmmeeeeettttttiiiiiiiiiimmmmmmeeeeeeesssss gggggeeeeeettttt kkkkkkeeeeeeyyyyyy  reeeepppeaaaaattttttttttssssss.  This fixes that.

In your new row, give the row the name keyboard.typematicMinDelay and then set the Value to 2000000.  Then Click Add Row to move on to the next entry.

Name the second entry RemoteDisplay.vnc.enabled  and the value should be TRUE.  Click Add Row to move onto the next entry.

Name this third entry RemoteDisplay.vnc.port  and the value needs to be 59xx (replace xx with a port between 00-64).  5900 – 5964 are the VNC port numbers and need to be unique per Virtual Machine.  See the screen shot below

Lastly, add a final row named RemoteDisplay.vnc.password and set the value to whatever password you would like to use.

All 4 rows

Before you can connect to the Console via VNC, you may have to modify the ESX Server’s Firewall settings.  By default ESX’s firewall does not have a rule for the VNC ports.  So, in order to keep this blog post simply & open the ports, we will just go into the Firewall Properties and enable an existing rule named “VM serial port connected over network”.  This will allow the connections.

Navigate to the ESX Server itself (not the VM).  Click on Configuration >> Security Profile.  Then click on the Properties link for the Firewall.

ESX Security Profiles

Within the Firewall Properties, enable the check box for the existing “VM serial port connected over network” default rule.  This will allow the connections necessary.

Note:  Your VMWare administrator could always modify the iptables rules from the ESX Server’s command line interface to only allow the VNC ports that are needed.  But we are keeping this simple for the purposes of this blog post.

Now the VM is setup!  You are ready to rock this.  Let’s setup a VNC Client.  You can use whatever client you would like, obviously.  I personally use JollyFastVNC on my Mac.

Note:  VNC will not connect unless the VM is powered on.

Add a new VNC Connection to your client.  The network address should be the IP Address of the ESX server (not the VCenter).  The port should match the 59xx port number you chose when adding that entry to the VM.

JollyFastVNC Client Settings

When you connect, you will be prompted for the VNC Password.

VNC Password Prompt

POOF!  You are on the console of the VM.

It Works!!!
It is ALIVE!

Well, I hope this was helpful!  Now you can access the console of all your ISE Virtual Machines without having to go through the VSphere client.  As always, feedback is very welcome.

Stay on the lookout for more Tips & Tricks!




What are WildCard Certificates? And how do I use them with Cisco’s ISE

What is a Wildcard Certificate?

A wildcard certificate is one that uses a wildcard notation (an asterisk and period before the domain name) and allows the certificate to be shared across multiple hosts in an organization.  An example CN value for a wildcard certificate’s Subject Name would look like the following:  *.company.local

If you configure a Wildcard Certificate to use *.company.local, that same certificate may be used to secure any host whose dns name ends in “.company.local”, such as:


Figure 1 shows an example of using a wildcard certificate to secure a web site (specifically, the web interface of an ISE node).  Notice in figure 1 that the URL entered into the browser address bar is “”, but the certificate’s common name is “*”.

Wildcard certificates secure communications in the same manner as a regular certificate, and requests are processed using the same validation methods.

Where are Certificates Used with ISE?

Certificates are employed often in a network implementing Secure Access.  The certificates are used to identify the Identity Services Engine (ISE) to an endpoint as well as to secure the communication between that endpoint and the ISE node.  The certificate is used for all HTTPS communication as well as the Extensible Authentication Protocol (EAP) communication.

HTTPS communication using the ISE certificate:

Every web portal with ISE version 1.1.0 and newer is secured using HTTPS (TLS encrypted HTTP communication).  Figure 2 describes the TLS encrypted process when communicating to the Admin portal.

  • Administrative Portal
  • Centralized Web Authentication (CWA) Portal
  • Sponsor Portal
  • Client Provisioning Portal (CPP) & Native Supplicant Provisioning (NSP)
  • MyDevices Portal


EAP Communication:

Certificates are used with nearly every possible EAP method.  The main examples include:

  • PEAP

With tunneled EAP methods such as PEAP and FAST, Transport Layer Security (TLS) is used to secure the credential exchange.  Much like going to an HTTPS web site, the client establishes the connection to the server, which presents its certificate to the client.  If the client trusts the certificate, the TLS tunnel is formed.  The client’s credentials are not sent to the server until after this tunnel is established, thereby ensuring a secure exchange.  In a Secure Access deployment, the client is a supplicant, and the server is an ISE Policy Services node.  Figure 2 describes an example using PEAP.

Why use Wildcard Certificates?

There are a number of reasons to implement wildcard certificates with an ISE deployment.  Ultimately, those who choose to use them, do so to ensure the end-user experience is as seamless as possible, especially given the vast difference and variety of endpoints.

Benefits of Wildcard Certificates

Some examples of benefits of wildcard certificate usage are:

1)     Cost savings.  Certificates signed by a 3rd-part Certificate Authority can be costly, especially as the number of servers increase.  Wildcard certificates may be used on all nodes of the ISE Deployment (also referred to as the “ISE Cube”).

2)     Operational efficiency.  Wildcard certificates allow all Policy Service Node (PSN) EAP and web services to share the same certificate.  In addition to significant cost savings, certificate administration is also simplified through “create once, apply to many”.

3)     Reduced authentication errors.  Wildcard certificates address issues as seen with Apple iOS devices where client stores trusted certificates within the profile, and does not follow the iOS Keychain where the signing root is trusted.  When an iOS client first communicates to a PSN it will not explicitly trust the PSN certificate, even though a trusted Certificate Authority has signed the certificate.

Using a wildcard certificate, the certificate will be the same across all PSNs, so user will only need to accept certificate once and successive authentications to different PSNs should proceed without error or prompting.

4)     Simplified supplicant configuration.  For example, Microsoft Windows supplicant with PEAP-MSCHAPv2 and server cert trust enabled often requires specification of each server certificate to trust, or user may be prompted to trust each PSN certificate when client connects using a different PSN.  With wildcard certificates, a single server certificate can be trusted rather than individual certificates from each PSN.

Ultimately, wildcard certificates result in an improved user experience.  Less prompting and more seamless connectivity will translate into happier users and increased productivity.

Drawbacks to Wildcard Certificates

There can be a number of benefits using wildcard certificates, but there are also a number of security considerations related to wildcard certificates including:

1)     Loss of auditability and non-repudiation

2)     Increased exposure of the private key

3)     Not as common or as well understood by admins

Although considered less secure than assigning a unique server certificate per ISE node, cost and other operational factors often outweigh the security risk and necessitate the need to offer this as an option to our customers in their ISE deployments. Note, that other security devices like the ASA also support wildcard certificates.

You must always be careful when deploying wildcard certificates. For example if you create a certificate with *.company.local and an attacker is able to recover the private key, that attacker can spoof any server in the company.local domain. Therefore it is considered a best practice to partition the domain space to avoid this type of compromise.

To address this possible issue and to limit the scope of use, wildcard certificates may also be used to secure a specific subdomain of your organization. Just add an asterisk (*) in the subdomain area of the common name where you want to specify the wildcard. For example, if you configure a wildcard certificate for *, that same certificate may be used to secure any host who’s dns name ends in “”, such as:


Wildcard Certificate Compatibility

Wildcard certificates are most commonly constructed with the wildcard listed as the canonical name (CN) of the subject field of the certificate itself, such as the example in Figure 1.  ISE version 1.2 and newer support this manner of construction, however not all endpoint supplicants will support the wildcard in the subject of the certificate.

All Microsoft native supplicants tested (including Windows Mobile) do not support wildcards in the subject of the certificate.  The use of another supplicant, such as Cisco’s AnyConnect Network Access Manager (NAM), will allow the use of wildcard characters in the subject field.  Another option is to use special wildcard certificates like DigiCert’s Wildcard Plus that is designed to work on incompatible devices by including specific sub-domains in the Subject Alternative Name of the certificate.

For more information on Microsoft’s support of wildcard certificates, see here:

Making Wildcards Work with all Devices

Although the limitation with Microsoft supplicants may appear to be a deterrent to using wildcard certificates, there are alternative ways to construct the certificate that allow it to work with all devices tested with Secure Access, including the Microsoft native supplicants.

Instead of constructing the subject to include the wildcard values, you may put those wildcard values into the Subject Alternative Name (SAN) field instead.  The SAN field maintains an extension designed for the checking of the domain name, dNSName.  See RFCs 6125 and 2128 for more detail, and a small excerpt from RFC 6125 is displayed in figure 4.

ISE Support for Wildcard Certificates

ISE added support for wildcard certificates in version 1.2.  Prior to version 1.2, ISE will perform verification of any certificates enabled for HTTPS to ensure the CN field matches the host Fully Qualified Domain Name (FQDN) exactly.  If the fields did not match, the certificate could not be used for HTTPS.

This restriction exists because prior to version 1.2, ISE would use that CN value to replace the variable in the url-redirect AV pair string.  For all Centralized Web Authentication (CWA), on-boarding, posture redirection and more, the CN value would be used.

Beginning in ISE version 1.2, the behavior has been modified to use the hostname as it is defined in the underlying operating system configuration of ISE, instead of relying on the CN field.

Constructing the Wildcard Certificate

Since we know we must insert the wildcard value into the Subject Alternative Name (SAN) field of the certificate as a workaround for Microsoft native supplicants, we are left with two main ways to construct the certificate:

Option 1: Leave the canonical name (CN) field of the subject blank and insert the wildcard into the SAN field.

While this appears to work perfectly well with most private Certificate Authorities, such as the Microsoft Active Directory CA, the majority of Public authorities will not allow the creation of a certificate without the CN value.

Figure 5 shows and example of a valid wildcard certificate without the CN field.

Option 2 (Cisco Preferred Best Practice): Use a generic hostname for the CN field of the subject, and insert both the same generic hostname and the wildcard value into the SAN Field.

This method has been successful with the majority of tested public Certificate Authorities, such as and  With these public CA’s the type of certificate to request is the “Unified Communications Certificate” (UCC).

Note:  With both option 1 and 2, the resulting wildcard certificate only needs to be imported into the ISE nodes running Policy Services, it is not required to import the wildcard certificate into the Policy Administration Nodes (PAN) or Monitoring and Troubleshooting (MnT) nodes.

How to Implement Wildcard Certificates

Now that we have reviewed wildcard certificates and their usage with ISE, we will walk through the creation of a wildcard certificate following the best practice of using a generic hostname for the CN field of the subject, and insert both the same generic hostname and the wildcard value into the SAN Field.

There are a few ways to import a wildcard certificate into ISE version 1.2.  This procedure will follow what we expect to be the most common approach, which is to create the Certificate Signing Request (CSR) within the ISE administrative interface and submit that CSR to the signing Certificate Authority (CA).  The resulting signed public key will be bound to the CSR on ISE.

The final private and public key-pair will be exported from the first ISE node, and imported on the other nodes in the deployment.

Let’s Create the Certificate Signing Request (CSR)

From the first ISE node, navigate to the certificates section of the administrative GUI.  For dedicated Policy Services Nodes, the path will be “Administration à Server Certificates”.  If the node is also an administrative node, the path will be “Administration à Certificates à Local Certificates”.

Step 1 Click Add > Generate Certificate Signing Request
Step 2 In the Certificate Subject enter the generic FQDN for the ISE PSNs.
Step 3 Select at least two DNS Names under the Subject Alternative Name (SAN) section

  • One of the DNS Names must match the CN= value from Step 2.
  • The other DNS Name should be the wildcard value.

Step 4 Ensure the “Allow Wildcard Certificates” check box is selected.
Step 5 Click Submit.   Figure 7 displays a sample CSR.

Export the CSR and Submit it to the Certificate Authority

Now that the CSR has been generated, we need to export it.

Step 1 Navigate to the Certificate Signing Requests screen
Step 2 Highlight the CSR, and click Export
Step 3 Save the CSR to your local machine.  Figure 8 illustrates the exporting of the CSR

Step 4 Open the CSR in your favorite text editor and copy all text from “—–BEGIN CERTIFICATE REQUEST—–“ through “—–END CERTIFICATE REQUEST—–“

Step 5 Paste the contents of the CSR into the certificate request on the chosen CA, such as seen in the following figures.

Step 6 Download the resulting signed certificate

In the case of figure 12, the certificate is just downloaded.  Some CA’s may email you after the certificate is issued, and you will need to download the certificate.  In many cases, the result will be a zip file containing not only your newly issued certificate, but also the public signing certificates of the CA to be added to the ISE trusted certificate store (as seen in figure 13).

Import the Root Certificates to the Certificate Store

Before we bind the newly signed certificate to the CSR on ISE, we want to ensure the signing root certificates exist in the trusted certificate store.

Note:  By performing the actions in this order, we are ensuring that all other nodes in the deployment will trust the new certificate before we bind it.

Step 1 Navigate to Administration à System à Certificates à Certificate Store
Step 2 Click Import
Step 3 Click Browse and locate the certificates for the signing certificate authority, as shown in figure 14
Step 4 Provide a friendly name for these, such as “Comodo Trusted Root”
Step 5 Ensure the checkbox for “Trust for client authentication or Secure Syslog services” is enabled
Step 6 Click Submit
Step 7 Repeat steps 2 through 6 for any additional root CA certificates

Bind the Newly Signed Certificate to the CSR

Now that the signing root certificates exist in the trusted certificate store, we can move forward binding the newly signed certificate to the signing request.

Step 1 Navigate back to Administration > System à Certificates > Local Certificates
Step 2 Click Add à Bind CA signed Certificate
Step 3 Click Browse and locate the signed certificate from the CA
Step 4 Provide a friendly name, such as “Comodo Signed Wildcard Certificate”
Step 5 Ensure the “Allow Wildcard Certificates” check box is enabled
Step 6 Choose the protocol for this certificate to be bound to: EAP, HTTPS or both
Step 7 Click Submit

Reuse the Wildcard Certificate on other ISE nodes

At this point, we have generated a certificate signing request using one of our ISE nodes.  This will use the private key from that ISE node and a new Public Key that has been created with a CN of “psn.ise.local” and SAN dNSName values of “psn.ise.local” and “*.ise.local” (the wildcard).

By binding the new signed certificate to the certificate signing request, we have a brand-new Public & Private key pair on this ISE node.

Our next procedures will be to export that key-pair and import both the private and public keys on all the other Policy Service Nodes, ensuring we have the exact same certificate on all PSNs.

Export the Key Pair

From the first ISE node, navigate to the certificates section of the administrative GUI.  For dedicated Policy Services Nodes, the path will be “Administration à Server Certificates”.  If the node is also an administrative node, the path will be “Administration à Certificates à Local Certificates”.

Step 1 Select the wildcard certificate
Step 2 Click Export
Step 3 Select Export Certificate and Private Key
Step 4 Provide a password that will be used later when importing the certificate key-pair
Step 5 Click Export
Step 6 The key-pair is exported as a zip file, save that zip file to a location that be accessed quickly

Import the Key-Pair on other ISE Nodes

On your local machine, you will need to extract the zip file from procedure 1, so the two certificate files may be accessed.

Then, on one of the remaining ISE nodes, navigate to the certificates section of the administrative GUI.  For dedicated Policy Services Nodes, the path will be “Administration à Server Certificates”.  If the node is also an administrative node, the path will be “Administration à Certificates à Local Certificates”.

Step 1 Click Add à Import Server Certificate
Step 2 Click Browse for the Certificate File, and locate the certificate file from the zip file with the .pem extension (for example “CNisaaaSANhasWildcard.pem”)
Step 3 Click Browse for the Private Key File, and locate the private key file from the zip file with the .pvk extension (for example “CNisaaaSANhasWildcard.pvk”)
Step 4 Provide the password you created in Procedure 1, Step 4
Step 5 Ensure the “Allow Wildcard Certificates” check box is enabled
Step 6 Choose the protocol for this certificate to be bound to: EAP, HTTPS or both
Step 7 Click Submit
Step 8 Repeat steps 2 through 7 for all remaining ISE Nodes

Testing Results:

This section is providing a sampling of the clients that have been tested and are proven to work with the wildcard certificates.  Both Option 1 and Option 2 from the section of this document labeled “Constructing the Wildcard Certificate” were tested.   This is a sampling only, as many more devices have been tested and proven to work.





Device Details
Cisco Cius




Android 2.2.2 / Kernel
Galaxy Player




Android 2.3.5 / Kernel
Galaxy Tab 10.1




Android 4.0.4 / Kernel 3.1.10
Galaxy Tab 2 – 7”




Android 4.1.1 / Kernel 3.0.31
Acer A110 Tab




Android 4.1.2 / Kernel 3.1.10
Google Nexus 7




Android 4.2.2 / Kernel 3.1.10-g05b777c
Galaxy Note 8.0




Android 4.1.2 / Kernel 3.0.31
iPod Touch 1st Gen




iOS 3.1.3 (7E18)




iOS 5.1.1 (9B206)




iOS 6.0.1 (10A523)
iPad Mini




iOS 6.1.2 (10B146)
iPhone 4




iOS 6.0 (10A403)
iPhone 5




iOS 6.1.3 (10B329)
Nook HD




Nook 2.1.0
MacBook Pro




OSX 10.7.5
MacBook Air




OSX 10.8.2 (12C30006)
Kindle Fire HD




Version 7.3.0_user_3013320
Microsoft Surface




Windows7 Native




Windows7 Ultimate ServicePack1
WindowsXP Native




WindowsXP SP3
Windows8 Native




Windows 8 Native Supplicant

Security Group Tagging Basics

Hi all! Back again.

In my last blog (which admittedly was a bit long, and verbose) I discussed the changing landscape of Identity Networking. With Identity Networking there are many different ways of controlling network access based on the context of a user and device. There is:

  • VLAN assignment, in which access is controlled at the Layer-3 edge, or by isolating that VLAN into a segmented virtual network (VRFs).
  • There is ACL assignment, which can be a local ACL, called into action by a RADIUS attribute, or a downloaded ACL (dACL). These ACLs are applied ingress at the switchport or virtual port in the case of the Wireless LAN Controller (WLC).
  • We just touched on the topic of a new scalable enforcement mechanism known as Security Group Tagging.

This new technology (Security Group Tagging) is going to be the focus of today’s blog.

Security Group Tagging allows for segmentation without needing VLANs, and even more importantly simplifies the operational management of firewall policy and access lists.  For our example in this blog there are two switches in the Access Layer, each with a user from the HR Department, and another user who needs access to Payment Card Industry (PCI) data.  These two users have absolutely NO need to ever communicate to one another.

The Policy is a simple one.  HR is allowed to communicate to HR, PCI is allowed to communicate with PCI.  However, they may not talk to one another, even though they could be on the same VLAN (same VLAN in the Access Layer or even the Data Center).

Our Policy:

With this SIMPLE policy, we are able to enable the flows as shown in the next figure:

  • PCI User attempting to talk to HR user on same switch & same VLAN is denied.
  • HR User on Switch 1 is able to communicate with HR User on Switch 2.
  • HR User is denied access to the PCI Server
  • PCI User is granted access to the PCI Server



If the benefits have not made themselves abundantly obvious already, let me point some out to you.  Security Group Tagging advantages are extensive throughout most IT network operations and may affect how they operate and the way decisions are made as it opens a variety of new possibilities that were not practical using VLAN-based topologies.

Advances Protection

Classifies endpoints by context, dynamically segments into security groups, and protects data center applications.

Simplifies Administration

Manages policy with plain language, enables changes in minutes, and automates the management of firewall rules.

Scales Extensively

Removes design complexity, helps increase network performance, and ensures dependable resource access.