Bonjour, <div><br></div><div>J&#39;imagine que certains d&#39;entre vous l&#39;ont remarqué, la nouvelle mise à jour de Chrome vient de rendre invalide tout certificat ne possédant pas d&#39;extension subjectAlternateName dans un certificat SSL/TLS.</div><div><br></div><div>Autant le dire, ça vient de me retrancher quelques heures à ma vie pour régénérer les certificats de nos sites internes. Surtout qu&#39;openssl ne rend pas franchement aisé l&#39;ajout de cette extension si votre autorité de certification ne crée pas l&#39;extension pour vous :</div><div><br></div><div>openssl req \<br>    -newkey rsa:2048 \<br>    -x509 \<br>    -nodes \<br>    -keyout server.pem \<br>    -new \<br>    -out server.pem \<br>    -subj /CN=localhost \<br>    -reqexts SAN \<br>    -extensions SAN \<br>    -config &lt;(cat /System/Library/OpenSSL/openssl.cnf \<br>        &lt;(printf &#39;[SAN]\nsubjectAltName=DNS:localhost&#39;)) \<br>    -sha256 \<br>    -days 3650<br></div><div><br></div><div>(exemple tiré d&#39;un rapport de bug pour webpack sur les certificats autosignés : <a href="https://github.com/webpack/webpack-dev-server/issues/854">https://github.com/webpack/webpack-dev-server/issues/854</a>) </div><div><br></div><div>Ce changement fait suite à la volonté de l&#39;équipe de développement de se conformer au RFC 2818 (datant de 2000) qui indique que la vérification de l&#39;identité du serveur via le CN est obsolète et qu&#39;elle doit se faire sur dNSName de l&#39;extension SAN.</div><div>Personnellement, je trouve cette préconisation bien pourrie puisque dans le cas d&#39;un nom unique, le CN suffit largement, mais bon... </div><div><br></div><div>Voilà, c&#39;était juste histoire de partager ma mauvaise humeur. </div><div><br></div><div>Bon courage à ceux qui devront s&#39;embêter suite à cette mise à jour. </div><div><br></div><div>-- </div><div>Yoan </div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><p dir="ltr">-- <br>
Yoan AGOSTINI</p>
</div>