Wie richte ich auf einem Cisco Switch mit IOS-XE 17.15.05 einen Cisco-ISE-Trustpoint ein?

Question

Accepted Answer

**Einen ISE-Trustpoint richtest du auf IOS‑XE 17.15.05 nicht „für ISE allgemein“ ein, sondern immer für einen konkreten Zweck: entweder damit der Switch der ISE-CA vertraut, oder damit der Switch selbst ein Zertifikat von dieser CA bekommt. Genau dieser Unterschied entscheidet über die richtige Konfiguration.** ([cisco.com](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9500/software/release/17-15/configuration_guide/sec/b_1715_sec_9500_cg/x_509v3_certificates_for_ssh_authentication.html))

## Der entscheidende Unterschied

Für Cisco ISE gibt es in der Praxis meist **zwei** Trustpoint-Szenarien:

1. **CA-/Server-Trust für ISE**
   Der Switch importiert das Root-/Intermediate-Zertifikat der ISE-CA, damit er Zertifikate prüfen kann, etwa bei TLS-gesicherten RADIUS-Funktionen. Ein Trustpoint kann auf IOS XE eine CA-Zertifikatskette aufnehmen; die CA wird typischerweise mit `crypto pki authenticate` importiert. ([cisco.com](https://www.cisco.com/c/en/us/support/docs/security-vpn/public-key-infrastructure-pki/220422-configure-ca-signed-certificates-with-io.html))

2. **Identity-Zertifikat für den Switch**
   Der Switch erzeugt einen Schlüssel, erstellt eine CSR und bekommt von der ISE- bzw. angebundenen CA ein eigenes Zertifikat zurück. Das ist nötig, wenn der Switch sich selbst per Zertifikat gegenüber anderen Diensten ausweisen soll. Cisco beschreibt dafür den Ablauf aus Trustpoint, CA-Authentifizierung, Enrollment und Zertifikatsimport. ([cisco.com](https://www.cisco.com/c/en/us/support/docs/security-vpn/public-key-infrastructure-pki/220422-configure-ca-signed-certificates-with-io.html))

Typischer Fehler: Nur das ISE-Serverzertifikat zu importieren. Entscheidend ist fast immer die **CA-Kette**, nicht nur das Leaf-Zertifikat. IOS XE erwartet den Trust über den Trustpoint gegen die ausstellende CA. ([cisco.com](https://www.cisco.com/c/en/us/support/docs/security-vpn/public-key-infrastructure-pki/220422-configure-ca-signed-certificates-with-io.html))

## Minimaler Weg: ISE-CA als Trustpoint importieren

Wenn der Switch nur der ISE-Zertifikatskette vertrauen soll, ist das der übliche Grundaufbau:

```cisco
conf t
crypto key generate rsa general-keys label SW-ISE-KEY modulus 2048

crypto pki trustpoint ISE-CA
 enrollment terminal pem
 revocation-check none
 rsakeypair SW-ISE-KEY

crypto pki authenticate ISE-CA
-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----
end
```

`crypto pki authenticate ` ist auf IOS XE der Standardweg, um das CA-Zertifikat in den Trustpoint zu laden. Cisco dokumentiert genau diesen PKI-Ablauf in den 17.15.x-Sicherheitsleitfäden. ([cisco.com](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9200/software/release/17-15/configuration_guide/cts/b_1715_cts_9200_cg.pdf))

Wichtig dabei:

- **PEM-Format** verwenden, wenn du `enrollment terminal pem` nutzt. ([cisco.com](https://www.cisco.com/c/en/us/support/docs/security-vpn/public-key-infrastructure-pki/220422-configure-ca-signed-certificates-with-io.html))
- Bei einer Kette mit Root und Intermediate importierst du die **ausstellende Kette**, nicht nur das Endzertifikat der ISE. ([cisco.com](https://www.cisco.com/c/en/us/support/docs/security-vpn/public-key-infrastructure-pki/220422-configure-ca-signed-certificates-with-io.html))
- `revocation-check none` ist oft im Labor nötig, in Produktion aber nur sinnvoll, wenn CRL/OCSP wirklich nicht erreichbar oder nicht vorgesehen ist. Cisco unterstützt Revocation-Prüfungen explizit; dauerhaft abzuschalten ist funktional bequem, aber sicherheitlich die schwächere Lösung. ([cisco.com](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9500/software/release/17-15/configuration_guide/sec/b_1715_sec_9500_cg/configuring_authorization_and_revocation_of_certificates_in_a_pki.html))

## Wenn der Switch selbst ein Zertifikat bekommen soll

Dann reicht `authenticate` allein nicht. Du brauchst zusätzlich CSR und Import des ausgestellten Zertifikats:

```cisco
conf t
crypto key generate rsa general-keys label SW-ID-KEY modulus 2048

crypto pki trustpoint ISE-ID
 enrollment terminal pem
 subject-name CN=switch01.example.local,O=Firma,C=DE
 rsakeypair SW-ID-KEY
 revocation-check none

crypto pki authenticate ISE-ID
-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----

crypto pki enroll ISE-ID
```

Danach gibst du die CSR an deine CA/ISE weiter und importierst das ausgestellte Zertifikat:

```cisco
crypto pki import ISE-ID certificate
-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----
```

Cisco beschreibt genau diese Reihenfolge: Trustpoint anlegen, CA authentifizieren, enrollen bzw. CSR erzeugen und anschließend das Identity-Zertifikat importieren. ([cisco.com](https://www.cisco.com/c/en/us/support/docs/security-vpn/public-key-infrastructure-pki/220422-configure-ca-signed-certificates-with-io.html))

## Für ISE/RADIUS besonders wichtig

Wenn du den Trustpoint für **RADIUS over TLS / RadSec / TLS-gesicherte RADIUS-Funktionen** nutzt, muss der Trustpoint anschließend auch unter der RADIUS-Konfiguration referenziert werden. Cisco dokumentiert dafür, dass ein TLS-Trustpoint für Client und Server konfiguriert wird; wenn beide identisch sind, kann derselbe Trustpoint-Name verwendet werden. ([cisco.com](https://www.cisco.com/c/en/us/td/docs/switches/lan/c9000/sec-crypto/radius/radius-configuration-guide/radius.html))

Die praktische Konsequenz: Ein korrekt angelegter Trustpoint allein reicht nicht, wenn der Dienst ihn nicht benutzt. Viele Setups scheitern nicht am Zertifikat, sondern daran, dass der Trustpoint nirgends an RADIUS, HTTPS oder SSH gebunden wurde. ([cisco.com](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9500/software/release/17-15/configuration_guide/sec/b_1715_sec_9500_cg/configuring_secure_socket_layer_http.html))

## Kontrolle und typische Fehler

Prüfen solltest du mindestens:

```cisco
show crypto pki trustpoints
show crypto pki certificates
show crypto pki sessions
```

Wenn der Import geklappt hat, siehst du den Trustpoint und die Zertifikatskette dort wieder. Cisco nutzt diese PKI-Objekte systemweit für die jeweiligen Anwendungen. ([cisco.com](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9500/software/release/17-15/configuration_guide/sec/b_1715_sec_9500_cg/x_509v3_certificates_for_ssh_authentication.html))

Die häufigsten Fehler sind:

- falsches Zertifikat importiert, also Leaf statt CA
- PEM/Base64-Format fehlerhaft
- Subject Name passt nicht zur CA-Policy
- Trustpoint erstellt, aber nicht dem eigentlichen Dienst zugewiesen
- Revocation aktiviert, obwohl der Switch CRL/OCSP nicht erreichen kann ([cisco.com](https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9500/software/release/17-15/configuration_guide/sec/b_1715_sec_9500_cg/configuring_authorization_and_revocation_of_certificates_in_a_pki.html))

## Klare Empfehlung

Für Cisco ISE auf IOS‑XE 17.15.05 ist der sauberste Weg fast immer:

- **einen separaten Trustpoint für die ISE-CA-Kette**
- **einen separaten Trustpoint für das Geräte-Identity-Zertifikat**
- erst danach den passenden Dienst daran binden

Das ist besser als ein „Alles-in-einem“-Trustpoint, weil Fehlersuche, Erneuerung und Zertifikatswechsel deutlich sauberer bleiben. Cisco trennt in seiner PKI-Logik ebenfalls klar zwischen CA-Vertrauen, Enrollment und dienstbezogener Nutzung. ([cisco.com](https://www.cisco.com/c/en/us/support/docs/security-vpn/public-key-infrastructure-pki/220422-configure-ca-signed-certificates-with-io.html))