Certbot et certificats SSL sur plusieurs domaines - besoin d'avis

Pause Café
#1

Hello, je souhaiterais avoir votre avis sur un truc.

J’héberge plusieurs domaines, j’utilise nginx et je souhaite me simplifier la vie autant que possible tout en ayant un niveau de sécurité raisonnable.

J’ai donc, pour chaque domaine, pondu un petit script que je joue pour chaque domaine, ici pour le domaine1 :

#!/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

certbot certonly                                                                                        \
        --non-interactive                                                                               \
        --rsa-key-size 4096                                                                             \
        --preferred-challenges http                                                                     \
        --nginx                                                                                         \
        --agree-tos                                                                                     \
        --email webadmin@domaine1.net                                                                     \
        --renew-by-default                                                                              \
        --cert-name cert_global_domaine1.com                                                              \
        --webroot-path /usr/share/nginx/html/www.domaine1.com -d domaine1.com -d www.domaine1.com
#       --dry-run

ça marche bien, j’ai un certificat solide et tout va bien.

Je joue le même script, mais avec mon domaine2, je remplace donc 2 ou 3 bricoles dedans, je rajoute un sous domaine et zou. Idem, ça marche très bien.

Par contre, tout ce petit monde est sur un serveur dont les hôtes nginx écoute toutes sur la même adresse. Je me retrouve donc avec des alertes SNI lorsque je veux passer ça sur ssllabs. En soit, ça n’est pas impactant pour les navigateurs récents, mais c’est quand même chiant pour ceux qui naviguent avec une relique (je n’ai pas envie qu’ils descendent les 2 certificats alors qu’il n’y a besoin que d’un seul).

J’ai donc plusieurs solutions :

  1. mettre une IP virtuelle pour chaque hôte NGINX ==> je ne peux pas, j’ai déjà une ip pour chaque MX de chaque domaine, ça va être un foutoir monstre à gérer après, car je vais devoir encore rajouter des IPs si je veux être propre jusqu’au bout…

  2. ne pas faire un certificat par domaine, mais mettre tout le monde dans le même certificat, et là, finit les problèmes de SNI en théorie…

ça reviendrait donc à faire ceci :

#!/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

certbot certonly                                                                                        \
        --non-interactive                                                                               \
        --rsa-key-size 4096                                                                             \
        --preferred-challenges http                                                                     \
        --nginx                                                                                         \
        --agree-tos                                                                                     \
        --email webadmin@domaine1.net                                                                     \
        --renew-by-default                                                                              \
        --cert-name cert_global                                                              \
        --webroot-path /usr/share/nginx/html/www.domaine1.com -d domaine1.com -d www.domaine1.com
        --webroot-path /usr/share/nginx/html/www.domaine2.com -d domaine2.com -d www.domaine2.com
        --webroot-path /usr/share/nginx/html/www.domaine3.com -d domaine3.com -d www.domaine3.com
#       --dry-run

Et du coup de n’appeler que cert_global dans chaque conf Nginx.

Mais je me dis, c’est trop beau pour être vrai, ça ne peut pas marcher et visiblement personne ne fait ça.

Ma question est donc la suivante : est-ce qu’en prod une solution comme ça fonctionnerait ? Quels sont les éventuels problèmes ? En dehors que c’est moins propre que d’avoir un cert par domaine principal.

En ce qui me concerne je trouve ça quand même vachement plus simple à gérer et on évite les problèmes de SNI, mais il doit y avoir un loup quelque-part.

#2

Bah non, tu donnes juste la même ip à l’hote NGINX que celle du MX du domaine qu’il sert, non ?
Je ne comprends pas tout à ton probléme, mais je ne vois pas trop pkoi tu veux en rajouter. :smiley:

C’est quoi “SNI” ?

#3

Hello,

C’est une extension de SSL, ça permet justement de dire qu’on peut se connecter avec plusieurs certificats différents sur une même IP.

Ca pose problème uniquement pour le coup pour les vieux navigateurs.

Si tu passes ton site principal à sur https://www.ssllabs.com/ssltest/analyze.html?d=TONSITE.fr&hideResults=on

Ou un des sous domaines contenu dans l’hôte par défaut (default server), tu n’auras pas d’alerte. Par contre, si sur une même IP (hôte nginx/apache qui la partage du moins), tu as d’autres hôtes qui ont elles aussi leur propre certificat, si tu refais le test, tu verras un peu plus bas apparaître un 2eme certificat, avec la mention no SNI., avec un mismatch dans les Alternative names.

Ce qui veut dire que le domaine que tu viens de tester (qui ne correspond pas au default_server), partage son ip avec le domaine principal (default_server du coup). Et un vieux navigateur, au lieu de descendre le bon certificat, va descendre les deux.

Après c’est ainsi que je l’ai compris, à force de faire et refaire des tests dans tous les sens.

Vu que ce n’est problématique que sur les vieux navigateurs et que si on ban SSL v2/v3, TLS1.0/1.1, avec tous les vieux ciphers à problème, il est possible que de toute façon, le navigateur sur lequel ça pourrait poser problème n’arrive même pas jusque là, puisque ne sachant pas négocier avec les protocoles et ciphers récents (dans mon cas, c’est ça, j’ai bloqué tous les vieux trucs et n’autorise que TLS.1.2 et TLS.1.3).

Pour l’histoire de l’IP utilisée par le MX, je pensais à tord que cette ip réservée par MX ne devait être utilisée seulement que pour un A/MX record. En fait, non. Il ne doit effectivement y avoir qu’un MX pour cette IP, mais derrière on peut y balancer ce qu’on veut en records, du moment que c’est le MX qui répond en premier (et qu’il n’y en a qu’un seul dans la liste).

#4

Bonjour,
Est-ce que tu as mis une redirection, style :

  • Votre navigateur n’est pas compatible…

Et si oui, je suis curieux de savoir comment…
Bonne journée.

#5

Bonjour,

Non, pas de redirection et d’ailleurs, si le protocole ou le cipher n’est pas supporté par le navigateur, je ne vois même pas comment faire ça, puisque logiquement, il ne doit même pas arriver à lire la moindre entête, dans la mesure où le dialogue n’arrive pas à s’établir.

Soit je considère qu’une part de risque est acceptable, j’autorise TLS 1.1 voir 1.0, en ouvrant la cipher list, soit je restreint car je considère le risque d’interception de données trop grand (ce qui est mon cas pour mon employeur).

Je vise toujours le A+ pour sslabs et crypto check, tout en ayant le maximum d’ouverture aux clients.

1 J'aime