Problème de trustpoint certificate Cat9800

[poncelef]

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.

[M02@rt37 · Accepted solution]

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.

[poncelef]

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

 

[M02@rt37]

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 ?

[MOEL]

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)#

[MJ666]

M02@rt37 

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 ?

[M02@rt37]

 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. 

[MJ666]

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?

[MJ666]

M02@rt37 

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 ..

[M02@rt37]

Bonjour @MJ666 

Merci pour ce retour !

[MJ666]

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

[M02@rt37]

Bonjour @MJ666 

L'authentification RADIUS sera celle par défaut pour SSH et n'offrent généralement pas d'option de basculement automatique vers un compte local si RADIUS est disponible.....

Vous pouvez en revanche être en RADIUS en nominal sur les VTY et en compte local en console.

[MJ666]

Bjr M02@rt37, voici la config actuelle sur les boitiers

username local priv 15 secret azerty
aaa new-model
!
aaa authentication login RADIUSLOGON group radius local
aaa authorization enable default group radius enable
aaa authentication dot1x default group radius
aaa authorization console
aaa authorization exec RADIUSLOGON group radius local
aaa authorization network default group radius
aaa accounting dot1x default start-stop group radius
!
line con 0
timeout login response 60
authorization exec RADIUSLOGON
login synchronous
login authentication RADIUSLOGON
stopbits 1

line vty 0 4
access-class 20 in
exec-timeout 5 0
timeout login response 60
authorization exec RADIUSLOGON
logging synchronous
login authentication RADIUSLOGON
transport input ssh

line vty 5 15
access-class 20 in
exec-timeout 5 0
timeout login response 60
authorization exec RADIUSLOGON
logging synchronous
login authentication RADIUSLOGON
logging synchronous
login authentication RADIUSLOGON
transport input ssh