Posts Tagged ‘certificat’

Linux : problème de connexion (chaîne de certification)

lundi, mars 23rd, 2020

Si votre système (ubuntu 18.xx par exmple) n’est pas bien à jour, il est possible que la chaîne de certification qu’il embarque ne soit plus valide. Cela est visible sur certains serveurs Web en https certifiés par Digicert, mais du coup aussi sur les serveur VPN vpn20-1 ou vpn20-2 qui utilise également ce type de certificat et de chaîne de certification.

Le log (merci Clément) :

Mar 23 07:51:31 SCI-DIEBOLD4 charon-nm: 09[IKE] no trusted RSA public key found for 'vpn20-2.univ-fcomte.fr'

Sur le serveur VPN nous avons cela :

Mon, 2020-03-23 07:51:31 10[ENC] parsed INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
Mon, 2020-03-23 07:51:31 10[ENC] generating INFORMATIONAL response 2 [ N(AUTH_FAILED) ]

Pour corriger le problème et réussir à établir la connexion, Clément nous à fourni la solution :

dpkg-reconfigure ca-certificates
(vous pouvez laisser tous les certificats coché, sinon celui qui est impératif est celui de Digicert)
update-ca-certificates

Tags:, ,
Posted in Informations utilisateurs | No Comments »

Problème d’utilisation multiple d’un certificat

lundi, août 24th, 2009

Attention lorsque vous avez plusieurs machines qui possèdent le même certificat.
L’utilisation du même certificat depuis deux machines distincts (même avec deux adresses IP distincts) ne sera pas possible. La deuxième connexion sera coupé toutes les 10 secondes environ par le serveur VPN.
Le système client ré-essayant de se connecter automatiquement, cela vous donnera une impression de marche partiel.

Tags:, ,
Posted in problèmes utilisateurs | No Comments »

Problème Linux : certificat non reconnu

jeudi, mars 19th, 2009

Un certificat non reconnu provoque est visible dans les logs du serveur /var/log/auth.log
Après la séquence de négociation correcte :
Mar 18 13:24:54 debian pluto[6621]: "vpn-l2tp-XP"[1] 172.21.7.202 #1: responding to Main Mode from unknown peer 172.21.7.202
Mar 18 13:24:54 debian pluto[6621]: "vpn-l2tp-XP"[1] 172.21.7.202 #1: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Mar 18 13:24:54 debian pluto[6621]: "vpn-l2tp-XP"[1] 172.21.7.202 #1: STATE_MAIN_R1: sent MR1, expecting MI2
Mar 18 13:24:55 debian pluto[6621]: "vpn-l2tp-XP"[1] 172.21.7.202 #1: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: no NAT detected
Mar 18 13:24:55 debian pluto[6621]: "vpn-l2tp-XP"[1] 172.21.7.202 #1: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Mar 18 13:24:55 debian pluto[6621]: "vpn-l2tp-XP"[1] 172.21.7.202 #1: STATE_MAIN_R2: sent MR2, expecting MI3

Et l’erreur proprement dite :
Mar 18 13:24:55 debian pluto[6621]: "vpn-l2tp-XP"[1] 172.21.7.202 #1: Main mode peer ID is ID_DER_ASN1_DN: 'C=FR, ST=Franche-Comte, O=UFC, OU=CRI, CN=choucroute, E=vpn-master@univ-fcomte.fr'
Mar 18 13:24:55 debian pluto[6621]: "vpn-l2tp-XP"[1] 172.21.7.202 #1: no crl from issuer "C=FR, ST=Franche-Comte, L=Besancon, O=UFC, OU=CRI, CN=CAvpn, E=vpn-master@univ-fcomte.fr" found (strict=no)
Mar 18 13:24:55 debian pluto[6621]: "vpn-l2tp-XP"[1] 172.21.7.202 #1: no suitable connection for peer 'C=FR, ST=Franche-Comte, O=UFC, OU=CRI, CN=choucroute, E=vpn-master@univ-fcomte.fr'
Mar 18 13:24:55 debian pluto[6621]: "vpn-l2tp-XP"[1] 172.21.7.202 #1: sending encrypted notification INVALID_ID_INFORMATION to 172.21.7.202:500
L’interprétation de l’erreur est assez simple puisque nous voyons que le certificat de choucroute contient OU=CRI ce qui n’est pas une valeur attendu (LINUX, XP, MACOS)

Tags:, ,
Posted in Informations utilisateurs | No Comments »

problème windows : impossible de trouver un certificat valide

mercredi, septembre 3rd, 2008

Si l’erreur à la connexion VPN est : “Impossible de trouver un certificat valide”, vous devez suivre les instructions suivantes :
– enlever tous les certificats de la machine
– enlever les autorités de certification
– remettre le certificat que l’on vous a donné (VPN UFC)
– remettre les autorités de certification (normalement celui du VPN UFC est dans le certificat délivré => automatique)

Re-essayez une connexion VPN

Tags:, ,
Posted in Informations utilisateurs | No Comments »

IPSEC et taille du certificat serveur

mercredi, mai 7th, 2008

Le protocole IKE d’échange des certificats entre le serveur et le client ne supporte pas, de la part du serveur, une fragmentation des paquets contenant le certificat. Ainsi, avec une clef de certificat de taille 1024 bits, tout se passe bien, mais si l’on en crée une de 4096 bits, le serveur est incapable de négocier avec le client une connexion IPSEC.
Les serveurs VPN sont donc équipés de certificats avec des clefs de 1024 bits.

Tags:, ,
Posted in informations techniques | 3 Comments »

Certificat client : usage

jeudi, avril 10th, 2008

Avertissement aux utilisateurs : lorsque le CRI vous délivre, par l’intermédiaire de votre correspondant réseau, un certificat pour utiliser le VPN, ce certificat est à votre nom ; il est personnel, non cessible et vous avez la pleine responsabilité de son utilisation.

Durée de validité du certificat : la durée d’un certificat est normalement de 3 ans sauf spécification contraire.
Lorsque votre certificat arrive à échéance vous serez averti (3 mois, 1 mois, 15 jours avant) ainsi que votre correpondant.

Compatibilité des certificats avec les différents systèmes d’exploitation : un certificat délivré par le CRI à un usager est configuré pour fonctionner avec un certain type de machine.
Les distinctions se font vis à vis de l’OS est plus particulièrement pour MacOS (tiger et suivants), Windows (XP et Vista), Linux (debian/ubuntu, centos/fedora, mandriva).
L’installation d’un certificat prévue pour un MacOS ne fonctionnera pas sur un Windows et vice-versa.

Format du certificat :
Pour windows, le certificat comporte un seul fichier qui porte l’extension .p12.

Pour Linux, le certificat est composé des trois fichiers à copier dans différents répertoires.

Pour MacOS, un seul fichier avec l’extension .p12.

Tags:, , ,
Posted in Informations utilisateurs | No Comments »

Certificat serveur et MacOS

jeudi, avril 10th, 2008

Le certificat du serveur doit absolument contenir une information subjectAltName. Dans le fichier openssl.cnf il faut donc (si on utilise tinyCA) configurer la section suivante ainsi :
[ server_cert ]
...
#subjectAltName = email:copy
subjectAltName = IP:"adresse du serveur VPN"
Sans cette option, les clients MacOS ne peuvent pas établir la connexion IPSEC.

Tags:, , ,
Posted in informations techniques | No Comments »