Algorithme de hachage sûr (SHA) 256 pour le Customer Voice Portal (CVP)

Introduction

Ce document décrit la procédure pour utiliser SHA256 avec CVP.

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• CVP
• Certificats

Composants utilisés

Les informations dans ce document sont basées sur CVP 10.5.

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est vivant, assurez-vous que vous comprenez l'impact potentiel de n'importe quelle commande.

Informations générales

Commençant en janvier 2016 tous les navigateurs ont rejeté les Certificats SHA1 signés. Ceci n'a pas rendu les services demandés correctement, à moins que vous vous déplaciez de SHA1 à SHA256.

Avec le développement récent dans les algorithmes de calcul aussi bien que la capacité de calcul explosive, SHA1 s'est développé plus faible jour après jour. Ceci a mené à la résistance fondamentale de collision de dégradation du SHA1 et de la cession certaine.

Configurer

Délivrez un certificat la procédure d'échange entre la console d'exécutions CVP (OAMP) :

Sur OAMP

Étape 1. CERT de l'exportation OAMP.

c:\Cisco\CVP\jre\bin\keytool.exe - exportation - v - keystore .keystore - storetype JCEKS - alias oamp_certificate - fichier oamp_security_76.cer

Étape 2. Certificat de la copie OAMP à Callserver et à importation.

c:\Cisco\CVP\jre\bin\keytool.exe - importation - trustcacerts - keystore .keystore - storetype JCEKS - alias orm_oamp_certificate - fichier oamp_security_76.cer

Sur le serveur d'appel

Étape 1. CERT de l'exportation CALLSERVER.

c:\Cisco\CVP\jre\bin\keytool.exe - exportation - v - keystore .ormkeystore - storetype JCEKS - alias orm_certificate - fichier orm_security_108.cer

Étape 2. CERT de la copie CALLSERVER à OAMP et à importation.

c:\Cisco\CVP\jre\bin\keytool.exe - importation - trustcacerts - keystore .keystore - storetype JCEKS - alias oamp_orm_certificate - fichier orm_security_108.cer

Étape 3. Certificat d'orm d'exportation dans le keystore de serveur d'appel.

C:\Cisco\CVP\conf\security > c:\Cisco\CVP\jre\bin\keytool.exe - importation - des trustcacerts - le keystore .keystore - le storetype JCEKS - alias vxml_orm_certificate - classent orm_security_108.cer

Vérifiez

Vous pouvez valider si la communication protégée est établie entre les composants. Naviguez vers la page > la Gestion de périphériques OAMP > server> > statistiques <managed

Des stats doivent être affichés.

Vous pouvez employer JConsole pour établir une connexion si la Sécurité est correctement installée :

Étape 1. c:\Cisco\CVP\conf\orm _jmx.conf sur OAMP ressemble à :

javax.net.debug = all
com.sun.management.jmxremote.ssl.need.client.auth = false
com.sun.management.jmxremote.authenticate = false
com.sun.management.jmxremote.port = 2099
com.sun.management.jmxremote.ssl = true
javax.net.ssl.keyStore=C:\Cisco\CVP\conf\security\.ormkeystore
javax.net.ssl.keyStorePassword=<local security password>

Étape 2. Ouvrez le jconsole de la commande.  Utilisez la commande :

C:\Cisco\CVP\jre\bin >jconsole.exe - J-Djavax.net.ss l.trustStore= C:\Cisco\CVP\conf\security\ .keystore - Le mot de passe de Sécurité de =<oamp de J-Djavax.net.ss l.trustStorePassword/client> de jconsole - J-Djavax.net.ss l.keyStore = C:\Cisco\CVP\conf\security\ .keystore - mot de passe de Sécurité de =<oamp de J-Djavax.net.ss l.keyStorePassword/client> de jconsole - J-Djavax.net.ss l.keyStoreType=JCEKS - mettent au point - J-Djavax.net.ss l.trustStoreType =JCEKS

Clé dans l'ip> <managed de serveur : port eg:2099> de jmx de <secure dans le domaine de processus distant.

Note: JConsole doit se connecter sans demande pour application pour sauter la méthode sécurisée.

Étape 3. Wireshark tandis que la connexion de jconsole est appelée. La capture te donne la vue dans les détails négociés tandis que prise de contact de Sécurité.

Suivis dans JMX

L'implémentation des utilisations java.util.logging JMX de se connecter mettent au point des suivis. Plusieurs de ces suivis concernent les classes non exposées internes, mais elles peuvent vous aider à comprendre ce qui va en fonction avec votre application.

L'implémentation JMX a deux ensembles d'enregistreurs :

• javax.management. \ * : tous les enregistreurs liés au JMX API
• javax.management.remote. \ * : les enregistreurs ont spécifiquement rapporté au distant API JMX

Vous pouvez trouver une description plus complète des enregistreurs JMX ici.

Vous pouvez lancer les suivis JMX de deux manières différentes :

• Statiquement, avec l'utilisation d'un fichier logging.properties
• Dynamiquement, avec l'utilisation d'un JMXTracing MBean. Dans l'expert en logiciel 6 de Javas, vous pouvez faire ceci pour une application, même si le connecteur JMX n'est pas activé sur la ligne de commande.

Utilisez un fichier logging.properties

Commencez votre application avec ces indicateurs :

java -Djava.util.logging.config.file=<logging.properties> ....

là où logging.properties lance des suivis pour des enregistreurs JMX :

handlers= java.util.logging.ConsoleHandler
.level=INFO

java.util.logging.FileHandler.pattern = %h/java%u.log
java.util.logging.FileHandler.limit = 50000
java.util.logging.FileHandler.count = 1
java.util.logging.FileHandler.formatter = java.util.logging.XMLFormatter

java.util.logging.ConsoleHandler.level = FINEST
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter

// Use FINER or FINEST for javax.management.remote.level - FINEST is
// very verbose...
//
javax.management.level=FINEST
javax.management.remote.level=FINER