CSR generieren und Zertifikate auf CMS anwenden

Einleitung

In diesem Dokument wird beschrieben, wie Sie eine CSR-Anforderung (Certificate Signing Request) generieren und signierte Zertifikate in Cisco Meeting Server (CMS) hochladen.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• Grundkenntnisse des CMS-Servers

Verwendete Komponenten

Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

• Putty oder ähnliche Software
• CMS 2.9 oder spätere Version

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

CSR erstellen

Es gibt zwei Möglichkeiten, CSR zu generieren. Eine Möglichkeit besteht darin, den CSR direkt auf dem CMS-Server über die Befehlszeilenschnittstelle (CLI) mit Administratorzugriff zu generieren. Die andere besteht darin, dies mit einer externen Zertifizierungsstelle eines Drittanbieters (Certificate Authority, CA) wie Open SSL zu tun.

In beiden Fällen muss der CSR mit der richtigen Syntax generiert werden, damit die CMS-Dienste ordnungsgemäß funktionieren.

Schritt 1: Syntaxstruktur

pki csr <key/cert basename> <CN:value> [OU:<value>] [O:<value>] [ST:<-value>] [C:<value>] [subjectAltName:<value>]

• <key/cert basename> ist eine Zeichenfolge, die den neuen Schlüssel und den CSR-Namen identifiziert. Es kann alphanumerische Zeichen, Bindestriche oder Unterstriche enthalten. Dies ist ein Pflichtfeld.
• <CN:value> ist der gebräuchliche Name. Hierbei handelt es sich um den vollqualifizierten Domänennamen (FQDN), der den genauen Standort des Servers im Domain Name System (DNS) angibt. Dies ist ein Pflichtfeld.
• [OU:<Wert>] ist der Name der Organisationseinheit oder Abteilung. Beispiele: Support, IT, Techniker, Finanzen. Dies ist ein optionales Feld.
• [O:<Wert>] ist der Name der Organisation oder des Unternehmens. In der Regel der gesetzlich eingetragene Name einer Firma. Dies ist ein optionales Feld.
• [ST:<Wert>] ist die Provinz, Region, Region oder das Bundesland. Zum Beispiel Buckinghamshire California. Dies ist ein optionales Feld.
• [C:<Wert>] ist das Land. Der zweistellige ISO-Code (International Organization for Standardization) für das Land, in dem Ihre Organisation ansässig ist. Beispiel: USA, GB, FR. Dies ist ein optionales Feld.
• [subjectAltName:<Wert>] ist der alternative Name (SAN) des Antragstellers. Ab X509 Version 3 (RFC 2459) ist es SSL-Zertifikaten (Secure Socket Layers) gestattet, mehrere Namen anzugeben, mit denen das Zertifikat übereinstimmen muss. In diesem Feld kann das generierte Zertifikat mehrere Domänen abdecken. Er kann IP-Adressen, Domänennamen, E-Mail-Adressen, reguläre DNS-Hostnamen usw. enthalten, die durch Kommas getrennt sind. Wenn es angegeben ist, müssen Sie auch den CN in diese Liste aufnehmen. Obwohl es sich um ein optionales Feld handelt, muss das SAN-Feld ausgefüllt werden, damit XMPP-Clients (Extensible Messaging and Presence Protocol) ein Zertifikat akzeptieren können. Andernfalls zeigen die XMPP-Clients einen Zertifikatfehler an.

Schritt 2: Generieren von Callbridge, SMPP, Webadmin und Webbridge CSR

1. Rufen Sie die CMS-CLI über Putty auf, und melden Sie sich mit dem Admin-Konto an.
2. Führen Sie die nächsten Befehle aus, um CSR für jeden auf CMS benötigten Dienst zu erstellen. Es ist auch möglich, ein einzelnes Zertifikat zu erstellen, das über einen Platzhalter (*.com) verfügt oder den Cluster-FQDN als CN, FQDNs jedes CMS-Servers und bei Bedarf eine Join-URL aufweist.

3. Wenn das CMS geclustert ist, führen Sie die nächsten Befehle aus.

Schritt 3: Erstellen des Datenbank-Cluster-CSR und Verwenden der integrierten Zertifizierungsstelle zum Signieren

Seit CMS 2.7 benötigen Sie Zertifikate für Ihr Datenbank-Cluster.  In Version 2.7 wurde eine integrierte Zertifizierungsstelle hinzugefügt, mit der die Datenbankzertifikate signiert werden können.

1. Führen Sie auf allen Cores das Entfernen des Datenbankclusters aus.
2. Führen Sie auf dem Primary pki selbstsignierte dbca CN aus. Beispiel:Pki selbstsignierte dbca CN:tplab.local 
3. Führen Sie auf der primären Seite pki csr dbserver CN:cmscore1.example.com subjectAltName aus.  Beispiel:cmscore2.example.com,cmscore3.example.com.
4. Erstellen Sie auf dem Primary ein Zertifikat für die Datenbank clientpki csr dbclient CN:postgres.
5. Verwenden Sie auf dem Primary dbca, um das dbserver certpki-Zeichen dbserver dbca zu signieren.
6. Verwenden Sie auf dem Primary dbca, um das dbclient cert pki-Zeichen dbclient dbca zu signieren.
7. Kopieren Sie die dbclient.crt auf alle Server, die eine Verbindung zu einem Datenbankknoten benötigen.
8. Kopieren Sie die Datei dbserver.crt auf alle Server, die mit der Datenbank verbunden sind (Knoten, die den Datenbankcluster bilden).
9. Kopieren Sie die Datei dbca.crt auf alle Server.
10. Führen Sie auf dem primären DB-Server das Datenbankcluster certs dbserver.key dbserver.crt dbclient.key dbclient.crt dbca.crt aus.  Dabei wird dbca.crt als root ca-cert verwendet.
11. Führen Sie auf dem primären DB-Server den lokalen Datenbankcluster-Knoten a aus.
12. Führen Sie auf dem primären DB-Server Datenbank-Cluster initialize aus.
13. Führen Sie auf dem primären DB-Server den Datenbank-Cluster-Status aus.  Must see Nodes: (me): Connected Primary.
14. Führen Sie auf allen anderen Cores, die mit dem Datenbankcluster verbunden sind, Datenbankclustercerts dbserver.key dbserver.crt dbclient.key dbclient.crt dbca.crt aus.
15. Führen Sie auf allen Kernen, die mit dem Datenbankcluster verbunden sind (nicht mit einer Datenbank verbunden), den Datenbankcluster certs dbclient.key dbclient.crt dbca.crt aus..
16. Bei verbundenen Kernen (am gleichen Standort wie eine Datenbank):
    • Führen Sie den lokalen Datenbankclusterknoten A aus.
    • Ausführen der Datenbankclusterverknüpfung.
17. ON-Cores, die verbunden sind (nicht am selben Standort wie eine Datenbank):
    • Ausführen des lokalen Datenbankclusterknotens a.
    • Datenbankclusterverbindung ausführen.

Schritt 4: Überprüfen der signierten Zertifikate

• Die Gültigkeit des Zertifikats (Ablaufdatum) kann mit der Zertifikatsüberprüfung überprüft werden. Führen Sie dazu den Befehl pki inspect <Dateiname> aus.
• Sie können überprüfen, ob ein Zertifikat mit einem privaten Schlüssel übereinstimmt. Führen Sie dazu den Befehl pki match <keyfile> <Zertifikatdatei> aus.
• Führen Sie den Befehl pki verify <cert> <Zertifikatbündel/Stammzertifizierungsstelle> aus, um zu überprüfen, ob ein Zertifikat von der Zertifizierungsstelle signiert wurde und ob das Zertifikatbündel zur Bestätigung verwendet werden kann.

Schritt 5: Signierte Zertifikate auf Komponenten auf CMS-Servern anwenden

1. Führen Sie die folgenden Befehle aus, um Zertifikate auf Webadmin anzuwenden:

webadmin disable
webadmin certs <keyfile> <certificate file> <certificate bundle/Root CA>
webadmin enable

2. Führen Sie die folgenden Befehle aus, um Zertifikate auf Callbridge anzuwenden:

callbridge certs <keyfile> <certificate file> <certificate bundle/Root CA>
callbridge restart

3. Führen Sie zum Anwenden von Zertifikaten auf Webbridge die folgenden Befehle aus (ersetzt durch webbridge3 in CMS 3.x mit neuen Konfigurationsanforderungen):

webbridge disable
webbridge certs <keyfile> <certificate file> <certificate bundle/Root CA>
webbridge enable

4. Führen Sie zum Anwenden von Zertifikaten auf XMPP die folgenden Befehle aus (in CMS 3.x nicht verfügbar):

xmpp disable
xmpp certs <keyfile> <certificate file> <certificate bundle/Root CA>
xmpp enable

5. Führen Sie die folgenden Befehle aus, um Zertifikate auf die Datenbank anzuwenden oder abgelaufene Zertifikate im aktuellen DB-Cluster zu ersetzen: 

database cluster remove (on all servers, noting who was primary before beginning)
database cluster certs <server_key> <server_certificate> <client_key> <client_certificate> <Root ca_crt>
database cluster initialize     (only on primary node)
database cluster join <FQDN or IP of primary>    (only on slave node)
database cluster connect <FQDN or IP of primary> (only on nodes that are not part of the database cluster)

6. Führen Sie die folgenden Befehle aus, um Zertifikate auf TURN anzuwenden:

turn disable
turn certs <keyfile> <certificate file> <certificate bundle/Root CA>
turn enable

Zertifikatvertrauensketten und Pakete

Seit CMS 3.0 müssen Sie Zertifikatvertrauensketten oder Full-Chain-Vertrauensstellungen verwenden.  Außerdem ist es für jeden Service wichtig, dass Sie wissen, wie Zertifikate erstellt werden sollen, wenn Sie Pakete erstellen.

Wenn Sie eine Zertifikatvertrauenskette erstellen, wie für Web Bridge 3 erforderlich, müssen Sie sie wie im Bild dargestellt erstellen, wobei die Entität "cert" oben, die Zwischenstufe in der Mitte, die Stammzertifizierungsstelle unten und ein einzelnes Wagenrücklaufzeichen angezeigt werden.

Jedes Mal, wenn Sie ein Paket erstellen, darf das Zertifikat nur einen Wagenrücklauf am Ende haben.

CA-Pakete wären die gleichen wie im Bild, es gäbe aber natürlich kein Entity-Zertifikat.

Fehlerbehebung

Wenn Sie ein abgelaufenes Zertifikat für alle Dienste mit Ausnahme von Datenbankzertifikaten ersetzen müssen, ist die einfachste Methode, neue Zertifikate mit dem GLEICHEN Namen wie die alten Zertifikate hochzuladen. In diesem Fall muss der Dienst nur neu gestartet werden, und Sie müssen den Dienst nicht neu konfigurieren.  

Wenn Sie pki csr ... ausführen und dieser Zertifikatsname mit einem aktuellen Schlüssel übereinstimmt, wird der Dienst sofort unterbrochen.  Wenn die Produktion live ist und Sie proaktiv einen neuen CSR und Key erstellen, verwenden Sie einen neuen Namen.  Sie können den aktuell aktiven Namen umbenennen, bevor Sie das neue Zertifikat auf die Server hochladen.

Wenn die Datenbankzertifikate abgelaufen sind, müssen Sie mit dem Datenbankclusterstatus überprüfen, wer die primäre Datenbank ist, und auf allen Knoten den Befehl database cluster remove ausführen.  Anschließend können Sie die Anweisungen aus Schritt 3 verwenden. Generieren Sie den CSR des Datenbankclusters, und signieren Sie ihn mit einer integrierten Zertifizierungsstelle.

Hinweis: Falls Sie die Cisco Meeting Manager (CMM)-Zertifikate erneuern müssen, lesen Sie das folgende Video: Updating the Cisco Meeting Management SSL Certificate (Aktualisierung des Cisco Meeting Management SSL-Zertifikats).

Zugehörige Informationen

• Technischer Support und Downloads von Cisco