search

cpp-frug / cpp-frug.github.io

Pages du site web
http://cpp-frug.github.io/
3 stars 1 forks source link

Certificat valide pour HTTPS #2

Open olibre opened 7 years ago

olibre commented 7 years ago

Salut @edouarda

L'URL https://cpp-frug.github.io/ (HTTPS) bascule sur http://cppfrug.org/ (HTTP) Et quand on tente un https://cppfrug.org/ (HTTPS) nous avons un message d'erreur de certificat :

cppfrug.org uses an invalid security certificate. The certificate is only valid for the following names: .github.com, github.com, .github.io, github.io Error code: SSL_ERROR_BAD_CERT_DOMAIN

Je n'ai aucune idée comment résoudre ce soucis. Est-ce que @devnewton aurait une idée ?

aurelienrb commented 7 years ago

C'est normal car c'est GitHub qui signe un certificat pour son domaine et pas le notre. Pour avoir du HTTPS sur notre domaine, il faut en assurer l'hébergement nous-mêmes avec notre propre certificat. C'est assez pénible à faire (même avec Let's Encrypt) et pas possible je pense sur l'hébergement gratuite 10M de OVH. Donc en bref : pas de HTTPS sur cppfrug.org !

ghost commented 7 years ago

Pourquoi ne pas prendre un VPS à pas cher pour être maître chez vous?

aurelienrb commented 7 years ago

Disons que ça coûte 40€ de plus par an (à qui?) et demande une administration régulière (par qui?). L'avantage du Github c'est que n'importe quel membre de la team peut mettre jour le site web via un simple git push. Et pour héberger des pages web statiques, perso je pense pas que HTTPS soit utile.

olibre commented 7 years ago

Hier, je voulais intégrer l'image http://cppfrug.org/images/Cpp-Francophonie.svg sur l'annonce du Meetup C++ https://www.meetup.com/User-Group-Cpp-Francophone/events/240136200/.

Le site Meetup.com n'a pas voulu du HTTP et a exigé le HTTPS => Utilisation de l'URL https://cppfrug.org/images/Cpp-Francophonie.svg

Et les internautes qui se connectaient sur la page de l'annonce du Meetup C++ avait une mauvaise surprise:

Les propriétaires de cppfrug.org ont mal configuré leur site web. Pour éviter que vos données ne soient dérobées, Firefox ne s’est pas connecté à ce site web.

De plus, le HTTP est de plus en plus déconseillé.

Par exemple, les dépôts Git crées récemment sur GitHub ne peuvent plus utiliser le HTTP:

GitHub Pages sites created after June 15, 2016 and using github.io domains are served over HTTPS.

Pour les vieux dépôts Git, dans les settings, on peut cocher la case:

[_] Enforce HTTPS
HTTPS provides a layer of encryption that prevents others from snooping on or tampering with traffic to your site. When HTTPS is enforced, your site will only be served over HTTPS.

Encore un argument en faveur du HTTPS: Passer au HTTPS pour améliorer son PageRank.

J'aime bien mettre mon grain de sel, mais j'apprécie la simplicité de l'hébergement sur GitHub. Je ne m'y connais pas suffisamment en Web, CNAME, HTTPS... pour gérer cette problématique. Donc si personne n'est motivée à faire fonctionner le HTTPS, cela me convient ;-)

mropert commented 7 years ago

Est-ce que vous savez de quel genre de charge on parle (nb d'utilisateurs/vues par jour, type de rendu/calcul effectué par le serveur)? Parce que si c'est pour héberger uniquement du statique, on ne devrait pas avoir besoin de grand chose.

ghost commented 7 years ago

Et avec un CNAME vers les pages github?

aurelienrb commented 7 years ago

Le principe de HTTPS c'est que l'authenticité du nom de domaine est validée par le certificat. Il faut prouver (via une procédure automatisée) que l'on est propriétaire du nom de domaine pour obtenir le certificat associé. Or GitHub n'est pas propriétaire de cppfrug.org. Donc GitHub ne peut pas servir du HTTPS au nom de cppfrug.org (c'est le principe même d'HTTPS). Si on force l'opération (via un CNAME) les navigateurs vont détecter une usurpation (cppfrug.org qui utilise un certificat au nom de *.github.io) et afficheront une belle alerte de sécurité.

HTTPS est pertinent dès lors qu'il y a un secret qui transite, tel une authentification par mot de passe. Donc ça a du sens pour Github ou Meetup. Mais pour des pages statiques publiques, surtout pour un petit site comme nous, ça me parait beaucoup plus discutable.

Mais bon, si on veut absolument passer en HTTPS, il faut prendre un hébergement chez OVH qui permet cela (en + du nom de domaine). Y'a 2 offres au même tarif (3.59€ par mois) :

Perso je préfère la première option qui est bien plus pérenne et rapide à mettre en place. L'upload via FTP peut être automatisée via une intégration continue avec Travis (gratuit mais pas hyper réactif) ou sinon via un miroir Gitlab.com avec un runner perso que je peux fournir.

aurelienrb commented 7 years ago

Le principe de n'intégration continue c'est que quand un commit / merge est effectué sur le repo associé au site web, un runner est lancé qui s'occupe de générer les pages HTML statiques (avec HUGO par exemple) puis d'uploader le résultat sur le serveur cppfrug.org via FTP ou SSH.

Ainsi il y a synchronisation automatique en quelques minutes sur simple git pushde n'importe quel membre du FRUG.

edouarda commented 7 years ago

C'est possible de faire du HTTPS en passant par GitHub, par exemple avec cloudflare.

olibre commented 7 years ago

Le sujet "GitHub Pages SSL Custom Domaine" concerne de nombreux autres utilisateur comme en atteste ce ticket et ses 419 commentaires:

Voici quelques infos sur des sujets plus ou moins éloignés:

aurelienrb commented 7 years ago

Hello, Je pense que pour commencer CloudFlare est une très bonne option (je savais pas qu'ils faisaient cela gratuitement!). Le retour d'expérience sur Github+Cloudflare -> VPS est intéressant (à noter que le HTTPS n'a pas été la raison de sa migration). Cela dit je continue à penser que pour nous un hébergement mutualisé avec OVH qui s'occupe du HTTPS et de la sécurisation du serveur est la meilleure option, même si contraignante à cause du FTP.

edouarda commented 7 years ago

+1 pour CloudFlare également. Cela sera sécurisé et demandera moins de travail.