Förtroendekedja

Du hämtar den betrodda certifikatkedjan från Control Hub och installerar det på dina XSPs under den första konfigurationen. Vi förväntar oss att uppdatera certifikatet innan det upphör och meddelar dig om hur och när det ska ändras.

Dina HTTP-servergränssnitt

XSP måste presentera ett offentligt signerat servercertifikat för Webex enligt beskrivningen i Beställningscertifikat. Ett själv signerat certifikat skapas för gränssnittet när du först skyddar gränssnittet. Det här certifikatet är giltigt i ett år från och med det datumet. Du måste ersätta det själv signerade certifikatet med ett offentligt signerat certifikat. Det är ditt ansvar att begära ett nytt certifikat innan det upphör.

Prenumerera på Webex statussida

Kontrollera först https://status.webex.com när du upplever ett oväntat avbrott i tjänsten. Om du inte har ändrat din konfiguration i Control Hub eller BroadWorks innan avbrottet ska du kontrollera statussidan. Läs mer om hur du prenumererar på status och incidentmeddelanden i Webexhjälpcenter.

Använda Control Hub Analytics

Webex spårar användnings- och kvalitetsdata för din organisation och dina kundorganisationer. Läs mer om Control Hub Analytics i Webex hjälpcenter.

Nätverksproblem

Kunder eller användare skapas inte i Control Hub med flowflödesetablering:

• Kan programservern nå URL:en för tillhandahållande?

• Är provisioneringskontot och lösenordet korrekta, finns det kontot i BroadWorks?

Kluster misslyckas konsekvent med anslutningstester:

MTLS-anslutningen till autentiseringstjänsten förväntas misslyckas när du skapar det första klustret i partnerhubben, eftersom du måste skapa klustret för att få åtkomst till Webex-certifikatkedjan. Utan det kan du inte skapa ett pålitligt ankare i verifieringstjänstenS XSPs, så testets MTLS-anslutning från Partner Hub lyckas inte.

• Är XSP-gränssnitten allmänt tillgängliga?

• Använder du rätt portar? Du kan ange en port i gränssnittsdefinitionen på klustret.

Gränssnitt misslyckas validering

Xsi-Actions och Xsi-Events-gränssnitt:

• Kontrollera att gränssnitts-URL:erna är korrekt angivna i klustret i partnerhubben, inklusive /v2.0/ i slutet av URL:erna.

• Kontrollera att brandväggen tillåter kommunikation mellan Webex och dessa gränssnitt.

• Läs om konfigurationsråden i det här dokumentet.

Gränssnitt för verifieringstjänsten:

• Kontrollera att gränssnitts-URL:erna är korrekt angivna i klustret i partnerhubben, inklusive /v2.0/ i slutet av URL:erna.

• Kontrollera att brandväggen tillåter kommunikation mellan Webex och dessa gränssnitt.

• Läs om konfigurationsråden i det här dokumentet, med särskild uppmärksamhet på:

  1. Se till att du har delat RSA-nycklar över alla XSP:er.
  2. Se till att du har angett AuthService-URL till webbbehållaren på alla XSPs.
  3. Om du redigerade TLS-chifferkonfigurationen ska du kontrollera att du använde den korrekta namnkonventionen. XSP kräver att du anger IANA-namnformatet för TLS-chiffer. En tidigare version av detta dokument angav felaktigt de chiffer som krävs i namnkonventionen för OpenSSL.

  4. Om du använder mTLS med autentiseringstjänsten, är då Webex-klientcertifikaten som har lästs in på din XSP/ADP trust store? Är appen (eller gränssnittet) konfigurerad för att kräva klientcertifikat?

  5. Om du använder CI-tokenvalidering med autentiseringstjänst, är appen (eller gränssnittet) konfigurerat så att det inte krävs klientcertifikat?

Klientproblem

Kontrollera att klienten är ansluten till BroadWorks

1. Logga in på Webex-appen.

2. Kontrollera att ikonen Samtalsalternativ (en telefon med kugghjulet ovanför) finns på sidopanelen.

   Om ikonen inte finns är det möjligt att användaren ännu inte har aktiverats för samtalstjänsten i Control Hub.

3. Öppna menyn Inställningar/Inställningar och gå till avsnittet Telefontjänster. Du bör se statusen SSO Session du ärinloggad.

   Om en annan telefontjänst, till exempel Webex Calling, visas använder användaren inte Webex för BroadWorks.

Den här verifieringen innebär:

• Klienten har överfört de Nödvändiga Webex-mikrotjänster.

• Användaren har verifierats.

• Klienten har utfärdat en JSON-webbtoken som sedan länge fungerar som en token av ditt BroadWorks-system.

• Klienten har hämtat enhetsprofilen och har registrerats i BroadWorks.

Klientloggar

Alla Webex-appklienter kan skicka loggar till Webex. Detta är det bästa alternativet för mobila klienter. Du bör också spela in användarens e-postadress och ungefärlig tid som problemet inträffade om du vill ha hjälp från TAC. Mer information finns i Var hittar jag support för Cisco Webex?

Om du behöver samla in loggar manuellt från en Windows-dator finns de på följande sätt:

Windows-dator: C:\Users\{username}\AppData\Local\CiscoSpark

Mac: /Users/{username}/Library/Logs/SparkMacDesktop

Problem med användar inloggning

mTLS Auth är felaktigt konfigurerad

Om alla användare påverkas ska du kontrollera mTLS-anslutningen från Webex till din autentiseringstjänsts URL:

• Kontrollera att antingen autentiseringstjänstens program eller det gränssnitt som används är konfigurerat för mTLS.

• Kontrollera att Webex-certifikatkedjan är installerad som en betrodd ankare.

• Kontrollera att servercertifikatet i gränssnittet/programmet är giltigt och signerat av en välkänd CA.

Kända BroadWorks-felkonfigurationer

chainDepth för låg

• Villkor: Du har följt proceduren för att kopiera certifikatkedjan till XSP:en och använda den för att skapa en betrodd ankare för att validera Cisco Webex klientanslutningar. XSP kör R21 SP1.

• Symtom: I R21 XSP_CLI/Interface/HttpClientAuthentication/Trusts> get visar inte alla förväntade certifikat i utfärdarkedjan.

• Orsak: I R21 finns det chainDepth parametern som, om den är för lågt inställd, förhindrar att hela certifikatutfärdarekedjan läggs till i den betrodda ankaren.

• Åtgärd:/XSP_CLI/Interface/Http?ClientAuthentication> set chainDepth 3

  Vid skrivtiden har Webex-klientcertifikatkedjan två mellanliggande utf?rdare. Ställ inte in denna parameter under 2, särskilt om den redan är högre. I händelse av att kedjanDepth inte är under 2 kan det bero på en korrupt kedjefil.