Certificate Expired at 2 AM. Authentication Failed. CEO Can't Get WiFi.

If you've been there, you know the pain.

ISE certificate issues are the #1 cause of unexpected outages. Not bugs. Not hardware. Expired certificates.

Here's what actually works—from someone who spent years fixing these failures for customers who thought certificates were "set and forget."

Why ISE Certificate Management Matters (More Than You Think)

ISE uses certificates for EVERYTHING:

• HTTPS admin portal
• EAP-TLS authentication
• RADIUS communication
• Node-to-node replication
• API integrations
• Guest portals

One expired cert? The whole thing can fail. And you won't know until users start calling.

The Certificate Types You Need to Know

1. System Certificates (ISE talking to ISE)

• Used for admin HTTPS portal
• Used for replication between nodes
• Automatically created during install (but self-signed)

Problem: Self-signed = browser warnings + not trusted

Fix: Replace with CA-signed cert immediately after deployment

2. EAP Certificates (ISE talking to endpoints)

• Used for 802.1X EAP-TLS authentication
• Presented to clients during auth
• Must be trusted by endpoints

Critical: If this expires, authentication STOPS. For everyone.

3. RADIUS DTLS Certificates (ISE talking to controllers)

• Used for encrypted RADIUS communication
• Between ISE and wireless controllers
• Optional but recommended

4. pxGrid Certificates (ISE talking to other security tools)

• For ISE→SIEM integration
• For ISE→Firewall integration
• For threat intelligence sharing

Bottom line: Lots of certs. Lots of expiration dates. Lots of ways to fail.

The "Self-Signed is Fine" Myth

Fresh ISE install comes with self-signed certificates. Cisco even walks you through it.

"We'll fix it later."

Then two years later, that cert expires. You had no monitoring. No alerts. First sign of trouble? Authentication failures.

What to do instead:

Day 1 (or day 2 at latest):

1. Set up internal CA or get commercial CA ready
2. Generate Certificate Signing Requests (CSRs) from ISE
3. Get certs signed by CA
4. Import and bind to ISE
5. Delete self-signed certs
6. Test everything

It's 30 minutes of work that prevents days of outages.

Certificate Planning Before Deployment

Answer these BEFORE you deploy ISE:

1. Internal CA or Commercial CA?

Internal CA (e.g., Microsoft CA):

• ✅ Free
• ✅ Automated renewal possible
• ✅ Full control
• ❌ Requires PKI infrastructure
• ❌ Must deploy root CA to all endpoints

Commercial CA (e.g., DigiCert, Let's Encrypt):

• ✅ Already trusted by endpoints/browsers
• ✅ No PKI infrastructure needed
• ❌ Costs money
• ❌ Manual renewal

My take: Internal CA for most enterprises. Commercial for guest/BYOD only.

2. SAN Certificates or Individual Certificates?

Subject Alternative Name (SAN) certificate:

• One cert covers multiple hostnames
• Example: ise1.company.com, ise2.company.com, ise.company.com
• Easier to manage

Individual certificates:

• One cert per node
• More work to renew
• But isolated if one node fails

Recommendation: SAN for admin certs, individual for EAP if you want maximum isolation.

3. Wildcard Certificates?

*.company.com - covers any hostname.

Pros:

• One cert for everything
• Easy renewals

Cons:

• Security risk if compromised
• Not recommended by Cisco for EAP
• Some clients don't like wildcards

Use case: Guest portals, admin access. NOT for production 802.1X.

The Certificate Lifecycle

###Step 1: Generate CSR (Certificate Signing Request)

From ISE GUI:

1. Administration → Certificates → Certificate Signing Requests
2. Generate Certificate Signing Request
3. Fill out:
   • Common Name (CN): FQDN of ISE node
   • Organization
   • Country
   • SAN (if multiple names)
4. Select key length: 2048 minimum, 4096 recommended
5. Select digest: SHA-256 minimum

Critical: CN MUST match FQDN. Not IP. Not short name. FQDN.

Step 2: Get CSR Signed

Take the CSR to your CA:

• Microsoft CA web enrollment
• Commercial CA portal
• Internal PKI team

Template matters:

• Web Server template for admin certs
• EAP template for auth certs
• Make sure template includes correct key usage

Step 3: Import Signed Certificate

Before importing:

• Verify you have the ROOT CA certificate
• Verify you have any INTERMEDIATE CA certificates
• Chain must be complete

Import order:

1. Root CA first
2. Intermediate CAs next
3. ISE certificate last

Bind to correct usage:

• Admin? Check "Admin"
• EAP? Check "EAP Authentication"
• Portal? Check "Portal"
• pxGrid? Check "pxGrid"

Test immediately:

• Browse to ISE admin (https://ise.company.com)
• Should show valid cert, no warnings
• Test authentication with one client

Step 4: Delete Old Certificates

Don't leave expired/unused certs lying around.

Before deleting:

• Verify new cert works
• Have rollback plan
• Do this during maintenance window

Delete:

• Old self-signed certs
• Expired certs
• Unused certs

Common Certificate Mistakes (That Break Everything)

Mistake #1: Incomplete Certificate Chain

You imported the ISE cert. Authentication works... on some devices. Not others.

Cause: Missing intermediate CA cert

Fix:

• Export FULL chain from CA
• Import Root + All Intermediates into ISE
• Verify with: openssl s_client -connect ise.company.com:443 -showcerts

Mistake #2: Wrong Common Name

CN = ise but clients connect to ise.company.com

Certificate doesn't match hostname. Auth fails.

Fix: CN MUST be FQDN. Always.

Mistake #3: Forgetting SAN for Load Balanced VIP

You load balance ISE PSNs behind ise-auth.company.com

Each PSN cert has its own hostname. VIP isn't in SAN.

Clients connect to VIP. Cert doesn't match. Auth fails.

Fix: Add VIP to SAN on ALL PSN certs.

Mistake #4: Not Monitoring Expiration

Certs expire. You forget. Everything breaks at once.

Fix: Set up monitoring NOW:

• ISE built-in cert expiry alerts
• External monitoring (Nagios, PRTG, etc.)
• Calendar reminders 90 days before expiry
• Automated email alerts

Mistake #5: No Test Environment for Renewal

You need to renew certs. But you've never done it before.

Do you really want to learn in production?

Fix: Lab environment. Practice renewal. Document the process. Then do it in production.

Certificate Renewal Without Downtime

Here's the process that doesn't break auth:

For Admin Certificates (Easy):

1. Generate new CSR (90 days before expiry)
2. Get new cert signed
3. Import new cert
4. Bind to Admin use
5. Test admin portal works
6. Delete old cert
7. Done

Downtime: Zero. Admin portal might hiccup for 5 seconds.

For EAP Certificates (Requires Planning):

Option 1: Staged Renewal (No Downtime)

1. Have both old and new certs active simultaneously
2. Import new cert 30 days before expiry
3. Bind to EAP (both certs now active)
4. Monitor - clients will use new cert automatically
5. After 7 days, delete old cert

Option 2: Maintenance Window

1. Schedule maintenance window
2. Import new cert
3. Delete old cert immediately
4. Force wireless client re-auth
5. Monitor for failures

I recommend Option 1. No outage. No panic.

Troubleshooting Certificate Issues

"Certificate is Invalid" Error

Check:

1. Is cert expired?
   • openssl x509 -in cert.pem -noout -dates
2. Does CN match hostname?
3. Is certificate chain complete?
4. Is Root CA trusted by client?

"Certificate Not Yet Valid" Error

Server time wrong. Seriously.

ISE time != Real time = Certs appear invalid

Fix: NTP. Always use NTP.

Clients Can't Validate Certificate

Check client trust store:

• Windows: certmgr.msc → Trusted Root CAs
• Mac: Keychain Access → System Roots
• Linux: /etc/ssl/certs/

Is your Root CA there? If not, clients can't validate ISE cert.

Some Clients Work, Others Don't

Usually:

• Incomplete cert chain
• Missing intermediate CA
• Some clients have root CA, others don't

Fix: Import ALL intermediates into ISE.

Advanced: Certificate Automation

SCEP (Simple Certificate Enrollment Protocol)

ISE can auto-enroll devices with certificates via SCEP.

Use case: BYOD onboarding, automated cert distribution

Setup:

1. Configure SCEP profile in ISE
2. Point to your CA's SCEP endpoint
3. Create provisioning policy
4. Users get certs automatically during onboarding

Caveat: Requires CA with SCEP support (Microsoft NDES, etc.)

Certificate Auto-Renewal

ISE can't auto-renew its own certs (unfortunately).

Workaround:

• Script the renewal process
• Use ACME protocol if compatible
• Monitor expiry, trigger renewal workflow

Not perfect. But better than manual.

Certificate Best Practices Checklist

Before Deployment:

• [ ] CA infrastructure ready (internal or commercial)
• [ ] Certificate template designed
• [ ] SAN planning complete
• [ ] Renewal process documented

During Deployment:

• [ ] Replace self-signed certs immediately
• [ ] Import complete certificate chain
• [ ] Verify CN matches FQDN
• [ ] Test with real clients
• [ ] Document what cert is used where

Post-Deployment:

• [ ] Set up expiry monitoring (90-day warning)
• [ ] Calendar reminders for renewal
• [ ] Test renewal process in lab
• [ ] Document renewal procedure
• [ ] Assign cert renewal owner

Quarterly:

• [ ] Review cert expiration dates
• [ ] Verify monitoring is working
• [ ] Test alert notifications
• [ ] Update documentation

Real-World Certificate Horror Stories

Story 1: The Friday Night Meltdown

Customer called. 5 PM Friday. Nobody can authenticate.

Root cause? EAP cert expired at 4:58 PM that day.

They had no monitoring. First sign of trouble? Help desk phone ringing off the hook.

Fix took 3 hours:

• Emergency CSR generation
• Wait for CA team to sign (they went home)
• Import new cert
• Test and verify
• Send all-clear

Lesson: Monitor expiry. Set alerts for 90 days out.

Story 2: The Partial Outage Nobody Understood

Some users could authenticate. Others couldn't. No pattern.

Turned out: Incomplete certificate chain.

iOS devices worked (they cached intermediate CA).
Windows laptops didn't (fresh validation every time).

Fix: Import intermediate CA into ISE. 5 minutes.

Lesson: Always import the full chain.

Story 3: The "We Renewed But It Still Broke" Mystery

Customer renewed cert properly. Imported to ISE. Bound to EAP.

Authentication still failing.

Problem: They forgot to delete the old expired cert.

ISE was presenting BOTH certs. Some clients got old one, failed.

Fix: Delete old cert. Done.

Lesson: Clean up after renewal.

Tools That Help

OpenSSL Commands I Use Daily:

View certificate details:

openssl x509 -in cert.pem -text -noout

Check expiration:

openssl x509 -in cert.pem -noout -enddate

Test ISE cert from client:

openssl s_client -connect ise.company.com:443 -showcerts

Verify cert chain:

openssl verify -CAfile root.pem -untrusted intermediate.pem cert.pem

ISE Certificate Heath Check:

Built into ISE (finally):

• Operations → Troubleshoot → Download Logs
• Select: Certificate Health Check Report

Shows:

• All certs in use
• Expiration dates
• Chain validation
• Binding status

Run this monthly.

When to Call for Help

Certificate issues CAN be simple. They can also spiral into multi-day nightmares.

Call an expert if:

• You've never done PKI before
• Your CA infrastructure is complex
• You have multiple ISE deployments
• Wildcard certs are involved
• You're not sure about SAN

Better to get it right the first time than fix it in production.

Need help?

• ISE Deployment Services - We handle certs correctly from day one
• MINT Program - Your team learns cert management during deployment

The Bottom Line

Certificates aren't glamorous. But they're critical.

30 minutes of planning prevents days of outages.

Set up monitoring. Document renewal. Practice in lab. Sleep better.

Written from TAC experience debugging hundreds of certificate-related ISE outages. These aren't theoretical best practices—this is what actually prevents 3 AM emergencies.