Le coup du SNI c'est assez bizarre en effet, c'est un classique du processus TLS non ?
Oui, depuis 2003.
En plus je croyais qu'il y avait un "fallback" vers un certificat unique (ce qui est mon cas) sans SNI...
Oui. openssl s_client -connect shaarli.guiguishow.info:443 -tls1_2 -servername 'bidule.guiguishow.info'
(un nom bidon dans le SNI) fonctionne. Même résultat avec d'autres serveurs web que le mien.
openssl s_client -connect dukeart.netlib.re:443 -tls1_2 -servername 'bidule.guiguishow.info'
ne fonctionne pas.
=> J'imagine qu'il y a quelque chose à activer dans Caddy. L'option default_sni par exemple.
Le réglage n'est peut-être pas au niveau de la config' TLS. Peut-être que tu n'as pas configuré de virtual host par défaut qui écoute pour tous les noms, par exemple ? En HTTP, tu rediriges tout nom qu'on te demande en HTTPS, même les trucs bidons (exemple ci-dessous), donc j'y crois pas, mais bon…
$ curl -D - http://testduke.example
HTTP/1.1 308 Permanent Redirect
Connection: close
Location: https://testduke.example/
Server: Caddy
Date: Sun, 03 Jan 2021 19:50:47 GMT
Content-Length: 0
Dommage pour Dillo et ça me fait relativiser certaines remarques de Bortzmeyer dans son dernier article sur le web compliqué...
Tout est toujours compliqué tant qu'on n'a pas approfondi / tenté la chose.
Tout ce qui est promu comme étant simple cache quelque chose, toujours.
En TLSv1.3, je peux pas changer l'ordre des //cipher suites// :
Sur mon Debian 10, Dillo utilise TLS 1.2 (quel que soit le serveur).
Ma remarque sur les suites de chiffrement est annulée par mon « édit » : ce n'était pas le bon diagnostic. :)