NHPREP — Hands-On CCNA, CCNP, CCIE Labs & Networking Courses

Objective

In this lesson you will manage certificates for Cisco ISE: create CSRs, import signed certificates, preload trusted root/intermediate CAs, and renew certificates used for EAP, portal (HTTPS), admin (GUI/REST), and pxGrid. Certificate management is critical in production because EAP and pxGrid depend on mutual TLS and server authentication — without valid certs, clients cannot perform 802.1X authentication or devices cannot join pxGrid. Real-world scenario: a campus migration from a test PKI to an enterprise PKI where ISE must present certificates trusted by endpoints and by external systems (RADIUS clients, browsers, and pxGrid peers).

Quick Recap

This lesson continues from the topology used in Lesson 1. We add a management station and a Certificate Authority (CA) host for signing CSRs. New IPs introduced in this lesson:

ISE Primary PAN (administrative interface): 10.1.1.10
ISE PSN (policy services node): 10.1.1.11
Management workstation / CA client: 10.1.1.20
Internal Certificate Authority (HTTP/S for retrieval): ca.lab.nhprep.com (10.1.1.30)

ASCII topology (management-plane only; exact IPs shown on every interface):

[Mgmt Workstation] 10.1.1.20
      |
      | mgmt
      |
[Switch] (Vlan10)
      |
      +--[ISE PAN] 10.1.1.10 (admin GUI / certificate store)
      |
      +--[ISE PSN] 10.1.1.11 (RADIUS/EAP)
      |
      +--[Internal CA] ca.lab.nhprep.com 10.1.1.30 (sign CSRs / publish CA certs)

Domain used in examples: lab.nhprep.com

Admin passwords used in examples: Lab@123

Key Concepts

Server authentication certificate vs. client certificate
For EAP (802.1X) and for HTTPS portals, ISE must present a server certificate whose subject name matches what clients expect (SSID/portal FQDN) and which is chain-trusted by endpoints. pxGrid uses mutual TLS: both sides authenticate via certificates.
Certificate chain and trust anchors
Devices validate a certificate by building a chain to a trusted root. If the ISE certificate is issued by an intermediate CA, the intermediate(s) must be present on ISE and the root must be preloaded into endpoint trust stores. In ISE you must import both the server certificate and any intermediate(s), and preload root CA certs into the ISE trust store for client authentication and syslog (see note about “Trust for client authentication and Syslog”).
Validity and rollover
When renewing a certificate, the old certificate may still be bound to services until the new cert is uploaded and explicitly chosen for EAP/portal/pxGrid/admin. Plan maintenance windows and staged rollovers to prevent authentication outages.
Packet-level behavior
During EAP-TLS and PEAP (with server-side TLS), the supplicant validates the server certificate during the TLS handshake. If a cert is invalid, the handshake fails and the RADIUS exchange ends with Access-Reject or times out. For pxGrid, the TLS handshake must complete using mutually trusted certificates; failure prevents pxGrid sessions from being established.
Practical naming
Use meaningful CN/SANs. For EAP use the SSID or RADIUS server name clients are configured to trust (for example: ise.pan.lab.nhprep.com). For portal/admin, use FQDNs resolvable by clients and admins.

Step-by-step configuration

We will perform these core actions:

Generate a CSR on the management workstation for the PAN.
Submit CSR to the internal CA and retrieve signed certificate + chain.
Import the root and intermediate CA certificates into ISE trust store.
Import the signed server certificate into ISE and bind it to services (EAP, portal, admin).
Verify pxGrid and EAP certificate state and test a TLS handshake.

Each step includes commands, why they matter, and verification output.

Step 1: Generate CSR and private key on the management workstation

What we are doing: create a private key and Certificate Signing Request (CSR) for the ISE PAN administrative certificate. We do this off-box to retain control over the private key and to create a CSR acceptable to the enterprise CA. This CSR will be submitted to the internal CA for signing.

# Generate a 2048-bit private key and CSR for CN=ise.pan.lab.nhprep.com
openssl genrsa -out ise-pan.key 2048
openssl req -new -key ise-pan.key -out ise-pan.csr -subj "/C=US/ST=State/L=City/O=NHPREP/OU=NetOps/CN=ise.pan.lab.nhprep.com"

What just happened:

openssl genrsa created a 2048-bit RSA private key saved as ise-pan.key. This private key must remain secret — if leaked, impersonation is possible.
openssl req -new created a CSR (ise-pan.csr) containing the public key and identifying information (CN, O, OU). The CA will use this CSR to issue the signed certificate.

Real-world note: Many enterprises require CSRs to include Subject Alternative Names (SANs). If you need SANs, generate a CSR with an openssl config file that lists SubjectAltName entries.

Verify:

# Show CSR content to validate subject and public key info
openssl req -in ise-pan.csr -noout -text

Expected output (excerpt; full certificate request block shown):

Certificate Request:
    Data:
        Version: 1 (0x0)
        Subject: C=US, ST=State, L=City, O=NHPREP, OU=NetOps, CN=ise.pan.lab.nhprep.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:... (hex bytes)
                Exponent: 65537 (0x10001)
    Attributes:
        a0:00
-----BEGIN CERTIFICATE REQUEST-----
MIIC... (base64 contents)
-----END CERTIFICATE REQUEST-----

Step 2: Submit CSR to Internal CA and retrieve signed certificate + chain

What we are doing: send the CSR to the internal CA (ca.lab.nhprep.com) and download the signed certificate and any intermediates. The resulting certificate plus intermediates will be imported to ISE. Using an internal CA ensures endpoints trust the chain if their root cert is already trusted.

# Example: submit CSR via HTTP API or by copying the CSR to the CA host.
# For lab demonstration, request signing locally using openssl (CA files on CA host)
openssl x509 -req -in ise-pan.csr -CA ca-root.crt -CAkey ca-root.key -CAcreateserial -out ise-pan.crt -days 365 -sha256
# Display the issued cert
openssl x509 -in ise-pan.crt -noout -text

What just happened:

The CA signed the CSR producing ise-pan.crt valid for 365 days. In production this would be done by the enterprise CA workflow (approval, templates, issuance).
The signed certificate contains the public key and the CA’s signature verifiable by the CA root certificate.

Real-world note: In production you rarely have CA root keys accessible; signing occurs through CA servers and workflows (e.g., Microsoft CA web enrollment, EJBCA, or vendor PKI). The important part is obtaining the server certificate and any intermediate CA certificates in PEM/DER format.

Verify:

# Inspect full certificate details including issuer
openssl x509 -in ise-pan.crt -noout -text

Expected output (excerpt; full x509 text):

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1234567890
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=State, L=City, O=NHPREP CA, CN=NHPREP Root CA
        Validity
            Not Before: Apr  1 00:00:00 2026 GMT
            Not After : Mar 31 23:59:59 2027 GMT
        Subject: C=US, ST=State, L=City, O=NHPREP, OU=NetOps, CN=ise.pan.lab.nhprep.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
...
-----BEGIN CERTIFICATE-----
MIIF... (base64 contents)
-----END CERTIFICATE-----

Also ensure you have the intermediate(s) (if any), e.g. intermediate.crt and the root ca-root.crt.

Step 3: Import root and intermediate CA certificates into ISE trust store

What we are doing: upload the CA root certificate and any intermediate certificates into ISE so ISE can present the full chain and validate client certificates. ISE also needs the root certificate in its trust store to validate client authentication and to allow services (e.g., Syslog) to verify upstream TLS peers.

# Example: copy certificates to ISE via SCP (management workstation to ISE)
scp ca-root.crt admin@10.1.1.10:/tmp/ca-root.crt
scp intermediate.crt admin@10.1.1.10:/tmp/intermediate.crt

# On the ISE appliance CLI (simple file move to the certificate store; GUI import performed later)
# Move to expected directory (example)
sudo mv /tmp/ca-root.crt /data/ca-certificates/ca-root.crt
sudo mv /tmp/intermediate.crt /data/ca-certificates/intermediate.crt

What just happened:

The root and intermediate certs were transferred to the ISE PAN appliance. In ISE you then import them into the CERTIFICATES > Trusted Certificates area via the GUI and mark trust for client authentication where appropriate (e.g., “Trust for client authentication and syslog”).

Real-world note: Preloading trusted root certificates (e.g., vendor manufacturer certs for phones/printers and your internal root) reduces client failures for certificate-based authentication and simplifies troubleshooting.

Verify:

# On the ISE CLI list the certificates copied
ls -l /data/ca-certificates/
# Show the root certificate text
openssl x509 -in /data/ca-certificates/ca-root.crt -noout -text

Expected output:

# ls -l /data/ca-certificates/
-rw-r--r-- 1 root root 1675 Apr  1 12:00 ca-root.crt
-rw-r--r-- 1 root root 1820 Apr  1 12:01 intermediate.crt

# openssl x509 -in /data/ca-certificates/ca-root.crt -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 987654321
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=State, L=City, O=NHPREP CA, CN=NHPREP Root CA
        Subject: C=US, ST=State, L=City, O=NHPREP CA, CN=NHPREP Root CA
        Validity
            Not Before: Jan  1 00:00:00 2025 GMT
            Not After : Jan  1 00:00:00 2028 GMT
...
-----BEGIN CERTIFICATE-----
MIIC... (base64)
-----END CERTIFICATE-----

After copying, use the ISE admin GUI (Administration → System → Certificates → Trusted Certificates) to import these files and check the box for “Trust for client authentication and syslog” for the root certs.

Step 4: Import issued server certificate into ISE and bind to services

What we are doing: Import the signed server certificate (ise-pan.crt) along with the private key (ise-pan.key) into the ISE certificate store and then assign that certificate to specific services: Admin (admin portal and REST API), Portal (Guest/Host/Guest flows), and EAP (RADIUS/802.1X). Binding ensures ISE presents this cert during TLS handshakes.

# Copy signed cert and private key to ISE
scp ise-pan.crt admin@10.1.1.10:/tmp/ise-pan.crt
scp ise-pan.key admin@10.1.1.10:/tmp/ise-pan.key

# Move to certificate import location on ISE
sudo mv /tmp/ise-pan.crt /data/certs/ise-pan.crt
sudo mv /tmp/ise-pan.key /data/certs/ise-pan.key

# (GUI step) In the ISE Admin GUI: Administration → System → Certificates → System Certificates
#   - Import: upload the certificate and private key pair (ise-pan.crt + ise-pan.key)
#   - When prompted, provide the private key password if any (not used here)
#   - After import, select the certificate and choose Actions → Bind Services
#   - Bind to: Admin, Portal, EAP, and pxGrid as required

What just happened:

The server certificate and private key were made available on the PAN. Importing into System Certificates allows ISE to use the certificate for TLS handshakes. Binding explicitly ties the certificate to the named services — only the bound certificate is offered during TLS negotiations for that service.

Real-world note: When binding certificates to EAP, ensure the CN or SAN(s) match the name configured on clients or SSIDs. If clients expect ise.pan.lab.nhprep.com and the cert CN is different, EAP will fail during server validation.

Verify:

# On ISE CLI show presence of certificate file
ls -l /data/certs/ise-pan.*
# Verify certificate details
openssl x509 -in /data/certs/ise-pan.crt -noout -text

# Example: verify service binding in ISE via REST (GUI verification also acceptable)
# curl -k -u admin:Lab@123 https://10.1.1.10:9060/ers/config/certholder | sed -n '1,150p'

Expected output (file listing + certificate display):

# ls -l /data/certs/ise-pan.*
-rw-r--r-- 1 root root 1675 Apr  1 12:10 /data/certs/ise-pan.crt
-rw------- 1 root root 1679 Apr  1 12:09 /data/certs/ise-pan.key

# openssl x509 -in /data/certs/ise-pan.crt -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1234567890
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=State, L=City, O=NHPREP CA, CN=NHPREP Root CA
        Subject: C=US, ST=State, L=City, O=NHPREP, OU=NetOps, CN=ise.pan.lab.nhprep.com
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:ise.pan.lab.nhprep.com, DNS:ise.lab.nhprep.com
...
-----BEGIN CERTIFICATE-----
MIIF... (base64 contents)
-----END CERTIFICATE-----

Confirm via GUI binding that Admin, Portal, and EAP services have the new certificate selected.

Step 5: Verify EAP and pxGrid TLS handshakes

What we are doing: validate that ISE presents the correct certificate during TLS handshakes for EAP (simulate with openssl s_client against RADIUS/EAP TLS port) and that pxGrid certificate is present. This confirms the chain is complete and the server cert is served.

# Test HTTPS admin portal certificate served by ISE (HTTPS usually on 443 or 9060 for ERS; use 443 for user portal)
openssl s_client -connect 10.1.1.10:443 -servername ise.pan.lab.nhprep.com -showcerts
# Test RADIUS/TLS (EAP) server certificate — EAP uses port 1812 for RADIUS; TLS handshake can be tested if EAP-TLS proxy supports TLS on a test port. For portal, use HTTPS as above.

What just happened:

openssl s_client performed a TLS handshake with the ISE admin/portal service and printed the certificate chain the server presented. You can inspect the server cert, verify issuer, and ensure the full chain (intermediate + root if sent) is visible.

Real-world note: Some ISE configurations intentionally do not send the root cert in the chain (best practice is to send intermediates but not the root). Ensure endpoints have the root cert in their trust store and that intermediates are served by ISE.

Verify:

# Expected snippet from the openssl s_client output showing server cert and chain
CONNECTED(00000003)
depth=2 C = US, ST = State, L = City, O = NHPREP CA, CN = NHPREP Root CA
verify return:1
depth=1 C = US, ST = State, L = City, O = NHPREP CA, CN = NHPREP Intermediate CA
verify return:1
depth=0 C = US, ST = State, L = City, O = NHPREP, OU = NetOps, CN = ise.pan.lab.nhprep.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=State/L=City/O=NHPREP/OU=NetOps/CN=ise.pan.lab.nhprep.com
   i:/C=US/ST=State/L=City/O=NHPREP CA/CN=NHPREP Intermediate CA
-----BEGIN CERTIFICATE-----
MIIF... (server cert)
-----END CERTIFICATE-----
 1 s:/C=US/ST=State/L=City/O=NHPREP CA/CN=NHPREP Intermediate CA
   i:/C=US/ST=State/L=City/O=NHPREP CA/CN=NHPREP Root CA
-----BEGIN CERTIFICATE-----
MIIF... (intermediate cert)
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/ST=State/L=City/O=NHPREP/OU=NetOps/CN=ise.pan.lab.nhprep.com
issuer=/C=US/ST=State/L=City/O=NHPREP CA/CN=NHPREP Intermediate CA
---
SSL handshake has read 3456 bytes and written 512 bytes
---

If the certificate chain looks correct and verification returns success, EAP clients and browsers should trust the ISE server certificate (given endpoints trust the root CA).

Verification Checklist

Check 1: CSR generated with correct CN/SAN for ise.pan.lab.nhprep.com. Verify with openssl req -in ise-pan.csr -noout -text.
Check 2: Root and intermediate CA certificates are present on the PAN and marked trusted for client authentication and syslog. Verify with ls -l /data/ca-certificates/ and certificate inspection.
Check 3: Signed server certificate is imported and bound to Admin, Portal, and EAP services. Verify binding via the ISE GUI or REST and confirm with openssl s_client -connect 10.1.1.10:443 -servername ise.pan.lab.nhprep.com -showcerts showing the correct cert and chain.

Common Mistakes

Symptom	Cause	Fix
Clients see EAP TLS failures and timeouts	ISE certificate CN/SAN does not match the expected server name configured on supplicants or RADIUS clients	Reissue certificate with correct CN/SAN matching the name clients expect (e.g., ise.pan.lab.nhprep.com) and bind to EAP
Browsers show certificate not trusted for portal pages	Root CA not trusted on the client or ISE did not include intermediate chain	Import root CA into client trust store or ensure intermediate certificates are imported into ISE and sent in the chain
pxGrid peers fail mutual TLS	pxGrid certificate not bound or pxGrid client cert missing/expired	Ensure pxGrid certificate is valid, bound to pxGrid service, and that pxGrid peers have the CA trust anchors
After renewal, services still present old certificate	New certificate uploaded but not bound to services	Re-bind the new certificate to Admin/Portal/EAP/pxGrid in ISE and restart services if required

Key Takeaways

Certificates are foundational for EAP, portal HTTPS, admin GUI/REST, and pxGrid: if certs are invalid or mismatched, authentication and integrations will fail.
Always include correct CN and SAN values for the names clients and services expect, and preload root certificates for device manufacturers and internal PKI roots to reduce failures.
Import intermediates into ISE and mark roots as trusted for client authentication and syslog; verify the full chain using openssl s_client.
When renewing certificates, plan a controlled rollover: import the new cert, bind it to services, and validate TLS handshakes before decommissioning the old certificate.

Tip: Keep a certificate inventory (expiration dates, SANs, issuer) and enable alerts for expiry. This prevents unexpected outages from expired ISE certificates.

If you want, the next lesson will cover integrating ISE with an enterprise CA (web enrollment) and automating certificate renewal for multiple nodes (PAN, PSN, pxGrid).

ISE Certificate Management

Objective

Quick Recap

Key Concepts

Step-by-step configuration

Step 1: Generate CSR and private key on the management workstation

Step 2: Submit CSR to Internal CA and retrieve signed certificate + chain

Step 3: Import root and intermediate CA certificates into ISE trust store

Step 4: Import issued server certificate into ISE and bind to services

Step 5: Verify EAP and pxGrid TLS handshakes

Verification Checklist

Common Mistakes

Key Takeaways