Introduction
Ce document décrit comment configurer la prise en charge de Cisco Customer Voice Portal (CVP) Call Server et VXML (Voice Extensible Markup Language) Server Transport Layer Security (TLS) pour le protocole HTTP (HyperText Transfer Protocol).
Conditions préalables
Conditions requises
Cisco vous recommande de prendre connaissance des rubriques suivantes :
- Serveur VXML CVP
- Navigateur vocal virtuel Cisco (CVB)
- Passerelles VXML
Components Used
Les informations contenues dans ce document sont basées sur les versions de logiciel suivantes :
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Informations générales
Actuellement, le serveur VXML peut avoir trois interfaces sécurisées avec différents composants, comme l'illustre l'image.
Interface TLS du serveur VXML
Interface 1. Il s'agit de l'interface HTTP (Hypertext Transfer Protocol) entre la passerelle VXML, le navigateur vocal virtualisé Cisco (CVB) et le serveur VXML. Ici, le serveur VXML agit en tant que serveur.
Interface 2. Il s'agit de l'interface HTTP type dans laquelle le serveur VXML interagit avec un serveur Web externe qui utilise l'interface HTTP/SOAP (Simple Object Access Protocol). Cette interface est définie comme faisant partie de l'élément personnalisé ou de l'élément WebService ou SOAP.
Interface 3. Il s'agit d'une base de données externe (DB) (Microsoft Structured Query Language (MSSQL) Server et ORACLE DB), qui utilise une interface d'élément de base de données intégrée ou une interface d'élément personnalisé.
Dans ce scénario, dans l'interface 1., le serveur VXML agit en tant que serveur et dans l'interface 2. et 3., VXML Server agit en tant que clients sécurisés.
Problème : Comment activer TLS 1.2 sur différentes interfaces du serveur VXML CVP
CVP VXML Server communique avec différents périphériques et serveurs à l'aide de différentes interfaces. TLS 1.2 doit être activé sur tous ces périphériques pour atteindre le niveau de sécurité souhaité.
Solution
Procédure d'activation de TLS 1.2 dans l'interface 1
Dans cette interface, comme décrit précédemment, CVP VXML Server agit en tant que serveur. Cette implémentation sécurisée est effectuée par Tomcat. Cette configuration est contrôlée par server.xml dans Tomcat.
Configuration type du connecteur :
<Connector SSLCertificateFile="C:\Cisco\CVP\conf\security\vxml.crt" SSLCertificateKeyFile="C:\Cisco\CVP\conf\security\vxml.key" SSLEnabled="true" acceptCount="1500"
ciphers="TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256"
clientAuth="false" disableUploadTimeout="true" enableLookups="false" executor="tomcatThreadPool" keyAlias="vxml_certificate"
keystoreFile="C:\Cisco\CVP\conf\security\.keystore" keystorePass="3WJ~RH0WjKgyq3CKl$x?7f0?JU*7R3}WW0jE,I*_RC8w2Lf" keystoreType="JCEKS" maxHttpHeaderSize="8192" port="7443"
protocol="org.apache.coyote.http11.Http11NioProtocol" scheme="https" secure="true" sslEnabledProtocols="TLSv1, TLSv1.1, TLSv1.2" sslProtocol="TLS"/>
Cet exemple a TLS v1.2, de sorte que les paramètres à configurer (sslEnabledProtocols et certificat) ont la configuration requise pour prendre en charge TLS 1.2.
Utilisez java keytool.exe afin de générer des certificats TLS 1.2. Cet outil est disponible à l'adresse Cisco\CVP\jre\bin\.
Documentation de Keytool
Procédure d'activation de TLS 1.2 dans l'interface 2
Il s’agit de l’interface la plus utilisée. Ici, le serveur VXML agit comme un client et doit ouvrir une communication sécurisée vers un serveur Web externe.
Il y a deux façons différentes de gérer cela.
- Utiliser le code personnalisé.
- Utilisez le cadre CVP.
Ceci décrit l'utilisation du cadre CVP.
À partir de la version 11.6, elle est activée par défaut, pour les versions précédentes, vérifiez ce tableau :
Si vous avez installé une version ES affectée par ce défaut : CSCvc39129 VXML Server en tant que client TLS, vous devez appliquer cette configuration manuelle :
Étape 1. Ouvrez l'éditeur du Registre et accédez à HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Apache Software Foundation\Procrun 2.0\VXMLServer\Parameters\Java.
Étape 2. Ouvrez Options Key et add-Dhttps.client.protocol=TLSv1.2 à la fin.
Étape 3. Redémarrez le service Cisco CVP VXMLServer.
Voici la liste rapide de la prise en charge des protocoles par défaut dans différentes versions de JAVA.
-Djdk.tls.client.protocols=TLSv1.2.
Cette configuration impose au serveur VXML d'utiliser TLS 1.2 dans Java SE Development Kit (JDK) 7 et JDK6.
Remarque : SSL est désactivé par défaut.
Procédure d'activation de TLS 1.2 dans l'interface 3
Dans cette interface, comme décrit précédemment, CVP VXML Server agit en tant que client et en tant que serveur de base de données tiers.
Assurez-vous que le serveur de base de données tiers prend en charge TLS 1.2 et TLS 1.2 est activé sur celui-ci.
Par exemple, si vous utilisez SQL Server 2014 avec Service Pack (SP) 2, il prend en charge TLS 1.2 et confirme que Le protocole TLS 1.2 est activé dans le Registre comme indiqué ici sur SQL Server :
SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
Afin d'activer TLS 1.2 pour l'interface 3 côté CVP :
Étape 1. Ouvrez l'éditeur du Registre et accédez à HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Apache Software Foundation\Procrun 2.0\VXMLServer\Parameters\Java.
Étape 2. Ouvrez Options Key et add-Djdk.tls.client.protocols=TLSv1.2 à la fin.
Étape 3. Redémarrez le service Cisco CVP VXMLServer.
Note: Vérifiez ce bogue pour plus de détails : la connexion à la base de données JNDI CSCvg20831 échoue avec CVP11.6 SQL 2014SP2.
Procédure de mise à niveau de la prise en charge JRE pour TLS 1.2
CVP prend en charge la mise à niveau de Java Runtime Environment (JRE) vers la dernière version pour les défauts de bogues.
Ce tableau présente les versions JAVA.
Versions JAVA
Suivez la procédure décrite dans ce lien.
Attention : Mise à niveau de 32 bits à 64 bits et inversement n'est pas pris en charge
Procédure de mise à niveau de Tomcat
La mise à niveau de Tomcat Minor est prise en charge. Cependant, assurez-vous de vérifier les problèmes de compatibilité entre les jarres personnalisées (AXIS, JDBC, etc.) avant d'effectuer la mise à niveau.
Pour plus de détails, consultez la procédure ici.