Certificats SSL
Résolu/Fermé
heliconius
Messages postés
539
Date d'inscription
mardi 1 juillet 2008
Statut
Membre
Dernière intervention
23 juin 2023
-
1 juil. 2019 à 18:20
mamiemando Messages postés 33401 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 28 novembre 2024 - 10 juil. 2019 à 10:40
mamiemando Messages postés 33401 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 28 novembre 2024 - 10 juil. 2019 à 10:40
A voir également:
- Certificats SSL
- Https //www.google.com/ gws_rd=ssl virus - Forum Virus
- Https://ad.doubleclick.net - Forum Samsung
- Https //www.google.com/ gws_rd=ssl - Forum Réseaux sociaux
- SSL - Forum Google Chrome
- Le client et le serveur ne sont pas compatibles avec une version de protocole ou une méthode de chiffrement ssl commune. ✓ - Forum Réseaux sociaux
4 réponses
mamiemando
Messages postés
33401
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
28 novembre 2024
7 804
Modifié le 2 juil. 2019 à 13:51
Modifié le 2 juil. 2019 à 13:51
Bonjour,
1) Non c'est quasiment transparent. Côté client client les changements sont mineurs (
a) activer le module ssl
b) éventuellement corriger/compléter la configuration de ton (tes) vhost(s) apache. Généralement on déclare un vhost pour le site en https et un pour le site en http. À terme on pourra supprimer le vhost http. Sous debian on configurerait typiquement
c) s'assurer que le site est joignable désormais en https (et donc éventuellement corriger les règles de ton pare-feu aka
À ce stade le site devrait devenir joignable en https mais avec un cadenas rouge (certificat invalide, et visible en ajoutant une exception de sécurité, etc...).
2) Le plus simple comme évoqué plus haut est de récupérer un certificat à l'aide de letsencrypt, simple à mettre en place sous linux (il suffit d'installer le paquet correspondant,
Une fois certbot configuré, le cadenas deviendra vert.
Bonne chance
1) Non c'est quasiment transparent. Côté client client les changements sont mineurs (
https://monsite.comau lieu de
https://monsite.com), mais maintenant c'est sécurisé. Côté serveur, il n'y a rien à faire côté code mais il va faire de la configuration à savoir (illustré avec les commandes qu'on lancerait sous debian/ubuntu) :
a) activer le module ssl
sudo a2enmod ssl sudo service apache2 restart
b) éventuellement corriger/compléter la configuration de ton (tes) vhost(s) apache. Généralement on déclare un vhost pour le site en https et un pour le site en http. À terme on pourra supprimer le vhost http. Sous debian on configurerait typiquement
/etc/apache2/sites-available/https.monsite.com.confainsi pour un wordpress :
<IfModule mod_ssl.c> <VirtualHost _default_:443> ServerAdmin webmaster@monsite.com ServerName monsite.com DocumentRoot /usr/share/wordpress Alias /wp-content "/var/lib/wordpress/wp-content" <Directory /usr/share/wordpress> Options FollowSymLinks AllowOverride Limit Options FileInfo DirectoryIndex index.php Require all granted </Directory> <Directory /var/lib/wordpress/wp-content> Options FollowSymLinks Require all granted </Directory> # Available loglevels: trace8, ..., trace1, debug, info, notice, warn, # error, crit, alert, emerg. # It is also possible to configure the loglevel for particular # modules, e.g. #LogLevel info ssl:warn ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined # For most configuration files from conf-available/, which are # enabled or disabled at a global level, it is possible to # include a line for only one particular virtual host. For example the # following line enables the CGI configuration for this host only # after it has been globally disabled with "a2disconf". #Include conf-available/serve-cgi-bin.conf # SSL Engine Switch: # Enable/Disable SSL for this virtual host. SSLEngine on # A self-signed (snakeoil) certificate can be created by installing # the ssl-cert package. See # /usr/share/doc/apache2/README.Debian.gz for more info. # If both key and certificate are stored in the same file, only the # SSLCertificateFile directive is needed. SSLCertificateFile /etc/letsencrypt/live/www.lincs.fr/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/www.lincs.fr/privkey.pem # Server Certificate Chain: # Point SSLCertificateChainFile at a file containing the # concatenation of PEM encoded CA certificates which form the # certificate chain for the server certificate. Alternatively # the referenced file can be the same as SSLCertificateFile # when the CA certificates are directly appended to the server # certificate for convinience. #SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt # Certificate Authority (CA): # Set the CA certificate verification path where to find CA # certificates for client authentication or alternatively one # huge file containing all of them (file must be PEM encoded) # Note: Inside SSLCACertificatePath you need hash symlinks # to point to the certificate files. Use the provided # Makefile to update the hash symlinks after changes. #SSLCACertificatePath /etc/ssl/certs/ #SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt # Certificate Revocation Lists (CRL): # Set the CA revocation path where to find CA CRLs for client # authentication or alternatively one huge file containing all # of them (file must be PEM encoded) # Note: Inside SSLCARevocationPath you need hash symlinks # to point to the certificate files. Use the provided # Makefile to update the hash symlinks after changes. #SSLCARevocationPath /etc/apache2/ssl.crl/ #SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl # Client Authentication (Type): # Client certificate verification type and depth. Types are # none, optional, require and optional_no_ca. Depth is a # number which specifies how deeply to verify the certificate # issuer chain before deciding the certificate is not valid. #SSLVerifyClient require #SSLVerifyDepth 10 # SSL Engine Options: # Set various options for the SSL engine. # o FakeBasicAuth: # Translate the client X.509 into a Basic Authorisation. This means that # the standard Auth/DBMAuth methods can be used for access control. The # user name is the `one line' version of the client's X.509 certificate. # Note that no password is obtained from the user. Every entry in the user # file needs this password: `xxj31ZMTZzkVA'. # o ExportCertData: # This exports two additional environment variables: SSL_CLIENT_CERT and # SSL_SERVER_CERT. These contain the PEM-encoded certificates of the # server (always existing) and the client (only existing when client # authentication is used). This can be used to import the certificates # into CGI scripts. # o StdEnvVars: # This exports the standard SSL/TLS related `SSL_*' environment variables. # Per default this exportation is switched off for performance reasons, # because the extraction step is an expensive operation and is usually # useless for serving static content. So one usually enables the # exportation for CGI and SSI requests only. # o OptRenegotiate: # This enables optimized SSL connection renegotiation handling when SSL # directives are used in per-directory context. #SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire <FilesMatch "\.(cgi|shtml|phtml|php)$"> SSLOptions +StdEnvVars </FilesMatch> <Directory /usr/lib/cgi-bin> SSLOptions +StdEnvVars </Directory> # SSL Protocol Adjustments: # The safe and default but still SSL/TLS standard compliant shutdown # approach is that mod_ssl sends the close notify alert but doesn't wait for # the close notify alert from client. When you need a different shutdown # approach you can use one of the following variables: # o ssl-unclean-shutdown: # This forces an unclean shutdown when the connection is closed, i.e. no # SSL close notify alert is send or allowed to received. This violates # the SSL/TLS standard but is needed for some brain-dead browsers. Use # this when you receive I/O errors because of the standard approach where # mod_ssl sends the close notify alert. # o ssl-accurate-shutdown: # This forces an accurate shutdown when the connection is closed, i.e. a # SSL close notify alert is send and mod_ssl waits for the close notify # alert of the client. This is 100% SSL/TLS standard compliant, but in # practice often causes hanging connections with brain-dead browsers. Use # this only for browsers where you know that their SSL implementation # works correctly. # Notice: Most problems of broken clients are also related to the HTTP # keep-alive facility, so you usually additionally want to disable # keep-alive for those clients, too. Use variable "nokeepalive" for this. # Similarly, one has to force some clients to use HTTP/1.0 to workaround # their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and # "force-response-1.0" for this. # BrowserMatch "MSIE [2-6]" \ # nokeepalive ssl-unclean-shutdown \ # downgrade-1.0 force-response-1.0 </VirtualHost> </IfModule>
c) s'assurer que le site est joignable désormais en https (et donc éventuellement corriger les règles de ton pare-feu aka
iptables).
À ce stade le site devrait devenir joignable en https mais avec un cadenas rouge (certificat invalide, et visible en ajoutant une exception de sécurité, etc...).
2) Le plus simple comme évoqué plus haut est de récupérer un certificat à l'aide de letsencrypt, simple à mettre en place sous linux (il suffit d'installer le paquet correspondant,
certbot-apache) et gratuit.
sudo apt-get update sudo apt-get install certbot python-certbot-apache sudo certbot --apache sudo certbot renew --dry-run sudo certbot renew --quiet
Une fois certbot configuré, le cadenas deviendra vert.
Bonne chance
zipe31
Messages postés
36402
Date d'inscription
dimanche 7 novembre 2010
Statut
Contributeur
Dernière intervention
27 janvier 2021
6 418
1 juil. 2019 à 18:49
1 juil. 2019 à 18:49
Salut,
Question 2 : Let's Encrypt ;-))
Question 2 : Let's Encrypt ;-))
WalterP
Messages postés
212
Date d'inscription
lundi 24 mars 2014
Statut
Membre
Dernière intervention
25 septembre 2024
5
Modifié le 1 juil. 2019 à 19:25
Modifié le 1 juil. 2019 à 19:25
Merci heliconius pour cet article ,
je viens de comprendre maintenant pourquoi mon site créé sur Unblog.fr n'est pas en https et pourquoi Mozilla m'indique à chaque connexion " Cette connexion n'est pas sécurisée. Les identifiants saisis ici pourraient être compromis. En savoir plus ".
Au départ je pensais que cette plate-forme ( Unblog.fr ) n'était pas sécurisée , ou l'était moins que les autres qui sont en https . Mais j'ai bien dû me rendre compte au fil du temps qu"il n'en était rien car mon site perso créé sur Unblog.fr n'a jamais été attaqué et que je n'ai jamais vu sur le forum Unblog.fr de plainte au sujet d'un site piraté !
Thank you and good luck !
je viens de comprendre maintenant pourquoi mon site créé sur Unblog.fr n'est pas en https et pourquoi Mozilla m'indique à chaque connexion " Cette connexion n'est pas sécurisée. Les identifiants saisis ici pourraient être compromis. En savoir plus ".
Au départ je pensais que cette plate-forme ( Unblog.fr ) n'était pas sécurisée , ou l'était moins que les autres qui sont en https . Mais j'ai bien dû me rendre compte au fil du temps qu"il n'en était rien car mon site perso créé sur Unblog.fr n'a jamais été attaqué et que je n'ai jamais vu sur le forum Unblog.fr de plainte au sujet d'un site piraté !
Thank you and good luck !
heliconius
Messages postés
539
Date d'inscription
mardi 1 juillet 2008
Statut
Membre
Dernière intervention
23 juin 2023
139
1 juil. 2019 à 20:05
1 juil. 2019 à 20:05
Oui, ça marche comme avant mais c'est repoussant pour les visiteurs...
avion-f16
Messages postés
19249
Date d'inscription
dimanche 17 février 2008
Statut
Contributeur
Dernière intervention
15 juin 2024
4 505
Modifié le 2 juil. 2019 à 20:41
Modifié le 2 juil. 2019 à 20:41
Bonjour,
En lisant ce message, j'ai l'impression que tu ne saisis pas le but de HTTPS et des connexions sécurisées, en général. Le but de ces connexions "SSL/TLS" est de mettre en place un cryptage de bout en bout, et faisant intervenir des certificats et des clés de cryptage privées, pour éviter qu'un intervenant "au milieu" n'écoute ou modifie les échanges entre le client/navigateur et le serveur.
« Cette connexion n'est pas sécurisée. Les identifiants saisis ici pourraient être compromis. En savoir plus »
Les navigateurs récents affichent les sites en HTTP comme "non sécurisé" dans le sens où les communications transitent en clair. Cela ne concerne pas la "sécurité" du site en lui-même, mais ces échanges en clair peuvent contenir des données sensibles (dont les mots de passe mais pas seulement) et être modifiés.
Lorsqu'un site est accessible en HTTPS, il est marqué comme "sécurisé" par le navigateur dans le sens où les échanges sont cryptés. Cela ne signifie pas que le site est dénué de vulnérabilités, que ton compte sur ce site ne sera jamais piraté, etc.
« Au départ je pensais que cette plate-forme ( Unblog.fr ) n'était pas sécurisée , ou l'était moins que les autres qui sont en https . Mais j'ai bien dû me rendre compte au fil du temps qu"il n'en était rien car mon site perso créé sur Unblog.fr n'a jamais été attaqué et que je n'ai jamais vu sur le forum Unblog.fr de plainte au sujet d'un site piraté ! »
Personnellement, je suis étonné de voir http://unblog.fr/wp-login.php sans HTTPS...
Si cette plateforme utilise uniquement du HTTP (et c'est le cas), alors navré de te l'apprendre, mais elle est bel et bien moins sécurisée que les autres sites en HTTPS.
Lorsque tu saisis tes identifiants pour te connecter à ton compte, tous les intervenants situés entre toi et le serveur pourraient récupérer le mot de passe. Ces intervenants sont généralement des sociétés sérieuses (ton FAI et les autres) et donc ne pratiquent pas cela. En tout cas, probablement pas pour le le blog d'un client lambda... et pour le reste (des choses plus sérieuses), peut-être le font-ils discrètement, aller savoir.
Il est aussi possible qu'une personne connectée à ton réseau écoute ces échanges, qu'il s'agisse d'un réseau WiFi ouvert ou d'un réseau privé câblé. Même si ces personnes n'ont que de bonnes intentions, es-tu sûr qu'aucun de ces ordinateurs ne soit infecté pas un virus qui pourrait se contenter d'être passif et ramasser un maximum d'informations ?
Pour les sites qui utilisent HTTPS uniquement sur la partie "formulaire de connexion" en pensant que le reste n'est pas important, ils se mettent le doigt dans l'œil : ces autres pages anodines qu'on pense sans grand intérêt pour les hackers, contiennent quand même des informations sensibles ou permettent de faire des actions avec des conséquences (des actions que la hacker pourrait exécuter).
Il y a aussi les attaques "actives", où le "man in the middle" passer au niveau supérieur, il peut modifier les échanges et cela ouvre un autre éventail de possibilités.
Comme exemple, prenons un logiciel qui interroge un serveur en HTTP pour savoir s'il y a une nouvelle mise à jour. Le hacker peut intervenir pour que la réponse soit "oui". Le logiciel demande alors au serveur, toujours en HTTP, l'adresse du nouveau .exe. Le hacker modifie encore la réponse et pousser le téléchargement de son propre .exe. Ce .exe est exécuté par l'application pour l'installation automatique.
Désolé si cela était déjà clair pour toi, mais j'ai eu l'impression que ça n'était pas le cas :)
En lisant ce message, j'ai l'impression que tu ne saisis pas le but de HTTPS et des connexions sécurisées, en général. Le but de ces connexions "SSL/TLS" est de mettre en place un cryptage de bout en bout, et faisant intervenir des certificats et des clés de cryptage privées, pour éviter qu'un intervenant "au milieu" n'écoute ou modifie les échanges entre le client/navigateur et le serveur.
« Cette connexion n'est pas sécurisée. Les identifiants saisis ici pourraient être compromis. En savoir plus »
Les navigateurs récents affichent les sites en HTTP comme "non sécurisé" dans le sens où les communications transitent en clair. Cela ne concerne pas la "sécurité" du site en lui-même, mais ces échanges en clair peuvent contenir des données sensibles (dont les mots de passe mais pas seulement) et être modifiés.
Lorsqu'un site est accessible en HTTPS, il est marqué comme "sécurisé" par le navigateur dans le sens où les échanges sont cryptés. Cela ne signifie pas que le site est dénué de vulnérabilités, que ton compte sur ce site ne sera jamais piraté, etc.
« Au départ je pensais que cette plate-forme ( Unblog.fr ) n'était pas sécurisée , ou l'était moins que les autres qui sont en https . Mais j'ai bien dû me rendre compte au fil du temps qu"il n'en était rien car mon site perso créé sur Unblog.fr n'a jamais été attaqué et que je n'ai jamais vu sur le forum Unblog.fr de plainte au sujet d'un site piraté ! »
Personnellement, je suis étonné de voir http://unblog.fr/wp-login.php sans HTTPS...
Si cette plateforme utilise uniquement du HTTP (et c'est le cas), alors navré de te l'apprendre, mais elle est bel et bien moins sécurisée que les autres sites en HTTPS.
Lorsque tu saisis tes identifiants pour te connecter à ton compte, tous les intervenants situés entre toi et le serveur pourraient récupérer le mot de passe. Ces intervenants sont généralement des sociétés sérieuses (ton FAI et les autres) et donc ne pratiquent pas cela. En tout cas, probablement pas pour le le blog d'un client lambda... et pour le reste (des choses plus sérieuses), peut-être le font-ils discrètement, aller savoir.
Il est aussi possible qu'une personne connectée à ton réseau écoute ces échanges, qu'il s'agisse d'un réseau WiFi ouvert ou d'un réseau privé câblé. Même si ces personnes n'ont que de bonnes intentions, es-tu sûr qu'aucun de ces ordinateurs ne soit infecté pas un virus qui pourrait se contenter d'être passif et ramasser un maximum d'informations ?
Pour les sites qui utilisent HTTPS uniquement sur la partie "formulaire de connexion" en pensant que le reste n'est pas important, ils se mettent le doigt dans l'œil : ces autres pages anodines qu'on pense sans grand intérêt pour les hackers, contiennent quand même des informations sensibles ou permettent de faire des actions avec des conséquences (des actions que la hacker pourrait exécuter).
Il y a aussi les attaques "actives", où le "man in the middle" passer au niveau supérieur, il peut modifier les échanges et cela ouvre un autre éventail de possibilités.
Comme exemple, prenons un logiciel qui interroge un serveur en HTTP pour savoir s'il y a une nouvelle mise à jour. Le hacker peut intervenir pour que la réponse soit "oui". Le logiciel demande alors au serveur, toujours en HTTP, l'adresse du nouveau .exe. Le hacker modifie encore la réponse et pousser le téléchargement de son propre .exe. Ce .exe est exécuté par l'application pour l'installation automatique.
Désolé si cela était déjà clair pour toi, mais j'ai eu l'impression que ça n'était pas le cas :)
WalterP
Messages postés
212
Date d'inscription
lundi 24 mars 2014
Statut
Membre
Dernière intervention
25 septembre 2024
5
Modifié le 3 juil. 2019 à 07:55
Modifié le 3 juil. 2019 à 07:55
Merci avion-f16 pour cette explication ! Non , ce n'était absolument pas clair du tout pour moi auparavant , et d'ailleurs je crois bien que je vais devoir relire une fois ou deux ton explication ! :)
Il s'agit donc plus du cryptage que de la vulnérabilité du site ! Enfin , disons les 2 si j'ai bien compris . En http les portes d'entrée sont donc ouvertes à beaucoup de monde ...
Lorsque je vais sur mon site Unblog je vois en Url : 1collection.unblog.fr/ et non pas http://1collection.unblog.fr/ . Le http était donc caché et je me demandais bien pourquoi ?
Mais bon , ce site Unblog n'est pas mon site principal , il n'y a aucune donnée sensible , je l'ai pris en exemple car c'est le seul qui m'indique :
« Cette connexion n'est pas sécurisée. Les identifiants saisis ici pourraient être compromis. En savoir plus »
J'utilise Unblog car ce site est rapide , fonctionne très bien et il a une présentation qui me convient bien . Sinon mon site principal est sur wordpress qui est en https , et donc certainement sécurisé je suppose ... :)
En tous cas j'apprécie l'explication que tu as donné ci-dessus et je vais la relire ...
Merci avion-f16 et à plus ...
Il s'agit donc plus du cryptage que de la vulnérabilité du site ! Enfin , disons les 2 si j'ai bien compris . En http les portes d'entrée sont donc ouvertes à beaucoup de monde ...
Lorsque je vais sur mon site Unblog je vois en Url : 1collection.unblog.fr/ et non pas http://1collection.unblog.fr/ . Le http était donc caché et je me demandais bien pourquoi ?
Mais bon , ce site Unblog n'est pas mon site principal , il n'y a aucune donnée sensible , je l'ai pris en exemple car c'est le seul qui m'indique :
« Cette connexion n'est pas sécurisée. Les identifiants saisis ici pourraient être compromis. En savoir plus »
J'utilise Unblog car ce site est rapide , fonctionne très bien et il a une présentation qui me convient bien . Sinon mon site principal est sur wordpress qui est en https , et donc certainement sécurisé je suppose ... :)
En tous cas j'apprécie l'explication que tu as donné ci-dessus et je vais la relire ...
Merci avion-f16 et à plus ...
Exileur
Messages postés
1475
Date d'inscription
mercredi 31 août 2011
Statut
Membre
Dernière intervention
16 décembre 2022
150
1 juil. 2019 à 23:17
1 juil. 2019 à 23:17
Salut,
Pour ce qui est de la reecriture du code, tu peux sed :
Ou tu peux mettre en place des redirections temporaire/permanente dans la configuration de ton apache / nginx / etc...
A plus
Pour ce qui est de la reecriture du code, tu peux sed :
sed -i -e 's_http_https_g' /usr/local/share/nginx/index.php
Ou tu peux mettre en place des redirections temporaire/permanente dans la configuration de ton apache / nginx / etc...
A plus
Exileur
Messages postés
1475
Date d'inscription
mercredi 31 août 2011
Statut
Membre
Dernière intervention
16 décembre 2022
150
1 juil. 2019 à 23:18
1 juil. 2019 à 23:18
Et sinon sans commentaires concernant l'envoi de mot de passe sans chiffrement .
avion-f16
Messages postés
19249
Date d'inscription
dimanche 17 février 2008
Statut
Contributeur
Dernière intervention
15 juin 2024
4 505
2 juil. 2019 à 20:53
2 juil. 2019 à 20:53
Les redirections http -> https sont une fausse bonne idée, elle est nécessaire mais pas suffisante : la première requête sera en HTTP et peut donc être modifiée ;)
Exileur
Messages postés
1475
Date d'inscription
mercredi 31 août 2011
Statut
Membre
Dernière intervention
16 décembre 2022
150
3 juil. 2019 à 10:20
3 juil. 2019 à 10:20
C'est exacte. Le mieux serait d'appliquer les deux solutions :)
En plus de bien former ses utilisateurs sur les questions de sécurité! ( un petit addon sympas -> https://addons.mozilla.org/fr/firefox/addon/https-everywhere/ )
En plus de bien former ses utilisateurs sur les questions de sécurité! ( un petit addon sympas -> https://addons.mozilla.org/fr/firefox/addon/https-everywhere/ )
3 juil. 2019 à 19:29
merci pour ta réponse détaillée mais j'avais bien compris la finalité de la sécuristation SSL et de la possibilité d'interception entre le client et le serveur et toutes les actions possibles par les "men of the middle". Je voulais simplement dire qu'acheter une sertificat 150 €/an pour un site professionnel, ça se justifie mais pour un petit site perso sans aucune donnée sensible c'est quand même un peu fort de café. Et les visiteurs devant de tels messages (tout le monde n'a pas ta connaissance sur le sujet, et j'en connais qui sont très basiques) éprouvent une impression de suspicion sur le site pourtant sans secret ni danger, suspicion qu'on ne peut écarter qu'avec une bonne centaine d'euros. Les hébergeurs devraient alors fournir, avec l'hébergement, un certificat SSL quand il s'agit d'un site non professionnel. Mais bien sût ils profitent de la vague et vendent, la plupart du temps plus cher que l'hébergement lui-même (je parle pour les petits sites).
Merci infiniment pour cette aide à la configuration. Je vais détailler ça et m'y atteler. Ayant eu les explications et les docs nécessaires, je marque le sujet Résolu. En cas de besoin, je reviendrai faire un tour... ;-)
En tout cas, merci.
Modifié le 3 juil. 2019 à 19:57
Je trouve que la généralisation de HTTPS est un gros plus pour la sécurité et la confidentialité, même pour les sites qui semblent "sans information confidentielles". Le simple fait d'utiliser HTTPS empêche les FAI/gouvernement de savoir ce qu'on fait en ligne. Même s'ils peuvent encore voir à quelle IP on se connecte, ils ne peuvent plus savoir quel site on visite (si le serveur héberge plusieurs sites, car le site à afficher est déterminé sur base de l'entête HTTP "Host" qui est alors chiffrée), ni les pages qu'on consulte.
Concernant le prix des certificats, heureusement qu'il y a Let's Encrypt, et la plupart des hébergeurs l'intègrent et, de mon point de vue, je n'ai pas l'impression qu'ils poussent à l'achat d'autres certificats. Le problème, c'est que à ma connaissance, il n'y a que Let's Encrypt qui délivre des certificats gratuits. Donc le forcing vers le HTTPS nous oblige à être dépendant d'une seule entité (Let's Encrypt), ou de nous pousser à débourser auprès des autres autorités de certifications payantes. Espérons donc qu'on ait pas un retour de bâton de la part de Let's Encrypt dans quelques temps. (Il y a aussi cPanel qui délivre des certificats "gratuits", mais c'est pas du gratuit car il faut payer une licence)
4 juil. 2019 à 16:13
1) il faut penser à le renouveler périodiquement tous les trois mois sinon le site deviendrait inaccessible. A moins de faire ça par un cron mais il faut prendre le temps de détailler tout ça.
2) j'aurai un peur peur aussi de "foutre la zone" dans la configuration de l'interface graphique de gestion (Plesk) dont les fichiers de configuration sont assez con-Plesk :-) même si son utilisation graphique est simple.
Mais tu as d'autres autorités de certifications que Let's Encrypt qui délivrent des certificats SSL gratuits. Tu as CAcert.org qui délivre des certificats pour une durée variable entre 6 mois et 2 ans selon le nombre de points acquis par un système d'accréditation un peu similaire à la toile de confiance de GPG/PGP. Tu peux te faire accréditer et/ou devenir accréditeur. Cela joue sur la durée de validité du certificat. Va voir et inscris toi et tu liras leur dispositif ; ça fait longtemps que ça existe.
Le sujet étant clos, je ne sais si tu seras averti de ce message. Confirme le moi et, si je n'ai pas de réponse, je t'enverrai ça en MP.
10 juil. 2019 à 10:40
En fait s'occupe de renouveler ledit certificat automatiquement pour toi. C'est juste un démon qui tourne sur la machine en question. Si tu suis les étapes que je t'ai indiqué il n'y a rien de plus à faire, ensuite tu as ton certificat gratuitement et indéfiniment. Donc plus besoin de se prendre la tête ;-)
Et ça c'est un énorme plus. Une solution classique (même gratuite) pose un problème de taille : tu dois penser à renouveler toi même le certificat. Si tu oublies ton site affiche côté client une erreur de sécurité ce qui est généralement assez dissuasif pour la plupart des utilisateurs.
Enfin, agit purement au niveau apache/nginx. A priori les règles configurées sont telles qu'elle n'impacte pas le fonctionnement du site (les règles ajoutées sont typiquement du genre, http://monsite.com devient https://monsite.com). Le vhost sous jacent n'est a priori pas impacté par de telle règle, même si bon nombre de framework sont basés sur des redirections au niveau du serveur web, car ce n'est pas le préfixe de l'URL qui est pris en compte. Donc plesk ou autre n'ont aucune raison d'être impacté, et encore une fois, c'est certbot qui s'occupe d'adapter la configuration apache, pas toi :-)