Researchers uncovered 12 previously unknown OpenSSL vulnerabilities, some buried in decades-old code, all fixed in a coordinated January release.

Source: AISLE

Read more: CyberSecBrief

L'erreur SSL_CLIENT_AUTH_CERT_NO_PRIVATE_KEY est une erreur courante qui survient lorsqu'un navigateur ou une application tente de se connecter à un serveur sécurisé sans trouver la clé privée associée au certificat client.

Cette erreur peut empêcher les utilisateurs d'accéder à des services essentiels et créer des problèmes de sécurité. Résoudre cette erreur est crucial pour garantir des connexions sécurisées et fiables, tant pour les utilisateurs que pour les administrateurs système.

Qu'est-ce que l'erreur SSL_CLIENT_AUTH_CERT_NO_PRIVATE_KEY ?

L'erreur SSL_CLIENT_AUTH_CERT_NO_PRIVATE_KEY se produit généralement lorsqu'un certificat client est utilisé pour l'authentification, mais que la clé privée associée à ce certificat est manquante ou inaccessible. Cette clé privée est nécessaire pour établir une connexion sécurisée, car elle permet de chiffrer et de décrypter les informations échangées.

Les causes de cette erreur peuvent varier, incluant une mauvaise configuration, des fichiers de clés corrompus ou manquants ou des problèmes de permission de fichiers.

Pour les utilisateurs finaux, cela se traduit par une incapacité à accéder aux sites ou services sécurisés, tandis que pour les administrateurs système, cela peut représenter un défi de dépannage et de maintenance.

Mesure 1 : Vérification de la présence de la clé privée

La première étape pour résoudre l'erreur SSL_CLIENT_AUTH_CERT_NO_PRIVATE_KEY consiste à vérifier si la clé privée associée au certificat client est bien présente. Sans cette clé privée, le certificat ne peut pas être utilisé pour établir une connexion sécurisée.

Voici les étapes pour vérifier la présence de la clé privée :

1. Localiser le certificat client

Identifiez le chemin où le certificat client est stocké sur le serveur. Les certificats sont souvent stockés dans des répertoires comme /etc/ssl/, /etc/pki/tls/, ou dans un répertoire spécifique à l'application ou au serveur web utilisé.

2. Vérifier les fichiers de clé

Les fichiers de clés privées sont souvent identifiés par des extensions telles que .key ou .pem. Assurez-vous que le fichier de clé privée correspondant au certificat client existe dans le même répertoire.

3. Utiliser des commandes OpenSSL :

Vous pouvez utiliser des commandes OpenSSL pour vérifier la correspondance entre la clé privée et le certificat client. Par exemple, la commande suivante extrait le modulus de la clé privée et du certificat pour comparer les deux :

openssl rsa -noout -modulus -in chemin_vers_votre_cle_privee.key | openssl md5

openssl x509 -noout -modulus -in chemin_vers_votre_certificat.crt | openssl md5



Si les valeurs de hash résultantes sont identiques, la clé privée correspond bien au certificat. Sinon, il y a un problème de correspondance ou de présence de la clé privée.

Cette première mesure permet de s'assurer que la clé privée est disponible et correctement associée au certificat client, une étape essentielle pour résoudre l'erreur SSL_CLIENT_AUTH_CERT_NO_PRIVATE_KEY.

Mesure 2 : Associer correctement le certificat et la clé privée

Une association correcte entre le certificat et la clé privée est essentielle pour éviter l'erreur SSL_CLIENT_AUTH_CERT_NO_PRIVATE_KEY. Si ces éléments ne sont pas correctement appariés, le serveur ne pourra pas utiliser le certificat pour établir une connexion sécurisée.

Voici comment associer correctement le certificat et la clé privée :

1. Vérifier les fichiers existants

Assurez-vous que vous disposez à la fois du certificat client (généralement avec une extension .crt ou .pem) et de la clé privée (généralement avec une extension .key).

2. Comparer les informations du certificat et de la clé privée :

- Utilisez la commande OpenSSL pour extraire et comparer les informations du certificat et de la clé privée :

openssl rsa -noout -modulus -in chemin_vers_votre_cle_privee.key | openssl md5

openssl x509 -noout -modulus -in chemin_vers_votre_certificat.crt | openssl md5

- Les valeurs de modulus doivent être identiques. Si elles ne le sont pas, cela signifie que la clé privée ne correspond pas au certificat.

3. Réassocier le certificat et la clé privée si nécessaire

Si vous avez plusieurs certificats et clés privées, essayez de trouver la paire correcte en vérifiant les modulus jusqu'à ce qu'ils correspondent. Vous pouvez également utiliser des fichiers de configuration du serveur pour vérifier quelle clé est référencée par quel certificat.

4. Configurer le serveur

Assurez-vous que le serveur est configuré pour utiliser le certificat et la clé privée corrects. Cela implique de vérifier les fichiers de configuration du serveur web (comme Apache ou Nginx) pour s'assurer que les chemins vers le certificat et la clé privée sont corrects.

Par exemple, dans un fichier de configuration Nginx, vous devriez avoir quelque chose comme :

ssl_certificate /chemin/vers/votre_certificat.crt;

ssl_certificate_key /chemin/vers/votre_cle_privee.key;



5. Redémarrer le serveur

Après avoir effectué les modifications nécessaires, redémarrez votre serveur pour appliquer les changements. Utilisez les commandes appropriées pour votre serveur, par exemple :

sudo systemctl restart nginx



En suivant ces étapes, vous vous assurerez que le certificat et la clé privée sont correctement associés, ce qui est crucial pour résoudre l'erreur SSL_CLIENT_AUTH_CERT_NO_PRIVATE_KEY.

Mesure 3 : Utilisation d'un format de fichier compatible

Pour résoudre l'erreur SSL_CLIENT_AUTH_CERT_NO_PRIVATE_KEY, il est aussi important d'utiliser des formats de fichiers compatibles pour vos certificats et clés privées. Les formats courants incluent PEM et DER, chacun ayant ses propres particularités et usages.

Voici comment gérer les formats de fichiers pour garantir la compatibilité :

1. Comprendre les formats de fichiers

- PEM (Privacy Enhanced Mail) : utilisé couramment pour les certificats et clés sur les serveurs web. Les fichiers PEM sont encodés en Base64 et encadrés par des en-têtes —–BEGIN CERTIFICATE—– et —–END CERTIFICATE—–.

- DER (Distinguished Encoding Rules) : format binaire utilisé principalement sur les systèmes Windows. Les fichiers DER n'ont pas d'en-têtes ou de pieds de page et sont moins lisibles par l'humain.

2. Identifier le format actuel de vos fichiers

Vous pouvez souvent identifier le format d'un fichier par son extension : .pem ou .crt pour PEM, .der pour DER. Toutefois, les extensions ne sont pas toujours fiables, il est donc préférable de vérifier le contenu des fichiers.

3. Conversion entre formats

Si vos certificats et clés privées ne sont pas dans le bon format, vous pouvez les convertir à l'aide d'OpenSSL. Voici quelques commandes utiles :

- Conversion de DER à PEM pour un certificat :

openssl x509 -inform der -in certificat.der -out certificat.pem

- Conversion de PEM à DER pour un certificat :

openssl x509 -outform der -in certificat.pem -out certificat.der

- Conversion de DER à PEM pour une clé privée :

openssl rsa -inform der -in cle_privee.der -out cle_privee.pem

- Conversion de PEM à DER pour une clé privée :

openssl rsa -outform der -in cle_privee.pem -out cle_privee.der

4. Configurer le serveur pour le bon format

Assurez-vous que votre serveur est configuré pour utiliser les fichiers au format attendu. Par exemple, Apache et Nginx s'attendent généralement à des fichiers au format PEM. Vérifiez et mettez à jour les fichiers de configuration si nécessaire.

5. Validation après conversion

Après conversion, validez que les fichiers sont corrects et fonctionnent comme prévu. Utilisez les commandes de vérification OpenSSL pour confirmer que les certificats et clés privées correspondent et sont lisibles.

Mesure 4 : Configuration correcte du serveur

Une configuration correcte du serveur est essentielle pour éviter l'erreur SSL_CLIENT_AUTH_CERT_NO_PRIVATE_KEY. Une mauvaise configuration peut empêcher le serveur de trouver ou de lire les fichiers de certificats et de clés privées nécessaires pour établir une connexion sécurisée.

Voici les étapes pour vérifier et corriger la configuration du serveur :

1. Vérifier les chemins des fichiers

Assurez-vous que les chemins des fichiers de certificats et de clés privées spécifiés dans la configuration du serveur sont corrects. Par exemple, dans un fichier de configuration Apache, vous devriez voir quelque chose comme :

SSLCertificateFile /chemin/vers/votre_certificat.crt

SSLCertificateKeyFile /chemin/vers/votre_cle_privee.key



Dans la configuration Nginx, cela pourrait ressembler à :

ssl_certificate /chemin/vers/votre_certificat.crt;

ssl_certificate_key /chemin/vers/votre_cle_privee.key;

2. Vérifier les directives de configuration SSL

Assurez-vous que toutes les directives SSL requises sont correctement définies. Pour Apache, cela inclut des directives telles que SSLEngine on, SSLProtocol, et SSLCipherSuite. Pour Nginx, cela inclut ssl_protocols, ssl_ciphers, et ssl_prefer_server_ciphers.

3. Configurer les certificats intermédiaires

Si votre certificat client nécessite des certificats intermédiaires pour établir une chaîne de confiance complète, assurez-vous qu'ils sont inclus dans le fichier de certificat ou configurés séparément.

Dans Apache, utilisez SSLCertificateChainFile, et dans Nginx, ajoutez les certificats intermédiaires directement dans le fichier de certificat principal.

4. Vérifier les permissions des fichiers

Les fichiers de certificats et de clés privées doivent avoir des permissions correctes pour être lus par le serveur mais protégés contre tout accès non autorisé. Par exemple, les fichiers de clés privées doivent généralement avoir des permissions 600, et les certificats 644 :

chmod 600 /chemin/vers/votre_cle_privee.key

chmod 644 /chemin/vers/votre_certificat.crt

5. Tester la configuration du serveur :

Après avoir apporté des modifications à la configuration, testez-la pour vous assurer qu'il n'y a pas d'erreurs syntaxiques.

- Pour Apache, utilisez :

apachectl configtest

- Pour Nginx, utilisez :

nginx -t

6. Redémarrer le serveur

Appliquez les changements en redémarrant le serveur. Utilisez les commandes appropriées pour votre serveur, comme :

sudo systemctl restart apache2

sudo systemctl restart nginx



En suivant ces étapes, vous pouvez vous assurer que la configuration de votre serveur est correcte, ce qui est crucial pour éviter l'erreur SSL_CLIENT_AUTH_CERT_NO_PRIVATE_KEY et garantir une connexion sécurisée.

Mesure 5 : Vérification des permissions des fichiers

Les permissions des fichiers de certificats et de clés privées jouent un rôle crucial dans la prévention de l'erreur SSL_CLIENT_AUTH_CERT_NO_PRIVATE_KEY. Des permissions incorrectes peuvent empêcher le serveur d'accéder aux fichiers nécessaires, ou pire, exposer ces fichiers sensibles à des accès non autorisés.

Voici comment vérifier et corriger les permissions des fichiers :

1. Vérifier les permissions actuelles

Utilisez la commande ls -l pour vérifier les permissions des fichiers de certificats et de clés privées. Par exemple :

ls -l /chemin/vers/votre_certificat.crt

ls -l /chemin/vers/votre_cle_privee.key

2. Permissions recommandées

Les clés privées doivent être strictement protégées. Les permissions recommandées pour les fichiers de clés privées sont 600, ce qui signifie que seul le propriétaire peut lire et écrire ce fichier :

chmod 600 /chemin/vers/votre_cle_privee.key

Les certificats peuvent être plus largement accessibles, mais doivent toujours être protégés contre les modifications. Les permissions recommandées pour les certificats sont 644 :

chmod 644 /chemin/vers/votre_certificat.crt

3. Vérifier le propriétaire des fichiers

Assurez-vous que les fichiers de certificats et de clés privées sont possédés par l'utilisateur et le groupe sous lesquels le serveur web s'exécute.

- Pour Apache, cela est souvent www-data. Pour Nginx, cela peut également être www-data ou l'utilisateur défini dans la configuration de Nginx.

chown www-data:www-data /chemin/vers/votre_certificat.crt

chown www-data:www-data /chemin/vers/votre_cle_privee.key

4. Sécuriser les répertoires contenant les fichiers

Assurez-vous que les répertoires contenant les fichiers de certificats et de clés privées ont des permissions appropriées et ne sont pas accessibles publiquement. Par exemple :

chmod 700 /chemin/vers/votre_repertoire

5. Surveiller les accès aux fichiers

Il peut être utile de surveiller les accès aux fichiers de certificats et de clés privées pour détecter toute tentative d'accès non autorisé. Utilisez des outils de surveillance de fichiers ou configurez des audits de sécurité.

Mesure 6 : Réinstallation du certificat client

Dans certains cas, l'erreur SSL_CLIENT_AUTH_CERT_NO_PRIVATE_KEY peut persister en raison de problèmes avec le certificat client lui-même. La réinstallation du certificat client peut être nécessaire pour résoudre ce problème. Voici comment procéder à une réinstallation propre du certificat client :

1. Sauvegarder les certificats et clés existants

Avant de faire toute modification, assurez-vous de sauvegarder les certificats et les clés existants. Cela vous permettra de revenir en arrière en cas de problème :

cp /chemin/vers/votre_certificat.crt /chemin/vers/sauvegarde/votre_certificat.crt

cp /chemin/vers/votre_cle_privee.key /chemin/vers/sauvegarde/votre_cle_privee.key

2. Supprimer les anciens certificats et clés

Si vous avez déterminé que les fichiers actuels sont corrompus ou incorrects, vous pouvez les supprimer en toute sécurité après avoir effectué une sauvegarde :

rm /chemin/vers/votre_certificat.crt

rm /chemin/vers/votre_cle_privee.key

3. Générer une nouvelle paire de clé et de certificat

- Utilisez OpenSSL pour générer une nouvelle paire de clé privée et de certificat. Voici un exemple de commande pour générer une nouvelle clé privée et une demande de signature de certificat (CSR) :

openssl genpkey -algorithm RSA -out /chemin/vers/votre_nouvelle_cle_privee.key

openssl req -new -key /chemin/vers/votre_nouvelle_cle_privee.key -out /chemin/vers/votre_demande_csr.csr

- Envoyez ensuite le fichier CSR à une autorité de certification (CA) pour obtenir un nouveau certificat client.

4. Installer le nouveau certificat client

Une fois que vous avez reçu le nouveau certificat client de l'autorité de certification, installez-le sur votre serveur. Copiez le certificat dans le répertoire approprié :

cp /chemin/vers/nouveau_certificat.crt /chemin/vers/votre_certificat.crt

5. Mettre à jour les fichiers de configuration du serveur :

Assurez-vous que les fichiers de configuration du serveur pointent vers les nouveaux fichiers de certificat et de clé privée.

- Par exemple, dans Apache :

SSLCertificateFile /chemin/vers/votre_certificat.crt

SSLCertificateKeyFile /chemin/vers/votre_nouvelle_cle_privee.key

- Pour Nginx

ssl_certificate /chemin/vers/votre_certificat.crt;

ssl_certificate_key /chemin/vers/votre_nouvelle_cle_privee.key;

6. Redémarrer le serveur

Appliquez les changements en redémarrant le serveur. Utilisez les commandes appropriées pour votre serveur :

sudo systemctl restart apache2

sudo systemctl restart nginx

Mesure 7 : Utilisation d'outils de diagnostic SSL

Pour diagnostiquer et résoudre l'erreur SSL_CLIENT_AUTH_CERT_NO_PRIVATE_KEY, l'utilisation d'outils de diagnostic SSL peut être extrêmement utile. Ces outils permettent de vérifier la configuration SSL, de tester les certificats et d'identifier les problèmes potentiels. Voici quelques outils et méthodes pour diagnostiquer les problèmes SSL :

1. OpenSSL

- OpenSSL est un outil puissant pour gérer et diagnostiquer les certificats SSL/TLS. Vous pouvez utiliser OpenSSL pour vérifier vos certificats et clés, tester les connexions SSL et plus encore.

- Exemple pour vérifier un certificat et une clé privée :

openssl rsa -check -in /chemin/vers/votre_cle_privee.key

openssl x509 -in /chemin/vers/votre_certificat.crt -text -noout

Pour tester une connexion SSL :

openssl s_client -connect votre_domaine:443

2. SSL Labs’ SSL Test

- Le SSL Test de SSL Labs est un service en ligne gratuit qui permet de tester l'installation SSL de votre site web. Il fournit des informations détaillées sur la configuration SSL, les certificats et les vulnérabilités potentielles.

- Accédez à SSL Labs SSL Test et entrez votre domaine pour obtenir un rapport détaillé.

3. Wireshark

- Wireshark est un analyseur de paquets réseau qui peut être utilisé pour capturer et analyser le trafic SSL/TLS. Cela peut aider à identifier les problèmes de négociation SSL et à vérifier que les certificats sont correctement échangés.

- Utilisez des filtres pour capturer uniquement le trafic SSL, par exemple :

ssl.handshake

4. curl

- curl est un outil en ligne de commande qui permet de transférer des données avec des URL. Il peut être utilisé pour tester les connexions SSL et obtenir des informations sur les certificats.

- Exemple de commande curl pour tester une connexion SSL

curl -vI https://votre_domaine

5. TestSSL.sh

- TestSSL.sh est un script en ligne de commande qui permet de tester les configurations SSL/TLS. Il est open-source et offre des diagnostics détaillés.

- Téléchargez et exécutez le script sur votre serveur pour obtenir des informations complètes sur votre configuration SSL :

./testssl.sh votre_domaine

6. Logs de serveur

- Consultez les logs de votre serveur web pour des messages d'erreur relatifs aux connexions SSL.

Read the full article