Certificat générique auto-signé

J'ai installé pihole à la maison, donc je veux pouvoir gérer les demandes de n'importe quel site Web avec mon propre serveur, pour montrer une page "ce site a été bloqué".

J'essaie de le faire en créant un certificat auto-signé pour toute 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 appareil Windows et Windows montre qu'il s'agit d'un certificat valide.

Cependant, le 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? N'est CN = *-ce pas autorisé? Comment pourrais-je réaliser ce que je veux?

ssl certificate

— Daniël van den Berg
source

Remarque: pour les principaux sites Web, votre navigateur n'acceptera probablement aucun certificat que vous parvenez à générer. Ces sites utilisent l'épinglage de certificats et soumettent les empreintes digitales de leurs certificats TLS à inclure dans ces navigateurs. Votre certificat ne correspondra pas à l'empreinte digitale stockée et sera bloqué. Voici plus d'informations: noncombatant.org/2015/05/01/about-http-public-key-pinning

— Martijn Heemels

les certificats auto-signés peuvent être problématiques comme vous l'avez découvert. Vous pouvez plutôt chercher à obtenir une certification «appropriée» de letsencrypt.org - ils sont gratuits et prennent en charge les caractères génériques. Selon le nombre d'hôtes que vous essayiez de couvrir avec * dont vous avez réellement besoin, un (ou plusieurs) certificats de letsencrypt pourrait vous couvrir

— Dave Smylie

@DaveSmylie c'est pour un adblocker, je ne possède pas les domaines.

— Daniël van den Berg

@Stewart, veuillez lire mon commentaire précédent.

— Daniël van den Berg

À noter également: si vous l'utilisez pour un adblocker, il peut être préférable de supprimer silencieusement les connexions aux serveurs concernés au lieu d'afficher une autre page. 90% des annonces modernes sont initialement chargées via JavaScript, il est donc peu probable que votre page alternative ait une réelle visibilité sur la page. Cela va probablement casser des choses, en fait, en essayant de charger des ressources non JavaScript en Javascript.

— Nzall

Réponses:

Ce n'est pas permis. En tant qu'addition spécifique au protocole à la validation de nom d'hôte TLS standard, tous les principaux navigateurs Web (clients HTTPS) ont essentiellement accepté de restreindre les certificats génériques à "eTLD + 1" - c'est-à-dire qu'il doit y avoir un "TLD efficace" plus un autre non -composant de carte sauvage.

En général, cela se traduit par la nécessité d'au moins deux composants (ce *.example.netn'est pas un problème, mais ce *.netn'est pas le cas *). La règle du "TLD effectif" étend cela aux suffixes à plusieurs niveaux, car les co.ukgens les utilisent comme "TLD" indivisibles dans la pratique. (Ainsi *.example.ac.ukest autorisé mais *.ac.ukne l'est pas.)

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

Voir la discussion connexe dans Security.SE qui contient une citation des exigences de base du forum CA-Browser (qui ne s'appliquent qu'aux autorités de certification WebPKI publiques, mais qui reflètent quand même l'implémentation générale):

Les AC DOIVENT révoquer tout certificat où un caractère générique apparaît dans la première position d'é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 serait implémenté dans un serveur Web ordinaire, mais c'est une méthode courante utilisée par les systèmes commerciaux d'interception TLS; 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) a une ssl_certificate_by_luaoption pour implémenter la génération dynamique de certificats. Le proxy Squid prend en charge l' imitation de certificats dans sa fonction ssl-bump.

Notez également que les SAN remplacent complètement le Subject-CN si les deux sont présents. Cela rend notamment le CN redondant (sauf si votre logiciel client est si ancien qu'il ne prend pas en charge le SAN), et pour les autorités de certification les navigateurs Web publics ne l'acceptent même plus.

— user1686
source

J'ai déjà découvert empiriquement cette limite TLD + 1 ici dans un projet. Merci de l'avoir présenté. +1

— Rui F Ribeiro

Merci pour votre réponse élaborée, je suppose que cela explique cela oui. Connaissez-vous une approche différente que je pourrais utiliser?

— Daniël van den Berg

A voté pour le placement stratégique de "et d'autres logiciels malveillants".

— Džuris

@ DaniëlvandenBerg: Il se trouve que j'en ai suggéré un dans le message lui-même. Je viens d'ajouter des liens vers des exemples Nginx et Squid.

— user1686

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

— Steffen Ullrich
source