nginx : plusieurs chemins de certification

Les autorités de certification font signer leurs nouveaux certificats racine en plus par des certificats racine plus anciens et largement répandus (signature croisée). Il existe ainsi plusieurs chemins de certification pour un même certificat de serveur : les clients dont le magasin de confiance contient déjà le nouveau certificat racine utilisent le chemin court ; les clients plus anciens, par exemple d’anciennes versions d’Android ou d’environnements d’exécution Java, utilisent un chemin passant par un certificat racine plus ancien.

nginx délivre exactement un fichier de certificats par clé. Plusieurs chemins sont obtenus lorsque ce fichier (server.pem) contient tous les certificats intermédiaires nécessaires aux chemins souhaités. Chaque client choisit ensuite le chemin correspondant à son magasin de confiance.

Ce guide suppose que le certificat du serveur et la clé ont été préparés comme décrit dans Renouveler un certificat acheté →. Il complète le fichier server.pem créé à cette occasion par des certificats intermédiaires supplémentaires.

Exemple : Sectigo avec trois chemins #

Le résultat SSL Labs → suivant montre un serveur doté d’un certificat Sectigo pour lequel il existe trois chemins de certification :

Le certificat du serveur (1) a été émis par Sectigo Public Server Authentication CA DV R36. Au-delà, les chemins se séparent :

Le certificat racine Sectigo Public Server Authentication Root R46 est relativement récent et absent des anciens magasins de confiance. Les chemins #2 et #3, dans lesquels R46 est signé par un certificat racine plus ancien, existent pour ces clients.

Un nom, trois certificats #

Sectigo Public Server Authentication Root R46 apparaît trois fois dans l’exemple. Malgré son nom, il n’est un certificat racine que dans le chemin #1. Dans les chemins #2 et #3, il s’agit de certificats distincts portant le même nom et la même clé, émis par une autre autorité de certification. Ils ne sont pas auto-signés et sont donc des certificats intermédiaires :

Le nom étant identique, les variantes ne se distinguent que par leur émetteur et leur empreinte. Le pin (Pin SHA256) est identique pour les trois, car il découle de la clé commune.

Erreurs dans l’exemple #

Le serveur de l’exemple n’est pas configuré correctement. Dans le chemin #2, il délivre également le certificat racine USERTrust RSA Certification Authority (Sent by server en orange) ; dans le chemin #3, la variante de R46 signée par AAA Certificate Services manque (Extra download). Les deux erreurs et leur correction sont décrites dans Vérifier la chaîne de certificats avec SSL Labs →. Les sections suivantes présentent la chaîne correcte pour les trois chemins.

Obtenir et identifier les certificats #

Outre le certificat du serveur, les trois chemins nécessitent les certificats intermédiaires suivants :

• Sectigo Public Server Authentication CA DV R36
• Sectigo Public Server Authentication Root R46, émis par USERTrust RSA Certification Authority
• Sectigo Public Server Authentication Root R46, émis par AAA Certificate Services

L’autorité de certification met les variantes à signature croisée à disposition sur son site web. SSL Labs propose également les certificats de chaque chemin au format PEM via l’icône de téléchargement à droite du titre du chemin. L’obtention des certificats intermédiaires et leur conversion au format PEM sont décrites de manière générale dans Obtenir les certificats intermédiaires de l’autorité de certification →.

Les noms de fichiers des autorités de certification ne permettant pas toujours de reconnaître la variante, chaque fichier est vérifié avant utilisation :

openssl x509 -in sectigo-r46-usertrust.pem -noout -subject -issuer -fingerprint -sha256

La ligne issuer indique l’émetteur, la ligne sha256 Fingerprint l’empreinte, qui doit correspondre au tableau ci-dessus ou à l’affichage de SSL Labs. OpenSSL l’affiche en majuscules avec des deux-points, SSL Labs en minuscules sans séparateur. Si subject et issuer sont identiques, il s’agit du certificat racine ; il n’est pas nécessaire.

Constituer la chaîne #

server.pem commence par le certificat du serveur, suivi du certificat intermédiaire qui l’a émis. Viennent ensuite les variantes à signature croisée. Les certificats racine ne sont pas inclus – ni le R46 auto-signé, ni USERTrust RSA Certification Authority, ni AAA Certificate Services. Les clients qui connaissent R46 comme certificat racine terminent le chemin dès Sectigo Public Server Authentication CA DV R36.

Après une sauvegarde du fichier existant (par exemple cp server.pem server.pem.old), la chaîne est assemblée :

cat server-cert.pem sectigo-dv-r36.pem sectigo-r46-usertrust.pem sectigo-r46-aaa.pem > server.pem

La vérification de la chaîne affiche ensuite quatre entrées :

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

subject=CN = mdm.example.com
issuer=C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication CA DV R36

subject=C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication CA DV R36
issuer=C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication Root R46

subject=C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication Root R46
issuer=C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority

subject=C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication Root R46
issuer=C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = AAA Certificate Services

Aucune entrée n’a un subject et un issuer identiques ; le fichier ne contient donc pas de certificat racine. Les deux dernières entrées ont le même subject, mais diffèrent par leur issuer.

Chaque certificat supplémentaire alourdit chaque établissement de connexion d’environ 1,5 à 2 Ko. Un chemin supplémentaire n’est donc inclus que si des appareils ou des clients dont le magasin de confiance ne contient pas le certificat racine le plus récent sont en service.

Configurer nginx #

La configuration nginx ne change pas : ssl_certificate pointe toujours vers server.pem, ssl_certificate_key vers server.key. nginx délivre tous les certificats du fichier dans l’ordre dans lequel ils y figurent.

server {
    listen 0.0.0.0:443 ssl default_server;
    …

    ssl_certificate      /etc/nginx/server.pem;
    ssl_certificate_key  /etc/nginx/server.key;
    …
}

Deux malentendus sont fréquents :

• Plusieurs entrées ssl_certificate sont prévues dans nginx pour des certificats de types de clé différents (par exemple RSA et ECDSA), et non pour des chaînes alternatives d’un même certificat.
• ssl_trusted_certificate sert à vérifier les réponses OCSP et les certificats clients. Les certificats de ce fichier ne sont pas délivrés aux clients et ne complètent donc pas la chaîne.

nginx est redémarré afin qu’il lise le fichier modifié :

• Installation Docker : Redémarrer le conteneur nginx →
• Installation native sous Windows ou Linux : Installation native : renouveler le certificat →

Vérifier le résultat #

Pour finir, la configuration est vérifiée avec SSL Labs comme décrit dans Vérifier la chaîne de certificats avec SSL Labs →. Après un changement de certificat, un nouveau test est lancé via Clear cache.

La configuration est correcte si, dans les onglets Mozilla, Apple, Android, Java et Windows, tous les certificats intermédiaires de chaque chemin portent la mention Sent by server et le dernier certificat de chaque chemin uniquement la mention In trust store. La mention Extra download ne doit apparaître dans aucun chemin, et aucun certificat marqué Self-signed ne doit porter en même temps la mention Sent by server.