Wie richte ich ein Zertifikat für die Weboberfläche von Cisco Nexus Dashboard 3.2.2m ein?

**Für die Weboberfläche von Cisco Nexus Dashboard 3.2.2m richtest du das Zertifikat unter _Administrative → Security Configuration_ ein; entscheidend ist, dass Zertifikat, privater Schlüssel und die komplette CA-Kette zusammenpassen, sonst bleibt die GUI trotz Upload als „nicht vertrauenswürdig“ sichtbar.** ([cisco.com](https://www.cisco.com/c/en/us/td/docs/dcn/nd/3x/articles-321/nexus-dashboard-admin-321.html)) ## So gehst du in 3.2.2m vor 1. Melde dich als Admin an der Nexus-Dashboard-GUI an. 2. Öffne **Administrative → Security Configuration**. 3. Bearbeite dort den Bereich für das **System-/Web-Zertifikat** der Cluster-Oberfläche. In der 3.2.x-Dokumentation ist diese Seite ausdrücklich der Ort für die Sicherheitszertifikate des Clusters. ([cisco.com](https://www.cisco.com/c/en/us/td/docs/dcn/nd/3x/articles-321/nexus-dashboard-admin-321.html)) 4. Lade hoch bzw. hinterlege: - das **Server-Zertifikat** für die GUI - den **privaten Schlüssel** - die **CA-/Intermediate-Kette** 5. Speichern und die Übernahme abwarten. Danach die Weboberfläche **neu im Browser öffnen**. ## Was das Zertifikat enthalten muss Entscheidend ist nicht nur, dass das Zertifikat „gültig“ ist, sondern dass es **für einen Webserver ausgestellt** wurde und zum aufgerufenen Namen passt. Wichtig sind vor allem: - **CN/SAN** muss auf den FQDN passen, mit dem du das Dashboard aufrufst - bei moderner Prüfung ist **SAN** wichtiger als nur der Common Name - die **Extended Key Usage** sollte **TLS Web Server Authentication** enthalten oder darf nicht restriktiv falsch gesetzt sein - die **komplette Zertifikatskette** muss vorhanden sein, nicht nur das Leaf-Zertifikat ([cisco.com](https://www.cisco.com/c/en/us/td/docs/dcn/nd/4x/articles-421/managing-certificates.html)) ## Typische Fehler in der Praxis Der häufigste Fehler ist nicht der Upload selbst, sondern der **falsche Hostname**. Beispiel: Wenn dein Zertifikat auf `nd.example.local` ausgestellt ist, du die GUI aber über die **Management-IP** öffnest, meldet der Browser weiter einen Zertifikatsfehler. Das ist kein Cisco-Fehler, sondern ein **Namenskonflikt zwischen URL und Zertifikat**. Fast genauso häufig: - Zertifikat und Key gehören nicht zusammen - Intermediate-CA fehlt - PEM-Datei enthält falsche Reihenfolge - Zertifikat ist nur für Client-Auth statt Server-Auth ausgestellt ## Sinnvolle Vorbereitung vor dem Upload Prüfe das Zertifikat vorher lokal mit OpenSSL. Damit sparst du dir die meisten Fehlversuche: ```bash openssl x509 -in server.crt -noout -text openssl rsa -in server.key -check openssl x509 -noout -modulus -in server.crt | openssl md5 openssl rsa -noout -modulus -in server.key | openssl md5 ``` Wenn die beiden MD5-Ausgaben für Zertifikat und Schlüssel gleich sind, passen Key und Zertifikat zusammen. ## Wichtiger Unterschied zu neueren Dokus Viele aktuelle Cisco-Treffer führen auf **4.x-Dokumentation**. Die ist als Orientierung nützlich, aber für **3.2.2m** ist die maßgebliche Stelle die **3.2.x Admin-Doku** mit **Security Configuration**. Die neueren Zertifikatsartikel beschreiben zusätzlich strengere Validierungsdetails, die beim Planen eines neuen Zertifikats trotzdem hilfreich sind. ([cisco.com](https://www.cisco.com/c/en/us/td/docs/dcn/nd/3x/articles-321/nexus-dashboard-admin-321.html)) Für die 3.2.x-Oberfläche ist die relevante Cisco-Seite die [Administrative Tasks 3.2.x](https://www.cisco.com/c/en/us/td/docs/dcn/nd/3x/articles-321/nexus-dashboard-admin-321.html). Für die Zertifikatsanforderungen ist die Cisco-Seite zu [Managing Certificates](https://www.cisco.com/c/en/us/td/docs/dcn/nd/4x/articles-421/managing-certificates.html) nützlich.