Configuración de SSH con autenticación x509 en dispositivos IOS

Opciones de descarga

  • PDF     (280.3 KB)
    Visualice con Adobe Reader en una variedad de dispositivos
  • ePub     (268.0 KB)
    Visualice en diferentes aplicaciones en iPhone, iPad, Android, Sony Reader o Windows Phone
  • Mobi (Kindle)     (227.9 KB)
    Visualice en dispositivo Kindle o aplicación Kindle en múltiples dispositivos
Actualizado:22 de noviembre de 2017
ID del documento:212178

Lenguaje no discriminatorio

El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.

Acerca de esta traducción

Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).

    Introducción

    Este documento describe cómo configurar el servidor SSH con el uso de certificados x509v3 en dispositivos IOS de acuerdo con el RFC6187 estándar.
    El protocolo Secure Shell Protocol (SSH) proporciona autenticación mutua, es decir, tanto el cliente como el servidor se autentican. Tradicionalmente, el servidor utiliza el par de claves público y privado RSA para la autenticación. El cliente SSH calcula la suma de comprobación de la clave pública y pregunta al administrador si es de confianza. El administrador debe exportar la clave pública desde el router con el método fuera de banda y comparar los valores. En la práctica, este es un método engorroso y a menudo la clave pública es aceptada sin verificación, lo que lleva al riesgo potencial de ataques de intermediarios.
    El estándar RFC6187 es una solución a esta preocupación, ya que proporciona un nivel similar de seguridad y experiencia de usuario al protocolo TLS (seguridad de la capa de transporte) que se utiliza habitualmente para proteger las transmisiones basadas en la Web.

    Prerequisites

      

    Requirements

    Cisco recomienda que tenga conocimiento sobre estos temas:

    • infraestructura PKI

    Componentes Utilizados

    La información que contiene este documento se basa en las siguientes versiones de software y hardware.

    • Router CSR 1000v con IOS-XE versión 16.6.1
    • Cliente de Pragma Fortress SSH
    • Servidor OCSP de Windows Server 2016
    • Identity Services Engine versión 2.1

    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 tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

    Configurar

    Diagrama de la red

    Consideraciones sobre la implementación

    • Un El cliente SSH compatible con RFC6187 es necesario para aprovechar la función.

    • La función se ha implementado en la versión 15.5(2)T del IOS y en la versión 15.5(2)S del IOS-XE.

    • El cliente y servidor SSH negocia los mecanismos de autenticación soportados. Todos los mecanismos de autenticación previamente soportados en el dispositivo pueden continuar ejecutándose simultáneamente con los mecanismos de autenticación basados en x509 para asegurar una transición fluida.

    • El administrador puede optar por utilizar el método de autenticación basado en x509 sólo para el servidor, sólo para el cliente o ambos. 

    • El servidor IOS puede verificar si el certificado presentado por el cliente no está revocado. Para ello, se consulta la base de datos de certificados revocados en cada conexión. Esto permite la revocación del acceso sin necesidad de reconfigurar otros dispositivos, en caso de que la clave privada del certificado se vea comprometida o si el acceso de un usuario específico necesita ser revocado.

    • La verificación de revocación es opcional, pero se recomienda tener la posibilidad de denegar el acceso en función de las credenciales comprometidas. Otra opción es realizar la autorización para el nombre de usuario obtenido del certificado en el sistema de control de acceso del controlador de acceso de terminal externo (TACACS) o el servidor RADIUS. En caso de que el certificado se vea comprometido, la cuenta se puede inhabilitar en el servidor externo para evitar el acceso con el uso de ese certificado.

    • La autorización de los usuarios puede ser realizada por un servidor externo o puede ser omitida (todos los usuarios con un certificado válido se supone que tienen privilegios para acceder al dispositivo). El método anterior se utiliza en este ejemplo para simplificar.

    • Para verificar correctamente los datos de autenticación de la otra parte, el cliente y el servidor sólo necesitan confiar en una Autoridad de Certificación (CA) común. Esto significa que sólo el certificado de CA que firmó el certificado del router debe instalarse en el almacén de certificados de confianza del dispositivo cliente.

    • El certificado proporciona información sobre la identidad de la otra parte (el nombre común y el nombre alternativo del sujeto se utilizan normalmente para ese fin). El cliente debe comparar el nombre de host o el nombre de la dirección IP del servidor proporcionado como entrada por el administrador con los datos de identidad disponibles en el certificado presentado. Limita seriamente las oportunidades de ataques de personas intermedias u otros ataques de suplantación.

    Configuraciones

    Configure los parámetros AAA. En un escenario básico (sin servidor de autorización externo), se puede omitir la autorización del nombre de usuario obtenido del certificado.

    aaa new-model
    aaa authorization network CERT none

     Configure un punto de confianza que retenga el certificado de CA y opcionalmente el certificado del router. 

    crypto pki trustpoint SSH
     enrollment mode ra
     enrollment url http://10.1.1.2:80/CertSrv/mscep/mscep.dll
     serial-number
     ip-address 10.0.0.1
     subject-name cn=10.0.0.1
     revocation-check ocsp
     ocsp url http://10.1.1.2/ocsp
     rsakeypair SSH 2048
     authorization list CERT
     ! The username has to be fetched from the certificate for accounting and authorization purposes. Multiple options are available.
     authorization username subjectname commonname

    Consejo: En caso de que el servidor OCSP no sea accesible, el administrador puede optar por no permitir todo el acceso usando la configuración revocation-check ocsp o permitir el acceso sin la verificación de revocación usando revocation-check ocsp none (no recomendado).

    Configure los mecanismos de autenticación permitidos utilizados durante la negociación del túnel SSH.

    ! Alorithms used to authenticate server
    ip ssh server algorithm hostkey x509v3-ssh-rsa ssh-rsa

    ! Acceptable algorithms used to authenticate the client
    ip ssh server algorithm authentication publickey password keyboard

    ! Acceptable pubkey-based algorithms used to authenticate the client
    ip ssh server algorithm publickey x509v3-ssh-rsa ssh-rsa

    Configure el servidor SSH para utilizar certificados correctos en el proceso de autenticación.

    ip ssh server certificate profile
       ! Certificate used by server    
       server
          trustpoint sign SSH

       ! CA used to authenticate client certificates
       user
          trustpoint verify SSH

    (Opcional) Integración con el servidor TACACS 

    Después de obtener el nombre de usuario del certificado, el IOS puede realizar la autorización para ese nombre de usuario contra el servidor TACACS. Esto es especialmente útil si el servidor TACACS ya está implementado para la administración del dispositivo. 

    Nota: El servidor IOS SSH actualmente no soporta el encadenamiento de métodos de autenticación. Esto significa que si los certificados se utilizan para autenticar al usuario, el servidor TACACS no se puede utilizar para la autenticación de contraseña. Sólo se puede utilizar para autorización.

    Configure el servidor TACACS.

    tacacs server ISE
     address ipv4 10.1.1.3
     key cisco123

    Configure la lista de autorización para utilizar el servidor TACACS.

    aaa authorization network ISE group tacacs+

    1. Configuración de ISE (Identity Services Engine). El ejemplo de configuración se puede encontrar en: 

    https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/200208-Configure-ISE-2-0-IOS-TACACS-Authentic.html

    2. Configure el perfil TACACS. Parámetro adicional cert-application=todos deben configurarse para que la autorización tenga éxito, navegue hasta Centros de trabajo > Administración de dispositivos > Elementos de políticas > Resultados > Perfiles TACACS > Agregar.

    3. Para configurar el conjunto de políticas, navegue hasta Centros de trabajo > Administración de dispositivos > Conjuntos de políticas de administración de dispositivos > Agregar.

    Verificación

    show ip ssh 
    SSH Enabled - version 1.99
    Authentication methods:publickey,password,keyboard-interactive
    Authentication Publickey Algorithms:x509v3-ssh-rsa,ssh-rsa
    Hostkey Algorithms:x509v3-ssh-rsa,ssh-rsa
    --- output truncated ----

    show users 
     Line User Host(s) Idle Location
     1 vty 0 admin1 idle 00:02:37 192.168.1.100

    Troubleshoot

    Estas depuraciones se utilizan para realizar un seguimiento de la sesión correcta:

    debug ip ssh detail
    debug crypto pki transactions
    debug crypto pki messages
    debug crypto pki validation

    Aug 21 20:07:08.717: SSH0: starting SSH control process
    ! Server identifies itself
    Aug 21 20:07:08.717: SSH0: sent protocol version id SSH-1.99-Cisco-1.25
    ! Client identifies itself
    Aug 21 20:07:08.771: SSH0: protocol version id is - SSH-2.0-Pragma FortressCL 5.0.10.766
    Aug 21 20:07:08.771: SSH2 0: kexinit sent: kex algo = diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1

    ! Authentication algorithms supported by server
    Aug 21 20:07:08.771: SSH2 0: kexinit sent: hostkey algo = x509v3-ssh-rsa,ssh-rsa
    Aug 21 20:07:08.772: SSH2 0: kexinit sent: encryption algo = aes128-ctr,aes192-ctr,aes256-ctr
    Aug 21 20:07:08.772: SSH2 0: kexinit sent: mac algo = hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-sha1-96
    Aug 21 20:07:08.772: SSH2 0: SSH2_MSG_KEXINIT sent
    Aug 21 20:07:08.915: SSH2 0: SSH2_MSG_KEXINIT received
    Aug 21 20:07:08.916: SSH2 0: kex: client->server enc:aes256-ctr mac:hmac-sha1 
    Aug 21 20:07:08.916: SSH2 0: kex: server->client enc:aes256-ctr mac:hmac-sha1 

    ! Client chooses authentication algorithm
    Aug 21 20:07:08.916: SSH2 0: Using hostkey algo = x509v3-ssh-rsa
    Aug 21 20:07:08.916: SSH2 0: Using kex_algo = diffie-hellman-group-exchange-sha1
    Aug 21 20:07:08.917: SSH2 0: Modulus size established : 4096 bits
    Aug 21 20:07:08.976: SSH2 0: expecting SSH2_MSG_KEX_DH_GEX_INIT
    Aug 21 20:07:09.141: SSH2 0: SSH2_MSG_KEXDH_INIT received

    ! Server sends certificate associated with trustpoint "SSH"
    Aug 21 20:07:09.208: SSH2 0: Sending Server certificate associated with PKI trustpoint "SSH"
    Aug 21 20:07:09.208: CRYPTO_PKI: (A003C) Session started - identity selected (SSH)
    Aug 21 20:07:09.208: SSH2 0: Got 2 certificate(s) on certificate chain
    Aug 21 20:07:09.208: CRYPTO_PKI: Rcvd request to end PKI session A003C.
    Aug 21 20:07:09.208: CRYPTO_PKI: PKI session A003C has ended. Freeing all resources.
    Aug 21 20:07:09.209: CRYPTO_PKI: unlocked trustpoint SSH, refcount is 0
    Aug 21 20:07:09.276: SSH2: kex_derive_keys complete
    Aug 21 20:07:09.276: SSH2 0: SSH2_MSG_NEWKEYS sent
    Aug 21 20:07:09.276: SSH2 0: waiting for SSH2_MSG_NEWKEYS
    Aug 21 20:07:16.927: SSH2 0: SSH2_MSG_NEWKEYS received
    Aug 21 20:07:17.177: SSH2 0: Authentications that can continue = publickey,password,keyboard-interactive
    Aug 21 20:07:17.225: SSH2 0: Using method = none
    Aug 21 20:07:17.226: SSH2 0: Authentications that can continue = publickey,password,keyboard-interactive
    Aug 21 20:07:32.305: SSH2 0: Using method = publickey

    ! Client sends certificate
    Aug 21 20:07:32.305: SSH2 0: Received publickey algo = x509v3-ssh-rsa
    Aug 21 20:07:32.305: SSH2 0: Verifying certificate for user 'admin1' in SSH2_MSG_USERAUTH_REQUEST
    Aug 21 20:07:32.305: SSH2 0: Verifying certificate for user 'admin1'
    Aug 21 20:07:32.306: SSH2 0: Received a chain of 2 certificate
    Aug 21 20:07:32.308: SSH2 0: Received 0 ocsp-response
    Aug 21 20:07:32.308: SSH2 0: Starting PKI session for certificate verification
    Aug 21 20:07:32.308: CRYPTO_PKI: (A003D) Session started - identity not specified
    Aug 21 20:07:32.309: CRYPTO_PKI: (A003D) Adding peer certificate
    Aug 21 20:07:32.310: CRYPTO_PKI: found UPN as admin1@example.com 
    Aug 21 20:07:32.310: CRYPTO_PKI: Added x509 peer certificate - (1016) bytes
    Aug 21 20:07:32.310: CRYPTO_PKI: (A003D) Adding peer certificate
    Aug 21 20:07:32.310: CRYPTO_PKI: Added x509 peer certificate - (879) bytes
    Aug 21 20:07:32.311: CRYPTO_PKI: ip-ext-val: IP extension validation not required
    Aug 21 20:07:32.311: CRYPTO_PKI: create new ca_req_context type PKI_VERIFY_CHAIN_CONTEXT,ident 31
    Aug 21 20:07:32.312: CRYPTO_PKI: (A003D)validation path has 1 certs

    Aug 21 20:07:32.312: CRYPTO_PKI: (A003D) Check for identical certs
    Aug 21 20:07:32.312: CRYPTO_PKI : (A003D) Validating non-trusted cert
    Aug 21 20:07:32.312: CRYPTO_PKI: (A003D) Create a list of suitable trustpoints
    Aug 21 20:07:32.312: CRYPTO_PKI: Found a issuer match
    Aug 21 20:07:32.312: CRYPTO_PKI: (A003D) Suitable trustpoints are: SSH,
    Aug 21 20:07:32.313: CRYPTO_PKI: (A003D) Attempting to validate certificate using SSH policy
    Aug 21 20:07:32.313: CRYPTO_PKI: (A003D) Using SSH to validate certificate
    Aug 21 20:07:32.313: CRYPTO_PKI: Added 1 certs to trusted chain.
    Aug 21 20:07:32.314: CRYPTO_PKI: Prepare session revocation service providers
    Aug 21 20:07:32.314: CRYPTO_PKI: Deleting cached key having key id 30
    Aug 21 20:07:32.314: CRYPTO_PKI: Attempting to insert the peer's public key into cache
    Aug 21 20:07:32.314: CRYPTO_PKI:Peer's public inserted successfully with key id 31
    Aug 21 20:07:32.315: CRYPTO_PKI: Expiring peer's cached key with key id 31
    Aug 21 20:07:32.315: CRYPTO_PKI: (A003D) Certificate is verified

    ! Revocation status is checked
    Aug 21 20:07:32.315: CRYPTO_PKI: (A003D) Checking certificate revocation
    Aug 21 20:07:32.315: OCSP: (A003D) Process OCSP_VALIDATE message
    Aug 21 20:07:32.315: CRYPTO_PKI: (A003D)Starting OCSP revocation check
    Aug 21 20:07:32.316: CRYPTO_PKI: OCSP server URL is http://10.1.1.2/ocsp
    Aug 21 20:07:32.316: CRYPTO_PKI: no responder matching this URL; create one!
    Aug 21 20:07:32.316: OCSP: (A003D)OCSP Get Response command
    Aug 21 20:07:32.317: CRYPTO_PKI: http connection opened
    Aug 21 20:07:32.317: CRYPTO_PKI: OCSP send header size 132
    Aug 21 20:07:32.317: CRYPTO_PKI: sending POST /ocsp HTTP/1.0
    Host: 10.1.1.2
    User-Agent: RSA-Cert-C/2.0
    Content-type: application/ocsp-request
    Content-length: 312


    Aug 21 20:07:32.317: CRYPTO_PKI: OCSP send data size 312
    Aug 21 20:07:32.322: OCSP: (A003D)OCSP Parse HTTP Response command
    Aug 21 20:07:32.322: OCSP: (A003D)OCSP Validate DER Response command
    Aug 21 20:07:32.322: CRYPTO_PKI: OCSP response status - successful.
    Aug 21 20:07:32.323: CRYPTO_PKI: Decoding OCSP Response
    Aug 21 20:07:32.323: CRYPTO_PKI: OCSP decoded status is GOOD.
    Aug 21 20:07:32.323: CRYPTO_PKI: Verifying OCSP Response
    Aug 21 20:07:32.325: CRYPTO_PKI: Added 11 certs to trusted chain.
    Aug 21 20:07:32.325: ../VIEW_ROOT/cisco.comp/pki_ssl/src/ca/provider/revoke/ocsp/ocsputil.c(547) : E_NOT_FOUND : no matching entry found
    Aug 21 20:07:32.325: ../VIEW_ROOT/cisco.comp/pki_ssl/src/ca/provider/revoke/ocsp/ocsputil.c(547) : E_NOT_FOUND : no matching entry found
    Aug 21 20:07:32.326: CRYPTO_PKI: (A003D) Validating OCSP responder certificate
    Aug 21 20:07:32.327: CRYPTO_PKI: OCSP Responder cert doesn't need rev check
    Aug 21 20:07:32.328: CRYPTO_PKI: response signed by a delegated responder
    Aug 21 20:07:32.328: CRYPTO_PKI: OCSP Response is verified
    Aug 21 20:07:32.328: CRYPTO_PKI: (A003D) OCSP revocation check is complete 0
    Aug 21 20:07:32.328: OCSP: destroying OCSP trans element
    Aug 21 20:07:32.328: CRYPTO_PKI: Revocation check is complete, 0
    Aug 21 20:07:32.328: CRYPTO_PKI: Revocation status = 0
    Aug 21 20:07:32.328: CRYPTO_PKI: Remove session revocation service providers
    Aug 21 20:07:32.329: CRYPTO_PKI: Remove session revocation service providers
    Aug 21 20:07:32.329: CRYPTO_PKI: (A003D) Certificate validated
    Aug 21 20:07:32.329: CRYPTO_PKI: Populate AAA auth data
    Aug 21 20:07:32.329: CRYPTO_PKI: Selected AAA username: 'admin1'
    Aug 21 20:07:32.329: CRYPTO_PKI: Anticipate checking AAA list: 'CERT'
    Aug 21 20:07:32.329: CRYPTO_PKI: Checking AAA authorization
    Aug 21 20:07:32.329: CRYPTO_PKI_AAA: checking AAA authorization (CERT, admin1, <all>)
    Aug 21 20:07:32.329: CRYPTO_PKI_AAA: pre-authorization chain validation status (0x400)
    Aug 21 20:07:32.329: CRYPTO_PKI_AAA: post-authorization chain validation status (0x400)
    Aug 21 20:07:32.329: CRYPTO_PKI: (A003D)chain cert was anchored to trustpoint SSH, and chain validation result was: CRYPTO_VALID_CERT
    Aug 21 20:07:32.329: CRYPTO_PKI: destroying ca_req_context type PKI_VERIFY_CHAIN_CONTEXT,ident 31, ref count 1
    Aug 21 20:07:32.330: CRYPTO_PKI: ca_req_context released
    Aug 21 20:07:32.330: CRYPTO_PKI: (A003D) Validation TP is SSH
    Aug 21 20:07:32.330: CRYPTO_PKI: (A003D) Certificate validation succeeded
    Aug 21 20:07:32.330: CRYPTO_PKI: Rcvd request to end PKI session A003D.
    Aug 21 20:07:32.330: CRYPTO_PKI: PKI session A003D has ended. Freeing all resources.
    Aug 21 20:07:32.395: SSH2 0: Verifying certificate for user 'admin1'
    Aug 21 20:07:32.395: SSH2 0: Received a chain of 2 certificate
    Aug 21 20:07:32.396: SSH2 0: Received 0 ocsp-response
    Aug 21 20:07:32.396: SSH2 0: Starting PKI session for certificate verification
    Aug 21 20:07:32.396: CRYPTO_PKI: (A003E) Session started - identity not specified
    Aug 21 20:07:32.396: CRYPTO_PKI: (A003E) Adding peer certificate
    Aug 21 20:07:32.397: CRYPTO_PKI: found UPN as admin1@example.com 
    Aug 21 20:07:32.397: CRYPTO_PKI: Added x509 peer certificate - (1016) bytes
    Aug 21 20:07:32.397: CRYPTO_PKI: (A003E) Adding peer certificate
    Aug 21 20:07:32.398: CRYPTO_PKI: Added x509 peer certificate - (879) bytes
    Aug 21 20:07:32.398: CRYPTO_PKI: ip-ext-val: IP extension validation not required
    Aug 21 20:07:32.400: CRYPTO_PKI: create new ca_req_context type PKI_VERIFY_CHAIN_CONTEXT,ident 32
    Aug 21 20:07:32.400: CRYPTO_PKI: (A003E)validation path has 1 certs

    Aug 21 20:07:32.400: CRYPTO_PKI: (A003E) Check for identical certs
    Aug 21 20:07:32.400: CRYPTO_PKI : (A003E) Validating non-trusted cert
    Aug 21 20:07:32.401: CRYPTO_PKI: (A003E) Create a list of suitable trustpoints
    Aug 21 20:07:32.401: CRYPTO_PKI: Found a issuer match
    Aug 21 20:07:32.401: CRYPTO_PKI: (A003E) Suitable trustpoints are: SSH,
    Aug 21 20:07:32.401: CRYPTO_PKI: (A003E) Attempting to validate certificate using SSH policy
    Aug 21 20:07:32.401: CRYPTO_PKI: (A003E) Using SSH to validate certificate
    Aug 21 20:07:32.402: CRYPTO_PKI: Added 1 certs to trusted chain.
    Aug 21 20:07:32.402: CRYPTO_PKI: Prepare session revocation service providers
    Aug 21 20:07:32.402: CRYPTO_PKI: Deleting cached key having key id 31
    Aug 21 20:07:32.403: CRYPTO_PKI: Attempting to insert the peer's public key into cache
    Aug 21 20:07:32.403: CRYPTO_PKI:Peer's public inserted successfully with key id 32
    Aug 21 20:07:32.404: CRYPTO_PKI: Expiring peer's cached key with key id 32
    Aug 21 20:07:32.404: CRYPTO_PKI: (A003E) Certificate is verified
    Aug 21 20:07:32.404: CRYPTO_PKI: (A003E) Checking certificate revocation
    Aug 21 20:07:32.404: OCSP: (A003E) Process OCSP_VALIDATE message
    Aug 21 20:07:32.404: CRYPTO_PKI: (A003E)Starting OCSP revocation check
    Aug 21 20:07:32.405: CRYPTO_PKI: OCSP server URL is http://10.1.1.2/ocsp
    Aug 21 20:07:32.405: CRYPTO_PKI: no responder matching this URL; create one!
    Aug 21 20:07:32.405: OCSP: (A003E)OCSP Get Response command
    Aug 21 20:07:32.406: CRYPTO_PKI: http connection opened
    Aug 21 20:07:32.406: CRYPTO_PKI: OCSP send header size 132
    Aug 21 20:07:32.406: CRYPTO_PKI: sending POST /ocsp HTTP/1.0
    Host: 10.1.1.2
    User-Agent: RSA-Cert-C/2.0
    Content-type: application/ocsp-request
    Content-length: 312


    Aug 21 20:07:32.406: CRYPTO_PKI: OCSP send data size 312
    Aug 21 20:07:32.409: OCSP: (A003E)OCSP Parse HTTP Response command
    Aug 21 20:07:32.410: OCSP: (A003E)OCSP Validate DER Response command
    Aug 21 20:07:32.410: CRYPTO_PKI: OCSP response status - successful.
    Aug 21 20:07:32.410: CRYPTO_PKI: Decoding OCSP Response
    Aug 21 20:07:32.411: CRYPTO_PKI: OCSP decoded status is GOOD.
    Aug 21 20:07:32.411: CRYPTO_PKI: Verifying OCSP Response
    Aug 21 20:07:32.413: CRYPTO_PKI: Added 11 certs to trusted chain.
    Aug 21 20:07:32.413: ../VIEW_ROOT/cisco.comp/pki_ssl/src/ca/provider/revoke/ocsp/ocsputil.c(547) : E_NOT_FOUND : no matching entry found
    Aug 21 20:07:32.413: ../VIEW_ROOT/cisco.comp/pki_ssl/src/ca/provider/revoke/ocsp/ocsputil.c(547) : E_NOT_FOUND : no matching entry found
    Aug 21 20:07:32.414: CRYPTO_PKI: (A003E) Validating OCSP responder certificate
    Aug 21 20:07:32.415: CRYPTO_PKI: OCSP Responder cert doesn't need rev check
    Aug 21 20:07:32.415: CRYPTO_PKI: response signed by a delegated responder
    Aug 21 20:07:32.416: CRYPTO_PKI: OCSP Response is verified
    Aug 21 20:07:32.416: CRYPTO_PKI: (A003E) OCSP revocation check is complete 0
    Aug 21 20:07:32.416: OCSP: destroying OCSP trans element
    Aug 21 20:07:32.416: CRYPTO_PKI: Revocation check is complete, 0
    Aug 21 20:07:32.416: CRYPTO_PKI: Revocation status = 0
    Aug 21 20:07:32.416: CRYPTO_PKI: Remove session revocation service providers
    Aug 21 20:07:32.416: CRYPTO_PKI: Remove session revocation service providers
    Aug 21 20:07:32.416: CRYPTO_PKI: (A003E) Certificate validated
    Aug 21 20:07:32.417: CRYPTO_PKI: Populate AAA auth data
    Aug 21 20:07:32.417: CRYPTO_PKI: Selected AAA username: 'admin1'
    Aug 21 20:07:32.417: CRYPTO_PKI: Anticipate checking AAA list: 'CERT'
    Aug 21 20:07:32.417: CRYPTO_PKI: Checking AAA authorization
    Aug 21 20:07:32.417: CRYPTO_PKI_AAA: checking AAA authorization (CERT, admin1, <all>)
    Aug 21 20:07:32.417: CRYPTO_PKI_AAA: pre-authorization chain validation status (0x400)
    Aug 21 20:07:32.417: CRYPTO_PKI_AAA: post-authorization chain validation status (0x400)
    Aug 21 20:07:32.417: CRYPTO_PKI: (A003E)chain cert was anchored to trustpoint SSH, and chain validation result was: CRYPTO_VALID_CERT
    Aug 21 20:07:32.417: CRYPTO_PKI: destroying ca_req_context type PKI_VERIFY_CHAIN_CONTEXT,ident 32, ref count 1
    Aug 21 20:07:32.417: CRYPTO_PKI: ca_req_context released
    Aug 21 20:07:32.417: CRYPTO_PKI: (A003E) Validation TP is SSH
    Aug 21 20:07:32.417: CRYPTO_PKI: (A003E) Certificate validation succeeded
    Aug 21 20:07:32.418: CRYPTO_PKI: Rcvd request to end PKI session A003E.
    Aug 21 20:07:32.418: CRYPTO_PKI: PKI session A003E has ended. Freeing all resources.
    Aug 21 20:07:32.418: SSH2 0: Verifying signature for user 'admin1' in SSH2_MSG_USERAUTH_REQUEST
    Aug 21 20:07:32.418: SSH2 0: Received a chain of 2 certificate
    Aug 21 20:07:32.418: SSH2 0: Received 0 ocsp-response
    Aug 21 20:07:32.418: CRYPTO_PKI: found UPN as admin1@example.com 

    ! Certificate status verified successfully
    Aug 21 20:07:32.419: SSH2 0: Client Signature verification PASSED
    Aug 21 20:07:32.419: SSH2 0: Certificate authentication passed for user 'admin1'
    Aug 21 20:07:32.419: SSH2 0: authentication successful for admin1
    Aug 21 20:07:32.470: SSH2 0: channel open request
    Aug 21 20:07:32.521: SSH2 0: pty-req request
    Aug 21 20:07:32.521: SSH2 0: setting TTY - requested: height 25, width 80; set: height 25, width 80
    Aug 21 20:07:32.570: SSH2 0: shell request
    Aug 21 20:07:32.570: SSH2 0: shell message received
    Aug 21 20:07:32.570: SSH2 0: starting shell for vty
    Aug 21 20:07:32.631: SSH2 0: channel window adjust message received 8

    En caso de que se haya revocado el certificado para admin1:

    Aug 21 19:39:52.081: CRYPTO_PKI: OCSP Response is verified
    Aug 21 19:39:52.081: CRYPTO_PKI: (A0024) OCSP revocation check is complete 0
    Aug 21 19:39:52.082: OCSP: destroying OCSP trans element
    Aug 21 19:39:52.082: CRYPTO_PKI: Revocation check is complete, 0
    Aug 21 19:39:52.082: CRYPTO_PKI: Revocation status = 1
    Aug 21 19:39:52.082: CRYPTO_PKI: Remove session revocation service providers
    Aug 21 19:39:52.082: CRYPTO_PKI: Remove session revocation service providers
    Aug 21 19:39:52.082: CRYPTO_PKI: (A0024) Certificate revoked
    Aug 21 19:39:52.082: %PKI-3-CERTIFICATE_REVOKED: Certificate chain validation has failed. The certificate (SN: 750000001B78DA4CC0078DEC0700000000001B) is revoked
    Aug 21 19:39:52.082: CRYPTO_PKI: (A0024)chain cert was anchored to trustpoint Unknown, and chain validation result was: CRYPTO_CERT_REVOKED
    Aug 21 19:39:52.082: CRYPTO_PKI: destroying ca_req_context type PKI_VERIFY_CHAIN_CONTEXT,ident 18, ref count 1
    Aug 21 19:39:52.082: CRYPTO_PKI: ca_req_context released
    Aug 21 19:39:52.083: CRYPTO_PKI: (A0024) Certificate validation failed

    Información Relacionada

    TAC Authored

    Con la colaboración de ingenieros de Cisco

    • Jan Krupa
      TAC

    ¿Resultó útil este documento?

    FeedbackComentarios

    Contacte a Cisco

    Este documento se aplica a estos productos