Configuration de SSH avec authentification x509 sur les périphériques IOS

Options de téléchargement

  • PDF     (280.8 KB)
    Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
  • ePub     (269.2 KB)
    Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
  • Mobi (Kindle)     (229.4 KB)
    Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils
Mis à jour:22 novembre 2017
ID du document:212178

Langage exempt de préjugés

Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

    Introduction

    Ce document décrit comment configurer le serveur SSH avec l'utilisation de certificats x509v3 sur des périphériques IOS conformément à la norme RFC6187.
    Le protocole SSH (Secure Shell Protocol) fournit une authentification mutuelle, c'est-à-dire que le client et le serveur sont authentifiés. Traditionnellement, le serveur utilise la paire de clés privée et publique RSA pour l'authentification. Le client SSH calcule la somme de contrôle de la clé publique et demande à l'administrateur si elle est approuvée. L'administrateur doit exporter la clé publique à partir du routeur à l'aide de la méthode hors bande et comparer les valeurs. Dans la pratique, il s'agit d'une méthode lourde et souvent la clé publique est acceptée sans vérification, ce qui entraîne un risque potentiel d'attaques de l'homme du milieu.
    La norme RFC6187 est une solution à ce problème car elle fournit un niveau de sécurité et d'expérience utilisateur similaire au protocole TLS (Transport Layer Security) couramment utilisé pour protéger les transmissions basées sur le Web.

    Conditions préalables

      

    Conditions requises

    Cisco vous recommande de prendre connaissance des rubriques suivantes :

    • Infrastructure PKI

    Components Used

    Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

    • Routeur CSR 1000v exécutant IOS-XE version 16.6.1
    • Client SSH Pragma Forteresse
    • Serveur OCSP Windows Server 2016
    • Identity Services Engine version 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 votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

    Configuration

    Diagramme du réseau

    Considérations relatives au déploiement

    • Un Le client SSH compatible RFC6187 est nécessaire pour tirer parti de cette fonctionnalité.

    • Cette fonctionnalité a été implémentée dans IOS version 15.5(2)T et IOS-XE version 15.5(2)S.

    • Le client et le serveur SSH négocient les mécanismes d'authentification pris en charge. Tous les mécanismes d'authentification précédemment pris en charge sur le périphérique peuvent continuer à s'exécuter simultanément avec les mécanismes d'authentification x509 afin d'assurer une transition en douceur.

    • L'administrateur peut choisir d'utiliser la méthode d'authentification x509 uniquement pour le serveur, le client uniquement ou les deux. 

    • Le serveur IOS peut vérifier si le certificat présenté par le client n'est pas révoqué. Pour ce faire, la base de données des certificats révoqués est consultée sur chaque connexion. Cela permet la révocation de l'accès sans avoir à reconfigurer d'autres périphériques, au cas où la clé privée du certificat est compromise ou si l'accès d'un utilisateur spécifique doit être révoqué.

    • La vérification de révocation est facultative, mais il est fortement recommandé d'avoir la possibilité de refuser l'accès en fonction d'informations d'identification compromises. Une autre option consiste à exécuter l'autorisation pour le nom d'utilisateur extrait du certificat sur le serveur TACACS (Terminal Access Controller Access Control System) externe ou RADIUS. Si le certificat est compromis, le compte peut être désactivé sur le serveur externe pour empêcher l'accès avec l'utilisation de ce certificat.

    • L'autorisation des utilisateurs peut être exécutée par un serveur externe ou elle peut être ignorée (tous les utilisateurs possédant un certificat valide supposé avoir des privilèges d'accès au périphérique). L'ancienne méthode est utilisée dans cet exemple à des fins de simplicité.

    • Afin de vérifier correctement les données d'authentification de l'autre partie, le client et le serveur doivent uniquement faire confiance à une autorité de certification commune. Cela signifie que seul le certificat de l'autorité de certification qui a signé le certificat du routeur doit être installé sur le magasin de certificats de confiance du périphérique client.

    • Le certificat fournit des informations sur l'identité de l'autre partie (Common Name et Subject Alternative Name sont généralement utilisés à cette fin). Le client doit comparer le nom d'hôte ou d'adresse IP du serveur fourni en entrée par l'administrateur avec les données d'identité disponibles dans le certificat présenté. Cela limite considérablement les possibilités d'attaques par l'homme du milieu ou d'autres imitations.

    Configurations

    Configurez les paramètres AAA. Dans un scénario de base (sans serveur d'autorisation externe), l'autorisation du nom d'utilisateur extrait du certificat peut être ignorée.

    aaa new-model
    aaa authorization network CERT none

     Configurez un point de confiance qui contient le certificat CA et éventuellement le certificat du routeur. 

    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

    Astuce : En cas d'inaccessibilité du serveur OCSP, l'administrateur peut choisir de refuser tout accès en utilisant la configuration revocation-check ocsp ou d'autoriser l'accès sans contrôle de révocation en utilisant revocation-check ocsp none (non recommandé).

    Configurez les mécanismes d'authentification autorisés utilisés lors de la négociation de tunnel 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

    Configurez le serveur SSH pour qu'il utilise les certificats corrects dans le processus d'authentification.

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

       ! CA used to authenticate client certificates
       user
          trustpoint verify SSH

    (Facultatif) Intégration avec le serveur TACACS 

    Une fois le nom d'utilisateur extrait du certificat, l'IOS peut effectuer l'autorisation de ce nom d'utilisateur sur le serveur TACACS. Ceci est particulièrement utile si le serveur TACACS est déjà déployé pour l'administration des périphériques. 

    Note: Le serveur SSH IOS ne prend actuellement pas en charge le chaînage des méthodes d'authentification. Cela signifie que si les certificats sont utilisés pour authentifier l'utilisateur, le serveur TACACS ne peut pas être utilisé pour l'authentification par mot de passe. Il ne peut être utilisé qu'à des fins d'autorisation.

    Configurez le serveur TACACS.

    tacacs server ISE
     address ipv4 10.1.1.3
     key cisco123

    Configurez la liste d'autorisations pour utiliser le serveur TACACS.

    aaa authorization network ISE group tacacs+

    1. Configurer ISE (Identity Services Engine). L'exemple de configuration se trouve à l'adresse suivante : 

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

    2. Configurez le profil TACACS. Le paramètre supplémentaire cert-application=all doit être configuré pour que l'autorisation réussisse, accédez à Centres de travail > Administration des périphériques > Éléments de stratégie > Résultats > Profils TACACS > Ajouter.

    3. Afin de configurer l'ensemble de stratégies, accédez à Centres de travail > Administration des périphériques > Jeux de stratégies d'administration des périphériques > Ajouter.

    Vérification

    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

    Dépannage

    Ces débogages sont utilisés pour suivre la session réussie :

    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

    Dans le cas où le certificat d'admin1 a été révoqué :

    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

    Informations connexes

    TAC Authored

    Contribution d’experts de Cisco

    • Jan Krupa
      TAC

    Ce document vous est-il utile?

    FeedbackCommentaires

    Contacter Cisco

    Ce document s’applique à ces produits