web-dev-qa-db-fra.com

Certificat générique auto-signé

Pihole étant installé chez moi, je souhaite pouvoir traiter les demandes de tout site Web avec mon propre serveur, afin d'afficher une page "ce site a été bloqué".

J'essaie de le faire en créant un certificat auto-signé pour n'importe quelle URL et en l'installant sur mon appareil. Les commandes que j'ai utilisées pour générer le certificat:

openssl genrsa 2048 > pihole.key
openssl req -new -x509 -nodes -days 36500\
    -key pihole.key \
    -subj "/C=NL/ST=Utrecht, Inc./CN=*" \
    -reqexts SAN \
    -config <(cat /etc/ssl/openssl.cnf \
        <(printf "\n[SAN]\nsubjectAltName=DNS:*,DNS:*")) \
    -out pihole.cert
openssl x509 -noout -fingerprint -text < pihole.cert > pihole.info
cat pihole.cert pihole.info > pihole.pem
service Apache2 reload

J'ai installé ce certificat sur mon périphérique Windows, et Windows indique qu'il s'agit d'un certificat valide.

Cependant, chrome me donne un NET::ERR_CERT_COMMON_NAME_INVALID, et Edge me donne une erreur similaire (DLG_FLAGS_SEC_CERT_CN_INVALID)

Pourquoi est-ce? CN = * est-il simplement interdit? Comment pourrais-je réaliser ce que je veux?

sslcertificate
14
Daniël van den Berg

Ce n'est pas permis. En tant que protocole spécifique à la validation standard du nom d’hôte TLS, tous les principaux navigateurs Web (clients HTTPS) ont essentiellement accepté de limiter les certificats génériques à "eTLD + 1" - c’est-à-dire qu’il doit exister un "TLD effectif" plus un autre. composant -wildcard.

Généralement, cela signifie qu’il faut au moins deux composants (*.example.net convient, mais *.net ne l’est pas, pas plus qu'un * seul). La règle "TLD effectif" étend cette extension aux suffixes à plusieurs niveaux sous la forme co.uk que les utilisateurs utilisent comme "TLD" indivisibles dans la pratique. (Donc, *.example.ac.uk est autorisé mais *.ac.uk ne l’est pas.)

Vous pouvez vérifier comment la liste des suffixes publics est implémentée dans Chromium et dans Mozilla .

Voir discussion connexe dans Security.SE qui contient une citation des exigences de base du forum CA-Browser (qui s'appliquent uniquement aux autorités de certification WebPKI publiques, mais reflètent néanmoins la mise en œuvre générale):

Les CA DOIVENT révoquer tout certificat dans lequel un caractère générique apparaît dans la première position de l'étiquette immédiatement à gauche d'une étiquette "contrôlée par le registre" ou d'un "suffixe public".

Pour éviter cette restriction, créez une autorité de certification qui émet des certificats "à la demande" pour le site Web que vous essayez de visiter. Je ne sais pas comment cela pourrait être mis en œuvre sur un serveur Web classique, mais il s'agit d'une méthode courante utilisée par les systèmes d'interception TLS commerciaux; programmes antivirus et autres logiciels malveillants; et des outils de développement tels que la suite Burp Proxy.

Par exemple, le serveur Web OpenResty (essentiellement Nginx-with-Lua) dispose de l'option ssl_certificate_by_lua pour implémenter la génération de certificat dynamique. Le proxy Squid prend en charge le certificat imitant dans sa fonctionnalité ssl-bump.

Notez également que les réseaux SAN sont complètement override le sujet-CN si les deux sont présents. Cela rend le CN principalement redondant (à moins que votre logiciel client soit si ancien, il ne dispose pas du support SAN, et les navigateurs Web des autorités de certification publiques ne l'acceptent même plus.

36
grawity

Il ne peut y avoir qu'un seul caractère générique dans un certificat (c'est-à-dire pas *.*.example.com), il ne peut correspondre qu'à une seule étiquette (c'est-à-dire seulement www, pas www.example.com), il ne peut être qu'à la position la plus à gauche (c'est-à-dire *.www.example.com mais pas www.*.example.com) être à l'intérieur du suffixe public (c'est-à-dire pas *.com).

4
Steffen Ullrich