le 21-08-2023 05:52 AM
Bonjour,
Suite à un problème de communication entre un DNAC et un cluster de 9800, avec une erreur : fatal libcrypto error when SSH to netconf port. J'ai suivi ces recommandations : CSCvt43974 : Bug Search Tool (cisco.com) C'est-à-dire la suppression du Trustpoint auto-signé puis la régénération d'un certificat.
Malheureusement sans succès et je me retrouve sans le Trustpoint auto-signé, il était décrit dans un autre poste (A self-signed certificate is added to a Cisco Catalyst switch that is managed through HTTPS - Cisco Community) qu'enlever puis réactiver le serveur https permettait de re-générer un certificat auto-signé, mais dans mon cas, ça n'a pas fonctionné. J'ai temporairement désactivé le https pour conserver un accès à la page web.
Pouvez-vous m'aider pour re-générer un Trustpoint auto-signé, avec une nouvelle paires de clé et un certificat pour résoudre mon ancien problème d'accès au netconf et à la page web https.
D'avance, je vous remercie.
Résolu ! Accéder à la solution.
le 21-08-2023 06:02 AM
Bonjour @poncelef,
Il faut depuis le 9800 supprimer le trustpoint puis générer une nouvelle paire de clé RSA et un nouveau trunspoint.
no crypto pki trustpoint trustpoint_name
crypto key generate rsa general-keys modulus size
crypto pki trustpoint trustpoint_name
enrollment selfsigned
subject-name cn=Common_Name
revocation-check none
rsakeypair key_label
exit
Enregistrez le Trustpoint auto-signé:
crypto pki enroll trustpoint_name
Il faut s'assurer que les Common Names et les autres paramètres doivent être adaptés à votre configuration et à vos besoins.
le 21-08-2023 06:02 AM
Bonjour @poncelef,
Il faut depuis le 9800 supprimer le trustpoint puis générer une nouvelle paire de clé RSA et un nouveau trunspoint.
no crypto pki trustpoint trustpoint_name
crypto key generate rsa general-keys modulus size
crypto pki trustpoint trustpoint_name
enrollment selfsigned
subject-name cn=Common_Name
revocation-check none
rsakeypair key_label
exit
Enregistrez le Trustpoint auto-signé:
crypto pki enroll trustpoint_name
Il faut s'assurer que les Common Names et les autres paramètres doivent être adaptés à votre configuration et à vos besoins.
le 21-08-2023 06:31 AM
Bonjour,
Merci pour votre réponse très rapide !
Alors grâce à vous j'ai pu récupérer l'accès en HTTPS en spécifiant le trustpoint nouvellement créé :
show ip http server status
HTTP server status: Enabled
HTTP server port: 80
HTTP server active supplementary listener ports: 21111
HTTP server authentication method: aaa
HTTP server auth-retry 0 time-window 0
HTTP server digest algorithm: md5
HTTP server access class: 0
HTTP server IPv4 access class: None
HTTP server IPv6 access class: None
HTTP server base path:
HTTP File Upload status: Disabled
HTTP server upload path:
HTTP server help root:
Maximum number of concurrent server connections allowed: 300
Maximum number of secondary server connections allowed: 50
Server idle time-out: 180 seconds
Server life time-out: 180 seconds
Server session idle time-out: 600 seconds
Maximum number of requests allowed on a connection: 25
Server linger time : 60 seconds
HTTP server active session modules: ALL
HTTP secure server capability: Present
HTTP secure server status: Enabled
HTTP secure server port: 443
HTTP secure server ciphersuite: rsa-aes-cbc-sha2 rsa-aes-gcm-sha2
dhe-aes-cbc-sha2 dhe-aes-gcm-sha2 ecdhe-rsa-aes-cbc-sha2
ecdhe-rsa-aes-gcm-sha2 ecdhe-ecdsa-aes-gcm-sha2
HTTP secure server TLS version: TLSv1.2 TLSv1.1
HTTP secure server client authentication: Disabled
HTTP secure server PIV authentication: Disabled
HTTP secure server PIV authorization only: Disabled
HTTP secure server trustpoint: XXXX-Management
HTTP secure server peer validation trustpoint:
HTTP secure server ECDHE curve: secp256r1
HTTP secure server active session modules: ALL
Par contre le netconf ne fonctionne toujours pas, j'ai toujours cette erreur : %DMI-2-NETCONF_SSH_CRITICAL: Chassis 2 R0/0: ncsshd_bp: NETCONF/SSH: fatal: mm_answer_sign: Xkey_sign failed: error in libcrypto
La commande show netconf-yang status renvoit ça :
netconf-yang: enabled
netconf-yang ssh port: 830
netconf-yang candidate-datastore: disabled
Pour information, c'est un cluster de 2 C9800-L en version 17.3.6 avec ces patches d'installés :
--------------------------------------------------------------------------------
Type Defect_ID Version St Filename
--------------------------------------------------------------------------------
APSP CSCwe10047 17.03.06. C C9800-L-universalk9_wlc.17.03.06.CSCwe10047.S
SMU CSCwd03847 17.03.06. C C9800-L-universalk9_wlc.17.03.06.CSCwd03847.S
SMU CSCwc05366 17.03.06. C C9800-L-universalk9_wlc.17.03.06.CSCwc05366.S
--------------------------------------------------------------------------------
Encore merci pour votre aide.
Cordialement
le 22-08-2023 06:43 AM
Bonjour @poncelef,
les certificats utilisés pour NETCONF sont-ils corrects et valides ? Vérifiez les dates d'expiration et l'ensemble de la chaîne de confiance du certificat.
Pas de Firewall ou ACL dans l'infra empêchant la com sur le port 830 ?
le 18-09-2024 03:51 AM
Bonjour,
Il faut reset le netconf sur le WLC:
csr-hub(config)#no netconf-yang
csr-hub(config)#
*Jun 9 15:01:04.021: yang-infra: netconf-yang server has been notified to stop
csr-hub(config)#
csr-hub(config)#netconf-yang
The existing self-signed trustpoint cannot be used for NETCONF.
Delete it and create a new one? [yes/no]: yes
CRYPTO_PKI: setting trustpoint policy TP-self-signed-3222202584 to use keypair TP-self-signed-3222202584
csr-hub(config)#
le 13-03-2024 11:38 AM
J'ai une alarme de certificat SSL de PRTG qui met correctement en évidence le "Unable to check revocation status"
avec <sh crypto ca certificates> je peux voir que l'autorité de certification émettrice ou racine ou l'autorité de certification racine est disponible pour être interrogée.
Je peux également voir le certificat via Cisco ASDM
>Configuration>Accès distant VPN>Gestion des certificats>Certificats CA.
Je ne comprends pas pourquoi je reçois cette alarme depuis une semaine sur 3 des 20 pare-feux ASA.
J'utilise la commande suivante sur le pare-feu dans le CLI et si j'importe une règle de pare-feu à partir du pare-feu et que j'effectue ensuite un déploiement, le paramètre est écrasé : ssl trustp-point My_trustpoint
conf t
dynamic-access-policy-confi activate
vpn-addr-assign local reuse-delay 0
no ssl trust-point <My_trustpoint>
Je ne comprends pas pourquoi (CSM) Cisco Security Manager continue à supprimer la dernière ligne de commande et malheureusement, je n'ai pas trouvé le coin du CSM où cela est configuré....
C'est probablement la raison pour laquelle des messages apparaissent dans le prtg, parce que l'autorité de certification vérifiée n'est pas la bonne ou qu'il s'agit, par défaut, de certificats auto-signés sur les firewalls.
la chaîne n'est malheureusement pas acheminée vers l'internet". Impossible de résoudre le nom de domaine" est le message que j'ai reçu de ssllabs.com.
Existe-t-il une solution pour valider ou comparer mes paramètres ?
le 13-03-2024 12:02 PM
Bonjour @MJ666
La suppression involontaire de la commande "no ssl trust-point" par CSM pourrait être à l'origine de vos problèmes. Je vous recommande de vérifier attentivement la configuration de CSM pour vous assurer qu'elle ne modifie pas incorrectement les paramètres SSL sur vos pare-feux. En ce qui concerne la vérification des paramètres SSL, vous pouvez utiliser des outils tels que OpenSSL ou des services en ligne pour valider et comparer les configurations de certificats SSL sur vos pare-feux ASA. Assurez-vous également que vos certificats SSL sont correctement émis et ne présentent aucun problème de validation ou de résolution DNS.
14-03-2024 07:53 AM - modifié 14-03-2024 07:53 AM
M02@rt37 Sur mon serveur CSM j'execute un script qui me demande l'option4(le chemin exacte ou se trouve le certificat)
je ne retrouve pas le chemin.. Auriez-vous une idée?
le 25-03-2024 05:56 AM
Sur l'ensemble des Firewalls impactés, j'ai constaté que l'interface TrustPoint n'était pas créee.
Je l'ai fais, et ca fonctionne à 70%. Certains boitiers continuent de renvoyer le message ..
le 25-03-2024 06:05 AM
le 26-03-2024 12:43 AM
Bonjour,
Je désire installer un compte localdmin sur tous les switches et routers afin de pouvoir m'y connecter lorsque le radius(SSH) est indisponible.
Pour faire mon test après avoir installé le compte, je me rend compte le switch prend la priorité sur la connection SSH tant que le radius est disponible.
Avec
#conf t
#no aaa authentication login RADIUSLOGON group radius local
#no aaa authorization exec RADIUSLOGON group radius local
#aaa authentication login default local
#aaa authentication exec default local
#username localadmin privilige 15 secret azertytest
j'ai temporairement désactiver avec succès l'accès du switch au radius et j'arrive á me connecter localadmin()
Y aurait-il un moyen aaa de faire en sorte que le switch me propose d'utiliser soit le radius(ssh) soit localadmin(console port 0) sans avoir besoin de désactiver le radius?
Merci pour ton retour