Aruba/HPE ClearPass
Copy link to the page “Aruba/HPE ClearPass”
Renews HTTPS and RADIUS/EAP certificates on selected ClearPass cluster nodes and roles, preserving other services.
What happens
- The appliance connects to Aruba/HPE ClearPass through ClearPass Policy Manager REST API on port 443.
- Discovery matches the served fingerprint to the certificate stored in the selected node role. HTTPS(RSA) and HTTPS(ECC) are observed separately. An unambiguous match and a backup with the matching private key precede any change. If it fails: An ambiguous node or role is left unchanged. The result names the information needed without keys, passwords or configuration dumps.
- The package imports certificate, key and intermediates as encrypted PKCS#12 into selected roles. ClearPass fetches it from a temporary address restricted to cluster nodes. Other certificate roles are preserved.
- Verification reads the role again and observes the served certificate. HTTPS uses TLS with SNI and checks the selected RSA or EC role. RADIUS uses an authenticated EAP-TLS, TTLS or PEAP exchange with correlated responses to verify the EAP server’s TLS identity; it does not complete client login. If it fails: Import or verification failure triggers automatic rollback of affected roles in reverse order. A later administrator change is preserved; the result reports any role that could not be restored.
Technical details
- Connection
- The package runs on the appliance, which connects over HTTPS to ClearPass Policy Manager REST API, port 443. No agent is installed.
- Service ports
- 443, 1812
- You need
- OAuth client ID and secret with cluster, certificate and extension inventory access and import rights for selected roles. Supply direct node addresses and service names. First adoption needs an encrypted PKCS#12 backup containing the current certificate and matching private key; later renewals use the protected backup retained on the appliance. RADIUS also needs an allowed RADIUS client, shared secret and the routing attributes your EAP policy uses.
- Platform
- ClearPass Policy Manager with the node-role server certificate REST API. API shapes are documented for 6.11 and 6.14.1; discovery selects behavior from available capabilities.
- Actions
- Discovery, Installation, Verification, Rollback
- Packages
-
aruba-clearpass-api - Note
-
- aruba-clearpass-api 1.0.0 is a signing candidate. Installation requires the signed package and a signed deployment-agent list containing this version. Signing and publication are handled separately.
- TLS checks CA and server name or an explicit whole-certificate SHA-256 pin. OAuth credentials and private keys stay out of URLs, command lines and shareable results. The appliance must reach each selected node directly, and nodes must be able to fetch the encrypted import file.
- Certificate Enrollment Manager (CEM) can renew one role across the cluster. When selected targets cover the whole affected CEM instance, the package takes over using its expiry-only setting and reloads the instance. Partial coverage without a supported scoped control is left unchanged. CEM is never deleted; other instances and services are preserved. Rollback restores affected renewal settings and instance execution state, preserving later administrator changes.
- RADIUS service-certificate overrides are preserved. An override sharing the default role fingerprint needs an unambiguous binding before a change. HTTPS or RadSec certificates do not establish which certificate EAP serves. Server_name follows your portal name or client EAP trust policy and defaults to the node address.
- Rollback uses retained protected backups or the supplied first-adoption export. Restoring renewal settings alone needs no certificate backup or file server. Old encrypted files remain available during activation and recovery; the temporary file server then closes. A lost import response is reconciled by readback and observation without repeating the import.
- The package retains initial backups and later managed certificates as encrypted PKCS#12 in a private appliance directory. CERTOPS_BACKUP_DIR can override ~/.sslbrain/aruba-clearpass-backups. Retain the directory in protected appliance backups; it contains protected credentials and must stay private. Selected certificate pins advance through verified renewals within the original connection and destination selection. RADIUS probes can appear as incomplete sessions in Access Tracker.
Certificate requirements
ClearPass has separate HTTPS(RSA) and HTTPS(ECC) roles and a RADIUS/EAP server certificate per node. The agent’s key choices are RSA 2048, 3072 or 4096 bits and ECDSA P-256 or P-384. The API’s CSR menu also includes EC 521 bits; 4096 and 521 are the largest documented CSR choices, not documented external-import maxima. The ClearPass 6.11 evaluated TLS configuration describes RSA 2048/3072/4096 and EC P-256/P-384. Public import sources specify no general minimum or maximum key size for each role.
Common Name (CN) is required when creating a CSR in ClearPass. The sources do not establish whether CN is mandatory for an externally issued server-certificate import. Compatibility with CN-less ACME profiles such as tlsserver and minimal is therefore undocumented. Use SANs matching the guest portal hostname and the clients’ EAP server-validation policy.
Use a server certificate for server authentication (serverAuth EKU). The checked import sources specify no mandatory clientAuth EKU or keyEncipherment KU for the HTTPS or RADIUS/EAP server certificate. The CEM guide’s clientAuth requirement applies to the certificate authenticating the EST client to its issuer, not the deployed server certificate. EAP clients have their own requirements; an unpublished import constraint is no guarantee of acceptance by every client or minimal profile.
Aruba discourages wildcard CN and EV certificates for RADIUS/EAP because some clients cannot authenticate with them. This is a recommendation, not a documented import ban. CEM can generate DNS and IP SANs; the checked sources specify no SAN-count maximum or general external-import IP-SAN rule. HTTPS and EAP server names must match the selected service and client configuration.
The ClearPass 6.12 import dialog accepts a certificate with a saved key, a PKCS#12 file (.pfx/.p12), or separate certificate and key files. P7b Base64 chains are unsupported for HTTPS and RADIUS/EAP. The role API in the checked 6.11 and 6.14.1 definitions fetches a certificate or PKCS#12 from a URL; new external keys are supplied in password-protected PKCS#12. The dialog specifies no PEM/DER limits, and JKS import is undocumented.
The checked sources publish no version-specific PFX import rule for AES versus 3DES/RC2 encryption. A legacy example does not establish an AES ban. The API sends the PFX passphrase in the request body. The 6.12 guide specifies the cluster password for cluster PKCS#12 imports; the sources do not establish that arbitrary passphrases work on every cluster version. Staging URLs must contain no login, token or password.
Supply the server certificate with its matching private key and required intermediates. Import sources specify no mandatory chain order or root inclusion. Agent packaging can place the leaf first, followed by intermediates toward the issuer; this is not a documented ClearPass requirement. A PKCS#12 server-certificate export contains the certificate, intermediates and private key. Certificate API readback provides no documented private key for rollback.
The role API selects the destination by node UUID and role name. The checked sources specify no PFX friendly-name or alias requirements, including characters or maximum length. A JKS alias must not be introduced as a ClearPass requirement.
Use a certificate valid at deployment time. The checked sources specify no ClearPass minimum or maximum validity period for external imports. Public CA rules and client validation apply separately and must not be described as a ClearPass import limit.