Je maintiens un VPN sous Debian via OpenVPN qui à cessé de fonctionner la semaine dernière. Petit retour sur sa remise en fonctionnement.
Un utilisateur de mon réseau VPN m’a signalé qu’il n’arrivait plus à y accéder. Aucun message significatif ne s’affichait dans sa console.
Après une brève analyse du fichier de journalisation /var/log/syslog sur mon serveur, je tombe sur ces lignes :
TCP connection established with [AF_INET]XXX.XXX.XXX.XXX:51900 XXX.XXX.XXX.XXX:51900 VERIFY ERROR: depth=0, error=CRL has expired: C=FR, ST=FR, L=Versailles, O=foo.bar, CN=SoX, emailAddress=hostmaster@foo.bar XXX.XXX.XXX.XXX:51900 OpenSSL: error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed XXX.XXX.XXX.XXX:51900 TLS_ERROR: BIO read tls_read_plaintext error XXX.XXX.XXX.XXX:51900 TLS Error: TLS object -> incoming plaintext read error XXX.XXX.XXX.XXX:51900 TLS Error: TLS handshake failed XXX.XXX.XXX.XXX:51900 Fatal TLS error (check_tls_errors_co), restarting
L’info qui nous intéresse ici est error=CRL has expired.
Wikipedia nous explique que CRL c’est pour certificate revocation list ou liste de révocation de certificats. OK donc cette liste peut expirer et cela devient problématique.
Pour en savoir plus, je décide d’afficher le contenu du certificat en question via la commande openssl crl -in crl.pem -text :
Certificate Revocation List (CRL): Version 1 (0x0) Signature Algorithm: sha256WithRSAEncryption Issuer: /C=FR/ST=FR/L=Versailles/O=foo.bar/CN=foo.bar CA/emailAddress=hostmaster@foo.bar Last Update: Sep 27 15:08:34 2017 GMT Next Update: Oct 27 15:08:34 2017 GMT No Revoked Certificates. [...]
Cette liste indiquait donc que 30 jours après sa création, elle devait recevoir une mise à jour (Next Update).
Et en lisant un ticket reporté auprès de Debian, on apprend que la version 2.4 du client d’OpenVPN n’autorise plus les connexions clientes dont la date Next Update de la CRL est dans le passée.
En regardant le fichier de configuration openssl.cnf dans le dossier d’OpenVPN sur mon serveur, il y est effectivement inscrit :
default_crl_days= 30 # how long before next CRL
Tout cela est donc cohérent.
Histoire de ne pas avoir à faire une intervention tous les mois, je change la valeur 30 en 3650 pour être synchrone avec la durée de vie des autres certificats.
Il ne reste plus qu’à regénérer la CRL via la commande :
. ./vars && KEY_CN='' KEY_OU='' KEY_NAME='' KEY_ALTNAMES='' openssl ca -gencrl -keyfile ca.key -cert ca.crt -out crl.pem -config openssl.cnf
Et le tour est joué. On vérifie ?
Certificate Revocation List (CRL): Version 1 (0x0) Signature Algorithm: sha256WithRSAEncryption Issuer: /C=FR/ST=FR/L=Versailles/O=foo.bar/CN=foo.bar CA/emailAddress=hostmaster@foo.bar Last Update: Nov 8 11:04:53 2017 GMT Next Update: Nov 6 11:04:53 2027 GMT No Revoked Certificates.
Yep ! On est tranquille pour 10 ans 🙂
Sources :
Un immense merci. Tu viens de me faire économiser des jours de galères… Vraiment, je sais le temps que ça prend d’écrire des articles. Mais prendre de son temps pour en faire gagner (autant !) aux autres…. C’est vraiment cool 🙂
Merci pour ton retour, cela me fait très plaisir 🙂
Bonjour,
je voulais vous remercier d’avoir écrit cette documentation qui m’a permis de résoudre ce problème extremement bloquant.
Merci beaucoup et bonne continuation.
Raphaël
Bonjour,
C’est avec plaisir 🙂
Bonne continuation également.
Je comprends que cette commande:
. ./vars && KEY_CN= » KEY_OU= » KEY_NAME= » KEY_ALTNAMES= » openssl ca -gencrl -keyfile ca.key -cert ca.crt -out crl.pem -config openssl.cnf
définit les variables, appelle le cert et la keyfile et utilise le fichier openssl.cnf (openvpn-ssl.cnf pour moi) pour générer le crl. Cependant, à partir de quel dossier dois-je commencer en tant que ../vars renvoie une erreur ./vars: No such file or directory?
(Veuillez excuser mon français). Enfin, J’ai decide de reconstruire mon VPN avec un nouveau CA. D’abord, j’ai changé mon fiche de configuration de donner le crl un date de « Next Update » de 10 ans (3650). Le nouveau VPN m’a donné un nouveau fiche de crl.pem avec « Next Update » en 2030. Comme je ne peux pas trouvé aucun lien entre le texte de crl.pem et le VPN, j’ai copié le fiche crl.pem et remplacé le fiche qui existe dans un de mes VPN d’origines. Le VPN a commencé de marcher immediatement. Maintenant, tout les trois VPN sur mon serveur marche encore avec les mêmes certificates en utilisant ce nouveau fiche crl.pem. Un solution un peu plus complexe pour eux qui ne peuvent pas régénérer le fichier crl.pem avec la mèthode ci-dessus.
Il faut se placer dans le dossier
/etc/openvpn/NOM_DU_VPN/easy-rsapour pouvoir avoir accès au fichiervarsIdem, merci beaucoup, j’ai eu ce souci ce matin, et il a été résolu très rapidement grâce à la clarté de l’article 🙂
Comme mentionné ci-dessus, depuis la version 3 du paquet easy-rsa, cela se gère facilement avec le fichier vars, pour les options, et le script easy-rsa, notamment avec la commande « ./easy-rsa gen-crl » 😉
Bonjour,
bravo et merci pour cette documentation & bravo
Bien à vous
Avec plaisir 😀
Juste… pas sûr que ce soit très sécurity compliant comme démarche (10 ans pour la CRL -> elle devient inutile) 😀
« Online CAs should have CRL validity periods that due not exceed 1 week or 7 days. This is due to the fact that end entity certificates may become untrusted and need to be revoked. Using a period of 7 days or shorter ensures a reasonable amount of time to notify “clients” after a CRL has been revoked. »
https://xdot509.blog/2020/10/15/pki-best-practices/
Je suis d’accord dans le principe.
La solution serait-elle alors d’automatiser le renouvellement ? Est-ce quelque chose que vous avez déjà mis en place ?
Merciiii ! Tu viens de me sauver ma soirée !
C’est un plaisir de pouvoir aider les copains ! 😀