Skip to content

Certificat valide pour HTTPS  #2

Open
Open
Certificat valide pour HTTPS #2
Assignees
edouarda

Description

@olibre
olibre
opened on Jun 1, 2017

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 ?

Activity

  1. olibre
    assigned
    edouarda
    on Jun 1, 2017

  2. aurelienrb commented on Jun 2, 2017

    @aurelienrb
    aurelienrb
    on Jun 2, 2017
    Contributor

    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 !

  4. aurelienrb commented on Jun 2, 2017

    @aurelienrb
    aurelienrb
    on Jun 2, 2017
    Contributor

    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.

  5. olibre commented on Jun 3, 2017

    @olibre
    olibre
    on Jun 3, 2017
    MemberAuthor

    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 ;-)

  6. mropert commented on Jun 3, 2017

    @mropert
    mropert
    on Jun 3, 2017

    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.

  8. aurelienrb commented on Jun 3, 2017

    @aurelienrb
    aurelienrb
    on Jun 3, 2017
    Contributor

    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) :

    • Le plus simple est de laisser OVH s'occuper de tout via un hébergement perso. Avantages : zéro administration, on pose les fichiers via FTP et voilà.
    • Louer un serveur virtuel dédié offre toute la souplesse d'une machine sur laquelle on fait ce que l'on veut. Mais du coup il faut administrer + mettre à jour soit même de A à Z. Pour moi c'est très risqué sur le long et même moyen terme.

    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.

  9. aurelienrb commented on Jun 3, 2017

    @aurelienrb
    aurelienrb
    on Jun 3, 2017
    Contributor

    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.

  10. edouarda commented on Jun 3, 2017

    @edouarda
    edouarda
    on Jun 3, 2017
    Collaborator

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

  11. olibre commented on Jun 4, 2017

    @olibre
    olibre
    on Jun 4, 2017
    MemberAuthor

    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:

    • GitHub ne supporte pas les certificats SSL pour les custom domains car cela leur coûterait trop cher [1]
    • Cloudflare (mentionné par @edouarda) est gratuit[2] pour notre usage et voici le tutoriel: https://blog.cloudflare.com/secure-and-fast-github-pages-with-cloudflare/ (apparemment il faut remplacer[3] le CNAME cpp-frug.github.io par github.map.fastly.net et activer la redirection[4] HTTP vers HTTPS)
    • Autre solution technique: fly.io
    • Encore une autre solution : Google Firebase
    • Si on prend en compte la vie privée de nos internautes, il est préférable d'héberger nous même comme le propose @aurelienrb
    • Un court article intéressant sur le retour d’expérience: From Github Pages to Firebase, then to a VPS (Peter a aussi testé Cloudfare, et utilise actuellement Hugo+Caddy)
    • HTTP/2 (voir Wikipédia)
      • Déjà pris en charge pas nos navigateurs
      • Déjà pris en charge par cppfrug.org (14% of the top 10 million websites support HTTP/2)
      • Par contre, Chrome (et d'autres navigateurs) profitent du HTTP/2 seulement en https:// [5]
    • Chrome et Firefox devraient dans une future version:
      • tenter de basculer automatiquement sur le site en https://
      • si https:// non disponible => Afficher une alerte[6]
      • si disponible mais certificat incorrect => Afficher une alerte accrue

  12. aurelienrb commented on Jun 9, 2017

    @aurelienrb
    aurelienrb
    on Jun 9, 2017
    Contributor

    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.

  13. edouarda commented on Jun 9, 2017

    @edouarda
    edouarda
    on Jun 9, 2017
    Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions