Finesse-fout "SSPeerUnverifiedException" voor gadgets die op CA-ondertekende servers worden gehost

Inleiding

Dit document beschrijft de stappen om problemen op te lossen in het scenario waarbij een certificaatautoriteit (CA)-ondertekende certificaatketen wordt geüpload naar Finesse voor een externe webserver die een gadget host, maar de gadget niet te laden wanneer u inlogt bij Finesse en u de fout "SSLPeerUnverifiedException" ziet.

Bijgedragen door Gino Schweinsberger, Cisco TAC Engineer.

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• SSL-certificaten
• Finesse administratie
• Windows-serverbeheer
• Packet-opnameanalyse met Wireshark

Gebruikte componenten

De informatie in dit document is gebaseerd op de volgende softwareversies:

• Unified Contact Center Express (UCS X) 11.x
• Finesse 11.x

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

Dit zijn de voorwaarden waaronder de fout kan optreden:

• Stel dat de certificaatvertrouwensketen is geüpload naar Finesse
• Zorg ervoor dat de juiste servers/services opnieuw zijn opgestart
• Stel dat de gadget is toegevoegd aan de Finesse-lay-out met een HTTPS URL en dat de URL bereikbaar is

Dit is de fout die is waargenomen wanneer de agent zich aanmeldt bij Finesse:

"Er waren problemen met het maken van dit gadget. javax.net.ssl.SLPeerUnverifiedException: peer niet geverifieerd"

Problemen

Scenario 1: De hostserver onderhandelt over onveilige TLS

Wanneer Finesse Server een verbindingsverzoek doet aan de Hosting-server, adverteert Finesse Tomcat een lijst met encryptie-algoritmen die zij ondersteunt.

Sommige algoritmen worden niet ondersteund vanwege beveiligingskwetsbaarheden,

Als de Hosting server een van deze algoritmen selecteert, wordt de verbinding geweigerd:

• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA

Deze algoritmen zijn gekend om zwakke efemere sleutels van Diffie-Hellman te gebruiken wanneer het over de verbinding onderhandelt, en de kwetsbaarheid Logjam maakt dit een slechte keus voor verbindingen van TLS.

Volg het TLS-handshake-proces in een pakketopname om te zien welk algoritme wordt onderhandeld.

1. Finesse presenteert de lijst met ondersteunde algoritmen in de stap Client Hello:

2. Voor deze verbinding werd TLS_DHE_RSA_WITH_AES_256_CBC_SHA geselecteerd door de Hosting server tijdens de stap Server Hello omdat dat hoger is op zijn lijst van voorkeursalgoritmen.

3. Finesse stuurt een fatale waarschuwing en beëindigt de verbinding:

Oplossing

Om het gebruik van deze algoritmen te voorkomen, moet de Hosting server geconfigureerd zijn om deze een lage prioriteit te geven, of ze moeten volledig uit de lijst met beschikbare algoritmen verwijderd worden. Dit kan worden gedaan op een Windows Server met de Windows Group Policy editor (gpedit.msc).

Opmerking: Voor meer informatie over de effecten van Logjam in Finesse en het gebruik van gpedit, check:

Scenario 2: Het certificaat heeft een niet-ondersteund ondertekeningsalgoritme

Windows Server-certificeringsinstanties kunnen nieuwere handtekeningsstandaarden gebruiken om certificaten te ondertekenen. Zelfs het biedt grotere veiligheid dan SHA, is de goedkeuring van deze normen buiten de producten van Microsoft laag en beheerders zullen waarschijnlijk in interoperabiliteitskwesties lopen.

Finesse Tomcat vertrouwt op de SunMSCAPI security provider van Java om ondersteuning mogelijk te maken voor de verschillende handtekeningsalgoritmen en cryptografische functies die door Microsoft worden gebruikt. Alle huidige versies van Java (1.7, 1.8 en 1.9) ondersteunen alleen deze handtekeningalgoritmen:

• MD5 met RSA
• MD2S met RSA
• GEEN met RSA
• SHA1 met RSA
• SHA256 met RSA
• SHA384 met RSA
• SHA512 met RSA

Het is een goed idee om de versie van Java die op de server van Finesse draait te controleren om te bevestigen welke algoritmen in die versie worden ondersteund. De versie kan via deze opdracht worden gecontroleerd vanuit root toegang: java - versie

Opmerking: voor meer informatie over de Java SunMSCAPI-provider raadpleegt u https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunMSCAPI

Als een certificaat wordt voorzien van een andere handtekening dan de hierboven genoemde, kan Finesse het certificaat niet gebruiken om een TLS-verbinding te maken met de hostserver. Hiertoe behoren certificaten die zijn ondertekend met een ondersteund handtekeningtype, maar zijn afgegeven door certificeringsinstanties die hun eigen midden- en basiscertificaten hebben ondertekend met iets anders.

Als u een pakketopname bekijkt, sluit Finesse de verbinding met een "noodsignaal: Fout: certificaat onbekend", zoals in de afbeelding.

Op dit punt is nodig om de certificaten te controleren die worden aangeboden door de Hosting server en te zoeken naar niet-ondersteunde handtekeningsalgoritmen. Het is gebruikelijk om RSASSA-PSS als problematisch handtekeningsalgoritme te zien:

Als een certificaat in de keten is ondertekend met RSASSA-PSS, mislukt de verbinding. In dit geval toont de pakketopname aan dat de Root CA RSASSA-PSS gebruikt voor zijn eigen certificaat: 

Oplossing

Om dit probleem op te lossen, moet er een nieuw certificaat worden afgegeven door een CA-provider die alleen een van de ondersteunde SunMSCAPI-handtekeningstypen gebruikt die in de gehele certificaatketen worden vermeld, zoals eerder uitgelegd. 

Opmerking: voor meer informatie over het RSASSA-PSS-handtekeningsalgoritme, surf naar https://pkisolutions.com/pkcs1v2-1rsassa-pss/

Opmerking: Deze kwestie wordt gevolgd in het gebrek CSCve79330