Certificat SSL pour tous les domaines

Question

Est-il possible de générer un certificat openssl pour tous les domaines ? Je n'ai pas besoin de le signer avec un CA, aucun CA ne le fera jamais si c'est possible. J'en ai juste besoin pour une raison spécifique. Ou existe-t-il un moyen de le faire ?

Answer 1

est-il possible de générer un certificat openssl pour tous les domaines ?

Ça dépend, mais la plupart du temps, oui. J'appelle ça un "Super Cert".

Je ne peux que dire "principalement" car les navigateurs rejetteront la technique ci-dessous. D'autres agents utilisateurs, frameworks, bibliothèques et même systèmes d'exploitation l'accepteront.

---

En résumé, vous ajoutez ce qui suit à votre fichier openssl.cnf fichier :

[ x509_ext ]
...
subjectAltName          = @alternate_names
...

[ alternate_names ]

DNS.1       = *.com
DNS.2       = www.*.com
DNS.3       = *.net
DNS.4       = www.*.net
DNS.5       = *.gov
DNS.6       = www.*.gov
DNS.7       = *.mil
DNS.8       = www.*.mil
...

Ensuite, vous servez le même certificat pour chaque demande.

---

La raison pour laquelle ça marche est... Il existe deux groupes qui publient les règles que la majorité des agents utilisateurs suivent. Le premier est le Exigences de base de CA/Browser Forum . Le second est l'IETF avec RFC 5280 y RFC 6125 . Les navigateurs suivent le RE du Forum CA/Browser. D'autres agents utilisateurs, comme cURL et Wget, et des frameworks comme Java, Cocoa et .Net, suivent les RFC.

L'AC/B et l'IETF ont des règles pour faire correspondre le caractère générique, et cela signifie que vous devez travailler à la création du Super Cert. Vous ne pouvez pas simplement utiliser *_`.com_** y **_..com`_** pour tous les cas.

Selon les règles de correspondance, il arrive que plusieurs caractères génériques soient autorisés, que le caractère générique doive figurer dans l'étiquette la plus à gauche et qu'il ne puisse pas figurer dans l'étiquette du domaine.

---

Maintenant, les navigateurs refuseront de faire correspondre un nom comme *_`.com`_** dans un certificat. Elle est codifiée dans les exigences de base, et les domaines mondiaux de premier niveau (gTLD) sont répertoriés dans la liste des domaines de premier niveau. Liste de suffixes publics (PSL) utilisé par les navigateurs.

D'autres agents d'utilisateurs s'y conformeront volontiers, même si cela n'a aucun sens. Voici les agents utilisateurs, les bibliothèques et les frameworks qui ne parviennent pas à trouver la bonne correspondance. Ici, "bon" signifie fournir un niveau de sécurité médiocre. Ces agents utilisateurs devraient savoir que le canal est attaqué lorsqu'ils rencontrent un certificat qui prétend être émis pour l'ensemble du gTLD :

• Python
• Ruby
• Java
• .Net
• Cacao

Je crois me souvenir que PERL était le seul à avoir partiellement raison en rejetant *.com et ses amis. Cependant, il a accepté www.*.com si je me souviens bien.

Les autres agents utilisateurs qui n'ont pas rejeté les noms d'hôtes absurdes sont les suivants :

• wget
• bouclette
• gnutls
• ...

Lorsque j'ai déposé les rapports de bogue, la réponse la plus citée pour l'accepter était "... mais la RFC ne l'interdit pas".

J'ai essayé d'obtenir à la fois le Groupe de travail PKIX (ICP de l'Internet) et le Groupe de travail DBOUND (limites des domaines) de les rejeter (ou du moins de déconseiller leur acceptation) puisque nous savons qu'il n'existe pas d'organisation unique qui émet des certificats pour tous les pays de l'UE. .COM tous les .NET etc. Voir aussi Quelques travaux qui seront probablement acheminés vers le dbound plus tôt que tard .

---

James Polk a dit ça :

une AC ne le signera que si elle peut vérifier que vous contrôlez ces domaines. À moins, bien sûr, que vous puissiez tromper l'autorité de certification.

C'est en grande partie vrai. Si vous utilisez votre propre ICP, vous créez le Super Cert, le signez avec votre AC interne, et tout fonctionnera comme si une AC publique l'avait signé.

Cela suppose que vous avez installé le certificat de l'autorité de certification interne comme il se doit, mais c'est ce que vous faites lorsque vous exécutez votre propre autorité de certification.

Answer 2

Pas exactement. Vous pouvez auto-signer un certificat avec * comme nom commun. Évidemment, comme l'a souligné Robert, les utilisateurs recevront des avertissements, mais cette fois, l'avertissement concerne le fait que le certificat est signé par un émetteur inconnu. Laissez simplement vos utilisateurs l'accepter, éventuellement par un canal sécurisé (envoyez-leur un message S/MIME ou PGP avec votre certificat et votre clé publique, par exemple) et les avertissements seront également désactivés.

En ce qui concerne les autorités de certification, il est théoriquement possible de signer un certificat comportant autant de champs AltSubnectName que de sites Web à héberger en SSL, et c'est l'une des rares façons d'obtenir un hébergement SSL.

Answer 3

Non, il n'y a aucun moyen de générer un certificat qui correspond à tous les domaines. Et si vous pouvez générer un certificat qui correspond à plusieurs domaines - plusieurs, pas tous - une autorité de certification ne le signera que si elle peut vérifier que vous contrôlez ces domaines. À moins, bien sûr, que vous puissiez tromper l'autorité de certification.

Answer 4

Chaque certificat SSL est spécifique à un seul domaine. Si vous utilisez un certificat pour un domaine avec un autre, les utilisateurs recevront des avertissements indiquant que quelque chose de malhonnête se passe. (En plus de l'avertissement concernant un cert non signé).