Est-ce une mauvaise pratique d'utiliser des certificats SSL auto-signés?

Les certificats SSL sont assez chers pour les particuliers, surtout si vous devez sécuriser différents sous-domaines. J'envisage d'utiliser des certificats auto-signés, car mon objectif principal est de sécuriser la connexion et non de m'authentifier.

Cependant, plusieurs navigateurs affichent des avertissements désagréables lorsqu'ils rencontrent un tel certificat. Seriez-vous découragé d'utiliser des certificats auto-signés (par exemple pour une petite application Web ou la page d'administration d'un petit site Web)? Ou est-ce OK dans certains cas?

En général, il est mauvais d'utiliser un certificat auto-signé. Si vous faites cela, vous courez le risque que les gens quittent votre site lorsqu'ils reçoivent un avertissement indiquant que votre certificat est mauvais. Plus important encore, vous courez un plus grand risque de voir quelqu'un faire une attaque par injection où il utilise son propre certificat auto-signé à la place du vôtre et le visiteur ne saura rien de mieux.

Consultez l'article ici, http://www.sslshopper.com/article-when-are-self-signed-certificates-acceptable.html pour un peu plus d'informations à ce sujet.

Comme l'a dit RandomBen, les certificats auto-signés sont généralement mal vus pour les raisons qu'il a expliquées. Mais il y a une situation dans laquelle ils vont bien: si l'ensemble des personnes qui doivent soumettre des données sensibles à votre site Web est petit et limité, elles sont toutes quelque peu techniquement compétentes et vous êtes en mesure de communiquer avec toutes. Dans ce cas, vous pouvez donner à chaque personne les détails du certificat, puis ils peuvent vérifier manuellement le certificat lorsqu'ils se rendent sur votre site et ajouter une exception de sécurité le cas échéant.

À titre d'exemple extrême, sur mon VPS personnel, j'ai un sous-domaine administratif, auquel je ne devrais accéder que par moi. Il n'y aurait aucun problème à sécuriser ce domaine avec un certificat auto-signé car je peux vérifier manuellement que le certificat de serveur utilisé pour sécuriser la connexion est le même que j'ai installé sur le serveur.

Dans les cas où un certificat auto-signé ne fonctionnera pas ou si vous préférez en avoir un "réel", je recommande Let's Encrypt , un projet lancé par Internet Security Research Group et soutenu par les principales sociétés Internet, qui propose des certificats SSL sur sans frais. Ils peuvent le faire parce que le processus de vérification qu'ils utilisent est complètement automatisé, et en fait, un serveur Web qui prend en charge leur protocole ACME (comme Caddy , que j'utilise actuellement) peut obtenir des certificats entièrement par lui-même. Let's Encrypt ne vérifie pas que vous, en tant que personne, êtes ce que vous dites que vous êtes; il vérifie uniquement que votre serveur Web est capable de diffuser du contenu sur le domaine auquel il prétend. Let's Encrypt est pris en charge par tous les principaux navigateurs, mais il est bien connu que la vérification est minime, donc si vous exécutez quelque chose comme un site de commerce électronique ou quoi que ce soit où les gens soumettront des informations sensibles, vous devriez probablement dépenser de l'argent pour obtenir un certificat avec un niveau de validation plus élevé.

J'avais l'habitude de recommander les certificats gratuits StartSSL de StartCom pour les personnes qui ne voulaient pas payer pour la validation, mais plus maintenant. StartCom a été secrètement acquis par WoSign en 2016 et a ensuite délivré des certificats illégitimes pour plusieurs domaines. En conséquence, les principaux navigateurs ont supprimé leur prise en charge des certificats StartCom. (Pour autant que je sache, IE ne les a jamais pris en charge de toute façon.) En tout cas, Let's Encrypt est beaucoup plus pratique.

Ce n'est pas une mauvaise pratique d'utiliser des certificats auto-signés. Les certificats auto-signés ont de nombreux objectifs pratiques pour lesquels il n'est tout simplement pas logique d'utiliser un certificat signé par une autorité de certification.

Par exemple, sur plusieurs de mes serveurs, j'ai une connexion sans mot de passe configurée. Ce sont des serveurs auxquels je me connecte si souvent, et qui gardent parfois plusieurs connexions SSH ouvertes, qu'il est difficile de taper mon nom d'utilisateur et mon mot de passe à chaque fois.

À la place, j'utilise un certificat SSL auto-signé que je génère sur chacun de mes ordinateurs clients (un poste de travail au bureau, un ordinateur portable et mon poste de travail à domicile). Ce type de configuration me permet d'utiliser des phrases de passe assez longues, sécurisées et complètement uniques pour chacun de mes serveurs sans affecter la productivité. Et parce que j'ai un accès direct aux serveurs où je peux installer la clé publique pour chaque certificat, il est inutile d'utiliser un certificat signé par une autorité de certification.

Je pourrais configurer ma propre autorité de certification racine avec laquelle je peux signer tous les certificats à usage interne pour notre entreprise, et de cette façon, je n'aurais besoin d'installer qu'une seule clé publique sur chaque serveur. Cependant, notre organisation n'a pas atteint la taille qui le nécessite vraiment, et aux fins du HTTP sécurisé, ce serait toujours la même chose que d'avoir un certificat auto-signé.

De même, les certificats auto-signés sont fréquemment utilisés pour les connexions de messagerie, la signature PGP et les connexions de serveur à serveur où il est trivial de pré-échanger des clés publiques. Dans beaucoup de ces cas, cela est en fait plus sûr que de s'appuyer sur une chaîne de certificats qui pourrait être compromise à tout moment de la chaîne.

Si vous sécurisez plusieurs sous-domaines, vous souhaiterez peut-être utiliser des certificats génériques qui, selon le nombre de sous-domaines que vous sécurisez, pourraient s'avérer beaucoup moins chers que d'en acheter un par domaine; par exemple, RapidSSL a le caractère générique moins cher que les certificats individuels une fois que vous avez quatre domaines en cours d'utilisation.