Handling nødvendig: Sikkerhetsoppdatering for eMUDHRA sertifikatautoritet for Webex Calling Local Gateways

Etter sikkerhetshendelsen for eMUDHRA Certificate Authority (CA) i oktober 2026 ble tilliten til fire rotserti Webex Calling fiseringsinstanser fjernet. Hvis den sertifikatbaserte lokale gateway-trunken er avhengig av en av disse myndighetene, bytter du ut det berørte sertifikatet eller kjeden for å opprettholde sikker TLS-tilkobling. Hvis en berørt trunk-enhet er frakoblet, kan innkommende og utgående PSTN-anrop og lokale integrasjoner som er avhengige av den være utilgjengelige.

De berørte rotsertifikatene er:

EmSign Root TLS-CA — G3
EmSign ECC Root CA — G3
emSign Root CS CA - G3
AAA-sertifikattjenester (root for Comodo AAA-tjenester)

AAA Certificate Services ble ikke kompromittert. Den krysssignerte imidlertid de berørte eMUdhra-mellomliggende CA-ene, og ga en alternativ klareringsbane til de kompromitterte sertifikatene.

Kunder som bruker sertifikatbaserte Local Gateway-trunker (LGW) hvis sertifikatkjeder er avhengige av disse myndighetene, påvirkes. Dette inkluderer Sectigo-utstedte sertifikater som kjeder seg til AAA Certificate Services gjennom UserTrust.

Webex Callingavviser nå TLS-tilkoblinger fra berørte lokale gateways. Innkommende og utgående PSTN-anrop, og lokale anropsintegrasjoner som er avhengige av disse gatewayene, vil mislykkes.

Kjør den aktuelle kommandoen fra en autorisert datamaskin som kan nå gatewayens SIP TLS-port. Erstatt lgw.example.com og 5061 med gateway-vertsnavnet og TLS-porten. Hvis ekstern tilgang er begrenset, kjører du kommandoen fra en autorisert intern administrasjonsvert.

Linux eller macOS:

openssl s_client -connect lgw.example.com:5061 -showcerts </dev/null

Windows Kommandoprompt:

openssl s_client -connect lgw.example.com:5061 -showcerts <NUL

Før du begynner

Du trenger tilgang til Control Hub med tillatelse for å vise organisasjonens trunker.
Gateway-vertsnavnet og SIP TLS-porten for hver primær-, redundant- og sikkerhetskopieringsgateway.
Tilgang til en autorisert datamaskin med OpenSSL som kan nå hvert gateway-endepunkt.

Identifiser dine lokale gateway-trunker.

Gå til T jenester > PSTN og ruting > Gat eway-konfigurasjoner > Tr unk i Control Hub.
For kunder som bruker Cisco Calling Plan, er stamlisten også tilgjengelig under Service > An rop > Anropsruting > Tr unk.
Identifiser sertifikatbaserte trunker og registrer den konfigurerte FQDN- eller SRV-adressen, gateway-vertsnavnet og SIP TLS-porten. Gjenta for redundante gateways og sikkerhetskopieringsgateways.

Inspiser hver gateways sertifikatkjede.

Kjør gjeldende OpenSSL-kommando. Utdataene viser sertifikater presentert av den lokale gatewayen; den verifiserer ikke uavhengig hele kjeden mot klar Webex Calling eringslageret.
En TLS-håndtrykksfeil eller mislykket OpenSSL-bekreftelse beviser ikke at gatewayen påvirkes av denne tillitsoppdateringen.

Gjennomgå sertifikatemner og utstedere.

Gå gjennom sertifikatkjede-delen, gjennomgå hvert sertifikats emne (er:) og utsteder (i:). Sjekk fellesnavnet (CN) og hver kjedeoppføring for de mistroiske myndighetene som er oppført ovenfor.
For eksempel identifiserer en oppføring med emnet CN=UserTrust RSA Certification Authority og utsteder CN=AAA Certificate Services et sertifikat utstedt av AAA Certificate Services.

Tolk inspeksjonsresultatene.

Sertifikatkjede-resultat	Status
Enhver s: eller i: linje viser AAA Certificate Services eller en berørt emSign-myndighet	Berørt. Avhjelpe nå.
Ingen av de berørte myndighetene vises, og bagasjerommet er Online i Control Hub	Ikke berørt.
Ingen av de berørte myndighetene vises, men bagasjerommet er frak oblet	Kontakt partneren din eller Cisco TAC for å bekrefte mot Ciscos liste over berørte kunder.
Tilkoblingen går ut eller ingen sertifikatkjede returneres	Ufullstendige. Bekreft nettverkstilgang til gatewayens TLS-port, og prøv på nytt.

En gateway bekreftes som ikke berørt bare når ingen av de oppførte røttene vises og stammen er Online i Control Hub.

Erstatt en berørt sertifikatkjede.

Kontakt sertifikatleverandøren din for å få et erstatningssertifikat eller en alternativ kjede som avsluttes ved en root som er klarert avWebex Calling. I mange tilfeller kan det eksisterende gateway-sertifikatet beholdes og bare mellomkjeden erstattes. For berørte Sectigo-distribusjoner kan dette innebære å erstatte det AAA-krysssignerte UserTrust-sertifikatet med et passende alternativ.
Installer den oppdaterte sertifikatkjeden på den lokale gatewayen og gjenta sertifikatkontrollen.
Bekreft at koffer ten viser Online i Control Hub, og test innkommende og utgående anrop.

Bekreft lokal gateway-tilkobling.

Gjenta OpenSSL-inspeksjonen og bekreft at erstatningskjeden ikke lenger er avhengig av de mistroede myndighetene.
Bekreft at bagasjerommet viser Online i Control Hub.
Test innkommende og utgående PSTN-anrop og lokale anropsintegrasjoner som bruker trunken.
Gjenta validering for sikkerhetskopiering og redundante gateways.

Hva du skal gjøre videre

Hvis kjeden ser riktig ut, men kofferten forblir frakoblet, svekket eller ukjent:

Kontroller at sertifikatet er gyldig og riktig installert.
Kontroller hele mellomliggende CA-kjeden og forventet sertifikatidentitet.
Se gjennom TLS-tilkoblings- og sertifikatvalideringsfeil på gatewayen.
Kontakt sertifikatleverandøren, Cisco-partneren eller Cisco Technical Assistance Center (TAC) hvis problemet vedvarer. Når du kontakterCisco Technical Assistance Center, oppgi organisasjons-ID, berørte trunkdetaljer, gateway-vertsnavn, informasjon om sertifikatkjeden og relevante TLS-feilmeldinger.

Relatert informasjon:

Cisco AI Assistant

Takk for tilbakemeldingen.

Liten bedrift

Bedrift

Enheter

Løsninger for

Ressurser

Firma