In dit document wordt beschreven hoe u met Cisco Expressway x15.5 door de EKU-zonsondergang van de client navigeert.
Digitale certificaten zijn elektronische referenties die worden uitgegeven door vertrouwde certificeringsinstanties (CA's) die de communicatie tussen servers en clients beveiligen door authenticatie, gegevensintegriteit en vertrouwelijkheid te waarborgen. Deze certificaten bevatten EKU-velden (Extended Key Usage) die hun doel definiëren:
Traditioneel kan een enkel certificaat zowel server- als clientverificatie-EKU's bevatten, waardoor het voor twee doeleinden kan worden gebruikt. Dit is vooral belangrijk voor producten zoals Cisco Expressway die zowel als server als client fungeren in verschillende verbindingsscenario's.
Met ingang van juni 2026 beperkt het Chrome Root Program Policy Root Certificate Authority (CA) -certificaten die zijn opgenomen in de Chrome Root Store, waardoor multifunctionele roots worden uitgefaseerd om alle public-key infrastructure (PKI) -hiërarchieën uit te lijnen om alleen TLS-serverauthenticatie te gebruiken.
Opmerking: dit beleid is alleen van toepassing op certificaten die zijn uitgegeven door openbare CA's. Particuliere PKI en zelf ondertekende certificaten worden niet beïnvloed door dit beleid.
Als u geïnteresseerd bent in het lezen over de impact van zonsondergang van client EKU op Expressways, raadpleeg dan Prepare Expressway for Client Auth EKU Sunset in Public CA Certificates.
Expressway x15.5 wordt geleverd met een voorgestelde oplossing voor een probleem dat zich voordoet als gevolg van het niet instellen van client-EKU door alle openbare certificeringsinstanties. Dit is een wereldwijd probleem en treft alle leveranciers/implementaties die ervoor kiezen om openbare PKI-certificaten te gebruiken.
x15.4, een eerdere release, had een CLI-opdrachtcertificaat waarmee de beheerder alleen het EKU-servercertificaat (geen client-EKU aanwezig) kon uploaden op Expressway E.
xConfiguration XCP TLS Certificate CVS EnableServerEkuUpload: On
Opmerking: deze opdracht is uitgeschakeld op x15.5.
X15.5 heeft twee certificaatstores:
1. Servercertificaatarchief
2. Clientcertificaatarchief
Expressways (één NIC of twee NIC's): beide Expressway-interfaces kunnen naar behoefte gebruikmaken van twee certificaatstores.
Voorbeeld:
Opmerking: beide certificaatstores (client en server) gebruiken dezelfde vertrouwde CA-bibliotheek. Zorg ervoor dat de CA die server- en clientcertificaten heeft ondertekend, correct wordt geüpload in de Trust-opslag. Diagnostische logboeken bevatten nu een servercertificaat en een clientcertificaat in PEM-bestandsindeling.

Wanneer een upgrade wordt uitgevoerd, wordt het servercertificaat van x15.4 of een eerdere versie, de ExpressWay-servercertificaatopslag gekopieerd naar de clientcertificaatopslag op x15.5. Client- en servercertificaatstores op x15.5 hebben hetzelfde certificaat.
Expressway-server op 15.4, huidig servercertificaat Serienummer 46:df:76:aa:00:00:00:00:00:29
Certificaat:
Versie: 3 (0x2)
Serienummer:
46:DF:76:AA:00:00:00:00:00:29
geldigheid
Niet eerder: Mrt 14 02:37:40 2026 GMT
Niet na: Mrt 14 02:47:40 2028 GMT
Onderwerp: C = IN, ST = KA, L = KA, O = Cisco, OU = TAc, CN = cluster.s.com
Expressway-bestandssysteempersistente/cert-directory op x15.4:

Expressway-menu (Onderhoud > Beveiliging > Servercertificaat) op x15.4 (alleen veld Servercertificaat aanwezig):

Hier ziet u 2 certificaatopties onder Onderhoud > Beveiliging > clientcertificaat en servercertificaten. Na het upgraden naar x15.5 wordt hetzelfde certificaat weergegeven op zowel de server- als de clientcertificaatportals op webbeheer, omdat het servercertificaat van x15.4 is gekopieerd naar de clientcertificaatopslag op x15.5.

Na de upgrade naar x15.5 zijn het bestaande certificaat en de privésleutel gekopieerd naar het clientcertificaatarchief.
Expressway-bestandssysteempersistente/cert-directory op x15.5:

Op x15.5 is een nieuwe CLI-opdracht geïntroduceerd om Extended key use (EKU) tijdens TLS-handshake te controleren. De standaardwaarde is "ON". De opdrachtset is geldig op Expressway Core en Edge.
De opdrachtset activeert een controle voor alle INBOUND SIP TLS-verbindingen naar Expressway. (Inkomende client-HELLO's/certificaat gepresenteerd). Wanneer deze optie is ingeschakeld, wordt gecontroleerd of het certificaat dat door de TLS-initiator wordt gepresenteerd, client-EKU in certificaat bevat. ALS DEZE OPTIE IS UITGESCHAKELD, wordt de controle overgeslagen; de server-EKU wordt echter gecontroleerd als deze aanwezig is op het certificaat.
xconfiguration SIP TLS Certificate ExtendedKeyUse Checking Mode: AAN/UIT:
Opmerking: als u een clientcertificaat genereert en een CSR ondertekent die geen client-EKU bevat (een voorbeeld van een openbaar CA-ondertekend certificaat), kunt u dit certificaat niet handmatig uploaden in het clientcertificaatarchief. U moet er dus voor zorgen dat certificaten die worden gegenereerd door het ondertekenen van een CSR altijd de EKU van de klant bevatten (een particuliere CA kan worden gebruikt om de EKU van de klant in te voegen).
Tip: deze fout wordt duidelijk wanneer u probeert een certificaat met een CSR-handtekening te uploaden, dat de EKU van de client mist, in de certificaatopslag van de client.

Als u er echter voor kiest om een certificaat met alleen een server-EKU (geen client-EKU) te uploaden via de servercertificaatopslag en Servercertificaatbestand uploaden als clientcertificaat selecteert, wordt het certificaat gekopieerd naar de clientcertificaatopslag. Beheerders die geen door een particuliere certificeringsinstantie ondertekend certificaat op Expressway-Edge willen gebruiken, kunnen ervoor kiezen de EKU-server alleen te kopiëren van het servercertificaatarchief naar het clientcertificaatarchief.

Omdat er nu twee certificaatwinkels op Expressway zijn, zijn er meerdere scenario's van certificaatwinkels.
Voorwaarde 1: Upgrade
Wanneer de Expressway wordt bijgewerkt van x15.4 of eerder dan x15.5, is deze voorwaarde waar. Bestaande certificaten uit de x15.4-versie worden gekopieerd naar twee (2) certificaatstores. Op de x15.5-client en -server zijn de te-certificaten hetzelfde.

CA 1 = Interne CA
CA 2 = Openbare CA
In de volgende afbeelding heeft Expressway Core een clientcertificaat met server-EKU dat alleen is ondertekend door CA 2 (Public CA) en een servercertificaat met server-EKU dat alleen is ondertekend door CA 2 (Public CA). Op dezelfde manier heeft Expressway E een clientcertificaat met de server EKU ondertekend door CA2 (openbare CA) en een servercertificaat met server EKU alleen ondertekend door CA 2 (openbare CA).

Als het Expressway-kernservercertificaat geen client-EKU, Unified communications traversal zone, MRA heeft, werkt de WebRTC-proxy niet. Zorg ervoor dat het Expressway Core-servercertificaat een client-EKU heeft. Dit is een veel voorkomend geval waarbij gebruikers ervoor kiezen om alle certificaten van openbare CA te ondertekenen. Aangezien de openbare CA Client EKU niet in certificaten opneemt, wordt de zone Unified communications traversal wel actief.
Als u de UC-zone actief wilt maken, kunt u de EKU-controle op Expressway E uitschakelen. Dit brengt de UC-zone naar voren. SSH-tunnels blijven echter inactief. Vanaf vandaag vereist de SSH-tunnelcommunicatie op 2222 validatie van de klant-EKU.
MRA-clientaanmelding en WebRTC-proxyfuncties werken niet. Je zou je toevlucht kunnen nemen tot een privé-CA.
On Expressway-Edge ExtendedKeyUsage controleren ON.
xconfiguration SIP TLS Certificate ExtendedKeyUse Checking Mode: Aan:

Mislukte Unified Communication Zone:

Expressway E-logs tonen waar 10.106.80.16 = Expressway Core, 10.106.80.31 = Expressway Edge:

Schakel de EKU-controle uit op Expressway E.
xconfiguration SIP TLS Certificate ExtendedKeyUse Checking Mode: Uit

Unified communication zone Actief:

De ssh-tunnels mislukten echter nog steeds:

Expressway-gebeurtenislogboeken:

CA 1 = Interne CA
CA 2 = Openbare CA

Deze voorwaarde is een succesgeval. Ongeacht of de EKU-controlemodus AAN/UIT is, worden de zone voor Unified Communication en de SSH-tunnel beide actief. MRA-klanten werken.
Het maakt niet uit of de Expressway Edge EKU-controle UIT of AAN is. Het Expressway-kernclientcertificaat bevat client-EKU:


SSH-tunnels op Expressway-kern Actief:

SSH-tunnels op Expressway Edge Active:

MRA-zonestatus voor Unified Communication Actief:


MRA Client logt in en registreert:

Opmerking: vergelijk en noteer EKU's die aanwezig zijn in certificaten voor MRA en WebRTC-proxy om te werken. Het is een vergelijking tussen werkende en niet-werkende implementatie.
CA 1 = Interne CA
CA 2 = Openbare CA

In voorwaarde 3 worden alle certificaten ondertekend door interne CA (CA1).

In conditie 4 zijn de Expressway-core client- en servercertificaten (CA1) intern CA-ondertekend en zijn zowel client- als server-EKU aanwezig. Het Expressway E-servercertificaat is openbaar, CA-ondertekend en heeft alleen server-EKU. Servercertificaat wordt gekopieerd naar clientcertificaatarchief en kiest Servercertificaatbestand uploaden als clientcertificaat.
In Voorwaarde 4, wanneer de TLS-verbinding wordt gemaakt naar far-end, als Expressway -E een TLS-client hallo stuurt, moet far-end de client-EKU-controle uitschakelen (omdat het clientcertificaat geen client-authentische EKU heeft), anders is de TLS-verbinding mislukt.
Er kunnen veel meer voorwaarden of scenario's in het veld zijn op basis van gebruikersimplementatie en gebruiksscenario's en alle kunnen niet worden gedekt vanwege mijn beperkte gedachtestroom. Punten om te onthouden zijn echter:
Deze redenering is vastgesteld met deze testgevallen.
Voor dit scenario presenteert Expressway het clientcertificaat tijdens de MTLS-handshake met Webex.
Een videogesprek naar de Webex-bijeenkomst:
Voorbeeld gespreksstroom Jabber -à CUCM -à Exp Core - à Exp Edge - à Webex
10.106.80.31= Rand snelweg
163 129 37 33 = Webex
2026-03-24T11:54:26.106+00:00 smartslave tvcs: UTCTime="2026-03-24 11:54:26,106" Module="network.sip" Level="DEBUG": Action="Sent" Local-ip="10.106.80.31" Local-port="25002" DST-ip="163.129.37.33" DST-port="5061"
Expressway Edge heeft een clientcertificaat met dit serienummer (2f0000004c869c77c8981becde00000000004c).
Expressway Edge stuurt client hallo naar 'Webex' tijdens TLS-onderhandeling en verzendt vervolgens clientcertificaat.
Serienummer 2f0000004c869c77c8981becde0000000004c:
1. Expressway Edge stuurt client hello (pkt= 13699) naar ‘Webex tijdens mTLS-onderhandeling.
2. Webex stuurt een server hallo naar Expressway Edge (pkt=13701).
3. Webex stuurt het certificaat naar Expressway Edge (pkt=13711).
4. Webex vraagt het Expressway edge-certificaat "CertificateRequest" aan (pkt=13715).
5. Expressway Edge stuurt het certificaat naar Webex (pkt=13718).
(screenshot)

Clientcertificaat van Expressway Edge:

Expressway wordt een serverentiteit tijdens de mTLS-handshake en presenteert het servercertificaat:
Waar Expressway een servercertificaat presenteert, heeft Expressway een beveiligde buurzone boven 5061 met de verificatienaam ON.
Beveiligde buurzone tussen Expressway node x15.5 en Expressway node x8.11.4:
10.106.80.15 (x8.11.4) sends a client hello to 10.106.80.16 (x15.5) (pkt=736)
10.106.80.16 sends a server hello to 10.106.80.15 (pkt=738)
10.106.80.16 (x15.5) presents its server cert during TLS handshake (pkt=742) and requests client’s certificate ie 10.106.80.15 (x8.11.4)
10.106.80.15 (x8.11.4) sends client certificate (pkt=744)

Deze schermafbeelding toont het servercertificaat als overeenkomende serienummers:

Testcase 3: MRA-client is voorzien voor aanmelding en de workflow omvat verificatie van het verkeersservercertificaat tussen Expressway Core en CUCM.
10.106.80.16 = Expressway Core x15.5
10 106 80 38 = CUCM

Expressway Core-clientcertificaat:

| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
1.0 |
15-Apr-2026
|
Eerste vrijgave |