Vérifier la chaîne de certificats avec SSL Labs

Une connexion affichée comme valide par le navigateur lors de l’accès à l’interface web de Relution ne confirme pas encore que la configuration du certificat est correcte. Les navigateurs de bureau téléchargent souvent eux-mêmes les certificats intermédiaires manquants ou les ont déjà en cache. Les appareils mobiles, les clients basés sur Java et de nombreuses applications ne le font pas et refusent la connexion lorsque la chaîne est incomplète.

Le SSL Server Test gratuit de Qualys SSL Labs → vérifie le serveur depuis l’extérieur et indique quels certificats il délivre réellement et s’ils forment une chaîne valide pour les plateformes courantes. Cette vérification est recommandée après chaque changement de certificat, par exemple à la suite de Renouveler un certificat acheté →.

Prérequis #

SSL Labs vérifie le serveur via Internet. Pour cela, le nom d’hôte de l’External URL doit pouvoir être résolu publiquement dans le DNS et le serveur doit être accessible depuis Internet sur le port 443. Pour les serveurs accessibles uniquement depuis le réseau interne, la section Vérification sans accès à Internet → décrit une alternative avec OpenSSL.

Effectuer le test #

1. Sur www.ssllabs.com/ssltest →, le nom d’hôte de l’External URL est saisi dans le champ Hostname, par exemple mdm.example.com – sans https:// et sans chemin.
2. Si le résultat ne doit pas apparaître dans les listes publiques du site, l’option Do not show the results on the boards est activée.
3. Un clic sur Submit lance le test. Celui-ci dure quelques minutes.

Si le nom d’hôte est associé à plusieurs adresses IP (par exemple IPv4 et IPv6, ou plusieurs serveurs derrière un répartiteur de charge), SSL Labs vérifie chaque adresse séparément. Dans ce cas, le résultat de chaque adresse doit être examiné, car les serveurs peuvent être configurés différemment.

SSL Labs conserve les résultats en cache pendant un certain temps. Si le certificat a été remplacé depuis le dernier test, un nouveau test est lancé via le lien Clear cache de la page de résultats.

Évaluer le résultat #

La note globale en haut de la page de résultats évalue principalement les protocoles et les suites de chiffrement. Pour la chaîne de certificats, deux zones de la section du certificat du serveur sont déterminantes :

• Chain issues : cette ligne résume le résultat de la vérification de la chaîne. Avec une configuration correcte, elle indique None. Incomplete signifie qu’un certificat intermédiaire manque, Contains anchor que le certificat racine est également délivré et Incorrect order que les certificats sont délivrés dans le mauvais ordre.
• Certification Paths : les onglets Mozilla, Apple, Android, Java et Windows indiquent, pour le magasin de confiance (trust store) de chaque plateforme, par quel chemin le certificat du serveur remonte jusqu’à un certificat racine de confiance. Si un certificat intermédiaire a été signé par plusieurs autorités de certification (signature croisée), plusieurs chemins sont affichés (Path #1, Path #2 …).

Chaque chemin liste les certificats dans l’ordre, du certificat du serveur (1) jusqu’au certificat racine. La deuxième colonne indique la provenance de chaque certificat :

Configuration correcte #

Dans une configuration correcte, le serveur délivre le certificat du serveur et tous les certificats intermédiaires (Sent by server). Le certificat racine en fin de chemin provient du magasin de confiance (In trust store) :

Dans l’exemple, le serveur délivre le certificat du serveur pour mdm.example.com (1) et le certificat intermédiaire Sectigo Public Server Authentication CA DV R36 (2). Le certificat racine Sectigo Public Server Authentication Root R46 (3) figure dans le magasin de confiance. C’est la structure obtenue avec le guide Renouveler un certificat acheté →.

Le certificat racine est également délivré #

Si un certificat porte à la fois la mention Sent by server (en orange) et In trust store, le serveur délivre également le certificat racine. La ligne Chain issues indique alors Contains anchor :

Dans l’exemple, le certificat racine USERTrust RSA Certification Authority (4) figure dans server.pem. Les clients ne font confiance à un certificat racine que s’il se trouve dans leur propre magasin de confiance ; la copie délivrée n’est donc pas utilisée et ne fait qu’alourdir chaque établissement de connexion.

L’erreur est corrigée en retirant le certificat racine de server.pem :

1. Une sauvegarde est créée avant la modification, par exemple avec cp server.pem server.pem.old.

2. La commande suivante liste dans l’ordre tous les certificats du fichier avec leur titulaire (subject) et leur émetteur (issuer) :

   openssl crl2pkcs7 -nocrl -certfile server.pem | openssl pkcs7 -print_certs -noout
   

   Le certificat racine est l’entrée dont subject et issuer sont identiques, dans l’exemple la quatrième avec CN = USERTrust RSA Certification Authority.

3. Dans un éditeur de texte, le bloc de ce certificat est supprimé, de -----BEGIN CERTIFICATE----- jusqu’à -----END CERTIFICATE----- inclus. Les blocs figurent dans le fichier dans le même ordre que dans la sortie de la commande.

4. La commande de l’étape 2 est exécutée à nouveau ; aucune entrée avec un subject et un issuer identiques ne doit plus apparaître.

5. Le proxy inverse est redémarré afin qu’il lise le fichier modifié, voir Mettre en place le certificat dans le proxy inverse →. Le test est ensuite répété via Clear cache.

La constitution et la vérification de la chaîne sont décrites en détail dans Combiner le certificat du serveur et les certificats intermédiaires →.

Un certificat intermédiaire manque #

Si un certificat porte la mention Extra download (en orange), il manque dans la chaîne délivrée par le serveur. La ligne Chain issues indique alors Incomplete :

Dans l’exemple, le serveur ne délivre pas le certificat intermédiaire Sectigo Public Server Authentication Root R46 (3) – malgré son nom, il s’agit ici de la variante signée par AAA Certificate Services, donc d’un certificat intermédiaire et non d’un certificat racine. SSL Labs l’a téléchargé et a donc tout de même évalué le chemin comme Trusted. Les navigateurs de bureau se comportent souvent de la même manière, c’est pourquoi l’erreur passe fréquemment inaperçue dans le navigateur. Les appareils Android, les clients basés sur Java et de nombreuses applications ne téléchargent en revanche pas les certificats intermédiaires manquants et interrompent la connexion avec une erreur de certificat.

L’erreur est corrigée en ajoutant le certificat intermédiaire manquant à server.pem :

1. Le nom et l’empreinte (Fingerprint SHA256) de l’entrée portant la mention Extra download sont notés. L’empreinte est déterminante, car plusieurs variantes d’un certificat peuvent porter le même nom.

2. Le certificat intermédiaire est obtenu comme décrit dans Obtenir les certificats intermédiaires de l’autorité de certification →. SSL Labs propose également les certificats du chemin au format PEM via l’icône de téléchargement à droite du titre du chemin (Path #3 dans l’exemple) ; seul le bloc du certificat manquant en est repris. Si le certificat n’est pas au format PEM, il est converti comme décrit dans Convertir le certificat au format PEM →.

3. L’empreinte du fichier téléchargé doit correspondre à celle notée. OpenSSL l’affiche en majuscules avec des deux-points, SSL Labs en minuscules sans séparateur :

   openssl x509 -in intermediate.pem -noout -subject -issuer -fingerprint -sha256
   

4. Après une sauvegarde de server.pem (par exemple cp server.pem server.pem.old), le certificat intermédiaire est inséré après le certificat qu’il a émis. S’il se place en fin de chaîne, cat intermediate.pem >> server.pem suffit. Il convient de veiller à ce que -----END CERTIFICATE----- et -----BEGIN CERTIFICATE----- figurent sur des lignes distinctes.

5. La chaîne est contrôlée avec la commande de Combiner le certificat du serveur et les certificats intermédiaires →.

6. Le proxy inverse est redémarré, voir Mettre en place le certificat dans le proxy inverse →. Le test est ensuite répété via Clear cache.

Si, comme dans l’exemple, le certificat manquant appartient à un chemin supplémentaire destiné aux anciens magasins de confiance alors qu’un autre chemin est déjà complet, le serveur délivre plusieurs variantes du même certificat intermédiaire. La constitution d’une telle chaîne est décrite dans nginx : plusieurs chemins de certification →.

Vérification sans accès à Internet #

Si le serveur n’est pas accessible depuis Internet, la chaîne délivrée peut être affichée avec OpenSSL depuis un ordinateur du réseau interne. Le nom d’hôte est indiqué deux fois afin que le serveur sélectionne le certificat correspondant (SNI) :

openssl s_client -connect mdm.example.com:443 -servername mdm.example.com -showcerts </dev/null

La section Certificate chain de la sortie liste les certificats délivrés, numérotés à partir de 0, avec leur titulaire (s:) et leur émetteur (i:) :

Certificate chain
 0 s:CN = mdm.example.com
   i:C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication CA DV R36
 1 s:C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication CA DV R36
   i:C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication Root R46

La chaîne est correcte si le certificat du serveur se trouve en position 0 et si l’émetteur (i:) de chaque entrée correspond au titulaire (s:) de l’entrée suivante. L’émetteur de la dernière entrée est le certificat racine, qui ne figure pas lui-même dans la liste. Si la dernière entrée a un titulaire et un émetteur identiques, le certificat racine est également délivré.

À la fin de la sortie, la ligne Verify return code: 0 (ok) signale une chaîne valide. Les codes 20 (unable to get local issuer certificate) et 21 (unable to verify the first certificate) indiquent un certificat intermédiaire manquant. Ils apparaissent également lorsque le certificat racine est absent du magasin de confiance de l’ordinateur qui effectue la vérification, par exemple pour des certificats d’une autorité de certification privée.