Contenido

Introducción

Antecedentes

Confirme la licencia del teléfono VPN en el ASA

Exporte restricto y exporte CUCM sin restricción

Problemas frecuentes en el ASA

Certificados para el uso en el ASA

Trustpoint/certificado para la exportación ASA y la importación CUCM

El ASA presenta el certificado autofirmado ECDSA en vez del certificado configurado RSA

Base de datos externa para la autenticación de los usuarios del teléfono IP

Coincidencias del hash del certificado entre la lista de la confianza del certificado ASA y del teléfono VPN

Controle el hash SHA1

Descargue Configuración del teléfono IP el fichero

Decodifique el hash

Equilibrio de carga y Teléfonos IP VPN

CSD y Teléfonos IP

Registros ASA

Depuraciones ASA

Reglas DAP

Valores heredados de DfltGrpPolicy o de otros grupos

Cifras utilizadas del cifrado

Problemas frecuentes en el CUCM

Configuraciones VPN no aplicadas al teléfono IP

Método de autenticación del certificado

Control del ID del host

Resolución de otros problemas

Registros y depuraciones a utilizar en el ASA

Registros del teléfono IP

Problemas correlacionados entre los registros de los registros ASA y del teléfono IP

Registros ASA

Registros del teléfono

Palmo a la característica del puerto de la PC

Configuración del teléfono IP cambios mientras que es conectado por el VPN

Renovación del certificado ASA SSL

Introducción

Este documento describe cómo resolver problemas los problemas con los Teléfonos IP que utiliza el protocolo de Secure Sockets Layer (SSL) (Cliente de movilidad Cisco AnyConnect Secure) para conectar con Cisco un dispositivo de seguridad adaptante (ASA) se utilice que como un gateway de VPN y para conectar con las Comunicaciones unificadas de Cisco a un encargado (CUCM) que está utilizado como servidor de la Voz.

Por los ejemplos de la configuración de AnyConnect con los teléfonos VPN, refiera a estos documentos:

- SSLVPN con el ejemplo de la configuración de los Teléfonos IP

- Teléfono de AnyConnect VPN con el ejemplo de la configuración de autenticación del certificado

Antecedentes

Antes de que usted despliegue SSL VPN con los Teléfonos IP, confirme que usted ha cumplido estos requisitos iniciales para las licencias de AnyConnect para el ASA y para la versión restringida exportación E.E.U.U. del CUCM.

Confirme la licencia del teléfono VPN en el ASA

La licencia del teléfono VPN activa la característica en el ASA. Para confirmar el número de usuarios que puedan conectar con el AnyConnect (independientemente de si es un teléfono IP), controle la licencia superior de AnyConnect SSL. ¿Refiérase a qué licencia ASA es necesaria para el teléfono IP y las conexiones VPN móviles? para conocer más detalles.

En el ASA, utilice el comando show version para controlar si se activa la característica. El nombre de la licencia diferencia con la versión ASA:

- Versión 8.0.x ASA: el nombre de la licencia es AnyConnect para el teléfono de Linksys.

- El ASA release/versión 8.2.x y más adelante: el nombre de la licencia es AnyConnect para el teléfono de Cisco VPN.

Aquí está un ejemplo para la versión 8.0.x ASA:

ASA5505(config)# show ver

Cisco Adaptive Security Appliance Software Version 8.0(5)

Device Manager Version 7.0(2)

<snip>

Licensed features for this platform:

VPN Peers                    : 10

WebVPN Peers                 : 2

AnyConnect for Linksys phone : Disabled

<snip>

This platform has a Base license.

Aquí está un ejemplo para las versiones 8.2.x ASA y más adelante:

ASA5520-C(config)# show ver

Cisco Adaptive Security Appliance Software Version 9.1(1)

Device Manager Version 7.1(1)

<snip>

Licensed features for this platform:

AnyConnect Premium Peers          : 2              perpetual

AnyConnect Essentials             : Disabled       perpetual

AnyConnect for Cisco VPN Phone    : Disabled       perpetual

<snip>

This platform has an ASA 5520 VPN Plus license.

Exportación restringida y exportación CUCM sin restricción

Usted debe desplegar una versión restringida exportación E.E.U.U. de CUCM para la función del teléfono VPN.

Si usted utiliza una versión sin restricción de la exportación E.E.U.U. de CUCM, observe eso:

- Las configuraciones de Seguridad del teléfono IP se modifican para inhabilitar el cifrado de la señalización y de los media; esto incluye el cifrado proporcionado por la función del teléfono VPN.

- Usted no puede exportar los detalles VPN a través de la importación/de la exportación.

- Las casillas de verificación para el perfil VPN, el gateway de VPN, el grupo VPN, y configuración de la característica VPN no se visualizan.

Note: Una vez que usted actualiza a la versión sin restricción de la exportación E.E.U.U. de CUCM, usted no puede actualizar más adelante a, o realice un fresco instalan de, la versión restringida exportación E.E.U.U. de este software.

Problemas frecuentes en el ASA

Note: Usted puede utilizar el analizador del CLI de Cisco (clientes registrados solamente) para ver un análisis de las salidas del comando show. Usted debe también referir a la información importante en el documento de Cisco de los comandos Debug antes de que usted utilice los comandos debug.

Certificados para el uso en el ASA

En el ASA, usted puede utilizar los Certificados uno mismo-firmados SSL, los Certificados de tercera persona SSL, y los Certificados del comodín; ninguno de estos seguro la comunicación entre el teléfono IP y el ASA.

Solamente un certificado de identidad puede ser utilizado porque solamente un certificado se puede asignar a cada interfaz.

Para los Certificados de tercera persona SSL, instale el encadenamiento completo en el ASA, e incluya cualquier intermedio y certificado raíz.

Trustpoint/certificado para la exportación ASA y la importación CUCM

El certificado que el ASA presenta al teléfono IP durante la negociación SSL se debe exportar del ASA e importar en el CUCM. Controle el trustpoint asignado al interfaz al cual los Teléfonos IP conectan para saber qué certificado a exportar del ASA.

Utilice el comando SSL del funcionamiento de la demostración para verificar el trustpoint (certificado) que se exportará. Refiera al teléfono de AnyConnect VPN con el ejemplo de la configuración de autenticación del certificado para más información.

Note: Si usted ha desplegado un certificado de tercera persona a uno o más ASAs, usted necesita exportar cada certificado de identidad de cada ASA y después importarlo al CUCM como teléfono-VPN-confianza.

El ASA presenta el certificado autofirmado ECDSA en vez del certificado configurado RSA

Cuando ocurre este problema, los teléfonos de un más nuevo modelo no pueden conectar, mientras que los teléfonos modelo más viejos no experimentan ninguna problemas. Aquí sea abre una sesión el teléfono cuando ocurre este problema:

VPNC: -protocol_handler: SSL dpd 30 sec from SG (enabled)

VPNC: -protocol_handler: connect: do_dtls_connect

VPNC: -do_dtls_connect: udp_connect

VPNC: -udp_connect: getsockname failed

VPNC: -udp_connect: binding sock to eth0 IP 63.85.30.39

VPNC: -udp_connect: getsockname failed

VPNC: -udp_connect: connecting to 63.85.30.34:443

VPNC: -udp_connect: connected to 63.85.30.34:443

VPNC: -do_dtls_connect: create_dtls_connection

VPNC: -create_dtls_connection: cipher list: AES256-SHA

VPNC: -create_dtls_connection: calling SSL_connect in non-block mode

VPNC: -dtls_state_cb: DTLS: SSL_connect: before/connect initialization

VPNC: -dtls_state_cb: DTLS: SSL_connect: SSLv3 write client hello A

VPNC: -dtls_state_cb: DTLS: SSL_connect: DTLS1 read hello verify request A

VPNC: -dtls_state_cb: DTLS: SSL_connect: SSLv3 write client hello A

VPNC: -dtls_state_cb: DTLS: SSL_connect: SSLv3 flush data

VPNC: -dtls_state_cb: DTLS: write: alert: fatal:illegal parameter

VPNC: -vpnc_set_notify_netsd : cmd: 0x5 event: 0x40000 status: 0x0 error: 0x0

VPNC: -alert_err: DTLS write alert: code 47, illegal parameter

VPNC: -create_dtls_connection: SSL_connect ret -1, error 1

VPNC: -DTLS: SSL_connect: SSL_ERROR_SSL (error 1)

VPNC: -DTLS: SSL_connect: error:140920C5:SSL routines:SSL3_GET_SERVER_HELLO:

old session cipher not returned

VPNC: -create_dtls_connection: DTLS setup failure, cleanup

VPNC: -do_dtls_connect: create_dtls_connection failed

VPNC: -protocol_handler: connect: do_dtls_connect failed

VPNC: -protocol_handler: connect : err: SSL success DTLS fail

En las versiones 9.4.1 y más adelante, la criptografía elíptica de la curva se utiliza para el SSL/TLS. Cuando un cliente curva-capaz elíptico SSL VPN tal como un nuevo modelo del teléfono conecta con el ASA, se negocia la habitación elíptica de la cifra de la curva, y el ASA presenta al cliente SSL VPN con un certificado elíptico de la curva, incluso cuando el interfaz que corresponde se configura con un trustpoint RSA-basado. Para evitar que el ASA presente un certificado uno mismo-firmado SSL, el administrador debe quitar las habitaciones de la cifra que corresponden vía el comando de la cifra SSL. Por ejemplo, para un interfaz que se configure con un trustpoint RSA, el administrador puede ejecutar este comando para solamente negociar las cifras RSA-basadas:

ssl cipher tlsv1.2 custom "AES256-SHA:AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA"

Con la puesta en práctica del ID de bug CSCuu02848 de Cisco, la prioridad se da a la configuración. los Certificados Explícito-configurados se utilizan siempre. Los certificados autofirmados se utilizan solamente en ausencia de un certificado configurado.

Cifras propuestas del cliente

CERT RSA solamente

CERT EC solamente

Ambo Certs

Ninguno

El RSA cifra solamente

CERT de las aplicaciones RSA

Cifras de las aplicaciones RSA

CERT uno mismo-firmado RSA de las aplicaciones

Cifras de las aplicaciones RSA

CERT de las aplicaciones RSA

Cifras de las aplicaciones RSA

CERT uno mismo-firmado RSA de las aplicaciones

Cifras de las aplicaciones RSA

La EC cifra solamente (raro)

La conexión falla

CERT EC de las aplicaciones

Cifras EC de las aplicaciones

CERT EC de las aplicaciones

Cifras EC de las aplicaciones

CERT uno mismo-firmado EC de las aplicaciones

Cifras EC de las aplicaciones

Ambas cifras solamente

CERT de las aplicaciones RSA

Cifras de las aplicaciones RSA

CERT EC de las aplicaciones

Cifras EC de las aplicaciones

CERT EC de las aplicaciones

Cifras EC de las aplicaciones

CERT uno mismo-firmado EC de las aplicaciones

Cifras EC de las aplicaciones

Base de datos externa para la autenticación de los usuarios del teléfono IP

Usted puede utilizar una base de datos externa para autenticar a los usuarios del teléfono IP. Los protocolos tales como el Lightweight Directory Access Protocol (LDAP) o el dial de la autenticación remota en el servicio de usuario (RADIUS) se pueden utilizar para la autenticación de los usuarios del teléfono VPN.

Coincidencias del hash del certificado entre la lista de la confianza del certificado ASA y del teléfono VPN

Recuerde que usted debe descargar el certificado que se asigna al interfaz ASA SSL y cargarlo por teletratamiento como certificado de la Teléfono-VPN-confianza en el CUCM. Diversas circunstancias pudieron causar el hash para este certificado presentado por el ASA para no hacer juego el hash que el servidor CUCM genera y empuja al teléfono VPN a través del archivo de configuración.

Una vez que la configuración es completa, pruebe la conexión VPN entre el teléfono IP y el ASA. Si la conexión continúa fallando, controlar si el hash del certificado ASA hace juego el hash el teléfono IP está esperando:

1. Controle el hash del algoritmo de troceo seguro 1 (SHA1) presentado por el ASA.

2. Utilice el TFTP para descargar Configuración del teléfono IP el fichero del CUCM.

3. Decodifique el hash del hexadecimal al base 64 o del base 64 al hexadecimal.

Controle el hash SHA1

El ASA presenta el certificado aplicado con el comando del trustpoint SSL en el interfaz con el cual el teléfono IP conecta. Para controlar este certificado, abra el hojeador (en este ejemplo, Firefox), y ingrese el URL (el grupo-URL) con el cual los teléfonos deben conectar:

Descargue Configuración del teléfono IP el fichero

De una PC con el acceso directo al CUCM, descargue el fichero de los config TFTP para el teléfono con los problemas de conexión. Dos métodos de la transferencia directa son:

1. Abra a una sesión CLI en Windows, y utilice tftp - i <TFTP Server> CONSIGUE el comando del MAC address >.cnf.xml del <Phone de SEPT.

Note: Si usted recibe un error similar al abajo, usted debe confirmar que la característica del cliente TFTP está activada.

2. Utilice una aplicación tal como Tftpd32  para descargar el fichero:

3. Una vez que se descarga el fichero, abra el XML y encuentre la configuración del vpnGroup. Este ejemplo muestra la sección y el certHash que se verificarán:

<vpnGroup>

<mtu>1290</mtu>

<failConnectTime>30</failConnectTime>

<authMethod>2</authMethod>

<pswdPersistent>0</pswdPersistent>

<autoNetDetect>0</autoNetDetect>

<enableHostIDCheck>0</enableHostIDCheck>

<addresses>

<url1>https://10.198.16.140/VPNPhone</url1>

</addresses>

<credentials>

<hashAlg>0</hashAlg>

<certHash1>5X6B6plUwUSXZnjQ4kGM33mpMXY=</certHash1>

</credentials>

</vpnGroup>

Decodifique el hash

Confirme que ambos valores de troceo hacen juego. El navegador presenta el hash en el formato hexadecimal, mientras que el archivo XML utiliza el base 64, así que convierte un formato al otro para confirmar la coincidencia. Hay muchos traductores disponibles; un ejemplo es el TRADUCTOR, BINARIO .

Note: Si el valor de troceo anterior no hace juego, el teléfono VPN no confía en la conexión que se negocia con el ASA, y la conexión falla.

Equilibrio de carga y Teléfonos IP VPN

el SSL Carga-equilibrado VPN no se utiliza para los teléfonos VPN. Los teléfonos VPN no realizan la validación de certificado real sino que por el contrario utilizar desmenuza empujado hacia abajo por el CUCM para validar los servidores. Porque el Equilibrio de carga VPN es básicamente un cambio de dirección HTTP, requiere los teléfonos validar los certificados múltiples, que lleva al error. Los síntomas del error del Equilibrio de carga VPN incluyen:

- El teléfono alterna entre los servidores y tarda excepcionalmente un tiempo prolongado para conectar o falla eventual.

- Los registros del teléfono contienen los mensajes tales como éstos:

909: NOT 20:59:50.051721 VPNC: do_login: got login response

910: NOT 20:59:50.052581 VPNC: process_login: HTTP/1.0 302 Temporary moved

911: NOT 20:59:50.053221 VPNC: process_login: login code: 302 (redirected)

912: NOT 20:59:50.053823 VPNC: process_login: redirection indicated

913: NOT 20:59:50.054441 VPNC: process_login: new 'Location':

/+webvpn+/index.html

914: NOT 20:59:50.055141 VPNC: set_redirect_url: new URL

<https://xyz1.abc.com:443/+webvpn+/index.html>

CSD y Teléfonos IP

Actualmente, los Teléfonos IP no utilizan el Cisco Secure Desktop (CSD) y no conectan cuando el CSD se activa para el grupo de túnel o global en el ASA.

Primero, confirme si el ASA tiene CSD activado. Ingrese el comando webvpn del funcionamiento de la demostración en el ASA CLI:

ASA5510-F# show run webvpn

webvpn

enable outside

csd image disk0:/csd_3.6.6210-k9.pkg

csd enable

anyconnect image disk0:/anyconnect-win-3.1.00495-k9.pkg 1

anyconnect enable

ASA5510-F#

Para controlar los problemas CSD durante una conexión telefónica IP, controle los registros o las depuraciones en el ASA.

Registros ASA

%ASA-4-724002: Group <VPNPhone> User <Phone> IP <172.6.250.9> WebVPN session not

terminated. Cisco Secure Desktop was not running on the client's workstation.

Depuraciones ASA

debug webvpn anyconnect 255

<snip>

Tunnel Group: VPNPhone, Client Cert Auth Success.

WebVPN: CSD data not sent from client

http_remove_auth_handle(): handle 24 not found!

<snip>

Note: En un despliegue grande con una mucha carga de los usuarios de AnyConnect, Cisco recomienda que usted no activa el anyconnect del webvpn de la depuración. Su salida no se puede filtrar por la dirección IP, así que una gran cantidad de información pudo ser creada.

En las versiones 8.2 ASA y más adelante, usted debe aplicar el comando sin-CSD bajo webvpn-atributos del grupo de túnel:

tunnel-group VPNPhone webvpn-attributes

authentication certificate

group-url https://asa5520-c.cisco.com/VPNPhone enable

without-csd

En las versiones anteriores del ASA, esto no era posible, así que la única solución alternativa era inhabilitar el CSD global.

En el Cisco Adaptive Security Device Manager (ASDM), usted puede inhabilitar el CSD para un perfil de la conexión específico tal y como se muestra en de este ejemplo:

Note: Utilice un grupo-URL para apagar la característica CSD.

Reglas DAP

La mayoría de las implementaciones no sólo conectan los Teléfonos IP con el ASA pero también conectan diversos tipos de máquinas (Microsoft, Linux, Mac OS) y de dispositivos móviles (Android, IOS). Por este motivo, es normal encontrar una configuración existente de las reglas de la directiva del acceso dinámico (DAP), donde, la mayor parte del tiempo, está terminación la acción predeterminada bajo el DfltAccessPolicy de la conexión.

Si éste es el caso, cree una regla separada DAP para los teléfonos VPN. Utilice un parámetro específico, tal como el perfil de la conexión, y fije la acción para continuar:

Si usted no crea una directiva específica DAP para los Teléfonos IP, el ASA muestra un golpe bajo el DfltAccessPolicy y falla de conexión:

%ASA-6-716038: Group <DfltGrpPolicy> User <CP-7962G-SEP8CB64F576113> IP

<172.16.250.9> Authentication: successful, Session Type: WebVPN.

%ASA-7-734003: DAP: User CP-7962G-SEP8CB64F576113, Addr 172.16.250.9: Session

Attribute aaa.cisco.grouppolicy = GroupPolicy_VPNPhone

<snip>

%ASA-6-734001: DAP: User CP-7962G-SEP8CB64F576113, Addr 172.16.250.9,

Connection AnyConnect: The following DAP records were selected for this

connection: DfltAccessPolicy

%ASA-5-734002: DAP: User CP-7962G-SEP8CB64F576113, Addr 172.16.250.9: Connection

terminated by the following DAP records: DfltAccessPolicy

Una vez que usted crea una directiva específica DAP para los Teléfonos IP con el conjunto de la acción para continuar, usted puede conectar:

%ASA-7-746012: user-identity: Add IP-User mapping 10.10.10.10 -

LOCAL\CP-7962G-SEP8CB64F576113 Succeeded - VPN user

%ASA-4-722051: Group <GroupPolicy_VPNPhone> User <CP-7962G-SEP8CB64F576113> IP

<172.16.250.9> Address <10.10.10.10> assigned to session

%ASA-6-734001: DAP: User CP-7962G-SEP8CB64F576113, Addr 172.16.250.9, Connection

AnyConnect: The following DAP records were selected for this connection: VPNPhone

Valores heredados de DfltGrpPolicy o de otros grupos

En muchos casos, el DfltGrpPolicy se pone con varias opciones. Por abandono, estas configuraciones se heredan para la sesión del teléfono IP a menos que se especifiquen manualmente en la grupo-directiva que el teléfono IP debe utilizar.

Algunos parámetros que pudieron afectar a la conexión si se heredan del DfltGrpPolicy son:

- grupo-bloqueo

- VPN-túnel-protocolo

- VPN-simultáneo-claves

- VPN-filtro

Asuma que usted tiene este ejemplo de configuración en el DfltGrpPolicy y el GroupPolicy_VPNPhone:

group-policy DfltGrpPolicy attributes

vpn-simultaneous-logins 0

vpn-tunnel-protocol ikev1 ikev2 l2tp-ipsec ssl-clientless

group-lock value DefaultWEBVPNGroup

vpn-filter value NO-TRAFFIC

group-policy GroupPolicy_VPNPhone attributes

wins-server none

dns-server value 10.198.29.20

default-domain value cisco.com

La conexión hereda los parámetros del DfltGrpPolicy que no fueron especificados explícitamente bajo el GroupPolicy_VPNPhone y empuja toda la información al teléfono IP durante la conexión.

Para evitar esto, especifique manualmente los valores que usted necesita directamente en el grupo:

group-policy GroupPolicy_VPNPhone internal

group-policy GroupPolicy_VPNPhone attributes

wins-server none

dns-server value 10.198.29.20

vpn-simultaneous-logins 3

vpn-tunnel-protocol ssl-client

group-lock value VPNPhone

vpn-filter none

default-domain value cisco.com

Para controlar los valores predeterminados del DfltGrpPolicy, utilice la demostración funcionan con todo el comando de la grupo-directiva; este ejemplo aclara la diferencia entre las salidas:

ASA5510-F# show run group-policy DfltGrpPolicy

group-policy DfltGrpPolicy attributes

dns-server value 10.198.29.20 10.198.29.21

vpn-tunnel-protocol ikev1 ikev2 l2tp-ipsec ssl-client ssl-clientless

default-domain value cisco.com

ASA5510-F#

ASA5510-F# sh run all group-policy DfltGrpPolicy

group-policy DfltGrpPolicy internal

group-policy DfltGrpPolicy attributes

banner none

wins-server none

dns-server value 10.198.29.20 10.198.29.21

dhcp-network-scope none

vpn-access-hours none

vpn-simultaneous-logins 3

vpn-idle-timeout 30

vpn-idle-timeout alert-interval 1

vpn-session-timeout none

vpn-session-timeout alert-interval 1

vpn-filter none

ipv6-vpn-filter none

vpn-tunnel-protocol ikev1 ikev2 l2tp-ipsec ssl-client ssl-clientless

Aquí está la salida de la grupo-directiva hereda los atributos con el ASDM:

Cifras utilizadas del cifrado

Un teléfono de AnyConnect VPN probado con las ayudas del teléfono y de la versión de firmware 9.1.1 IP 7962G solamente dos cifras, que son ambo Advanced Encryption Standard (AES): AES256-SHA y AES128-SHA. Si las cifras correctas no se especifican en el ASA, la conexión se rechaza, tal y como se muestra en del registro ASA:

%ASA-7-725010: Device supports the following 2 cipher(s).

%ASA-7-725011: Cipher[1] : RC4-SHA

%ASA-7-725011: Cipher[2] : DES-CBC3-SHA

%ASA-7-725008: SSL client outside:172.16.250.9/52684 proposes the following

2 cipher(s).

%ASA-7-725011: Cipher[1] : AES256-SHA

%ASA-7-725011: Cipher[2] : AES128-SHA

%ASA-7-725014: SSL lib error. Function: SSL3_GET_CLIENT_HELLO Reason: no

shared cipher

Para confirmar si el ASA tiene las cifras correctas activadas, ingrese la demostración ejecutan todo el SSL y muestran los comandos SSL:

ASA5510-F# show run all ssl

ssl server-version any

ssl client-version any

ssl encryption rc4-sha1 aes128-sha1 aes256-sha1 3des-sha1

ssl trust-point SSL outside

ASA5510-F#

ASA5510-F# show ssl

Accept connections using SSLv2, SSLv3 or TLSv1 and negotiate to SSLv3 or TLSv1

Start connections using SSLv3 and negotiate to SSLv3 or TLSv1

Enabled cipher order: rc4-sha1 aes128-sha1 aes256-sha1 3des-sha1

Disabled ciphers: des-sha1 rc4-md5 dhe-aes128-sha1 dhe-aes256-sha1 null-sha1

SSL trust-points:

outside interface: SSL

Certificate authentication is not enabled

ASA5510-F#

Problemas frecuentes en el CUCM

Configuraciones VPN no aplicadas al teléfono IP

La configuración en el CUCM se crea una vez (gateway, grupo, y perfil), aplica las configuraciones VPN en el perfil común del teléfono:

1. Navegue al dispositivo > a las configuraciones del dispositivo > perfil común del teléfono.

2. Ingrese la información de VPN:

3. Navegue al Device (Dispositivo) > Phone (Teléfono) y confirme este perfil se asigna a la Configuración del teléfono:

Certifique el método de autenticación

Hay dos maneras de configurar la autenticación del certificado para los Teléfonos IP: El fabricante instaló el certificado (MIC) y localmente - el certificado significativo (LSC). Refiera al teléfono de AnyConnect VPN con el ejemplo de la configuración de autenticación del certificado para elegir la mejor opción para su situación.

Cuando usted configura la autenticación del certificado, exporte los certificados (raíz CA) del servidor CUCM e impórtelos al ASA:

1. Ábrase una sesión al CUCM.

2. Navegue el Certificate Management (Administración de certificados) unificado del > Security (Seguridad) de la administración OS.

3. Encuentre la función del proxy de la autoridad de certificación (CAPF) o Cisco_Manufacturing_CA; el tipo de certificado depende sobre si usted utilizó autenticación del certificado MIC o LSC.

4. Descargue el fichero a la computadora local.

Una vez que se descargan los ficheros, ábrase una sesión al ASA con el CLI o el ASDM e importe el certificado como certificado CA.

Por abandono, todos los teléfonos que utilizan el VPN se cargan con MICs. Los 7960 y 7940 teléfonos modelo no vienen con un MIC y requieren un procedimiento de la instalación especial de modo que el LSC se registre con seguridad.

Los Teléfonos IP más nuevos de Cisco (8811, 8841, 8851, y 8861) incluyen los Certificados MIC que son firmados por el nuevo SHA2 de fabricación CA:

- La versión 10.5(1) CUCM incluye y confía en los nuevos Certificados SHA2.

- Si usted funciona con una versión anterior CUCM, usted puede ser que sea requerido descargar el nuevo certificado CA de fabricación y:

- Cargúelo por teletratamiento a la CAPF-confianza de modo que los teléfonos puedan autenticar con CAPF para obtener un LSC.

- Cargúelo por teletratamiento a la CallManager-confianza si usted quiere permitir que los teléfonos autentiquen con un MIC para el SORBO 5061.

Consejo: Haga clic este link para obtener el SHA2 CA si el CUCM funciona con actualmente una versión anterior.

Precaución: Cisco recomienda que usted utiliza MICs para la instalación LSC solamente. Cisco utiliza los LSC para la autenticación de la conexión TLS con el CUCM. Porque los certificados raíz MIC pueden ser comprometidos, los clientes que configuran los teléfonos para utilizar MICs para la autenticación de TLS o para cualquier otro propósito hacen tan por su cuenta y riesgo. Cisco no asume ningún defecto si se compromete el MICs.

Por abandono, si un LSC existe en el teléfono, la autenticación utiliza el LSC, sin importar si un MIC existe en el teléfono. Si un MIC y un LSC existen en el teléfono, la autenticación utiliza el LSC. Si un LSC no existe en el teléfono, pero existe un MIC, la autenticación utiliza el MIC.

Note: Recuerde que, para la autenticación del certificado, usted debe exportar el certificado SSL del ASA e importarlo al CUCM.

Control del ID del host

Si el nombre común (NC) en el tema del certificado no hace juego el URL (grupo-URL) que los teléfonos utilizan para conectar con el ASA con el VPN, que inhabilitan el control del ID del host en el CUCM o utilice un certificado en el ASA que hace juego ese URL en el ASA.

Esto es necesario cuando el certificado SSL del ASA es un certificado del comodín, el certificado SSL contiene un diverso SAN (nombre alternativo sujeto), o el URL fue creado con la dirección IP en vez del nombre de dominio completo (FQDN).

Éste es un ejemplo de un registro del teléfono IP cuando el NC del certificado no hace juego el URL que el teléfono está intentando alcanzar.

1231: NOT 07:07:32.445560 VPNC: DNS has wildcard, starting checks...

1232: ERR 07:07:32.446239 VPNC: Generic third level wildcards are not allowed,

stopping checks on host=(test.vpn.com) and dns=(*.vpn.com)

1233: NOT 07:07:32.446993 VPNC: hostID not found in subjectAltNames

1234: NOT 07:07:32.447703 VPNC: hostID not found in subject name

1235: ERR 07:07:32.448306 VPNC: hostIDCheck failed!!

Para inhabilitar el incorporar del ID del host los CUCM, navegan a las funciones avanzadas > al perfil VPN > VPN:

Resolución de otros problemas

Registros y depuraciones a utilizar en el ASA

En el ASA, usted puede activar estas depuraciones y registros para resolver problemas:

logging enable

logging buffer-size 1048576

logging buffered debugging

debug webvpn anyconnect 255

Note: En un despliegue grande con una mucha carga de los usuarios de AnyConnect, Cisco recomienda que usted no activa el anyconnect del webvpnh de la depuración. Su salida no se puede filtrar por la dirección IP, así que una gran cantidad de información pudo ser creada.

Registros del teléfono IP

Para tener acceso a los registros del teléfono, active la característica del Acceso Web. Ábrase una sesión al CUCM, y navegue al Device (Dispositivo) > Phone (Teléfono) > a la Configuración del teléfono. Encuentre el teléfono IP en el cual usted quiere activar esta característica, y encuentre la sección para el Acceso Web. Aplique los cambios de configuración al teléfono IP:

Una vez que usted activa el servicio y reajusta el teléfono para inyectar esta nueva función, usted puede tener acceso al teléfono IP abre una sesión al navegador; utilice la dirección IP del teléfono de un ordenador con el acceso a esa subred. Vaya a los registros de la consola y controle los cinco archivos del registro. Porque el teléfono sobregraba los cinco ficheros, usted debe controlar todos estos ficheros en la orden encuentra la información que usted busca.

Los problemas correlacionados entre los registros ASA y el IP llaman por teléfono a los registros

Éste es un ejemplo de cómo correlacionar los registros del ASA y del teléfono IP. En este ejemplo, el hash del certificado en el ASA no hace juego el hash del certificado en el archivo de configuración del teléfono porque el certificado en el ASA fue substituido por un diverso certificado.

Registros ASA

%ASA-7-725012: Device chooses cipher : AES128-SHA for the SSL session with

client outside:172.16.250.9/50091

%ASA-7-725014: SSL lib error. Function: SSL3_READ_BYTES Reason: tlsv1 alert

unknown ca

%ASA-6-725006: Device failed SSL handshake with client outside:172.16.250.9/50091

Registros del teléfono

902: NOT 10:19:27.155936 VPNC: ssl_state_cb: TLSv1: SSL_connect: before/connect

initialization

903: NOT 10:19:27.162212 VPNC: ssl_state_cb: TLSv1: SSL_connect: unknown state

904: NOT 10:19:27.361610 VPNC: ssl_state_cb: TLSv1: SSL_connect: SSLv3 read

server hello A

905: NOT 10:19:27.364687 VPNC: cert_vfy_cb: depth:1 of 1, subject:

</CN=10.198.16.140/unstructuredName=10.198.16.140>

906: NOT 10:19:27.365344 VPNC: cert_vfy_cb: depth:1 of 1, pre_err: 18 (self

signed certificate)

907: NOT 10:19:27.368304 VPNC: cert_vfy_cb: peer cert saved: /tmp/leaf.crt

908: NOT 10:19:27.375718 SECD: Leaf cert hash =

1289B8A7AA9FFD84865E38939F3466A61B5608FC

909: ERR 10:19:27.376752 SECD: EROR:secLoadFile: file not found </tmp/issuer.crt>

910: ERR 10:19:27.377361 SECD: Unable to open file /tmp/issuer.crt

911: ERR 10:19:27.420205 VPNC: VPN cert chain verification failed, issuer

certificate not found and leaf not trusted

912: ERR 10:19:27.421467 VPNC: ssl_state_cb: TLSv1: write: alert: fatal:

unknown CA

913: ERR 10:19:27.422295 VPNC: alert_err: SSL write alert: code 48, unknown CA

914: ERR 10:19:27.423201 VPNC: create_ssl_connection: SSL_connect ret -1 error 1

915: ERR 10:19:27.423820 VPNC: SSL: SSL_connect: SSL_ERROR_SSL (error 1)

916: ERR 10:19:27.424541 VPNC: SSL: SSL_connect: error:14090086:SSL

routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

917: ERR 10:19:27.425156 VPNC: create_ssl_connection: SSL setup failure

918: ERR 10:19:27.426473 VPNC: do_login: create_ssl_connection failed

919: NOT 10:19:27.427334 VPNC: vpn_stop: de-activating vpn

920: NOT 10:19:27.428156 VPNC: vpn_set_auto: auto -> auto

921: NOT 10:19:27.428653 VPNC: vpn_set_active: activated -> de-activated

922: NOT 10:19:27.429187 VPNC: set_login_state: LOGIN: 1 (TRYING) --> 3 (FAILED)

923: NOT 10:19:27.429716 VPNC: set_login_state: VPNC : 1 (LoggingIn) --> 3

(LoginFailed)

924: NOT 10:19:27.430297 VPNC: vpnc_send_notify: notify type: 1 [LoginFailed]

925: NOT 10:19:27.430812 VPNC: vpnc_send_notify: notify code: 37

[SslAlertSrvrCert]

926: NOT 10:19:27.431331 VPNC: vpnc_send_notify: notify desc: [alert: Unknown

CA (server cert)]

927: NOT 10:19:27.431841 VPNC: vpnc_send_notify: sending signal 28 w/ value 13 to

pid 14

928: ERR 10:19:27.432467 VPNC: protocol_handler: login failed

Palmo a la característica del puerto de la PC

Usted puede conectar un ordenador directamente con un teléfono. El teléfono tiene un puerto del switch en la Placa posterior.

Configure el teléfono como usted lo hizo previamente, para activar el palmo al puerto de la PC en el CUCM, y para aplicar la configuración. El teléfono comienza a enviar una copia de cada bastidor a la PC. Utilice Wireshark en el modo promiscuo para capturar el tráfico para el análisis.

Configuración del teléfono IP cambios mientras que es conectado por el VPN

Una pregunta común es si usted puede modificar la configuración VPN mientras que el teléfono IP es conectado fuera de la red por AnyConnect. La respuesta está sí, pero usted debe confirmar algunas configuraciones.

Realice los cambios necesarios en el CUCM, después aplique los cambios al teléfono. Hay tres opciones (aplique los Config, reajustan, reinicio) para empujar la nueva configuración al teléfono. Aunque las tres opciones desconecten el VPN del teléfono y del ASA, usted puede volver a conectar automáticamente si usted está utilizando la autenticación del certificado; si usted está utilizando el Authentication, Authorization, and Accounting (AAA), le incitan para sus credenciales otra vez.

Note: Cuando el teléfono IP está en el lado remoto, recibe normalmente una dirección IP de un servidor externo del DHCP. Para que el teléfono IP reciba la nueva configuración del CUCM, debe entrar en contacto con el servidor TFTP en la oficina principal. El CUCM es normalmente el mismo servidor TFTP.

Para recibir los archivos de configuración con los cambios, confirme que la dirección IP para el servidor TFTP está puesta correctamente en las configuraciones de red en el teléfono; para la confirmación, utilice la opción 150 del servidor del DHCP o fije manualmente el TFTP en el teléfono. Este servidor TFTP es accesible con una sesión de AnyConnect.

Si el teléfono IP está recibiendo el servidor TFTP de un servidor local del DHCP pero ese direccionamiento es incorrecto, usted puede utilizar la opción del servidor alterna TFTP para reemplazar la dirección IP del servidor TFTP proporcionada por el servidor del DHCP. Este procedimiento describe cómo aplicar el servidor alterno TFTP:

1. Navegue a las configuraciones > a la configuración de la Configuración de la red IPv4.

2. Desplazamiento a la opción alterna TFTP.

3. Pulse la tecla suave del sí para que el teléfono utilice un servidor de la alternativa TFTP; si no, no pulse la ninguna tecla suave. Si la opción es bloqueada, prensa * * # para desbloquearla.

4. Presione la tecla programable Save.

5. Aplique el servidor alterno TFTP bajo opción del servidor 1 TFTP.

Revise los mensajes de estado en el buscador Web o en los menús del teléfono directamente para confirmar que el teléfono está recibiendo la información correcta. Si la comunicación se pone correctamente, usted ve los mensajes tales como éstos:

Si el teléfono no puede extraer la información del servidor TFTP, usted recibe los mensajes de error TFTP:

Renovación del certificado ASA SSL

Si usted hace un teléfono funcional de AnyConnect VPN poner pero su certificado ASA SSL está a punto de expirar, usted no necesita traer todos los Teléfonos IP al sitio principal para inyectar los nuevos Certificados SSL al teléfono; usted puede agregar los nuevos Certificados mientras que el VPN está conectado.

Si usted ha exportado o importado certificado raíz CA del ASA en vez del certificado de identidad y si usted quiere continuar utilizando al mismo vendedor (CA) durante esta renovación, no es necesario cambiar el certificado en el CUCM porque sigue siendo lo mismo. Pero, si usted utilizó el certificado de identidad, este procedimiento es necesario; si no, el valor de troceo entre el teléfono ASA y IP no hace juego, y la conexión no es confiada en por el teléfono.

1. Renueve el certificado en el ASA.

Note: Para los detalles, refiera a ASA 8.x: Renueve y instale el certificado SSL con ASDM. Cree un trustpoint separado y no aplique este nuevo certificado con el <name> del trustpoint SSL fuera del comando hasta que usted haya aplicado el certificado a todos los Teléfonos IP VPN.

2. Exporte el nuevo certificado.

3. Importe el nuevo certificado al CUCM como certificado de la Teléfono-VPN-confianza.

Note: Sea consciente de los certs que cargan por teletratamiento CSCuh19734 con el mismo NC sobregrabará el CERT viejo en la Teléfono-VPN-confianza

4. Navegue a la configuración de gateway de VPN en el CUCM, y aplique el nuevo certificado. Usted ahora tiene ambos Certificados: el certificado que está a punto de expirar y el nuevo certificado que no se ha aplicado al ASA todavía.

5. Aplique esta nueva configuración al teléfono IP. Navegue para aplicar los Config > reajustado > reinicio para inyectar los nuevos cambios de configuración al teléfono IP a través del túnel VPN. Asegúrese de que todos los Teléfonos IP estén conectados con el VPN y de que pueden alcanzar el servidor TFTP a través del túnel.

6. Utilice el TFTP para controlar los mensajes de estado y el archivo de configuración para confirmar que el teléfono IP recibió el archivo de configuración con los cambios.

7. Aplique el nuevo SSL Trustpoint en el ASA, y substituya el certificado viejo.

Note: Si se expira el certificado ASA SSL ya y si los Teléfonos IP no pueden conectar con AnyConnect; usted puede empujar los cambios (tales como el nuevo hash del certificado ASA) al teléfono IP. Fije manualmente el TFTP en el teléfono IP a una dirección IP pública así que el teléfono IP puede extraer la información de allí. Utilice un servidor del público TFTP para recibir el archivo de configuración; un ejemplo es crear una expedición del puerto en el ASA y reorientar el tráfico al servidor interno TFTP.