Certificat SSL

muqaddarmuqaddar Administrateur
septembre 2014 modifié dans Langages Web & serveurs #1

Salut,


 


Je voudrais passer un site en sécurisé avec https://.


 


J'ai du mal à  y voir clair dans la jungle des certificats SSL qu'on peut acheter ici ou là . Je ne savais pas que tant de sociétés en vendaient !


Et du mal à  comprendre comment l'installer chez mon hébergeur.


 


Bref, mon domaine est géré par OVH (on peut acheter des certificats chez eux à  60 euros / an par exemple). Mon hébergeur est ricain.


 


Apparemment, il faudrait acheter un certificat, le déposer sur mon serveur, et demander son activation à  mon hébergeur ?


 


Ai-je bien compris ? Y-a-til des alternatives gratuites ?


 


J'ajoute que  mon site est déjà  en https à  l'heure où je vous parle, mais il utilise le certificat (par défaut) de mon hébergeur, et donc les navigateurs envoient des messages comme quoi le certificat n'est pas vérifié. D'où ma question pour avoir et gérer mon propre certificat vérifié.


 


Qui peut me débroussailler tout ça ?

«1

Réponses

  • AliGatorAliGator Membre, Modérateur
    septembre 2014 modifié #2

    Va voir sur https://www.startssl.com/?lang=fr / https://www.startssl.com/?app=1


     


    C'est là  que je suis allé pour leur demander de me générer un certificat, valide, signé, que j'ai pu utiliser pour mon serveur de livraisons OTA (qui doit maintenant absolument être en HTTPS avec un certificat non pas autosigné mais bien validé par une autorité de certification).


     


    C'est plutôt bien expliqué (y'a des tutos pas à  pas, ce pour chaque serveur (selon si tu es sur du Apache, du Nginx, autre, ...) et système et tout), et en plus, c'est gratuit pour un certificat de classe 1 (ce qui suffit amplement pour un site web à  passer en HTTPS tout en étant bien signé par une autorité de certification et donc reconnu comme valide)


  • zoczoc Membre
    septembre 2014 modifié #3

    Moi mes domaines sont chez Gandi et ils offrent un certificat SSL par domaine chez eux pour la première année. Après le renouvellement du certificat c'est 12 euros par an. 


     


    A voir si c'est pas rentable de transférer ton/tes domaine(s) d'OVH vers Gandi...


  • muqaddarmuqaddar Administrateur
    septembre 2014 modifié #4


    Moi mes domaines sont chez Gandi et ils offrent un certificat SSL par domaine chez eux pour la première année. Après le renouvellement du certificat c'est 12 euros par an. 


     


    A voir si c'est pas rentable de transférer ton/tes domaine(s) d'OVH vers Gandi...




     


    Oui, j'avais vu l'offre de Gandi avant de poster, c'est pas mal, même si j'aime bien avoir tous mes domaines gérés par OVH (moins cher de 40%).


     


    J'en profite pour poser une question (stupide ?). Même si c'est le registrar qui fournit le certificat, il n'y a rien à  faire chez le registrar (en plus des DNS) ? Tout se passe chez l'hébergeur ?


  • muqaddarmuqaddar Administrateur


    Va voir sur https://www.startssl.com/?lang=fr / https://www.startssl.com/?app=1


     


    C'est là  que je suis allé pour leur demander de me générer un certificat, valide, signé, que j'ai pu utiliser pour mon serveur de livraisons OTA (qui doit maintenant absolument être en HTTPS avec un certificat non pas autosigné mais bien validé par une autorité de certification).


     


    C'est plutôt bien expliqué (y'a des tutos pas à  pas, ce pour chaque serveur (selon si tu es sur du Apache, du Nginx, autre, ...) et système et tout), et en plus, c'est gratuit pour un certificat de classe 1 (ce qui suffit amplement pour un site web à  passer en HTTPS tout en étant bien signé par une autorité de certification et donc reconnu comme valide)




     


    Je vais regarder ça de suite.


    Merci.



  • Oui, j'avais vu l'offre de Gandi avant de poster, c'est pas mal, même si j'aime bien avoir tous mes domaines gérés par OVH (moins cher de 40%).


     


    J'en profite pour poser une question (stupide ?). Même si c'est le registrar qui fournit le certificat, il n'y a rien à  faire chez le registrar (en plus des DNS) ? Tout se passe chez l'hébergeur ?




     


    Non, il n'y a rien à  faire. En fait la seule chose à  laquelle il faut faire attention, c'est de bien acheter un certificat avec le nom DNS exact du serveur HTTPS (ou un certificat "wildcard" pour ton domaine de base, mais c'est plus cher), parce qu'à  la moindre erreur, le navigateur affichera un warning...

  • muqaddarmuqaddar Administrateur
    septembre 2014 modifié #7


    Non, il n'y a rien à  faire. En fait la seule chose à  laquelle il faut faire attention, c'est de bien acheter un certificat avec le nom DNS exact du serveur HTTPS (ou un certificat "wildcard" pour ton domaine de base, mais c'est plus cher), parce qu'à  la moindre erreur, le navigateur affichera un warning...




     


    Bon, donc je suis passé par Gandi (gratuit la première année), puis 12 euros, comme tu disais.


    C'est assez simple et ça a l'air de marcher.


     


    Je n'ai pas pris de wilcard, mais j'ai donné le nom du domaine sans "www" (exemple.com), ce qui permet de le faire marcher avec "www" aussi.


     


    Si je teste dans un navigateur, je suis mitigé:


     


    - Chrome m'affiche mon https en vert (et non en barré comme hier)


     


  • Il faut sans doute ajouter un certificat racine à  Firefox. Le problème vient vraisemblablement du fait que le signataire de ton certificat est inconnu de Firefox.


  • AliGatorAliGator Membre, Modérateur
    Est-ce que l'erreur que tu as dans Firefox est exactement la même erreur qu'avec l'ancien certificat ?
    Je pense à  un système de cache des certificats SSL des sites que Firefox pourrait éventuellement utiliser (même si ça ne serait pas très malin, car cela laisserait la porte ouverte aux attaques MITM, mais bon, c'est une hypothèse à  vérifier quand même). Du coup un flush de Firefox (je sais pas comment, je n'utilise pas ce navigateur, mais doit bien y avoir moyen) pourrait résoudre le problème. Ou tester sur un autre poste depuis lequel tu n'es jamais allé sur ton site avec Firefox.
  • muqaddarmuqaddar Administrateur


    Est-ce que l'erreur que tu as dans Firefox est exactement la même erreur qu'avec l'ancien certificat ?

    Je pense à  un système de cache des certificats SSL des sites que Firefox pourrait éventuellement utiliser (même si ça ne serait pas très malin, car cela laisserait la porte ouverte aux attaques MITM, mais bon, c'est une hypothèse à  vérifier quand même). Du coup un flush de Firefox (je sais pas comment, je n'utilise pas ce navigateur, mais doit bien y avoir moyen) pourrait résoudre le problème. Ou tester sur un autre poste depuis lequel tu n'es jamais allé sur ton site avec Firefox.




     


    Sauf que je n'ai pas afficher le site auparavant.


     


    Donc l'hypothèse de jpImbert et plausible.


    Bizarre que le certificat de Gandi ne soit pas reconnu.

  • muqaddarmuqaddar Administrateur

    Etrangement, Safari iOS 7 ne reconnaà®t pas le certificat, et Safari iOS 8 le reconnaà®t !


  • AliGatorAliGator Membre, Modérateur
    Ca voudrait donc dire que le certificat racine en question n'est pas dans les racines du système (Trousseau d'accès -> "Racines du système" sur Mac), accessibles du coup à  priori par tous les logiciels qui voudraient vérifier la validité d'un certificat signé... mais qu'il serait dans une liste interne de certificats racines du navigateur ?

    Il me semble en effet que pas mal de navigateurs intègrent eux-même des certificats racines dans leur bundle, même si ça fait du coup un peu doublon avec ceux intégrés au système pour la plupart...

    Peut-être aussi que Firefox ne se base QUE sur sa liste interne de certificats racines et ne la complète pas du tout avec la liste des certificats racines du système, et manque de pot celui utilisé par Gandi est bien dans les racines de ton système mais pas dans Firefox ?!

    C'est qui le Root CA de ton certificat, au fait ?
  • muqaddarmuqaddar Administrateur
    septembre 2014 modifié #13

    C'est qui le Root CA de ton certificat, au fait ?



     


    C'est à  dire ?


     


    Ce qui m'étonne, c'est que dans les détails du certificat sous Safari, il me dit:


     


    Autorité de certification: NON


     


    Mais bon, je vais demander à  Gandi, ça sera sûrement plus simple.


  • muqaddarmuqaddar Administrateur

    Je pense qu'il doit y avoir un autre problème car Gandi certifie leur validité sur 99% des navigateurs dont Firefox.


     


  • AliGatorAliGator Membre, Modérateur
    septembre 2014 modifié #15

    C'est à  dire ?

    Bah si tu regardes la chaà®ne de validation dudit certificat, ça remonte jusqu'à  quel certificat racine ?

    Par exemple le site developer.apple.com est signé par un certificat "deveoper.apple.com" qui lui-même est émis/signé par "VeriSign Class 3 Extended Validation SSL SGC CA" (autorité de certification) qui est enfin signé par "VeriSign Class 3 Public Primary Certification Authority - G5", qui lui est le certificat racine (d'ailleurs c'est indiqué par sa petite icône marron plutôt que bleue que c'est un "root certificate" celui-là ).
  • muqaddarmuqaddar Administrateur
    septembre 2014 modifié #16
  • Bizarre car ce certificat racine est dans Firefox (Menu Firefox -> Préférences -> Avancé -> Certificats)


    Tu peux tenter de l'exporter du trousseau pour le réimporter dans Firefox.


  • muqaddarmuqaddar Administrateur


    Bizarre car ce certificat racine est dans Firefox (Menu Firefox -> Préférences -> Avancé -> Certificats)


    Tu peux tenter de l'exporter du trousseau pour le réimporter dans Firefox.




     


    Oui, je vais essayer.


    Merci !


     


    (on m'a signalé que y'avait pas de problème sur PC sur IE)

  • FKDEVFKDEV Membre
    septembre 2014 modifié #19

    Tu fais une redirection de site.com vers www.site.com ?


    T'es certain que ton certificat peut gérer les deux ?


  • muqaddarmuqaddar Administrateur
    septembre 2014 modifié #20


    Tu fais une redirection de site.com vers www.site.com ?


    T'es certain que ton certificat peut gérer les deux ?




     


    Oui, les 2 marchent sur les navigateurs où ça ne pose pas problème.


    Il faut demander le certificat pour site.com si on veut que ça marche aussi pour www.site.com.


    Par contre, ça ne marche pas pour toto.site.com, il faut une wilcard pour ça.


     


    Bizarre le coup de iOS 7 (pas reconnu) et iOS 8 (reconnu)...


  • zoczoc Membre
    septembre 2014 modifié #21

    Il faut demander le certificat pour site.com si on veut que ça marche aussi pour www.site.com.

    Ca, franchement, je suis loin d'en être certain... Avec un certificat "non wildcard", il faut un certificat avec le nom "www.site.com", parce que "site.com" marchera que pour "https://site.com"...

    Edit: Non c'est bon, je viens de voir que quand tu achètes "site.com" il te met "www.site.com" en noms alternatifs.
  • muqaddarmuqaddar Administrateur


    Edit: Non c'est bon, je viens de voir que quand tu achètes "site.com" il te met "www.site.com" en noms alternatifs.




     


    Exactement.


     


    Mais ça n'est pas le problème de toute façon.


    Je vais contacter Gandi.

  • C'est qu'il te manque les certificats intermédiaire.


     


    Théoriquement les clients sont capable d'aller chercher par eux même les certificats intermédiaire mais ça ne marche pas toujours. De fait sur les serveur on est capable de fournir à  la fois le certificat final ainsi que la chaine d'intermédiaire permettant de remonter jusqu'à  une racine connue.


  • muqaddarmuqaddar Administrateur


    C'est qu'il te manque les certificats intermédiaire.


     


    Théoriquement les clients sont capable d'aller chercher par eux même les certificats intermédiaire mais ça ne marche pas toujours. De fait sur les serveur on est capable de fournir à  la fois le certificat final ainsi que la chaine d'intermédiaire permettant de remonter jusqu'à  une racine connue.




     


    Et tu sais comment on fait ça ?

  • AliGatorAliGator Membre, Modérateur
    Ah tiens yoann toi qui a l'air de connaà®tre le sujet, je me suis toujours demandé : comment sont récupérés les certificats intermédiaires ?

    Par exemple si je demande à  une CA de me signer un certificat A, puis que je génère un certificat B que je signe avec A et un certificat C que je signe avec B... Pour pouvoir ensuite signer des trucs (un email, un site, ...) avec C :
    - Il faut que mon serveur envoie les certificats A, B et C à  la fois dans le handshake SSL ? De façon séparées
    - Ou bien le client récupère C, regarde s'il connait son signataire B, sinon il le demande, puis regarde s'il connait son signataire A, sinon il le demande, etc ? Et il le demande alors à  qui, au même serveur auquel il veut se connecter ? (J'imagine, ça va pas être un espèce de "serveur de certificats" car ça voudrait dire une autre connexion, et comment serait contrôlée le fait qu'il n'y ait pas une MitM entre temps ?)
    - Ou bien le serveur fournit un certificat C qui encapsule déjà  A et B, et de manière générale un certificat contient tous ses certificats intermédiaires (ou au moins une partie) pour remonter la chaà®ne ?


  • Et tu sais comment on fait ça ?




     


     


    http://wiki.gandi.net/fr/ssl/intermediate


     


    + la doc de OVH sur le sujet.



  • Ah tiens yoann toi qui a l'air de connaà®tre le sujet, je me suis toujours demandé : comment sont récupérés les certificats intermédiaires ?


    Par exemple si je demande à  une CA de me signer un certificat A, puis que je génère un certificat B que je signe avec A et un certificat C que je signe avec B... Pour pouvoir ensuite signer des trucs (un email, un site, ...) avec C :

    - Il faut que mon serveur envoie les certificats A, B et C à  la fois dans le handshake SSL ? De façon séparées

    - Ou bien le client récupère C, regarde s'il connait son signataire B, sinon il le demande, puis regarde s'il connait son signataire A, sinon il le demande, etc ? Et il le demande alors à  qui, au même serveur auquel il veut se connecter ? (J'imagine, ça va pas être un espèce de "serveur de certificats" car ça voudrait dire une autre connexion, et comment serait contrôlée le fait qu'il n'y ait pas une MitM entre temps ?)

    - Ou bien le serveur fournit un certificat C qui encapsule déjà  A et B, et de manière générale un certificat contient tous ses certificats intermédiaires (ou au moins une partie) pour remonter la chaà®ne ?




     


    Tu as grosso modo deux options.


     


     


    La première, théoriquement belle mais qui ne marche jamais est que tu ne donne que ton certificat, qui dans ses informations contient l'url de récupération du CRT de son signataire, qui lui même contient l'URL du CRT de son signataire, etc.


     


    En gros, de référence en référence, le client est censé télécharger l'ensemble des CRT intermédiaire jusqu'à  arrivé à  un signé par une autorité racine inclus d'origine dans le terminal.


     


     


    La seconde, c'est que le serveur lors de l'établissement de la session SSL va envoyer en plus de son certificat l'ensemble de la chaine, de sorte que le client n'ai rien à  télécharger. Il va valider l'ensemble de la chaine passé par le certificat et reprendre son process de contrôle à  la fin de cette chaine qui abouti normalement sur une autorité racine.

  • Moi clairement j'ai créé un fichier qui contient l'ensemble de la chaine de certificats et foutu son chemin dans la config d'apache, avec la directive "SSLCertificateChainFile".



  • Moi clairement j'ai créé un fichier qui contient l'ensemble de la chaine de certificats et foutu son chemin dans la config d'apache, avec la directive "SSLCertificateChainFile".




     


    C'est exactement ça. Par contre où ça se trouve dans l'admin d'OVH, aucune idée ^^

  • AliGatorAliGator Membre, Modérateur

    Tu as grosso modo deux options.
     
     
    La première, théoriquement belle mais qui ne marche jamais est que tu ne donne que ton certificat, qui dans ses informations contient l'url de récupération du CRT de son signataire, qui lui même contient l'URL du CRT de son signataire, etc.
     
    En gros, de référence en référence, le client est censé télécharger l'ensemble des CRT intermédiaire jusqu'à  arrivé à  un signé par une autorité racine inclus d'origine dans le terminal.
     
     
    La seconde, c'est que le serveur lors de l'établissement de la session SSL va envoyer en plus de son certificat l'ensemble de la chaine, de sorte que le client n'ai rien à  télécharger. Il va valider l'ensemble de la chaine passé par le certificat et reprendre son process de contrôle à  la fin de cette chaine qui abouti normalement sur une autorité racine.

    OK Merci c'est très clair.

    Mais du coup, si on utilise pas un CertificateChainFile (genre PEM qui embarque tous les certificats) " qui est en effet la méthode que j'ai utilisée en y repensant aussi, j'avais oublié cet élément de ma config Apache " mais qu'on fait la méthode 1 et envoie juste un certificat + l'URL de son parent... comment est assuré la sécurité de téléchargement du certificat parent ? S'il y en a besoin d'une en fait, c'est pas dit hein, mais je me dis que s'il faut 3 connexions à  3 serveurs différents pour récupérer C puis B puis A ne faut-il pas que ces connexions soient chacunes sécurisées ?

    Bon en fait en posant la question je réalise que certainement que non, car après tout on ne fait qu'échanger des certificats (avec leur clé publique incluse dedans), ça n'a rien de privé, tous ces certificats sont disponibles pour tout le monde après tout. Et même s'il y avait un MitM qu'est ce qu'il pourrait faire ? Renvoyer un faut certificat en retour, ça ne servirait à  rien car ce certificat n'étant pas le bon ne pourrait pas valider le certificat fils qu'on veut vérifier, donc j'imagine qu'en fait il n'y a pas de risque de ce côté finalement ?
  • muqaddarmuqaddar Administrateur

    Je ne suis pas chez OVH.


     


    Pour mon premier certificat, j'avais demandé l'activation à  mon hébergeur (je dépose le certificat DER à  la racine de mon /home), et ils l'activent.


     


    Donc, là , je viens aussi de déposer le certificat intermédiaire (DER aussi) et j'ai aussi demandé l'activation (on verra si ça marche).


Connectez-vous ou Inscrivez-vous pour répondre.