Security

I have EAP-TLS based wireless access setup and my client device certificates contain two OCSP FQDNs. At present both FQDNs resolve to the same IP address and route through the same FW which isn't ideal. I wanted to setup one OCSP FQDN so it resolves to a different IP and route it via my DR data centre. There seems to be no documentation about if ClearPass can even handle OCSP fail over (eg primary/secondary). I wanted to confirm if ClearPass can handle failover so that should the first FQDN OCSP server not respond ClearPass tries the 2nd (Claude seems to think it can't and the HPE chatbot just doesn't have a clue).

If ClearPass can't then my next approach would be to anycast the OCSP IP address so that if the primary stops responding the route gets withdrawn and the route via my alternative DC becomes active.

The documented failover is OCSP to CRL, not OCSP to a second responder. The EAP-TLS authentication method has Required (CRL fallback), and the guide says if an OCSP server isn't accessible to perform certificate validation you can skip the OCSP check and proceed with the CRL validation result. That's the only unreachable-responder path documented.

The override is singular too. Override OCSP URL from the Client enables one OCSP URL field, described as the replacement URL. Nothing in the guide says how ClearPass treats a cert carrying two AIA URLs, so whether it tries the second is undocumented either way. Thin reed for a DR path.

Your anycast plan is the right instinct. Withdraw the route and the same FQDN and IP lands in the other DC, with nothing riding on undocumented behavior. I'd turn on CRL fallback as a backstop while you're in there.

------------------------------
Dustin Burns
@Worldcom Exchange, Inc.
www.wei.com

- - -
The comments I post here are my own, and not my employers
If my post was useful accept solution and/or give kudos
Personal Blog: www.networkfieldnotes.com
- - -
------------------------------

to the best of my knowledge ClearPass does not per  say have OCSP failover but once can use CRL fallback, this is a method for auth to fallback to CRL in case there is no response for OCSP. Without CRL fallback, an OCSP server not responding in time will result in auth failures

------------------------------
If my post was useful accept solution and/or give kudos.
Any opinions expressed here are solely my own and not necessarily that of HPE or Aruba.
------------------------------

Original Message:
Sent: Sep 17, 2026 04:06 PM
From: DB86
Subject: ClearPass OCSP fail-over behaviour

The documented failover is OCSP to CRL, not OCSP to a second responder. The EAP-TLS authentication method has Required (CRL fallback), and the guide says if an OCSP server isn't accessible to perform certificate validation you can skip the OCSP check and proceed with the CRL validation result. That's the only unreachable-responder path documented.

The override is singular too. Override OCSP URL from the Client enables one OCSP URL field, described as the replacement URL. Nothing in the guide says how ClearPass treats a cert carrying two AIA URLs, so whether it tries the second is undocumented either way. Thin reed for a DR path.

Your anycast plan is the right instinct. Withdraw the route and the same FQDN and IP lands in the other DC, with nothing riding on undocumented behavior. I'd turn on CRL fallback as a backstop while you're in there.

------------------------------
Dustin Burns
@Worldcom Exchange, Inc.
www.wei.com

- - -
The comments I post here are my own, and not my employers
If my post was useful accept solution and/or give kudos
Personal Blog: www.networkfieldnotes.com
- - -
------------------------------

Assuming you have configured two OCSP URLs within your certificates the timeout delay (5-10 seconds) for HTTP would be too slow for the RADIUS Authentication, this is why CP recommends CRL as the fallback method.

Thanks everyone for your input. Very helpful!

Original Message:
Sent: Sep 18, 2026 06:32 AM
From: DC-b8b0c5
Subject: ClearPass OCSP fail-over behaviour

Assuming you have configured two OCSP URLs within your certificates the timeout delay (5-10 seconds) for HTTP would be too slow for the RADIUS Authentication, this is why CP recommends CRL as the fallback method.