Dit autrement, c’est le principe même de l’enregistrement DANE-EE qui permet(trait) de dégager la notion de CA, pas le fait d’épingler le certificat au lieu de la clef publique.
DANE-TA/EE n’est encore implémenté nul part malheureusement :'(
Mais TLSA, si tu pin sur le certificat, permet de s’affranchir des CA moisies, vu que si un faux certificat est émis (y compris par ta CA), il ne validera pas TLSA.
Un pin sur ta CA ou son intermédiaire te protège uniquement d’une usurpation par une autre CA.
Un pin sur ta clef ne te protège plus d’une compromission de ladite clef (possibilité d’émettre de nouveaux certificats, mais je t’accorde que ce cas est de toute façon un « tout est foutu » :P).
Et il est plus facile pour un humain de valider l’empreinte du certificat (dispo nativement et facilement dans les détails du certificat de ton navigateur) que celle de la clef associée (beaucoup plus difficile d’accès).
Et je rappelle à toute fin utile que la décision de changer de clef à chaque renouvellement n’est pas une décision de l’autorité de certification Let’s Encrypt. C’est une décision purement locale qui est du seul ressors du client, Let’s Encrypt n’impose rien du tout sur ce point.
LE n’incite pas à faire autrement. Et les paramètres par défaut sont malheureusement plus proche d’une imposition par le prestataire que d’un choix local. Les probabilités qu’un utilisateur les remettent en cause sont assez faibles (c’est même un des gros problèmes actuels de la crypto, avec des softs possédants une configuration par défaut mauvaise, et un des cheval de bataille du monde sécu du moment avec le « privacy/security by design »).
Donc comprendre comment la générer proprement (SAN, SHA-2...), faire la danse de la pluie et sacrifier 2 caisses de poulets lors de l’invocation openssl correspondante...
OK, en fait tu trolles.
Je te laisse mettre ici la ligne de commande openssl pour générer un CSR multi-domaine avec SAN et extensions X.509 corrects. On va rigoler...
J’ai même du développer ma propre PKI LE pour arriver à faire des choses correctes à ce niveau...
[^] # Re: 90 jours, et alors?
Posté par Aeris (site web personnel) . En réponse au message Let's Encrypt en prod en entreprise. Évalué à 1. Dernière modification le 22 septembre 2016 à 13:18.
DANE-TA/EE n’est encore implémenté nul part malheureusement :'(
Mais TLSA, si tu pin sur le certificat, permet de s’affranchir des CA moisies, vu que si un faux certificat est émis (y compris par ta CA), il ne validera pas TLSA.
Un pin sur ta CA ou son intermédiaire te protège uniquement d’une usurpation par une autre CA.
Un pin sur ta clef ne te protège plus d’une compromission de ladite clef (possibilité d’émettre de nouveaux certificats, mais je t’accorde que ce cas est de toute façon un « tout est foutu » :P).
Et il est plus facile pour un humain de valider l’empreinte du certificat (dispo nativement et facilement dans les détails du certificat de ton navigateur) que celle de la clef associée (beaucoup plus difficile d’accès).
LE n’incite pas à faire autrement. Et les paramètres par défaut sont malheureusement plus proche d’une imposition par le prestataire que d’un choix local. Les probabilités qu’un utilisateur les remettent en cause sont assez faibles (c’est même un des gros problèmes actuels de la crypto, avec des softs possédants une configuration par défaut mauvaise, et un des cheval de bataille du monde sécu du moment avec le « privacy/security by design »).
Je te laisse mettre ici la ligne de commande openssl pour générer un CSR multi-domaine avec SAN et extensions X.509 corrects. On va rigoler...
J’ai même du développer ma propre PKI LE pour arriver à faire des choses correctes à ce niveau...