Certificate for IPAD and PEAP still needed in ISE?

[dan hale]

Hi we have a new installation of ISE version 2.4 in a distributed deployment with two nodes. We have a legacy WLAN that we use for IPADS that does mac authentication and uses AD suthingication via PEAP on ACS 5 that I need to migrate to ISE.

Previously I had to generate a Certificate from one of our domain controllers to allow the IPAD's to accept the certificate and send out to the IPADs.

Has there been an option in ISE that I can just allow the IPAD's on the network without verifying the certificate, such has on our windows computers via Group Policy I have that option disabled.

And if not is there any updated online walk thru to to generate this certificate with Windows Active Directory IIS and install on ISE?

Thanks,

Dan

[Arne Bier · Accepted solution]

With EAP-PEAP, the Authenticating Server (ISE in this case) will always present a certificate to the Supplicant (in this case iPad) and the iPad has to decide whether or not to trust it (as you mentioned, in Windows you can untick that check box).  In iOS I have not seen that option - I think you will always get a certificate warning.  I would have thought that users can accept that warning once and then never see it again. It's ugly of course.

Because you have two ISE nodes and I assume both of them run the Policy Service (Radius), the proper way to do this is to

1. Create a System Certificate for each ISE node signed by a central PKI server
2. Push the PKI Root CA to the iPad (via Apple Configurator or other MDM)

The issue with not doing the above method, is that users might connect to ISE01 on Monday, accept the self-signed cert, and then on Tuesday they connect again and get ISE02, which has its own self-signed cert.  Therefore, the best way is to create an ISE certificate (for EAP purpose) that is signed by the Root CA.  Then it doesn't matter which ISE node the clients hit.  By the way, you can also get away with one certificate that you can re-use on both ISE nodes.  But rather create two CSR's (Certificate Signing Requests), one per ISE node, and then bind them to the appropriate ISE node.

As for doing this in AD, it requires a bit of setup, but once done, it's quite simple.  I did a bunch of google searches and figured it out.  Here are some high level things - let's assume you have Server 2012 R2

• Add the Certificate Authority role to the server
• Enable the IIS server to use https (a bit involved but necessary to allow you to browse to https://myserver/certsrv for the CSR submission)
• Create a certificate template that is a duplicate of the default web server.  Change the validity of the cert to say, 5 years.  And all the Client Auth EKU (in addition to the Web auth EKU).  Set the certificate to be exportable (this allows you to create a cert that you can import into multiple ISE nodes)
• Publish the template to the CA service
• Create the CSR on ISE nodes - get the resulting CSR as a PEM text output
• open IE to https://myserver2012/certsrv   and login as the admin user
• Request cert, select ISE profile, paste in the CSR and then download the cert
• Bind the cert to ISE

I really summarised a lot of stuff - but that's the high level outline.  I might get around to writing a blog about this but I fiddle my way around some of the more Microsofty-things - I only know what I know.

cheers

regards

Arne

[dan hale]

Thanks for the detail on this Arne!

[Francesco Molino]

Hi

The only way to get rid of the certificate warning on iPads, it will be to present a public cert signed by a trusted authority. You can achieve this using let's encrypt certificates.

If you already have a public cert with the private key, you can import it into ise and you can use alias cli command to decide to present another hostname/fqdn different from the one setup during configuration phase.

You can sign your ISE cert using your Microsoft PKI following the below steps:

- generate csr from ISE nodes

- go to https://your-windows-authority/certsrv --> depends on how it's been setup, it could be http also

- sign the csr using Web Server certificate template (it should be presented in the web portal otherwise you need to check this out with your windows experts)

- bind the cert to your csr on ise.

You can generate 1 certificate and import on both ise servers as well if you want.

Anyway, the root certificate, even if accepted by a user won't be trusted. To do so, you need to do on setting app, then general, then information and go the menu trusted certificates and put on your root certificate. If you want to do it automatically, you'll need to create a profile using Apple configurator and send it to all of users, then they'll just need to click on it and everything is going to be done automatically.

[Arne Bier]

Hi @Francesco Molino

How does one go about getting a certificate from https://letsencrypt.org/ ?  I thought you had to run an agent on the server that requests the cert - because ISE is so locked down, you won't be able to run the agent.  But perhaps you have found a way?  That would be brilliant!

[Francesco Molino]

Hi @Arne Bier

I didn't say it would be automatic because as you mentioned, you can't do it automatically. It was an example like i would have said GoDaddy.

By the way, what i do usually for ISE, for those who don't want to pay for a public cert, i install a Linux machine with a script running every quite 3 months, it gets the cert from let's encrypt, and send it by email. With this process, people don't forget to renew it. 

Sorry for the confusion! I hope one day we will have a module on ise for that or at least, API to be able to modify certificates.

[Arne Bier]

Hi @Francesco Molino

I'd like to know how to perform that procedure you mentioned (sending cert via email).

I have played around with certbot and I just can't get it to work.  For example, if I own the domain mycompany.com, but I have not registered any of my hosts in the public DNS, e.g. ise01.mycompany.com is not in the public DNS, but of course it's on my internal DNS, then how does letsencrypt get around the NXDOMAIN issue (non existent domain) ?

I am trying this "certbot certonly" procedure, but getting stuck at the domain validation.  I would like to know how you get around that.

regards

Arne

[Francesco Molino]

Most of the time, i use wildcard certificates because they'll be used on different devices.
To do so using certbot, you need to add a dns txt entry on your public dns name. If you look on let's encrypt it's explained. Otherwise you can Audi search for wildcard certificate let's encrypt and you'll find some posts how to achieve this using certbot.

At the end, you'll need to do something on your public dns to be able to get your domain validated and dns txt record is the simplest way.

[layhlaing]

Hello Francesco,

Sorry to be adding a question to this thread but I presume it is related.

Regarding "The only way to get rid of the certificate warning on iPads, it will be to present a public cert signed by a trusted authority.", I have recently worked on a new ISE 2.3 deployment and migrated services across from the old 2.1 deployment, and have initially utilized a public cert signed by a trusted authority for EAP. It worked fine without any warnings on browsers however we had to accept / trust the certificate on Microsoft and Apple client devices, or with a wireless gpo for windows workstations to trust the top CA in the certificate hierarchy. Just wondering if there is any specific requirement on the public cert to work on EAP without manually requiring to trust the certificate? Thanks.

Regards,

Lay

[ajc]

Unfortunately for APPLE devices you would have to accept the untrusted certificate warning once unless you FORGET the network BUT if you are using more than 1 PSN and you do not have a SAN/Wildcard cert for EAP on ISE, then when you are roaming, the 802.1x reauthentication could alternate PSN's causing the untrusted certificate warning to be displayed on the enduser device at any time. You cannot cache more than 1 untrusted cert on the enduser device and that's why the warning keeps showing up.

https://support.apple.com/en-ca/HT204132

If I am not wrong, I think you can distribute via GPO the Root and Intermediate CA into the enduser Trusted Certificate Authorities DB on windows devices so you can get rid of that warning for that kind of devices no matter if you are using PEAP or EAP-TLS.

[Jason Kunst · Accepted solution]

Apple devices require you to trust every certificate that is used for EAP. Regardless of the chain and trust. Wildcard should be used in environments where devices are going to roam between PSNs on a frequent basis. With this they only trust the cert once and then it will work on all PSNs

https://www.networkworld.com/article/2225032/infrastructure-management/what-are-wildcard-certificates-and-how-do-i-use-them-with-ciscos-ise.html
https://www.cisco.com/c/en/us/td/docs/security/ise/2-4/admin_guide/b_ise_admin_guide_24/b_ise_admin_guide_24_new_chapter_0111.html#concept_8ECCCAF1252E40DDB9A786C0AC7BC3B2

[ajc]

I am not quite sure that a ROOT CA included in the Apple Trusted Certificate Authorities List x iOS that signed the ISE Certificate for EAP (not chained cert) when is presented to the enduser for EAP authentication would trigger the untrusted certificate warning. I will give a try. I am also aware of:

An intermediate CA certificate is a subordinate certificate issued by the trusted root specifically to issue end-entity server certificates. The result is a trust-chain that begins at the trusted root CA, through the intermediate and finally ending with the SSL certificate issued to you. Such certificates are called chained root certificates. The usage of an intermediate certificate thus provides an added level of security as the CA does not need to issue certificates directly from the CA root certificate.