D’ailleurs ton exemple est erroné puisque le CN devrait être identique à au moins un des SAN indiqués, généralement même le 1er.
NON. Ça c’est pour la compatibilité avec de très vieux clients qui ne connaissent rien d’autre que le CN et qui ne tiennent pas compte des SAN. L’utilisation du champ CN pour identifier le serveur est deprecated (cf RFC 6125).
(Et de toute façon dans le cas d’une CSR destinée à Let’s Encrypt peu importe, puisque la CA ignore complètement le CN fourni dans la requête. Le CN présent dans mon fichier de config est un reliquat de l’époque où je signais moi-même mes certificats.)
Et il te manque aussi la gestion des paramètres d’utilisation de la clef (avec sa compatibilité Netscape).
Ça c’est l’autorité de certification qui les ajoute au moment de signer la requête. (Tu peux les mettre d’emblée dans la requête si tu veux mais je ne connais aucune CA qui accepte de recopier bêtement les extensions de la requête dans le certificat final.)
[^] # Re: 90 jours, et alors?
Posté par gouttegd . En réponse au message Let's Encrypt en prod en entreprise. Évalué à 3. Dernière modification le 22 septembre 2016 à 15:30.
NON. Ça c’est pour la compatibilité avec de très vieux clients qui ne connaissent rien d’autre que le CN et qui ne tiennent pas compte des SAN. L’utilisation du champ CN pour identifier le serveur est deprecated (cf RFC 6125).
(Et de toute façon dans le cas d’une CSR destinée à Let’s Encrypt peu importe, puisque la CA ignore complètement le CN fourni dans la requête. Le CN présent dans mon fichier de config est un reliquat de l’époque où je signais moi-même mes certificats.)
Ça c’est l’autorité de certification qui les ajoute au moment de signer la requête. (Tu peux les mettre d’emblée dans la requête si tu veux mais je ne connais aucune CA qui accepte de recopier bêtement les extensions de la requête dans le certificat final.)