Certificat SSL pour une adresse IP publique?


10

J'ai juste essayé d'acheter un SSL Comodo Positive, mais il a été rejeté car il ne prend pas en charge une adresse IP publique, mais il ne prend en charge qu'un nom de domaine.

Quelqu'un connaît-il un fournisseur de certificats SSL qui prend en charge l'adresse IP publique au lieu d'un nom de domaine?

Mon entreprise a un serveur dédié hébergé avec une société d'hébergement Web, qui est utilisé pour exécuter un bugtracker pour plusieurs projets (pour plusieurs clients). Puisqu'il n'est utilisé que pour un bugtracker, nous n'avons pas besoin d'un nom de domaine (nos clients y accèdent en tapant l'IP publique dans leur navigateur).


2
Je voudrais configurer un nom de domaine afin que vous n'ayez pas à vous souvenir de l'adresse IP lorsque vous êtes à un endroit où vous ne l'avez pas mis en signet. De plus, lorsque vous changez d'IP, ce sera transparent.
Mark Wagner

Réponses:


16

Je pense que vous pouvez le faire, mais pas de la façon dont vous essayez de le faire.

Un certificat SSL est une déclaration liant une clé de chiffrement publique à une structure X.500 qui comprend un élément CN ou Common Name; un certificat signé en est un où la liaison est certifiée de manière vérifiable par une autorité de certification tierce, en utilisant une clé publique déjà connue des utilisateurs finaux (cette pile de certificats d'autorité de certification (CA) vivant dans votre navigateur).

Lorsque vous visitez un site Web sécurisé SSL avec un navigateur, le CN signé est porté à la connaissance du navigateur. Ce que le navigateur choisit d'en faire dépend du navigateur. Les navigateurs que je connais le comparent au nom d'hôte demandé, et une erreur s'il est différent (ou si cette liaison certifiée ne résiste pas à l'analyse, par exemple le certificat de signature n'est pas connu du navigateur ou la liaison est sortante). à jour, mais c'est une autre question). Rien ne vous empêche en principe d'obtenir un certificat signé publiquement où le CN est une adresse IP et non un FQDN (nom de domaine complet) [1], mais cela ne fera pas comme par magie le navigateur compare le CN avec l'IP au lieu du nom d'hôte demandé .

Je soupçonne que la façon la plus simple de résoudre votre problème est de démarrer votre propre autorité de certification, ce qui est facile à faire, et il existe de nombreux didacticiels publics sur; l'un est ici . Une fois que vos utilisateurs finaux auront importé votre autorité de certification dans leur navigateur, tous les certificats que vous émettrez seront acceptés comme faisant autorité.

Vous pouvez alors avoir un deuxième problème en ce que vous souhaitez exécuter un grand nombre de sites NameVirtualHost sur une seule adresse IP. Cela a toujours été insurmontable, car (contrairement à TLS) la négociation SSL a lieu avant toute autre chose sur une connexion; c'est-à-dire que le CN incorporé dans votre certificat est communiqué et utilisé par le client avant que le client ne puisse dire à quel hôte il essaie de se connecter.

Récemment, une extension de protocole appelée SNI (Server Name Indication) semble avoir été introduite, ce qui permet au client et au serveur d'indiquer qu'ils aimeraient faire des trucs de nom d'hôte avant la présentation du certificat SSL, ce qui permet le bon d'un ensemble des certificats à fournir par le serveur. Apparemment, cela nécessite Apache 2.2.10, une version suffisamment récente d'OpenSSL et ( surtout ) une prise en charge côté client.

Donc, si je devais faire ce que vous essayez de faire, je chercherais à créer mon propre certificat CA, en disant à mes utilisateurs finaux qu'ils doivent utiliser des navigateurs qui prennent en charge SNI et importer mon certificat racine CA, et couper et signer mes propres certificats SSL pour chaque site bugtrack.

[1] D'accord, vous n'avez peut-être trouvé personne pour le faire, mais c'est un détail d'implémentation. Ce que j'essaie de montrer ici, c'est que même si vous le faisiez, cela ne résoudrait pas votre problème.


4
Pour une application spécifique, pourquoi pas? Si elle est fabriquée par le fournisseur de l'application et que vous ne lui faites pas confiance, vous êtes quand même foutu par rapport à cette application, car il a la clé SSL privée et peut décrypter les choses malgré tout. et si cela les inquiète autant, il peut simplement couper des certificats auto-signés pour chacun de ses sites buqtrack, et ils peuvent les importer au besoin.
MadHatter

2
@Tom - si vous ne faites pas confiance à la personne qui vous offre le certificat dans l'exemple ci-dessus, pourquoi voudriez-vous même faire affaire avec eux en premier lieu? Que le certificat SSL soit délivré ou non par / avec le soutien d'une autorité de certification connue est le moindre de vos soucis de confiance WRT si vous confiez des données à une application `` en ligne ''.
Rob Moir

2
Je suppose que la crainte est que, comme il semble qu'il n'y ait aucun moyen d'installer une autorité de certification faisant autorité uniquement pour certains domaines, une fois qu'ils ont installé ma racine d'autorité de certification, je peux certifier les sites bancaires en ligne aussi facilement que ma propre application de suivi des bogues. Si je peux empoisonner leur cache DNS, je peux alors effectuer une attaque d'homme au milieu sur leurs services bancaires en ligne. Si cela les inquiète vraiment et qu'ils ne veulent pas utiliser un navigateur personnalisé pour ce projet, comme je l'ai dit ci-dessus, je pourrais couper un certificat auto-signé pour chaque bugtracker individuel, que les clients pourraient installer selon les besoins.
MadHatter

1
Tom, je suis en fait d'accord avec cette raison pour vouloir utiliser un certificat «de confiance». En fait, je suis d'accord à 100%. Ce n'est pas ainsi que votre commentaire original est apparu.
Rob Moir

1
Nom de domaine flamboyant? Ma langue maternelle n'est pas l'anglais, pouvez-vous expliquer cela? De plus, mon patron préfère utiliser une adresse IP publique, peut-être qu'il ne veut pas que le site soit trouvé par un moteur de recherche (les moteurs de recherche peuvent-ils trouver le site même s'il n'a pas de nom de domaine?)
moteur de série

10

Je connais une autorité de certification racine qui est pré-remplie avec tous les principaux navigateurs et émet des certificats SSL sur les adresses IP publiques: jetez un œil à GlobalSign . Ils lisent les informations RIPE pour valider votre demande de certificat, vous voudrez peut-être d'abord vérifier que l'entrée RIPE est émise avec le nom correct.

En ce qui concerne les commentaires, cette entrée a obtenu:

Oui , il est préférable d'acheter un nom de domaine et d'émettre un certificat SSL sur ce CN. C'est aussi moins cher que l'option GlobalSign ci-dessus.

Mais il y a des cas où les certificats SSL avec une IP publique comme CN sont utiles. De nombreux fournisseurs d'accès Internet et gouvernements bloquent les sites indésirables basés sur l'infrastructure DNS. Si vous proposez une sorte de site susceptible d'être bloqué, par exemple pour des raisons politiques, c'est une bonne option pour que ce site soit accessible via son adresse IP publique. En même temps, vous aurez envie de trafic Chiffrer pour les utilisateurs et vous ne voulez pas que vos utilisateurs non-tech à passer par les tracas de cliquer par des avertissements d'exception de sécurité de leur navigateur (parce que le CN du certificat ne correspond pas à celui que vous avez entré). Leur faire installer votre propre autorité de certification racine est encore plus compliqué et pas réaliste.


Notamment, "un serveur dédié hébergé avec une société d'hébergement Web" n'aura guère son propre RIP, mais le réseau environnant aura plutôt une entrée RIPE (sur la société d'hébergement)
Hagen von Eitzen

1

Allez-y et achetez le nom de domaine. Ils sont bon marché, ne soyez pas moins chers que ça. Vous n'en avez besoin que d'un. Peut-être même simplement configurer bugtracker.yourcompany.com.

Ensuite, pour chaque bugtracker, configurez un sous-domaine pour ce nom. Obtenez un certificat SSL pour chacun de ces sous-domaines. Étant donné que vous semblez particulièrement opposé aux coûts, l'entreprise avec laquelle vous souhaitez faire affaire s'appelle StartSSL.

http://www.startssl.com/

La raison pour laquelle vous souhaitez les utiliser est que (en plus d'être approuvés par les principaux navigateurs), leurs certificats ne coûtent pas un bras et une jambe. Le type le plus basique de cert est vraiment, honnêtement, sans merde. Ils vérifient votre identité, puis vous permettent d'en émettre autant que vous le souhaitez. Si vous voulez des certificats plus sophistiqués (qui coûtent normalement plusieurs centaines de dollars), vous cherchez environ 50 $ pour 2 ans pour prendre en charge SSL pour plusieurs domaines sur une seule IP.

Ils sont super bon marché pour ce que vous obtenez. Ils émettent de vrais certificats, approuvés par les navigateurs de vos clients, et non des essais de 90 jours comme le font d'autres endroits.


1
Je ne pense pas non plus comprendre cela. Un certificat SSL correctement émis est un jeton d'identification à lui seul; l'autorité de certification ne fournit aucun service après le problème. Mon site est sécurisé sur un certificat RapidSSL, mais s'il tombait en panne demain, mon certificat serait tout aussi efficace qu'aujourd'hui.
MadHatter

2
Combien de vos clients vont faire une vérification complète des antécédents de votre fournisseur SSL? Ils devraient vraiment creuser avant de réaliser qu'ils faisaient affaire avec une entreprise qui faisait affaire avec une entreprise israélienne. Comme l'a dit MadHatter, l'instabilité politique a très peu à voir avec la validité de votre certificat. Une fois émis, il est valable jusqu'à son expiration, point final. Mais c'est cool si vous voulez payer à un autre registraire de l'argent ridicule pour quelque chose qui n'est pas techniquement compliqué. Les certificats SSL sont l'une des escroqueries les plus ridicules de tous les temps.
Paul McMillan

2
Hé, tout ce qu'il faut, c'est un seul client pour le faire sauter. Désolé car je ne suis pas très clair depuis le début. Mon pays n'autorise pas son peuple à faire des affaires avec Israël. C'est tout.
moteur série

1
Oui, cela aurait été une chose plus utile à dire. Les certificats SSL sont inutilement chers, mais à l'échelle des affaires, le coût n'est presque rien.
Paul McMillan

2
"Une fois délivré, il est valable jusqu'à son expiration, point final". Sauf s'il contient des informations de révocation, est révoqué et que le client applique la vérification de révocation. Et un CA en faillite serait probablement obligé de révoquer tous ses certificats. Je dis juste
Ryan Bolger
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.