Let's Encrypt est une autorité de certification, et ils ont plus ou moins les mêmes privilèges et pouvoirs que toute autre autorité de certification existante (et plus importante) sur le marché.

À partir d'aujourd'hui, le principal inconvénient l'utilisation d'un certificat Let's Encrypt est la compatibilité. C'est un problème auquel toute nouvelle autorité de certification doit faire face lorsqu'elle approche du marché.

Pour qu'un certificat soit approuvé, il doit être signé par un certificat appartenant à une autorité de certification de confiance. Pour être digne de confiance, une autorité de certification doit avoir le certificat de signature intégré dans le navigateur / le système d'exploitation. Une autorité de certification qui entre sur le marché aujourd'hui, en supposant qu'elle soit approuvée par le programme de certificat racine de chaque navigateur / système d'exploitation à partir du jour 0 (ce qui est impossible), sera incluse dans les versions actuelles des différents navigateurs / systèmes d'exploitation. Cependant, ils ne pourront pas être inclus dans les versions plus anciennes (et déjà publiées).

En d'autres termes, si un CA Foo rejoint le programme racine le jour 0 lorsque la version de Google Chrome est 48 et Max OSX est 10.7, le Foo CA ne sera inclus (et approuvé) dans aucune version de Chrome antérieure à 48 ou Mac OSX antérieure à 10.7. Vous ne pouvez pas faire confiance rétroactivement à une autorité de certification.

Pour limiter le problème de compatibilité, Let's Encrypt a fait signer son certificat racine par une autre autorité de certification plus ancienne (IdenTrust). Cela signifie qu'un client qui n'inclut pas de certificat racine LE peut toujours se replier sur IdenTrust et que le certificat sera approuvé ... dans un monde idéal. En fait, il semble qu'il existe différents cas où cela ne se produit pas actuellement (Java, Windows XP, iTunes et autres environnements). C'est donc le principal inconvénient de l'utilisation d'un certificat Let's Encrypt: une compatibilité réduite par rapport à d'autres concurrents plus anciens.

Outre la compatibilité, d'autres inconvénients possibles sont essentiellement liés à la politique d'émission de Let's Encrypt et à leurs décisions commerciales. Comme tout autre service, ils peuvent ne pas offrir certaines fonctionnalités dont vous avez besoin.

Voici quelques différences notables de Let's Encrypt par rapport aux autres CA ( j'ai également écrit un article à leur sujet):

• LE ne sort pas actuellement certificats génériques (ils commenceront à émettre des certificats génériques en janvier 2018) LE délivre maintenant des certificats génériques en utilisant le protocole ACMEv2 mis à jour
• LE les certificats ont une expiration de 90 jours
• LE émet uniquement des certificats validés par domaine ou DNS (ils ne prévoient pas d'émettre OV ou EV, ils ne valident donc que la propriété et non l'entité qui demande le certificat)
• Actuellement très restrictif limitation de débit ^† (ils continueront d'assouplir la limite tout en se rapprochant de la fin de la bêta)

Les points ci-dessus ne sont pas nécessairement des inconvénients. Cependant, ce sont des décisions commerciales qui peuvent ne pas répondre à vos exigences spécifiques, et dans ce cas, elles représenteront des inconvénients par rapport à d'autres alternatives.

^† la limite de taux principale est 20 certificats par domaine enregistré par semaine. Cependant, cela ne limite pas le nombre de renouvellements que vous pouvez émettre chaque semaine.

La raison d'utiliser Let's Encrypt peut être le prix. Ces certificats seront gratuits.

Mais je vois un inconvénient possible pour les sites Web autres que les petits. Big CA propose des certificats wildcard, des certificats Extended Validation qui présentent certains avantages (de mon point de vue). De plus, ce programme est dirigé vers des serveurs Web, mais que se passe-t-il si vous avez un serveur d'application ou que vous souhaitez sécuriser le serveur de messagerie

Mise à jour : Il est actuellement possible de demander un certificat, non lié à serveurs Web. Donc mon dernier argument n'est plus valable. voici un exemple d'utilisation de cette option:

  ./letsencrypt-auto certonly --standalone -d example.com  

Update2 : À partir de janvier 2018, Let's Encrypt commencera à émettre des certificats wildcard

Les certificats Wildcard arriveront en janvier 2018

6 juillet 2017 • Josh Aas, directeur exécutif d'ISRG

Let's Encrypt commencera à émettre des certificats wildcard en janvier 2018. Les certificats Wildcard sont une fonctionnalité couramment demandée et nous comprenons qu'il existe certains cas d'utilisation où ils facilitent le déploiement HTTPS. Nous espérons que l’offre de jokers aidera à accélérer la progression du Web vers 100% HTTPS.

Un autre argument n’est donc plus valide.

Un inconvénient qui empêche les grandes entreprises d'envisager Let's Encrypt est que les visiteurs qui se connectent au site ne peuvent pas être sûrs que c'est la société qui héberge le site.

C'est parce que Let's Encrypt a des problèmes certificats pour un domaine gratuits sans validation d'identité (personnelle ou d'entreprise) ( Let's Encrypt propose uniquement la validation de domaine).

Modifié pour ajouter: Pour le but de la transmission sécurisée ce n'est pas un gros problème. Mais, si vous voulez vérifier que c'est bien la société que vous recherchiez qui détient le nom de domaine, une recherche whois peut ne pas suffire. Les certificats de classe 2 ou 3 ou EV ont l'avantage que l'entreprise et le domaine sont vérifiés par l'autorité de certification.

Un autre problème avec l'utilisation de Let'encrypt est que dans le scénario d'entreprise, nous devons également installer un certificat sur l'équilibreur de charge et le fournisseur CDN. Tous les fournisseurs de CDN n'ont pas d'API pour changer cela automatiquement. Aussi, à partir de maintenant, la validité de Let's encrypt est de 90 jours, ce qui complique davantage ce processus.

Oui, en utilisant Let's Encrypt, vous révoquez votre droit de défendre votre propriété intellectuelle, y compris le brevet, la marque, le secret commercial ou le droit d'auteur contre la violation par ISRG.

https://letsencrypt.org/ documents / LE-SA-v1.1.1-August-1-2016.pdf

PAR MANIER D'EXPLICATIONS SUPPLÉMENTAIRES CONCERNANT LA PORTÉE DE LA CLAUSE DE NON-RESPONSABILITÉ ET SANS RENONCER OU LIMITER CE QUI PRÉCÈDE EN AUCUN CAS, ISRG NE FAIT, ET ISRG EXCLUT EXPRESSÉMENT, TOUTE GARANTIE CONCERNANT SON DROIT D'UTILISER TOUTE TECHNOLOGIE, INVENTION, CONCEPTION TECHNIQUE, PROCESSUS OU MÉTHODE COMMERCIALE UTILISÉE DANS LA DÉLIVRANCE DE CERTIFICATS DE CRYPTE DE LET OU LA FOURNITURE DE TOUT SERVICES D'ISRG. VOUS RENONCEZ EXPRESSÉMENT ET AFFIRMATIVEMENT LE DROIT DE TENIR ISRG POUR RESPONSABLE DE QUELQUE MANIÈRE QUE CE SOIT, OU DE DEMANDER UNE INDEMNISATION CONTRE ISRG, POUR TOUTE INFRACTION AUX DROITS DE PROPRIÉTÉ INTELLECTUELLE, Y COMPRIS BREVET, MARQUE DE COMMERCE, SECRET COMMERCIAL OU COPYRIGHT.

Cette dernière phrase.