Inleiding
Dit document beschrijft hoe u kunt bepalen of het door de certificaatinstantie (CA) ondertekende certificaat overeenkomt met het bestaande certificaataanvraag (CSR) voor Cisco Unified Application Server.
Voorwaarden
Vereisten
Cisco raadt u aan kennis te hebben van X.509/CSR.
Gebruikte componenten
Dit document is niet beperkt tot specifieke software- en hardware-versies.
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 de potentiële impact van elke opdracht begrijpen.
Verwante producten
Dit document kan ook met deze hardware- en softwareversies worden gebruikt:
- Cisco Unified Communications Manager (CUCM)
- Cisco Unified IM and Presence
- Cisco Unified Unity Connection-software
- CUIS
- Cisco Meidasence
- Cisco Unified Contact Center Express (UCCX)
Achtergrondinformatie
Een certificeringsaanvraag bestaat uit een vooraanstaande naam, een openbare sleutel en een optionele reeks eigenschappen die gezamenlijk ondertekend zijn door de entiteit die om de certificering verzoekt. Certificeringsverzoeken worden toegezonden aan een certificeringsinstantie die het verzoek in een X.509-certificaat omzet. In welke vorm heeft de certificeringsinstantie het nieuw ondertekende certificaat teruggegeven dat niet onder het toepassingsgebied van dit document valt. Een PKCS #7-bericht is één mogelijkheid.(RFC:2986).
Cisco Communications Manager-certificaatbeheer
Het voornemen om een reeks eigenschappen op te nemen is tweeledig:
- Om andere informatie over een bepaalde entiteit te verstrekken, of een aanspreekwachtwoord waarmee de entiteit later om intrekking van certificaten kan verzoeken.
- Om eigenschappen te verschaffen voor opname in X.509-certificaten. De huidige Unified Communications (UC)-servers ondersteunen geen uitdagingswachtwoord.
Huidige Cisco UC-servers vereisen deze eigenschappen in een CSR zoals weergegeven in deze tabel:
Informatie |
Beschrijving |
orka |
organisatorische eenheid |
oornaam |
naam van de organisatie |
plaats |
plaats van de organisatie |
toestand |
organisatiestatus |
land |
landcode kan niet worden gewijzigd |
alternatieve hostname |
alternatieve naam |
Probleem
Wanneer u UC ondersteunt, kunt u veel gevallen tegenkomen waarin het door CA ondertekende certificaat niet op de UC-servers wordt geüpload. U kunt niet altijd identificeren wat heeft plaatsgevonden op het moment van het creëren van het ondertekende certificaat, aangezien u niet de persoon bent die de CSR gebruikte om het ondertekende certificaat te maken. In de meeste scenario's duurt het opnieuw tekenen van een nieuw certificaat meer dan 24 uur. UC-servers zoals CUCM hebben geen gedetailleerd logbestand/spoor om te helpen identificeren waarom het uploaden van het certificaat mislukt, maar geven gewoon een foutmelding. De bedoeling van dit artikel is om de kwestie te vernauwen, of het nu een UC-server of een CA-kwestie is.
Algemene praktijk voor door CA ondertekende certificaten in CUCM
CUCM ondersteunt integratie met CA’s van derden met behulp van een PKCS#10 CSR-mechanisme dat toegankelijk is op de Cisco Unified Communications Operating System Manager GUI. Klanten, die momenteel CA's van derden gebruiken moeten het CSR-mechanisme gebruiken om certificaten voor Cisco CallManager, CAPF, IPSec, en Tomcat uit te geven.
Stap 1. Verander het Identificeer voordat u de CSR genereert.
De identiteit van de CUCM-server om een CSR te genereren kan worden gewijzigd met behulp van de opdracht ingesteld web-security zoals in deze afbeelding wordt getoond.
Als u in de bovengenoemde velden ruimte hebt, gebruikt u " om de opdracht zoals in de afbeelding te bereiken.
Stap 2. Generate CSR zoals getoond in de afbeelding.
Stap 3. Download de CSR en laat het ondertekend door CA zoals in de afbeelding.
Stap 4. Upload het CA-ondertekend certificaat naar de server.
Wanneer de CSR gegenereerd is en het certificaat getekend is en u het niet uploadt met een foutbericht "Fout bij lezen van het certificaat" (zoals in deze afbeelding getoond), moet u controleren of de CSR opnieuw gegenereerd is of het ondertekende certificaat zelf de oorzaak van de afgifte is.
Er zijn drie manieren om te controleren of de CSR opnieuw wordt gegenereerd of het ondertekende certificaat zelf de oorzaak van de uitgifte is.
Oplossing 1. Gebruik OpenSSL-opdracht in root (of linux)
Stap 1. Meld u aan bij de wortel en navigeer naar de map zoals in de afbeelding.
Stap 2. Kopieer het ondertekende certificaat naar dezelfde map met Secure FTP (SFTP). Als u geen SFTP-server kunt instellen, kan het uploaden in de TFTP-map ook het certificaat naar het CUCM verkrijgen zoals in de afbeelding wordt weergegeven.
3. Controleer de MD5 op de CSR en het ondertekende certificaat zoals in de afbeelding weergegeven.
Oplossing 2. Gebruik elke SSL-certificaattoetser van internet
Oplossing 3. Vergelijk inhoud met elke CSR-decoder van internet
Stap 1. Kopieer de gedetailleerde informatie van het sessiecertificaat voor elke sessie zoals in deze afbeelding.
Stap 2. Vergelijk ze in een gereedschap zoals Kladblok+ met de stekker Vergelijken zoals in deze afbeelding.