CSR genereren en certificaten toepassen op CMS

Inleiding

In dit document wordt beschreven hoe u Certificate Signing Request (CSR) kunt genereren en ondertekende certificaten kunt uploaden naar Cisco Meeting Server (CMS)

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• Basiskennis van CMS Server

Gebruikte componenten

De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:

• Putty of soortgelijke software
• CMS 2.9 of hoger

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Genereer de CSR

Er zijn twee manieren waarop u CSR kunt genereren, een daarvan is om de CSR rechtstreeks op de CMS-server te genereren vanuit Command Line Interface (CLI) met beheerderstoegang, de andere is om het te doen met externe 3rd party Certificate Authority (CA) zoals Open SSL.

In beide gevallen moet de CSR worden gegenereerd met de juiste syntaxis om CMS-services goed te laten werken.

Stap 1. syntaxisstructuur

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

• <key/cert basename> is een tekenreeks die de nieuwe sleutel en de CSR-naam identificeert. Het kan alfanumerieke tekens, koppeltekens of onderstrepingstekens bevatten. Dit is een verplicht veld.
• <CN:value> is de algemene naam. Dit is de volledig gekwalificeerde domeinnaam (FQDN) die de exacte locatie van de server in het domeinnaamsysteem (DNS) opgeeft. Dit is een verplicht veld.
• [OU:<value>] is de naam van de organisatie-eenheid of afdeling. Bijvoorbeeld Support, IT, Engineer, Finance. Dit is een optioneel veld.
• [O:<value>] is de naam van de organisatie of het bedrijf. Meestal de wettelijk opgerichte naam van een bedrijf. Dit is een optioneel veld.
• [ST:<value>] is de provincie, regio, provincie of staat. Bijvoorbeeld Buckinghamshire California. Dit is een optioneel veld.
• [C:<value>] is het land. De tweeletterige ISO-code (International Organization for Standardization) voor het land waar uw organisatie is gevestigd. Bijvoorbeeld US, GB, FR. Dit is een optioneel veld.
• [subjectAltName:<value>] is de alternatieve naam van het onderwerp (SAN). Vanaf X509 versie 3 (RFC 2459) zijn Secure Socket Layers (SSL)-certificaten toegestaan om meerdere namen op te geven die het certificaat moet overeenkomen. Met dit veld kan het gegenereerde certificaat meerdere domeinen bestrijken. Het kan IP-adressen, domeinnamen, e-mailadressen, gewone DNS-hostnamen, enz. bevatten, gescheiden door komma's. Als het is opgegeven, moet u ook de GN in deze lijst opnemen. Hoewel dit een optioneel veld is, moet het SAN-veld worden ingevuld zodat XMPP-clients (Extensible Messaging and Presence Protocol) een certificaat kunnen accepteren, anders geven de XMPP-clients een certificaatfout weer.

Stap 2. Callbridge, Smpp, Webadmin en Webbridge CSR genereren

1. Open de CMS CLI met Putty en log in met de beheerdersaccount.
2. Voer de volgende opdrachten uit om CSR te maken voor elke benodigde service op CMS. Het is ook acceptabel om een enkele cert te maken met een wild card (*.com) of met het cluster FQDN als CN, FQDN's van elke CMS-server en, indien nodig, lid te worden van de URL.

3. Als het CMS is geclusterd, voert u de volgende opdrachten uit.

Stap 3. Genereer de CSR van het databasecluster en gebruik de ingebouwde CA om ze te ondertekenen

Sinds CMS 2.7 moet u over certificaten voor uw databasecluster beschikken.  In 2.7 hebben we een ingebouwde CA opgenomen die kan worden gebruikt om de databasecertificaten te ondertekenen.

1. Voer op alle kernen het verwijderen van databaseclusters uit.
2. Voer op de primaire pagina pki selfsigned dbca CN uit. Voorbeeld: Pki selfsigned dbca CN:tplab.local 
3. Voer op de primaire pki csr dbserver CN:cmscore1.example.com subjectAltName uit.  Voorbeeld: cmscore2.example.com, cmscore3.example.com.
4. Maak op de primaire database een cert voor clientpki csr dbclient CN: postgres.
5. Gebruik dbca op de primaire server om de dbserver certpki sign dbserver dbca te ondertekenen.
6. Gebruik dbca op de primaire map om de dbclient cert pki sign dbclient dbca te ondertekenen.
7. Kopieer dbclient.crt naar alle servers die verbinding moeten maken met een databaseknooppunt
8. Kopieer het bestand dbserver.crt naar alle servers die zijn aangesloten op de database (knooppunten die deel uitmaken van het databasecluster).
9. Kopieer het bestand dbca.crt naar alle servers.
10. Voer op de primaire DB-server databasecluster certs dbserver.key dbserver.crt dbclient.key dbclient.crt.dbca.crt uit.  Deze gebruikt de dbca.crt als de root ca-cert.
11. Voer op de primaire DB-server een lokale node van een databasecluster uit.
12. Voer op de primaire DB-server het databasecluster initialiseren uit.
13. Voer op de primaire DB-server de status van het databasecluster uit.  Moet Nodes zien: (me): Verbonden Primair.
14. Voer op alle andere kernen die zijn gekoppeld aan het databasecluster databasecluster certs dbserver.key dbserver.crt.dbclient.key dbclient.crt uit.
15. Voer op alle kernen die zijn verbonden (niet samen met een database) met het databasecluster databasecluster certs.dbclient.key.dbclient.crt uit.
16. Op kernen die zijn gekoppeld (samen met een database):
    • Lokale knooppunt A van databasecluster uitvoeren.
    • Voer databaseclusterjoin uit.
17. ON-kernen die zijn aangesloten (niet op dezelfde locatie als een database):
    • Lokale knooppunt A van databasecluster uitvoeren.
    • Database Cluster Connect uitvoeren.

Stap 4. Controleer de ondertekende certificaten

• De geldigheid van het certificaat (vervaldatum) kan worden geverifieerd met certificaatinspectie, voer de opdracht pki inspect <bestandsnaam>.
• U kunt controleren of een certificaat overeenkomt met een privésleutel en de opdracht pki match <keyfile> <certificaatbestand> uitvoeren.
• Om te valideren dat een certificaat is ondertekend door de certificeringsinstantie en dat de certificaatbundel kan worden gebruikt om het certificaat te bevestigen, voert u de opdracht pki verifieer <cert> <certificaatbundel/basiscertificeringsinstantie>.

Stap 5. Ondertekende certificaten toepassen op onderdelen op CMS-servers

1. Voer de volgende opdrachten uit om certificaten toe te passen op Webadmin:

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

2. Voer de volgende opdrachten uit om certificaten toe te passen op Callbridge:

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

3. Voer de volgende opdrachten uit om certificaten toe te passen op Webbridge (vervangen door webbridge3 in CMS 3.x met nieuwe configuratievereisten):

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

4. Voer de volgende opdrachten uit om certificaten toe te passen op XMPP (Niet beschikbaar in CMS 3.x):

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

5. Voer de volgende opdrachten uit om certificaten toe te passen op de database of verlopen certificaten te vervangen in het huidige DB-cluster: 

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. Voer de volgende opdrachten uit om certificaten toe te passen op TURN:

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

Certificaat vertrouwensketens en bundels

Sinds CMS 3.0 bent u verplicht om certificaatvertrouwensketens of volledige ketenvertrouwensrelaties te gebruiken.  Het is ook belangrijk voor elke service dat u weet hoe certs moeten worden gebouwd wanneer u bundels maakt.

Wanneer u een certificaatvertrouwensketen bouwt, zoals vereist voor Web bridge 3, moet u deze bouwen zoals weergegeven in de afbeelding, met de entiteit cert bovenaan, de tussenpersonen in het midden, de root-CA onderaan en vervolgens een enkele retourzending.

Telkens wanneer u een bundel maakt, moet het certificaat aan het einde slechts één retourzending hebben.

CA-bundels zouden hetzelfde zijn als in de afbeelding, alleen zou er natuurlijk geen entiteitscertificaat zijn.

Problemen oplossen

Als u een verlopen certificaat moet vervangen voor alle services, behalve databasecertificaten, is de eenvoudigste methode om nieuwe certificaten te uploaden met dezelfde naam als de oude certificaten. Als u dit doet, hoeft de service alleen maar opnieuw te worden gestart en hoeft u de service niet opnieuw te configureren.  

Als u pki csr uitvoert ... en die bepaalde naam overeenkomt met een huidige sleutel, wordt de service onmiddellijk onderbroken.  Als de productie live is en u proactief een nieuwe CSR en sleutel maakt, gebruikt u een nieuwe naam.  U kunt de huidige actieve naam wijzigen voordat u het nieuwe cert naar de servers uploadt.

Als de databasecertificaten zijn verlopen, moet u controleren met de status van het databasecluster wie de primaire database is en op alle knooppunten de opdracht databasecluster verwijderen uitvoeren.  Vervolgens kunt u de instructies uit stap 3 gebruiken. Genereer de CSR van het databasecluster en gebruik een ingebouwde CA om ze te ondertekenen.

Opmerking: Als u de Cisco Meeting Manager (CMM)-certificaten wilt vernieuwen, raadpleegt u de volgende video: Het Cisco Meeting Management SSL-certificaat bijwerken.

Gerelateerde informatie

• Cisco Technical Support en downloads