Différences

Ci-dessous, les différences entre deux révisions de la page.

--- sysadmin:linux:gestion_certificats:generer_certificat_san_localhost [2021/10/28 17:30] – yoann
+++ sysadmin:linux:gestion_certificats:generer_certificat_san_localhost [2022/08/02 15:55] (Version actuelle) – ajout d'une référence externe yoann
@@ Ligne 9: / Ligne 9: @@
 Après plusieurs essais il ressort que:
-  * Les certificats SAN sur un TLD sont valides s'ils n'utilisent pas le wilcard;
+  * Les certificats SAN listant des TLD sont valides s'ils n'utilisent pas le wilcard;
-  * Les certificats SAN génériques sur un TLD sont refusés: *.localhost, *.local, *.any sont invalides;
+  * Les certificats SAN génériques sur un domaine de deuxieme niveau sont refusés: *.localhost, *.local, *.any sont invalides;
-  * Les certificats SAN génériques sous un nom de domaine de deuxième niveau sont valides: *.any.domain est valide
+  * Les certificats SAN utilisant le wilcard sur un nom de domaine de troisième niveau sont valides: *.any.domain est valide
+De ce que j'ai pu déduire le caractère générique (étoile ou **wilcard**) ne peut s'appliquer que sur un **FQDN  pour désigner les serveurs ou les sous-domaines mais pas les domaines et les TLDs**.
-Qui qu'il en soit, c'est en général une mauvaise idée de travailler directement avec localhost ou avec un TLD:
+Pour rappel le FQDN est formaté ainsi: server.subdomain.domain.tld.
+Notons également que c'est en général une mauvaise idée de travailler directement avec .localhost ou avec un TLD:
   * L'enregistrement ou la configuration de cookies peut poser des problèmes;
   * Certaines API incluses dans l'application rejettent des URL de la forme ''http://localhost'' les services peuvent alors produire des erreurs ou se comporter différemment en local;
-Pour ces raisons, il est préférable de générer un certificat sur des FQDN avec au minimum des noms de domaine deuxième niveau comme ''*.something.top''. Pour que le nom de domaine évoque bien que l'hébergement est local j'ai fait le choix d'utiliser **''*.host.me''**
+Ci-dessous pour rappel les manipulations faites avec un certificat de test
+<code bash>
+# Affiche la valeur du champ SAN (Subject Alternate Name)
+openssl x509 -noout -text -in service.localhost.crt | grep -i -A 1 "Subject Alternative Name"
+            X509v3 Subject Alternative Name:
+                IP Address:127.0.0.1, DNS:localhost, DNS:service.localhost, DNS:*.service.localhost, DNS:any, DNS:*.any
+</code>
+Comme on peut le voir ci-dessus, le champ SAN contient une adresse IP 127.0.0.1, si on contacte le serveur qui a cette même IP tout se passe bien:
+<code bash>
+curl -v --cacert ca-chain.cert.pem https://127.0.0.1
+...
+*  subjectAltName: host "127.0.0.1" matched cert's IP address!
+</code>
+Le champ SAN contient deux noms localhost et any, ici encore tout se passe bien:
+<code bash>
+curl -v --cacert ca-chain.cert.pem https://localhost
+...
+*  subjectAltName: host "localhost" matched cert's "localhost"
+</code>
+C'est pour les valeurs *.any et *.localhost du certificat que le résultat obtenu est différent de celui attendu. Le caractère générique devrait nous permettre d'utiliser un nom de la forme traefik.any ou traefik.localhost. Cependant on obtient une erreur:
+<code bash>
+curl -v --cacert ca-chain.cert.pem https://traefik.any
+...
+*  subjectAltName does not match traefik.any
+* SSL: no alternative certificate subject name matches target host name 'traefik.any'
+* Closing connection 0
+* TLSv1.3 (OUT), TLS alert, close notify (256):
+curl: (60) SSL: no alternative certificate subject name matches target host name 'traefik.any'
+More details here: https://curl.haxx.se/docs/sslcerts.html
+</code>
+Cette erreur ne se manifeste plus au niveau inférieur avec *.service.localhost
+<code bash>
+curl -v --cacert ca-chain.cert.pem https://traefik.service.localhost
+...
+*  subjectAltName: host "traefik.service.localhost" matched cert's "*.service.localhost"
+</code>
+Pour ces raisons, il est préférable de générer un certificat SAN avec des FQDN ( c'est à dire des noms de domaine de troisième niveau comme ''*.something.tld''.
+En utilisant .localhost en TLD on évite tout risque collision (La RFC 2606 le définit comme l'un des quatre domaines de premier niveau réservé). Aucun sous-domaines réels dans le système de nom de domaine (Domain Name System) d'Internet ne peut être construit en dessous. Un nom d'un domaine de premier niveau réservé n'est pas inclus dans les serveurs racines du DNS.
+Pour que le nom de domaine évoque bien que l'hébergement de services locaux j'ai fait le choix d'utiliser **''*.services.localhost''**
 <code bash>
 # Depuis le répertoire de l'autorité de certification intermédiaire
 cd intermediate_ca/
-export dn=srv.localhost
+export dn=localhost
+# Création de la clé privée
+openssl genrsa -out private/$dn.key 2048
+chmod 400 private/$dn.key
+# Création de la CSR
+openssl req -new -config CSR.cnf -key private/$dn.key -out csr/$dn.csr
+</code>
+Préparer le fichier des extensions X509 en complétant la section ''%%[alt_names]%%'' avec les FQDN
+<code bash>
+# Création du certificat
+openssl x509 -req -extfile build_cert_with_SAN.ext -days 30 -in csr/$dn.csr -CA certs/intermediate_ca.cert.pem -CAkey private/intermediate_ca.key -CAcreateserial -out certs_x509/$dn.crt
+# effacer la variable
+unset $dn
 </code>
-===== Tester la connexion =====
@@ Ligne 51: / Ligne 122: @@
   * https://en.wikipedia.org/wiki/.local
   * https://www.ionos.fr/digitalguide/domaines/gestion-de-domaine/fqdn/
+  * https://fr.wikipedia.org/wiki/Domaine_de_premier_niveau#Domaine_de_premier_niveau_r%C3%A9serv%C3%A9
+  * https://www.golinuxcloud.com/openssl-subject-alternative-name/

wikinotes

Outils pour utilisateurs

Outils du site

Différences

Outils de la page