Wiki / General

Monitoring Cisco ISE, RADIUS & NPS

Last updated

Monitoring Cisco ISE, RADIUS & NPS Certificates

RADIUS servers and network-access platforms like Cisco ISE, Microsoft NPS, and FreeRADIUS don't have one certificate — they have several, each doing a different job, and most of them are nowhere near the admin web page you'd think to monitor. When one of them expires the failure is loud and network-wide: an expired EAP certificate breaks every Wi-Fi and wired 802.1X login at once, while the admin console keeps loading fine. This page explains which certificates these systems present, how CertTracker reaches each one, and how to set up complete coverage.

The one thing to understand first

On Cisco ISE (and most RADIUS platforms) a certificate is assigned a role — Admin, EAP Authentication, Portal, pxGrid, RADIUS DTLS, SAML. The role decides how the certificate is presented on the network, and that decides how CertTracker has to fetch it. A single certificate can fill several roles, or each role can have its own certificate. In practice they diverge: the EAP certificate is very often a separate, longer-lived certificate shared across all Policy Service Nodes, precisely so that renewing it doesn't force every device to re-onboard.

The practical consequence: monitoring the admin website on port 443 does not tell you whether your EAP certificate is about to expire. They're frequently different certificates. You need a monitor per role.

And because ISE is a distributed deployment, each node (PAN / PSN) presents its own certificates. Complete coverage is roles × nodes, not one monitor per appliance.

Cisco ISE certificate roles and how to monitor each

ISE role Where it lives How to monitor it
Admin HTTPS on TCP/443 Direct TLS monitor on node:443 (most people already have this)
Portal (guest, sponsor, BYOD, hotspot) HTTPS on TCP/8443 (portals can use any port in 8000–8999) One Direct TLS monitor per portal port, e.g. node:8443
pxGrid TLS on TCP/8910 Direct TLS monitor on node:8910 (see caveat below)
RadSec (RADIUS over TLS) TLS on TCP/2083 Direct TLS monitor on node:2083, if RadSec is enabled
RADIUS DTLS DTLS on UDP/2083 Not directly pollable yet — see the RADIUS DTLS caveat below
EAP Authentication Inside the EAP exchange over RADIUS UDP/1812 — never on an open port EAP / RADIUS monitor (this is the one that needs the private poller)
SAML In identity-provider metadata, not on the wire Not network-monitored

Most of these — Admin, Portal, pxGrid, RadSec — are ordinary TLS on a port. You cover them today by adding a Direct TLS monitor pointed at the right port on each node. No special configuration; the only trick is knowing the port for each role.

The two that need more attention are EAP Authentication (covered by the EAP monitor type, below) and RADIUS DTLS (a known gap, below).

The EAP certificate — the one that matters most

The EAP Authentication certificate is the one ISE presents to a laptop or phone during 802.1X (PEAP, EAP-TTLS, or EAP-TLS). It is never exposed on a listening port — it only appears inside the EAP conversation carried over RADIUS. That's why a normal TLS monitor can't see it, and why its expiry is such a common, painful outage: nothing you'd routinely check goes red until authentication itself starts failing for everyone.

CertTracker captures this certificate with an EAP / RADIUS monitor. It performs exactly enough of a RADIUS + EAP handshake for the server to present its certificate, reads it, and stops — it never actually authenticates, so no user account, password, or client certificate is required. The same monitor type works for Cisco ISE, Microsoft NPS, and FreeRADIUS, and for PEAP, EAP-TTLS, and EAP-TLS, because all three present the server certificate the same way up front.

What you need to set up an EAP monitor

  1. A private poller on the network that can reach the RADIUS server. EAP monitors run on your own private poller — never the shared public poller. Your RADIUS server isn't on the public internet, and the shared secret should never leave your premises, so CertTracker only ever assigns EAP monitors to a private poller you control.
  2. Authorize the poller as a RADIUS client (NAS). RADIUS servers reject requests from unknown clients before any EAP happens. Add the private poller's IP address as an authorized client / NAS on the RADIUS server, with a shared secret:
  3. Cisco ISE: Administration → Network Resources → Network Devices → Add the poller's IP with a RADIUS shared secret.
  4. Microsoft NPS: NPS console → RADIUS Clients → New, enter the poller's IP and a shared secret; make sure a Network Policy permits your EAP method (PEAP is enabled by default).
  5. FreeRADIUS: add a client { } block for the poller's IP in clients.conf.
  6. Enter the shared secret in CertTracker. When you create the monitor, paste the same shared secret. It's stored encrypted, shown as •••••• afterward, and only ever handed to the private poller you assigned — it's never displayed again or sent anywhere else.

EAP monitor fields

  • RADIUS auth port — defaults to 1812 (authentication, not 1813 accounting).
  • EAP method — Auto (accept whatever the server offers), or pin PEAP / EAP-TTLS / EAP-TLS.
  • Outer identity — defaults to anonymous; this is the unprotected identity sent before the tunnel, and it never needs to be a real account.
  • Shared secret — write-only; enter or replace it, never read it back.
  • Assigned private poller — required.
  • NAS-Identifier / NAS-IP (optional) — set these if your RADIUS policy keys on them to select the right network policy.

What CertTracker captures

Once the EAP handshake reaches the server certificate, an EAP monitor produces the same certificate metadata as any HTTPS monitor — Subject, Issuer, Serial, Signature Algorithm, public key, SANs, Valid From / Expiration, SHA-1 and SHA-256 fingerprints, and the negotiated TLS version. Everything downstream works identically: change detection writes to Change History, and expiration alerts fire at your per-monitor threshold through the same email pipeline. You'll see a small pill next to the monitor showing it's an EAP monitor and which method captured the certificate.

Recommended setup for a Cisco ISE deployment

For a two-node deployment (one PAN, one PSN) you'd typically end up with:

  • Admin — Direct TLS on pan:443 and psn:443
  • Portal — Direct TLS on psn:8443 (add one per additional portal port you use)
  • pxGrid — Direct TLS on pan:8910 (if you run pxGrid)
  • EAP Authentication — one EAP / RADIUS monitor per PSN that terminates 802.1X, via your private poller

If the same certificate fills several roles in your deployment, CertTracker will show the same certificate on each of those monitors — that's correct, and each monitor still has its own history and alerts.

Caveats

  • Admin ≠ EAP. This is the whole point of the page: do not assume a healthy :443 monitor means your EAP certificate is fine. Set up the EAP monitor separately.
  • RADIUS DTLS (UDP/2083) is not directly pollable yet. Cisco's "RADIUS DTLS" role uses datagram TLS over UDP — a different transport from RadSec's RADIUS-over-TLS on TCP/2083. CertTracker's TLS poller speaks TLS-over-TCP, so pointing a Direct TLS monitor at 2083 will not capture a DTLS-only certificate. In most deployments this is fine because Cisco recommends matching the RADIUS DTLS role to the Admin certificate per node — so your :443 monitor already tracks that same certificate. Only if you've assigned a dedicated certificate to RADIUS DTLS is it currently uncovered; support for a native DTLS probe is a planned enhancement.
  • pxGrid uses mutual TLS. pxGrid asks the client for a certificate, but the server presents its own certificate first, which is what CertTracker reads. If a pxGrid monitor reports a handshake error instead of a certificate, let support know — that endpoint may need the same special handling used for EAP.
  • RADIUS is UDP. If an EAP monitor times out, check (in order): the poller can reach the server on UDP/1812; the poller's IP is authorized as a RADIUS client; the shared secret matches exactly; and a network policy permits the EAP method you chose. A "server rejected our NAS IP"-style result almost always means step 2 was missed.
  • Modern RADIUS requires a Message-Authenticator. CertTracker always includes it (required by recent ISE and NPS hardening), so you don't need to configure anything for that — but very old RADIUS servers that reject it aren't supported.

Adding the monitors

  1. Monitors → + Add Monitor
  2. For Admin / Portal / pxGrid / RadSec: pick Direct TLS and set the port (443 / 8443 / 8910 / 2083).
  3. For the EAP certificate: pick EAP / RADIUS, choose the assigned private poller, enter the shared secret, and adjust the method/port/identity if needed.
  4. Add Monitor — the first poll fires within seconds.

Repeat per node. Once they're in, expiry alerts and change history work the same across every role — so the certificate that used to break your whole network silently now warns you weeks ahead, on the same schedule as everything else.