Certificates for BYOD

What it is

BYOD relies on certificates in two directions: the device must trust ISE, and ISE must trust the certificates it issues to devices.

ISE has certificates for its own services, and a certificate authority that issues certificates to endpoints. Getting the trust right is the main job in a BYOD design.

How it works

You manage three groups of certificates: the ISE system certificates, the trusted certificates, and the certificates issued to endpoints.

System certificates

System certificates identify each ISE node. Each certificate is marked with the usages it serves. The main usages are:

One certificate can carry several usages, or you can use a separate certificate for each. The list is in the admin portal under Administration, System, Certificates, System Certificates.

You create a signing request in the portal, send it to a CA, and then bind the signed certificate to the request. The subject alternative name should hold the node FQDN, so that clients see a matching name.

Trusted certificates

The trusted certificates store holds the CA certificates that ISE trusts. Each entry has trust settings, such as trust for authentication within ISE, and trust for client authentication.

For BYOD you need the signer of any external CA that you use. You also need the CA that signs the endpoint certificates, if it is not the ISE CA, so ISE accepts those certificates in EAP-TLS.

The ISE internal CA

ISE includes its own certificate authority. It issues the endpoint certificates for BYOD, so you do not need an outside CA for onboarding.

The internal CA has a hierarchy. A root CA runs on the primary admin node, and the PSNs act as subordinate CAs that issue certificates to the endpoints they onboard.

The settings and issued certificates are under Administration, System, Certificates, Certificate Authority.

The internal CA also supports revocation. It can publish a CRL, and it has an OCSP responder, so ISE can check whether an endpoint certificate has been revoked.

Certificate templates

A certificate template defines what the endpoint certificate looks like. It sets the subject, such as the common name, and the subject alternative name. It also sets the key size, the lifetime and the signing CA.

ISE has a default template for EAP authentication, and you can copy it and change it.

A common design puts the user name in the common name and the device MAC address in the subject alternative name. That lets policy tie the certificate to both the user and the device.

The templates are found under the certificate authority settings in the same area of the portal.

Using an external CA

If your company runs its own CA, ISE can use it instead. The usual method is SCEP, a protocol that lets ISE request certificates on behalf of the device.

You add a SCEP RA profile in the external CA settings, with the address of the CA. The certificate template or the supplicant profile then names that profile.

ISE acts as a registration authority, and the external CA issues the certificate.

Choose this method if your security rules need all certificates to come from one CA. Choose the internal CA if you want a simple design that ISE manages.

Trust on the device

The device must trust the ISE EAP certificate, or it will not complete the secure connection. The supplicant profile installs the signer certificate for this. It must also trust the portal certificate, or the browser shows warnings.

For portals, a certificate from a well known public CA avoids most warnings. For the EAP certificate, a company CA is usual, because you control the trust on managed devices.

Matching the certificate in policy

During EAP-TLS, ISE needs to know which field holds the identity. A certificate authentication profile names the field.

It can also compare the certificate with the identity store, such as Active Directory. The authentication policy then uses the profile as its identity source.

Verify

Open the system certificates and check the usages, the names and the expiry dates. Open the issued certificates list to see the endpoint certificates. In the live logs, a failed EAP-TLS login shows a reason such as an unknown CA or an expired certificate.