Problemen met verificatie van expressway-verkeersserver oplossen

Inleiding

Dit document beschrijft de gedragsverandering op Expressway-versies van X14.2.0 en hoger gekoppeld aan Cisco bug ID CSCwc69661 of Cisco bug ID CSCwa25108.

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• Basisconfiguratie Expressway
• MRA-basisconfiguratie

Gebruikte componenten

De informatie in dit document is gebaseerd op Cisco Expressway versie X14.2 en 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.

Achtergrondinformatie

Met deze gedragsverandering gemarkeerd door Cisco bug ID CSCwc69661 of Cisco bug ID CSCwa25108 Bovendien voert de verkeersserver op het Expressway-platform certificaatverificatie uit van de Cisco Unified Communication Manager (CUCM), Cisco Unified Instant Messaging & Presence (IM&P) en Unity-serverknooppunten voor de Mobile and Remote Access (MRA) -services. Deze wijziging kan leiden tot MRA-aanmeldingsfouten na een upgrade op uw Expressway-platform.  

Hypertext Transfer Protocol Secure (HTTPS) is een beveiligd communicatieprotocol dat gebruikmaakt van Transport Layer Security (TLS) om de communicatie te versleutelen. Het creëert dit beveiligde kanaal door het gebruik van een TLS-certificaat dat wordt uitgewisseld in de TLS-handshake. Dit dient twee doelen: authenticatie (om te weten met wie de externe partij waarmee u verbinding maakt) en privacy (de codering). De authenticatie beschermt tegen man-in-the-middle-aanvallen en de privacy voorkomt dat aanvallers de communicatie afluisteren en manipuleren.

TLS (certificaat) verificatie wordt uitgevoerd in het zicht van authenticatie en stelt u in staat om er zeker van te zijn dat u verbinding hebt gemaakt met de juiste externe partij. De verificatie bestaat uit twee afzonderlijke items:

1. keten van de Trusted Certificate Authority (CA)

2. Alternatieve benaming (SAN) of algemene benaming (GN)

Betrouwbare CA-keten

Als Expressway-C het certificaat dat CUCM / IM&P / Unity verzendt, wil vertrouwen, moet het in staat zijn om een koppeling van dat certificaat naar een certificeringsinstantie op het hoogste niveau (root) op te zetten die het vertrouwt. Een dergelijke koppeling, een hiërarchie van certificaten die een entiteitencertificaat koppelt aan een root CA-certificaat, wordt een vertrouwensketen genoemd. Om een dergelijke keten van vertrouwen te kunnen verifiëren, bevat elk certificaat twee velden: Uitgever (of uitgegeven door) en Onderwerp (of uitgegeven aan).

Servercertificaten, zoals die welke CUCM naar Expressway-C verzendt, hebben in het veld Onderwerp doorgaans hun volledig gekwalificeerde domeinnaam (FQDN) in de GN:

        Issuer: DC=lab, DC=vngtp, CN=vngtp-ACTIVE-DIR-CA
        Subject: C=BE, ST=Flamish-Brabant, L=Diegem, O=Cisco, OU=TAC, CN=cucm.vngtp.lab

Voorbeeld van een servercertificaat voor CUCM.vngtp.lab. Het heeft de FQDN in het CN attribuut van het Subject veld samen met andere attributen zoals het Land (C), Staat (ST), Locatie (L), ... U kunt ook zien dat het servercertificaat wordt uitgedeeld (uitgegeven) door een CA met de naam vngtp-ACTIVE-DIR-CA.

CA's op het hoogste niveau (root CA's) kunnen ook een certificaat afgeven om zichzelf te identificeren. In zo’n root CA certificaat zie je dat de Issuer en Subject dezelfde waarde hebben:

        Issuer:  DC=lab, DC=vngtp, CN=vngtp-ACTIVE-DIR-CA
        Subject: DC=lab, DC=vngtp, CN=vngtp-ACTIVE-DIR-CA

Het is een certificaat dat door een root-CA wordt uitgedeeld om zichzelf te identificeren.

In een typische situatie geven root-CA's niet rechtstreeks servercertificaten uit. In plaats daarvan geven ze certificaten uit voor andere CA's. Dergelijke andere CA's worden dan intermediaire CA's genoemd. Tussenliggende CA's kunnen op hun beurt rechtstreeks servercertificaten of certificaten uitgeven voor andere tussenliggende CA's. U kunt een situatie hebben waarin een servercertificaat wordt uitgegeven door intermediaire CA 1, die op zijn beurt een certificaat krijgt van intermediaire CA 2 enzovoort. Tot slot krijgt intermediate CA zijn certificaat rechtstreeks van de root CA:

Server certificate :
        Issuer:  DC=lab, DC=vngtp, CN=vngtp-intermediate-CA-1
        Subject: C=BE, ST=Flamish-Brabant, L=Diegem, O=Cisco, OU=TAC, CN=cucm.vngtp.lab
Intermediate CA 1 certificate :
        Issuer:  DC=lab, DC=vngtp, CN=vngtp-intermediate-CA-2 
        Subject: DC=lab, DC=vngtp, CN=vngtp-intermediate-CA-1 
Intermediate CA 2 certificate :
        Issuer:  DC=lab, DC=vngtp, CN=vngtp-intermediate-CA-3 
        Subject: DC=lab, DC=vngtp, CN=vngtp-intermediate-CA-2 
...
Intermediate CA n certificate :
        Issuer:  DC=lab, DC=vngtp, CN=vngtp-ACTIVE-DIR-CA
        Subject: DC=lab, DC=vngtp, CN=vngtp-intermediate-CA-n 
Root CA certificate :
        Issuer:  DC=lab, DC=vngtp, CN=vngtp-ACTIVE-DIR-CA
        Subject: DC=lab, DC=vngtp, CN=vngtp-ACTIVE-DIR-C

Nu, om Expressway-C het servercertificaat dat CUCM verzendt te laten vertrouwen, moet het in staat zijn om de vertrouwensketen van dat servercertificaat op te bouwen tot een root CA-certificaat. Om dat te laten gebeuren, moet u het root CA-certificaat en ook alle tussenliggende CA-certificaten uploaden (als die er zijn, wat niet het geval is als de root CA het servercertificaat van CUCM rechtstreeks zou hebben uitgegeven) in het vertrouwensarchief van Expressway-C.

Opmerking: Hoewel de velden Uitgever en Onderwerp eenvoudig op een menselijk leesbare manier de vertrouwensketen kunnen opbouwen, gebruikt CUCM deze velden niet in het certificaat. In plaats daarvan gebruikt het de X509v3 Authority Key Identifier en de X509v3 Subject Key Identifier velden om de vertrouwensketen op te bouwen. Deze sleutels bevatten identificatoren voor de certificaten die nauwkeuriger zijn dan de velden Onderwerp/Uitgever: er kunnen 2 certificaten zijn met dezelfde velden Onderwerp/Uitgever, maar één ervan is verlopen en één is nog steeds geldig. Ze zouden allebei een andere X509v3-onderwerpsleutel hebben, zodat CUCM nog steeds de juiste vertrouwensketen kan bepalen.

Dit is echter niet het geval voor Expressway volgens Cisco bug ID CSCwa12905 en het is niet mogelijk om twee verschillende (zelf ondertekende) certificaten te uploaden in de vertrouwenswinkel van Expressway die dezelfde Common Name (CN) hebben. De manier om dit te corrigeren, is om CA-ondertekende certificaten te gebruiken of om er verschillende Common Names voor te gebruiken of om te zien dat het altijd hetzelfde certificaat gebruikt (mogelijk via de hergebruikcertificaatfunctie in CUCM 14).

SAN- of CN-controle

Stap 1 controleert de vertrouwenswinkel, maar iedereen die een certificaat heeft dat is ondertekend door een CA in de vertrouwenswinkel, zou dan geldig zijn. Dit is duidelijk niet voldoende. Daarom is er een extra controle die bevestigt dat de server waarmee u specifiek verbinding maakt inderdaad de juiste is. Dit gebeurt op basis van het adres waarvoor het verzoek is ingediend.

Dezelfde soort bewerking gebeurt in uw browser, dus u kunt dit zien in een voorbeeld. Als u naar Cisco.com bladert, ziet u een vergrendelingspictogram naast de URL die u hebt ingevoerd en dit betekent dat het een vertrouwde verbinding is. Dit is zowel gebaseerd op de CA-vertrouwensketen (vanaf het eerste gedeelte) als op de SAN- of CN-controle. Als u het certificaat opent (via de browser door op het vergrendelingspictogram te klikken), ziet u dat de algemene naam (te zien in het veld Uitgegeven aan:) is ingesteld op Cisco.com en dat komt precies overeen met het adres waarmee u verbinding wilt maken. Op die manier kunt u er zeker van zijn dat u verbinding maakt met de juiste server (omdat u de CA vertrouwt die het certificaat heeft ondertekend en die de verificatie uitvoert voordat het het certificaat uitdeelt).

Wanneer u naar de details van het certificaat kijkt, en met name naar de SAN-items, ziet u dat hetzelfde wordt herhaald, evenals enkele andere FQDN's:

Dit betekent dat wanneer u bijvoorbeeld zou vragen om verbinding te maken met Cisco.com, dit ook als een beveiligde verbinding zou worden weergegeven omdat deze in de SAN-vermeldingen is opgenomen.

Wanneer u echter niet naar Cisco.com bladert maar rechtstreeks naar het IP-adres (genummerd webadres), wordt er geen beveiligde verbinding weergegeven omdat de CA die het heeft ondertekend niet wordt vertrouwd. Het gepresenteerde certificaat bevat niet het adres (72.163.4.161) dat u hebt gebruikt om verbinding te maken met de server.

In de browser kunt u dit omzeilen, maar het is een instelling die u kunt inschakelen op TLS-verbindingen die een bypass niet is toegestaan. Daarom is het belangrijk dat uw certificaten de juiste CN- of SAN-namen bevatten die de externe partij van plan is te gebruiken om er verbinding mee te maken.

Gedragsverandering

MRA-services zijn sterk afhankelijk van verschillende HTTPS-verbindingen via de Expressways naar de CUCM / IM & P / Unity-servers om correct te verifiëren en de juiste informatie te verzamelen die specifiek is voor de client die inlogt. Deze communicatie vindt meestal plaats via poorten 8443 en 6972.

Versies lager dan X14.2.0

In versies lager dan X14.2.0 is de verkeersserver op Expressway-C die de beveiligde HTTPS-verbindingen afhandelt die het certificaat dat door het externe einde werd gepresenteerd, niet hebben geverifieerd. Dit kan leiden tot man-in-the-middle-aanvallen. Op de MRA-configuratie is er een optie voor TLS-certificaatverificatie door de configuratie van de TLS Verify Mode'to On wanneer u CUCM- / IM&P- / Unity-servers zou toevoegen onder Configuration > Unified Communications > Unified CM-servers / IM- en Presence Service-knooppunten / Unity Connection-servers. De configuratieoptie en het relevante informatievak worden als voorbeeld weergegeven, wat aangeeft dat de FQDN of IP in het SAN wordt geverifieerd, evenals de geldigheid van het certificaat en of het is ondertekend door een vertrouwde certificeringsinstantie.

Deze TLS-certificaatverificatie wordt alleen uitgevoerd bij de detectie van de CUCM / IM&P / Unity-servers en niet op het moment dat MRA inlogt wanneer de verschillende servers worden opgevraagd. Een eerste nadeel van deze configuratie is dat deze alleen wordt geverifieerd voor het adres van de uitgever dat u toevoegt. Het valideert niet of het certificaat op de abonneeknooppunten correct is ingesteld omdat het de abonneeknoopinfo (FQDN of IP) ophaalt uit de database van de uitgeversknooppunt. Een tweede nadeel van deze configuratie is ook dat wat aan de MRA-clients wordt geadverteerd als de verbindingsinformatie kan verschillen van het adres van de uitgever dat in de Expressway-C-configuratie is geplaatst. Bijvoorbeeld op CUCM, onder Systeem > Server kunt u de server adverteren met een IP-adres (bijvoorbeeld 10.48.36.215) en dit wordt vervolgens gebruikt door de MRA-clients (via de proxied Expressway-verbinding), maar u kunt de CUCM op Expressway-C toevoegen met de FQDN van cucm.steven.lab. Dus neem aan dat het tomcat-certificaat van CUCM cucm.steven.lab als SAN-invoer bevat, maar niet het IP-adres, dan slaagt de ontdekking met de TLS Verify Mode ingesteld op Aan, maar de daadwerkelijke communicatie van de MRA-clients kan zich richten op een ander FQDN of IP en dus de TLS-verificatie niet uitvoeren.

Versies van X14.2.0 en hoger

Vanaf versie X14.2.0 voert de Expressway-server de TLS-certificaatverificatie uit voor elke HTTPS-aanvraag die via de verkeersserver wordt gedaan. Dat betekent dat het ook dit doet wanneer de TLS Verify Mode is ingesteld op Off tijdens de detectie van de CUCM / IM&P / Unity nodes. Wanneer de verificatie niet slaagt, wordt de TLS-handshake niet voltooid en mislukt het verzoek, wat kan leiden tot verlies van functionaliteit zoals redundantie, of failover-problemen of volledige aanmeldingsfouten bijvoorbeeld. Als de TLS Verify Mode is ingesteld op On, garandeert dit niet dat alle verbindingen goed werken, zoals in het voorbeeld later wordt beschreven.

De exacte certificaten die de Expressway controleert in de richting van de CUCM / IM & P / Unity knooppunten zijn zoals weergegeven in het gedeelte van de MRA gids.

Afgezien van de standaard voor TLS-verificatie, is er ook een wijziging geïntroduceerd in X14.2 die een andere voorkeursvolgorde voor de cijferlijst kan adverteren, afhankelijk van uw upgradepad. Dit kan leiden tot onverwachte TLS-verbindingen na een software-upgrade, omdat het kan gebeuren dat vóór de upgrade het Cisco Tomcat- of Cisco CallManager-certificaat is aangevraagd bij CUCM (of een ander product met een afzonderlijk certificaat voor het ECDSA-algoritme), maar dat na de upgrade wordt gevraagd om de ECDSA-variant (die de veiligere codeervariant is dan RSA). De Cisco Tomcat-ECDSA- of Cisco CallManager-ECDSA-certificaten kunnen worden ondertekend door een andere CA of gewoon nog steeds zelf ondertekende certificaten (de standaard).

Deze wijziging van de volgorde van de coderingsvoorkeur is niet altijd relevant voor u, omdat deze afhankelijk is van het upgradepad zoals wordt weergegeven in de opmerkingen bij de release van Expressway X14.2.1. In het kort kunt u zien uit Onderhoud > Beveiliging > Coderingen voor elk van de cijferlijsten of het ECDHE-RSA-AES256-GCM-SHA384 al dan niet vooraf gaat. Als dit niet het geval is, geeft het de voorkeur aan het nieuwere ECDSA-cijfer boven het RSA-cijfer. Als dat zo is, dan heb je het gedrag zoals eerder bij RSA dat dan de hogere voorkeur heeft.

Er zijn twee manieren waarop de TLS-verificatie in dit scenario zou kunnen mislukken, die later in detail worden behandeld:

1. CA die het certificaat op afstand heeft ondertekend, wordt niet vertrouwd.

a. Zelfondertekend certificaat

b. Certificaat ondertekend door onbekende CA

2. Het verbindingsadres (FQDN of IP) is niet in het certificaat opgenomen.

Scenario's voor probleemoplossing

De volgende scenario's tonen een vergelijkbaar scenario in een laboratoriumomgeving waar MRA-aanmelding niet is mislukt na een upgrade van Expressway van X14.0.7 naar X14.2. Ze delen overeenkomsten in de logs, maar de resolutie is anders. De logboeken worden verzameld door de diagnostische logboekregistratie (van Onderhoud > Diagnostiek > Diagnostische logboekregistratie) die werd gestart voordat de MRA-aanmelding werd gestart en gestopt nadat de MRA-aanmelding was mislukt. Er is geen extra foutopsporingslogboekregistratie ingeschakeld.

1. CA Ondertekend dat het certificaat op afstand niet wordt vertrouwd

Het externe certificaat kan worden ondertekend door een CA die niet is opgenomen in het vertrouwensarchief van de Expressway-C of kan een zelf ondertekend certificaat zijn (in wezen ook een CA) dat niet is toegevoegd in het vertrouwensarchief van de Expressway-C-server.

In het voorbeeld hier kunt u zien dat de verzoeken die naar CUCM gaan (10.48.36.215 - cucm.steven.lab) correct worden afgehandeld op poort 8443 (200 OK-respons), maar het geeft een fout (502-respons) op poort 6972 voor de TFTP-verbinding.

===Success connection on 8443===

2022-07-11T18:55:25.910+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:25,910" Module="network.http.trafficserver" Level="INFO": Detail="Receive Request" Txn-id="189" TrackingID="6af9a674-9ebc-41ea-868e-90e7309a758c" Src-ip="127.0.0.1" Src-port="35764" Last-via-addr="" Msg="GET http://vcs_control.steven.lab:8443/c3RldmVuLmxhYi9odHRwcy9jdWNtLnN0ZXZlbi5sYWIvODQ0Mw/cucm-uds/user/emusk/devices HTTP/1.1"

2022-07-11T18:55:25.917+02:00 vcsc traffic_server[18242]:  Event="Request Allowed" Detail="Access allowed" Reason="In allow list" Username="emusk" Deployment="1" Method="GET" Request="https://cucm.steven.lab:8443/cucm-uds/user/emusk/devices" Rule="https://cucm.steven.lab:8443/cucm-uds/user/" Match="prefix" Type="Automatically generated rule for CUCM server" UTCTime="2022-07-11 16:55:25,916"
2022-07-11T18:55:25.917+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:25,916" Module="network.http.trafficserver" Level="INFO": Detail="Sending Request" Txn-id="189" TrackingID="6af9a674-9ebc-41ea-868e-90e7309a758c" Dst-ip="10.48.36.215" Dst-port="8443" Msg="GET /cucm-uds/user/emusk/devices HTTP/1.1"
2022-07-11T18:55:25.955+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:25,955" Module="network.http.trafficserver" Level="INFO": Detail="Receive Response" Txn-id="189" TrackingID="" Src-ip="10.48.36.215" Src-port="8443" Msg="HTTP/1.1 200 "
2022-07-11T18:55:25.956+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:25,955" Module="network.http.trafficserver" Level="INFO": Detail="Sending Response" Txn-id="189" TrackingID="" Dst-ip="127.0.0.1" Dst-port="35764" Msg="HTTP/1.1 200 "

===Failed connection on 6972===

2022-07-11T18:55:26.000+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:26,000" Module="network.http.trafficserver" Level="INFO": Detail="Receive Request" Txn-id="191" TrackingID="bb0c8492-8c15-4537-a7d1-082dde781dbd" Src-ip="127.0.0.1" Src-port="35766" Last-via-addr="" Msg="GET http://vcs_control.steven.lab:8443/c3RldmVuLmxhYi9odHRwcy9jdWNtLnN0ZXZlbi5sYWIvNjk3Mg/CSFemusk.cnf.xml HTTP/1.1"

2022-07-11T18:55:26.006+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:26,006" Module="network.http.trafficserver" Level="INFO": Detail="Sending Request" Txn-id="191" TrackingID="bb0c8492-8c15-4537-a7d1-082dde781dbd" Dst-ip="10.48.36.215" Dst-port="6972" Msg="GET /CSFemusk.cnf.xml HTTP/1.1"
2022-07-11T18:55:26.016+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:26,016" Module="network.http.trafficserver" Level="INFO": Detail="Sending Request" Txn-id="191" TrackingID="bb0c8492-8c15-4537-a7d1-082dde781dbd" Dst-ip="10.48.36.215" Dst-port="6972" Msg="GET /CSFemusk.cnf.xml HTTP/1.1"
2022-07-11T18:55:26.016+02:00 vcsc traffic_server[18242]: [ET_NET 0] WARNING: Core server certificate verification failed for (cucm.steven.lab). Action=Terminate Error=self signed certificate server=cucm.steven.lab(10.48.36.215) depth=0
2022-07-11T18:55:26.016+02:00 vcsc traffic_server[18242]: [ET_NET 0] ERROR: SSL connection failed for 'cucm.steven.lab': error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
2022-07-11T18:55:26.024+02:00 vcsc traffic_server[18242]: UTCTime="2022-07-11 16:55:26,024" Module="network.http.trafficserver" Level="INFO": Detail="Sending Response" Txn-id="191" TrackingID="" Dst-ip="127.0.0.1" Dst-port="35766" Msg="HTTP/1.1 502 connect failed"

De fout van certificaat, verificatie mislukt, geeft aan dat de Expressway-C de TLS-handshake niet kon valideren. De reden hiervoor wordt weergegeven op de waarschuwingsregel omdat deze een zelf ondertekend certificaat aangeeft. Als de diepte wordt weergegeven als 0, is het een zelf ondertekend certificaat. Wanneer de diepte hoger is dan 0, betekent dit dat het een certificaatketen heeft en dus wordt ondertekend door een onbekende CA (vanuit het perspectief van Expressway-C).

Wanneer u kijkt in het pcap-bestand dat is verzameld op de tijdstempels die worden vermeld in de tekstlogboeken, kunt u zien dat CUCM het certificaat presenteert met CN als cucm-ms.steven.lab (en cucm.steven.lab als SAN) ondertekend door steven-DC-CA aan de Expressway-C op poort 8443.

Maar wanneer u het certificaat inspecteert dat op poort 6972 wordt gepresenteerd, kunt u zien dat het een zelf ondertekend certificaat is (Uitgever is zelf) met CN ingesteld als cucm-EC.steven.lab. De uitbreiding -EC geeft de indicatie dat dit het ECDSA-certificaat is dat is ingesteld op CUCM.

Op CUCM onder Cisco Unified OS Administration kunt u kijken naar de certificaten die aanwezig zijn onder Beveiliging > Certificaatbeheer zoals hier wordt weergegeven. Het toont een ander certificaat voor tomcat en tomcat-ECDSA waarbij de tomcat CA-ondertekend is (en vertrouwd wordt door de Expressway-C) terwijl het tomcat-ECDSA-certificaat zelfondertekend is en hier niet vertrouwd wordt door de Expressway-C.

2. Verbindingsadres (FQDN of IP) is niet opgenomen in het certificaat

Naast de vertrouwensopslag, controleert de verkeersserver ook het verbindingsadres waarnaar de MRA-client het verzoek richt. Wanneer u bijvoorbeeld CUCM hebt ingesteld onder Systeem > Server uw CUCM met het IP-adres (10.48.36.215), dan adverteert de Expressway-C dit als zodanig aan de klant en worden daaropvolgende verzoeken van de klant (benaderd via de Expressway-C) gericht op dit adres.

Wanneer dat specifieke verbindingsadres niet in het servercertificaat is opgenomen, mislukt ook de TLS-verificatie en wordt er een 502-fout gegenereerd die bijvoorbeeld tot MRA-aanmeldingsfouten leidt.

2022-07-11T19:49:01.472+02:00 vcsc traffic_server[3916]: UTCTime="2022-07-11 17:49:01,472" Module="network.http.trafficserver" Level="DEBUG": Detail="Receive Request" Txn-id="144" TrackingID="0a334fa8-41e9-4b97-adf4-e165372c38cb" Src-ip="127.0.0.1" Src-port="30044" Last-via-addr=""
HTTPMSG:
|GET http://vcs_control.steven.lab:8443/c3RldmVuLmxhYi9odHRwcy8xMC40OC4zNi4yMTUvODQ0Mw/cucm-uds/user/emusk/devices?max=100 HTTP/1.1
...

2022-07-11T19:49:01.478+02:00 vcsc traffic_server[3916]: UTCTime="2022-07-11 17:49:01,478" Module="network.http.trafficserver" Level="INFO": Detail="Sending Request" Txn-id="144" TrackingID="0a334fa8-41e9-4b97-adf4-e165372c38cb" Dst-ip="10.48.36.215" Dst-port="8443" Msg="GET /cucm-uds/user/emusk/devices?max=100 HTTP/1.1"
2022-07-11T19:49:01.478+02:00 vcsc traffic_server[3916]: UTCTime="2022-07-11 17:49:01,478" Module="network.http.trafficserver" Level="DEBUG": Detail="Sending Request" Txn-id="144" TrackingID="0a334fa8-41e9-4b97-adf4-e165372c38cb" Dst-ip="10.48.36.215" Dst-port="8443"
HTTPMSG:
|GET /cucm-uds/user/emusk/devices?max=100 HTTP/1.1
...

2022-07-11T19:49:01.491+02:00 vcsc traffic_server[3916]: [ET_NET 2] WARNING: SNI (10.48.36.215) not in certificate. Action=Terminate server=10.48.36.215(10.48.36.215)
2022-07-11T19:49:01.491+02:00 vcsc traffic_server[3916]: [ET_NET 2] ERROR: SSL connection failed for '10.48.36.215': error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed

Waar c3RldmVuLmxhYi9odHRwcy8xMC40OC4zNi4yMTUvODQ0Mw vertaalt (base64) naar steven.lab/https/10.48.36.215/8443, waaruit blijkt dat het de verbinding moet maken naar 10.48.36.215 als het verbindingsadres in plaats van naar cucm.steven.lab. Zoals te zien is in de pakketopnames, bevat het CUCM-tomcat-certificaat niet het IP-adres in het SAN en wordt de fout dus gegenereerd.

Hoe het gemakkelijk te valideren

U kunt valideren of u dit gedrag gemakkelijk tegenkomt met de volgende stappen:

1. Diagnostische registratie starten op de Expressway-E- en C-server(s) (idealiter met TCPDumps ingeschakeld) vanuit Onderhoud > Diagnostiek > Diagnostische registratie (in het geval van een cluster volstaat het om deze vanaf de primaire node te starten) 

2. Probeer een MRA-log in of test de kapotte functionaliteit na de upgrade 

3. Wacht tot het mislukt en stop vervolgens de diagnostische registratie op de Expressway-E- en C-server(s) (in het geval van een cluster moet u ervoor zorgen dat u de logs van elk knooppunt van het cluster afzonderlijk verzamelt) 

4. Upload en analyseer de logs in de tool Collaboration Solution Analyzer.

5. Als het probleem zich voordoet, worden de meest recente waarschuwings- en foutregels opgehaald die betrekking hebben op deze wijziging voor elk van de getroffen servers 

CA-diagnosehandtekening

SNI Diagnostic Signature

Oplossing

De oplossing op lange termijn is ervoor te zorgen dat de TLS-verificatie goed verloopt. Welke actie moet worden uitgevoerd, hangt af van het weergegeven waarschuwingsbericht.

Wanneer u de "WAARSCHUWING: verificatie van het kernservercertificaat is mislukt voor (<server-FQDN-or-IP>). Action=Terminate Error=self signed certificate server=cucm.steven.lab(10.48.36.215) depth=x" bericht, dan moet u de trust store op de Expressway-C servers dienovereenkomstig bijwerken. Met de CA-keten die dit certificaat heeft ondertekend (diepte > 0) of met het zelf ondertekende certificaat (diepte = 0) van Onderhoud > Beveiliging > Vertrouwd CA-certificaat. Zorg ervoor dat u deze actie uitvoert op elke server in het cluster. Een andere optie zou zijn om het certificaat op afstand te ondertekenen door een bekende CA in de Expressway-C-vertrouwenswinkel.

Opmerking: Expressway staat niet toe dat u twee verschillende (zelf ondertekende) certificaten uploadt naar de vertrouwenswinkel van Expressway die dezelfde Common Name (CN) hebben als volgens Cisco bug ID CSCwa12905. Om dit te corrigeren, gaat u naar CA-ondertekende certificaten of upgrade uw CUCM naar versie 14, waar u hetzelfde (zelf ondertekende) certificaat opnieuw kunt gebruiken voor Tomcat en CallManager.

Wanneer u het bericht "WAARSCHUWING: SNI (<server-FQDN-or-IP>) niet in certificaat" ziet, geeft dit aan dat deze server FQDN of IP niet is opgenomen in het certificaat dat is gepresenteerd. U kunt het certificaat aanpassen om die informatie op te nemen of u kunt de configuratie wijzigen (zoals met CUCM System > Server naar iets dat in het servercertificaat is opgenomen) en vervolgens de configuratie op de Expressway-C-server vernieuwen om er rekening mee te houden.

Gerelateerde informatie

De oplossing op korte termijn is om de workaround toe te passen zoals gedocumenteerd om terug te vallen op het vorige gedrag vóór X14.2.0. U kunt dit uitvoeren via de CLI op de Expressway-C-serverknooppunten met de nieuw geïntroduceerde opdracht:

xConfiguration EdgeConfigServer VerifyOriginServer: Off