Cisco Catalyst 9800

1. Prepare the target and certificate

Open Deploy → Agentless connectors, configure a Cisco WLC target and select Catalyst 9800. The ens0key server needs SSH access and HTTPS access to the controller. Keep a verified SSH recovery path and a copy of the current service-to-trustpoint references.

Use a certificate with a matching private key, complete issuing chain, valid dates, Server Authentication and the intended DNS/IP SANs. The tested lab path uses an RSA leaf and RSA issuing CA. Selecting an RSA leaf does not change the CA signing key. Follow the Windows ADCS guide for template preparation and issuance.

2. Configure Binding

• ▸Services: choose WebAdmin, WebAuth or both. Saving changes configures the next explicit deployment; it does not deploy to the controller.
• ▸PKCS#12 profile: explicitly select Modern AES / SHA-256 for the IOS-XE 17.12.1+ recipe. Existing omitted profiles retain Legacy; there is no automatic profile retry against live trustpoints.
• ▸Transfer: HTTPS upload is the default from 1.0.31, including existing Catalyst targets with no explicit transport. SSH key-only credentials do not authenticate the WebUI upload; the controller account needs HTTPS login access too.
• ▸WebAuth verification: set the actual portal URL if you want TLS/HTTP health checked. Without a URL, the result verifies the binding only.

ens0key 1.0.33 · Ogledni podaci

3. Verify device trust

Pin the SSH host key. For HTTPS, configure system/public CA trust, a private CA with the correct DNS/SNI, or an independently verified exact leaf fingerprint. These settings authenticate the controller's currently served certificate, before sending its replacement.

An administrator can use Fetch device certificate to view public metadata without sending credentials or a bundle. Compare its SHA-256 fingerprint through the controller console or another trusted channel, then confirm the identity and save. Fetching alone does not verify trust. Advanced options provide CA, DNS/SNI and manual fingerprint fields.

4. Deploy and confirm the result

Choose Deploy and select the issued certificate. The server snapshots the selected running/startup bindings and management state; ambiguous state stops the operation before upload. It uploads a fresh encrypted PKCS#12 to bootflash over HTTPS and imports it over pinned SSH.

The connector checks the imported leaf and RSA key association before changing service bindings. Version 1.0.33 rejects a failed or ambiguous RSA association, with no automatic EC-key removal. WebAdmin deployment restarts management HTTPS and checks the exact intended TLS leaf and WebUI response before saving configuration. Temporary deployment-owned files are deleted and their absence checked.

Read the deployment result and Log. Independently open WebAdmin with the intended SAN name/IP and verify certificate identity and client trust. Import success alone does not establish service health. WebAuth binding verification does not establish a working guest portal unless that portal is actually checked.

5. Recovery and interrupted deployments

From 1.0.32, a durable recovery record tracks selected service state. CLI, readback, TLS, SSH or uncertain-save failures trigger recovery over a fresh pinned SSH connection. Recovery checks the prior exact TLS identity and HTTP service, and restores/readbacks selected startup bindings when a save was uncertain. Interrupted records are retried on server startup and periodically; pending records protect target deletion.

Network or device loss can leave recovery pending. Changed target addresses, SSH pins or unrelated later bindings require manual review. Inspect the record and device before retrying. Prior trustpoints are retained; remove a label only after checking all controller consumers. File deletion is not forensic erasure of flash.

Compatibility and scope

HTTPS upload uses a firmware-specific WebUI interface. Lab Catalyst 9800-CL IOS-XE 17.12.7a has positive RSA/RSA WebAdmin and failure-recovery evidence; other firmware, chains and actual guest portals need their own acceptance. A 1.0.30 import failure on 17.12.6a is not a successful compatibility result. The 1.0.31 recovery issue is addressed in 1.0.32; use the current release for the additional RSA-association checks.

Explicit legacy HTTP requires acknowledgement and a restricted source; it uses a temporary per-deployment URL. There is no automatic insecure fallback. AireOS retains its TFTP flow, one service and Legacy profile; the Catalyst HTTPS and durable-recovery claims do not apply to it. Versions 1.0.30–1.0.33 do not require a native agent or helper upgrade for these agentless changes.