Let's Encrypt est une autorité de certification gratuite, automatisée et ouverte, gérée pour le bénéfice du public. Les principes clés de Let's Encrypt sont :
Les principes clés de Let's Encrypt sont gratuits :toute personne possédant un nom de domaine peut utiliser Let's Encrypt pour obtenir un certificat de confiance sans frais.
- Gratuit : Toute personne possédant un nom de domaine peut utiliser Let's Encrypt pour obtenir un certificat de confiance sans frais.
- Automatique : Un logiciel s'exécutant sur un serveur Web peut interagir avec Let's Encrypt pour obtenir un certificat en toute simplicité, le configurer en toute sécurité pour son utilisation et s'occuper automatiquement du renouvellement.
- Sécurisé : Let's Encrypt servira de plate-forme pour faire progresser les meilleures pratiques de sécurité TLS, à la fois du côté de l'autorité de certification et en aidant les opérateurs de sites à sécuriser correctement leurs serveurs.
- Transparent : Tous les certificats délivrés ou révoqués seront enregistrés publiquement et accessibles à tous.
- Ouvrir : Le protocole d'émission et de renouvellement automatique sera publié en tant que norme ouverte que d'autres pourront adopter.
- Coopérative : Tout comme les protocoles Internet sous-jacents eux-mêmes, Let's Encrypt est un effort conjoint au profit de la communauté, au-delà du contrôle d'une seule organisation.
(source :https://letsencrypt.org/about/)
Introduction
Tout d'abord, nous devons mentionner certains côtés sombres du service Let's Encrypt. Aussi formidable que soit l'idée d'une autorité de certification publique et ouverte, elle nous pose également de nombreux problèmes. Les développeurs ont essayé de rendre le système d'obtention de certificats aussi simple que possible, mais cela nécessite toujours une plus grande compétence d'administration de serveur. Par conséquent, de nombreux développeurs comme celui d'ISPConfig (http://www.ispconfig.org/) ont implémenté cette solution directement dans leur. Cela apporte aux gens un déploiement plus efficace et une supervision sur l'ensemble du système beaucoup plus facile et flexible.
Véritable complication
De nombreuses personnes ont décidé d'implémenter Let's Encrypt sur leurs sites de production. Je trouve cela quand même une très mauvaise idée à faire sans être très (mais vraiment très) prudent. Let's Encrypt vous apporte la liberté mais vous limite également dans l'utilisation du certificat avec le cryptage SHA-256 RSA. La prise en charge de SHA-256 s'est améliorée au cours des dernières années. La plupart des navigateurs, plates-formes, clients de messagerie et appareils mobiles prennent déjà en charge SHA-256. Cependant, certains systèmes d'exploitation plus anciens tels que Windows XP pré-SP3 ne prennent pas en charge le chiffrement SHA-256. De nombreuses organisations pourront passer à SHA-256 sans rencontrer de problèmes d'expérience utilisateur, et beaucoup voudront peut-être encourager les utilisateurs exécutant des systèmes plus anciens et moins sécurisés à effectuer une mise à niveau.
Dans ce didacticiel, nous allons traiter cette incompatibilité d'une manière simple, mais toujours désagréable.
Prérequis
- Apache 2.4 et supérieur
- OpenSSL version 1.0.1e et ultérieure
- Apache mod_rewrite activé
Toute l'idée
Comme mentionné précédemment, il existe encore des appareils incompatibles avec la signature SHA-256 sur Internet. Lorsque j'ai été obligé de déployer un SSL sur certains sites Web, j'ai dû choisir entre deux options :
- Utiliser Let's Encrypt l'avoir gratuitement mais pas pour tous.
- Acheter un certificat avec une signature 128 bits.
Eh bien, toujours l'option non. 1 était le seul moyen car il avait été promis au client il y a longtemps (:Plus de théorie :
Plus de théorie
J'espère avoir expliqué le besoin et maintenant nous pouvons traiter les téléspectateurs non pris en charge de notre site Web. De nombreuses personnes utilisent des machines Windows XP avec SP2 et inférieur (oui, il y en a encore beaucoup). Nous devons donc filtrer ces personnes.
Dans votre "/etc/apache2/sites-available/your_domain.com.conf" ajoutez ce qui suit à la fin du fichier :
RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} !(NT\ 5) [NC]
RewriteRule ^(.*) https:// your_domain.com [R]
RewriteCond obtient une chaîne à partir de l'en-tête http de l'invité accédant à votre page. Vous pouvez simplement vérifier le vôtre et trouver plus d'informations ici : http://www.useragentstring.com/
La condition que nous avons utilisée nous dit quelque chose comme "si la chaîne ne contient pas 'NT 5'", alors RewriteRule exécute/applique la règle de redirection [R] vers la variante https de votre domaine, NT 5 est une chaîne de version du système d'exploitation pour les appareils Windows XP .Si vous n'utilisez pas cette redirection, les utilisateurs incompatibles ne pourront pas accéder à votre site Web en https.
Si vous n'utilisez pas cette redirection, les utilisateurs incompatibles ne pourront pas accéder à votre site Web https. Je dois vous avertir que cette solution n'est pas parfaite à 100 % comme certains d'entre eux
Je dois vous avertir que cette solution n'est pas parfaite à 100 % car certains clients n'ont pas à vous fournir d'informations pertinentes ou réelles. J'ai travaillé avec AWstats pour déterminer quel taux de systèmes inconnus accèdent à ma page et il est d'environ 1,3 %, donc assez peu de demandes. Si vous souhaitez traiter des systèmes d'exploitation inconnus pour garantir leur compatibilité, vous pouvez également ajouter inconnu dans la condition (RewriteCond %{HTTP_USER_AGENT} !(NT\ 5|unknown) [NC]).
Awstats
Après avoir réussi à "non rediriger" vos visiteurs incompatibles (en les maintenant dans un monde http non sécurisé), vous pouvez vous concentrer sur le côté https.
Configuration HTTPS
Nous supposons maintenant que vous avez déjà attribué le certificat à votre serveur Web et que vous l'avez également activé.
Dans votre fichier de configuration vhost, ajoutez à nouveau ce qui suit :
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
SSLProtocol All -SSLv2 -SSLv3
SSLCompression off
SSLHonorCipherOrder On
Le CipherSuite utilisé ici est un peu plus long que d'habitude. C'est pour une meilleure compatibilité. Vous pouvez obtenir le vôtre sur : https://cipherli.st/ ou https://mozilla.github.io/server-side-tls/ssl-config-generator/
Je dois encore mentionner que vous n'obtiendrez jamais une configuration parfaite pour répondre à la politique de haute sécurité et à la compatibilité. Vous devriez trouver un compromis.
Après avoir utilisé ces paramètres, vous pouvez tester la configuration et la compatibilité de votre serveur sur : https://www.ssllabs.com/ssltest/index.html
Vous allez trouver une longue liste d'appareils compatibles et incompatibles, ainsi que des informations supplémentaires pour vous orienter vers votre propre solution "parfaite".