Sinon j’ai découvert NameCheap il n’y a pas longtemps, chez qui je prend mes certificats SSL maintenant. Le wildcard est à 94$ mais surtout le premier prix c’est 9$ pour un domaine simple.
après le choix ce fait suivant ce que fais ton application, multiple tenant ou pas ? I18n grace aux sous domaines ? https://www.namecheap.com/security/ssl-certificates/comodo/positivessl-wildcard.aspx -- Benjamin Guimberteau e-mail : b.guimbert...@gmail.com skype : b.guimberteau Le 21 juin 2014 à 13:52:52, Thibaut Barrère (thibaut.barr...@gmail.com) a écrit: mais attention ce n'est probablement pas exactement le même type de certificat etc aussi, vérifiez avant! Envoyé de mon iPhone Le 21 juin 2014 à 13:46, Thibaut Barrère <thibaut.barr...@gmail.com> a écrit : 100$ ici: https://dnsimple.com/plans Envoyé de mon iPhone Le 21 juin 2014 à 13:40, Olivier El Mekki <oelme...@gmail.com> a écrit : Wow, ça vaut le coup. Les wildcards comodo commencent à $330 [1]. Dommage qu'il faille héberger le nom de domaine chez eux pour avoir cette offre. [1] http://ssl.comodo.com/wildcard-ssl-certificates.php On Saturday, June 21, 2014 1:27:37 PM UTC+2, Thibaut Barrère wrote: Moi je fais full ssl. J'ai pris du wild card comodo via dnsimple, ça doit être ~100$ de tête. Envoyé de mon iPhone Le 21 juin 2014 à 12:40, Olivier El Mekki <oelm...@gmail.com> a écrit : Hello, J'ai pour l'instant une seule page en https (la page de paiement qui utilise stripe), mais je me pose la même question. Voici les avantages et inconvénients que j'ai trouvé dans les deux cas. Utiliser du tout ssl -------------------- C'est probablement plus cohérent et si tu as un certificat, c'est dommage de ne pas l'utiliser. Il y a un certain coût en performance pour l'utilisation de ssl, mais il est relativement négligeable (avec une configuration ssl correct, par exemple en n'oubliant d'inclure les certificats parents dans ton certificat pour minimiser le nombre de requêtes). Le principal problème que je vois est le coût. Si tu veux faire du tout ssl, il va te falloir un certificat wildcard, parce qu'un jour où l'autre, tu vas utiliser un cdn (si ce n'est pas le cas dès le début). Ça rajoute directement plusieurs centaines d'euros au coût de ton certificat. Si tu as une api, la latence peut également être non négligeable (si un service repose sur un service, le second doit avoir des performances exemplaires). À voir au cas par cas les besoins de performance des apis. Utiliser une seule page en ssl ------------------------------ Dans le cas d'une page de paiement, tu peux réussir à te débrouiller avec un certificat single domain. Ces pages sont généralement épurées. Si tu venais à utiliser un cdn, tu pourrais donc inclure ton css directement dans la page. Cela pose néanmoins des problèmes au développement. Déjà, il faut que tu fasses tourner deux process, en dev (un normal et un ssl), en utilisant god, un procfile ou whatever. J'utilise personnellement god, ça me permet de démarrer le tout en une commande quand j'ai besoin des pages ssl, mais je ne peux plus par exemple mettre des `binding.pry`. C'est surement contournable si je prennais le temps d'y réfléchir, mais c'est juste suffisamment ennuyeux pour être remarquable. Ensuite, il y a le problème des tests d'intégration. Je n'ai pas trouvé pour l'instant de moyen propre de faire switcher capybara/poltergeist entre ssl et non ssl. Du coup, j'ai dû mettre ... des conditions qui testent si on est en environment test au moment de générer les liens qui changent le protocol (et ne pas le changer en env de test), ce qui est absolument horrible (si quelqu'un a une autre idée, je suis prenneur). En conclusion, je dirais : fais du tout ssl si ta boite est riche :) (et prend en compte le cas de la latence des apis) On Saturday, June 21, 2014 7:31:38 AM UTC+2, Guirec Corbel wrote: Salut, J'ai un site avec une partie sécurisé et je me demandais si ça vallait la peine de faire certaines parties non sécurisé et s'il y a des intérets à ça. Le boulot que ça rajoute serait de définir quels sont les pages sécurisées ou non. D'après ce que je vois, les navigateurs mettent en cache les parties sécurisées aussi. Quel est votre opinion? Merci! -- -- Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse rails...@googlegroups.com Pour résilier votre abonnement envoyez un e-mail à l'adresse railsfrance...@googlegroups.com --- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "Railsfrance". Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse railsfrance...@googlegroups.com. Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout. -- -- Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse railsfrance@googlegroups.com Pour résilier votre abonnement envoyez un e-mail à l'adresse railsfrance-unsubscr...@googlegroups.com --- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "Railsfrance". Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse railsfrance+unsubscr...@googlegroups.com. Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout. -- -- Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse railsfrance@googlegroups.com Pour résilier votre abonnement envoyez un e-mail à l'adresse railsfrance-unsubscr...@googlegroups.com --- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "Railsfrance". Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse railsfrance+unsubscr...@googlegroups.com. Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout. -- -- Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse railsfrance@googlegroups.com Pour résilier votre abonnement envoyez un e-mail à l'adresse railsfrance-unsubscr...@googlegroups.com --- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Railsfrance. Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse railsfrance+unsubscr...@googlegroups.com. Pour plus d'options, visitez le site https://groups.google.com/d/optout .
