Bonjour à tous,
Je me permets de poster sur la liste car nous rencontrons en ce moment beaucoup de problème avec notre ancien fournisseur de certificat SSL car chrome ne reconnait plus certaines autorités de certificattions.
A tritre d'exemple Trustico ne semble plus en mesure de fournir les certificats SSL de Digicert en raison de l'arret de reconnaissance par le navigateur Chrome
voici leur message
http://paste.privianet.com/1F0C3AB3D2/d6621d2c8a75837e0cd3289cc6ecf615
Il semble que la seule issue soit de commander des cerificats Comodo mais ils ne s'agit pas d'une CA d'un niveau suffisant (il faut installer 2 certificats intermédiaires pour le chainer à la racine)
De plus, nous sommes client Thawte également et Thawte continue à nous fournir des certificats en nous indiquant qu'il n'y a pas de problème ..... ?
Thawte a mis à jour ses PKI suite aux avertissement de Google...est-ce suffisant pour chrome?
Peut-être que le problème ne vient que des revendeurs de certifiat SSL ?
Si Digicert (qui comprend Symantec: Thawte, Geotrust, RapidLL) n'est plus reconnue, que reste-il comme autorité de certificattion ?
Peut-être que LetsEncrypt est la voie que tout le monde doit pendre ? Mais du coup comment achete-t-on des certificats pour la validation d'organisation ou la validation étendue ?
Pouvez vous me donner votre avis et votre positionnement sur ce sujet ?
bonne journée
jean-christophe PAROLA
Je pense que beaucoup d'entre nous sommes dans le même cas.
On 12/02/2018 16:08, JC PAROLA wrote:
Bonjour à tous,
Bonjour,
Je me permets de poster sur la liste car nous rencontrons en ce moment beaucoup de problème avec notre ancien fournisseur de certificat SSL car chrome ne reconnait plus certaines autorités de certificattions.
A tritre d'exemple Trustico ne semble plus en mesure de fournir les certificats SSL de Digicert en raison de l'arret de reconnaissance par le navigateur Chrome
voici leur message
http://paste.privianet.com/1F0C3AB3D2/d6621d2c8a75837e0cd3289cc6ecf615
etant client rapidssl, et symantec ayant vendu sa division a digicert il est prevu un reenrolement des certificats vers la pki de digicert.
je n'ai rien entendu concernant le fait que google va enlever digicert de son browser, le message parle bien des cerificats symantec
Bonne apres midi
Le 12 février 2018 à 16:08, JC PAROLA contact@sels-ingenierie.com a écrit :
Bonjour à tous,
Salut,
Pouvez vous me donner votre avis et votre positionnement sur ce sujet ?
Je pense qu'il y a une incompréhension : Chrome ne fait plus confiance aux *anciennes* AC Symantec (Symantec, Geotrust, Thawte, RapidSSL).
DigiCert a racheté le business SSL de Symantec et a migré ses marques sous ces AC. Donc tu ne devrais pas avoir d'avertissement de sécurité : il te suffit de régénérer tes certificats et de mettre à jour les certificats intermédiaires.
merci pour vos retours. Mon fournisseur m'a bien fourni des certificats de remplacement mais il avait omis de me dire que les futurs certificats de Symantec générés avec la nouvelle PKI seraient bien accepés, il a préféré m'orentité vers Comodo. Merci pour vos éclairage. Bonne journée
Le lundi 12 février 2018 16:22:20, Jonathan Leroy jonathan@unsigned.inikup.com a écrit:
Je pense qu'il y a une incompréhension : Chrome ne fait plus confiance aux *anciennes* AC Symantec (Symantec, Geotrust, Thawte, RapidSSL).
DigiCert a racheté le business SSL de Symantec
Attention, dans cette affaire, Chrome a annoncé qu'il ne faisait plus confiance à Symantec. Mais ce n'est pas allé beaucoup plus loin.
Par contre, Mozilla est allé un pas plus loin, en se posant la question de la confiance qui pouvait être transférée lors le rachat de Symantec par Digicert, et a posté un article de blog à ce sujet :
https://blog.mozilla.org/security/2017/10/31/statement-digicerts-proposed-pu...
Le post date de novembre et ne semble pas avoir eu de suite, mais on peut penser qu'ils ont Digicert à l'oeil et que pour le moindre problème, ils pourraient les ejecter aussi...
A+ Jacques.
Le 12 février 2018 à 22:23, Jacques Belin jbelin@oryva.net a écrit :
Attention, dans cette affaire, Chrome a annoncé qu'il ne faisait plus confiance à Symantec. Mais ce n'est pas allé beaucoup plus loin.
Par contre, Mozilla est allé un pas plus loin, en se posant la question de la confiance qui pouvait être transférée lors le rachat de Symantec par Digicert, et a posté un article de blog à ce sujet :
https://blog.mozilla.org/security/2017/10/31/statement-digicerts-proposed-pu...
Le post date de novembre et ne semble pas avoir eu de suite, mais on peut penser qu'ils ont Digicert à l'oeil et que pour le moindre problème, ils pourraient les ejecter aussi...
Ce post a été publié en pleine discussion sur le rachat des activités SSL de Symantec par DigiCert. Il était notamment question à l'époque de savoir si DigiCert allait ou non remplacer l'infra et les procédures Symantec, reconnues comme défaillantes à de nombreuses reprises, par les siennes (qui pour le coup sont assez irréprochables).
La question a été réglée puisque tous les backends et procédures utilisées lorsque vous commandez chez un CA Symantec sont désormais ceux de DigiCert.
Dans tous les cas : - Chaque CA a été migré sur un certificat intermédiaire chez DigiCert. Dans le cas ou un navigateur choisirait de ne plus faire confiance à un des CA Symantec, seul le certificat intermédiaire en question serait révoqué, et non le CA racine DigiCert. - Une décision de retrait de confiance par les navigateur n'est jamais prise à la légère, et ils évitent de prendre des décisions qui "casseraient" Internet. D'ailleurs dans le cas des CA Symantec, le retrait de la confiance a été très progressif.
Peut-être que LetsEncrypt est la voie que tout le monde doit pendre ? Mais du coup comment achete-t-on des certificats pour la validation d'organisation ou la validation étendue ?
Pouvez vous me donner votre avis et votre positionnement sur ce sujet ?
Pourquoi vouloir des certificats EV ou OV ? Pour avoir le nom de sa boite dans la barre d'adresse ? Je doute que cela fasse une grande différence pour le end-user.
Il serait nettement préférable de passer chaque déploiement dans ssllabs pour s'assurer que plus rien ne traîne en SSL2/3 ou TLSv1 et de régler une bonne fois pour toute les millions de sites en mixed content. Sans compter les security headers qu'on aimerait bien voir un jour correctement mis pour éviter les XSS et autres injections, à commencer par le HSTS.
Et si on veux 'faire les choses bien' et offrir de vraies garanties de sécurité (attention, je n'ai pas dit que c'était suffisant), on peut pousser jusqu'à HPKP.
Si on rajoute à ça que let's encrypt fournira des wildcard dans quelques jours [1], je vois mal quel intérêt ont encore les autorités commerciales.
Petite note : avec DNSSEC et DANE, on pourra, un jour, mettre directement la clé publique dans le DNS. En fait, on peut déjà, c'est juste que les browsers ne le supportent pas.
Julien
1 : https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.htm...
Le 14/02/2018 à 11:03, Julien Escario a écrit :
Peut-être que LetsEncrypt est la voie que tout le monde doit pendre ? Mais du coup comment achete-t-on des certificats pour la validation d'organisation ou la validation étendue ?
Pouvez vous me donner votre avis et votre positionnement sur ce sujet ?
Pourquoi vouloir des certificats EV ou OV ? Pour avoir le nom de sa boite dans la barre d'adresse ? Je doute que cela fasse une grande différence pour le end-user.
Il serait nettement préférable de passer chaque déploiement dans ssllabs pour s'assurer que plus rien ne traîne en SSL2/3 ou TLSv1 et de régler une bonne fois pour toute les millions de sites en mixed content. Sans compter les security headers qu'on aimerait bien voir un jour correctement mis pour éviter les XSS et autres injections, à commencer par le HSTS.
Et si on veux 'faire les choses bien' et offrir de vraies garanties de sécurité (attention, je n'ai pas dit que c'était suffisant), on peut pousser jusqu'à HPKP.
Si on rajoute à ça que let's encrypt fournira des wildcard dans quelques jours [1], je vois mal quel intérêt ont encore les autorités commerciales.
tout ca c'est tres joli mais ca parle que du web et neglige tout les autres services qui on besoin de certificats ssl pour fonctionner.
de plus lets encrypt change tout les 90 jours si je me souveint bien donc totalement inutilisable dans d'autres contextes
Bonne journee
Bonjour,
Le Wed, 14 Feb 2018 11:20:41 +0100, Benoit Mortier benoit.mortier@opensides.be a écrit :
tout ca c'est tres joli mais ca parle que du web et neglige tout les autres services qui on besoin de certificats ssl pour fonctionner.
de plus lets encrypt change tout les 90 jours si je me souveint bien donc totalement inutilisable dans d'autres contextes
Effectivement, il faut du web pour le renouvellement, mais cela n'empêche absolument pas l'utilisation pour d'autres services, en utilisant un serveur web léger pour le renouvellement, ou l'option standalone de certbot, par exemple. Je m'en sers personnellement pour un serveur IRC (en utilisant le Nginx du site web se trouvant sur le même serveur) et mon serveur de mail (avec Lighttpd), d'ailleurs.
Bon après-midi.
Le 14/02/2018 à 12:20, Breizh a écrit :
Bonjour,
Le Wed, 14 Feb 2018 11:20:41 +0100, Benoit Mortier benoit.mortier@opensides.be a écrit :
tout ca c'est tres joli mais ca parle que du web et neglige tout les autres services qui on besoin de certificats ssl pour fonctionner.
de plus lets encrypt change tout les 90 jours si je me souveint bien donc totalement inutilisable dans d'autres contextes
Effectivement, il faut du web pour le renouvellement, mais cela n'empêche absolument pas l'utilisation pour d'autres services, en utilisant un serveur web léger pour le renouvellement, ou l'option standalone de certbot, par exemple. Je m'en sers personnellement pour un serveur IRC (en utilisant le Nginx du site web se trouvant sur le même serveur) et mon serveur de mail (avec Lighttpd), d'ailleurs.
je me voit mal avec des process http sur chaque machine qui contient des certificats et tout ca a faire passer par le firewall etc dans des environements professionels
de plus on est quand meme pas sur de la perenite de lets encrypt, pas que celle des registrar soit meilleure :)
bonne apres-midi
On 14/02/2018 12:24, Benoit Mortier wrote:
Le 14/02/2018 à 12:20, Breizh a écrit :
Bonjour,
Le Wed, 14 Feb 2018 11:20:41 +0100, Benoit Mortier benoit.mortier@opensides.be a écrit :
tout ca c'est tres joli mais ca parle que du web et neglige tout les autres services qui on besoin de certificats ssl pour fonctionner.
de plus lets encrypt change tout les 90 jours si je me souveint bien donc totalement inutilisable dans d'autres contextes
Effectivement, il faut du web pour le renouvellement, mais cela n'empêche absolument pas l'utilisation pour d'autres services, en utilisant un serveur web léger pour le renouvellement, ou l'option standalone de certbot, par exemple. Je m'en sers personnellement pour un serveur IRC (en utilisant le Nginx du site web se trouvant sur le même serveur) et mon serveur de mail (avec Lighttpd), d'ailleurs.
je me voit mal avec des process http sur chaque machine qui contient des certificats et tout ca a faire passer par le firewall etc dans des environements professionels
de plus on est quand meme pas sur de la perenite de lets encrypt, pas que celle des registrar soit meilleure :)
Bonjour,
Je ne comprend pas cette dernière remarque, ni celle d'avant d'ailleurs. Lets encrypt ne risque pas de mourir; il est juste supporté par tous les cadors du Web et d'ailleurs https://letsencrypt.org/sponsors/ .
Sur la première remarque : https://letsencrypt.org/docs/faq/ On peut faire un certificat validé pour le domaine entier, ça accepte les wildcards, donc il suffit d'une seule machine dédiée au renouvellement. A part si vous avez besoin de valider l'organisation (OV) ou si vous avez besoin d'un certificat étendu (EV), ça fonctionne.
Sur la limite de 90 jours, il y a de plusieurs méthodes pour renouveler ça automatiquement, et entre nous, je trouve ça plutôt réconfortant.
Rémy.
bonne apres-midi
Liste de diffusion du FRsAG http://www.frsag.org/
Will Let’s Encrypt issue wildcard certificates?
We support wildcard certificates as part of the ACMEv2 test environment endpoint. Wildcard certificates issued by the ACMEv2 test environment are for testing only and not trusted by browsers. Wildcard issuance requires base domain validation using DNS-01 challenges. A production ready ACMEv2 environment for issuing trusted wildcard certificates will be availableFebrurary 27th.
J'ai raté un truc ou c'est pas encore tout à fait prêt ?
Le 14 févr. 2018 à 13:58, Remy Dernat a écrit :
On 14/02/2018 12:24, Benoit Mortier wrote:
Le 14/02/2018 à 12:20, Breizh a écrit :
Bonjour,
Le Wed, 14 Feb 2018 11:20:41 +0100, Benoit Mortier benoit.mortier@opensides.be a écrit :
tout ca c'est tres joli mais ca parle que du web et neglige tout les autres services qui on besoin de certificats ssl pour fonctionner.
de plus lets encrypt change tout les 90 jours si je me souveint bien donc totalement inutilisable dans d'autres contextes
Effectivement, il faut du web pour le renouvellement, mais cela n'empêche absolument pas l'utilisation pour d'autres services, en utilisant un serveur web léger pour le renouvellement, ou l'option standalone de certbot, par exemple. Je m'en sers personnellement pour un serveur IRC (en utilisant le Nginx du site web se trouvant sur le même serveur) et mon serveur de mail (avec Lighttpd), d'ailleurs.
je me voit mal avec des process http sur chaque machine qui contient des certificats et tout ca a faire passer par le firewall etc dans des environements professionels
de plus on est quand meme pas sur de la perenite de lets encrypt, pas que celle des registrar soit meilleure :)
Bonjour,
Je ne comprend pas cette dernière remarque, ni celle d'avant d'ailleurs. Lets encrypt ne risque pas de mourir; il est juste supporté par tous les cadors du Web et d'ailleurs https://letsencrypt.org/sponsors/ .
Sur la première remarque : https://letsencrypt.org/docs/faq/ On peut faire un certificat validé pour le domaine entier, ça accepte les wildcards, donc il suffit d'une seule machine dédiée au renouvellement. A part si vous avez besoin de valider l'organisation (OV) ou si vous avez besoin d'un certificat étendu (EV), ça fonctionne.
Sur la limite de 90 jours, il y a de plusieurs méthodes pour renouveler ça automatiquement, et entre nous, je trouve ça plutôt réconfortant.
Rémy.
bonne apres-midi
Liste de diffusion du FRsAG http://www.frsag.org/
-- Rémy Dernat Ingénieur d'Etudes MBB/ISE-M _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
On 14/02/2018 14:11, David Ponzone wrote:
Will Let’s Encrypt issue wildcard certificates?
We support wildcard certificates as part of the ACMEv2 test environment endpoint. Wildcard certificates issued by the ACMEv2 test environment are for testing only and not trusted by browsers. Wildcard issuance requires base domain validation using DNS-01 challenges. A production ready ACMEv2 environment for issuing trusted wildcard certificates will be availableFebrurary 27th.
J'ai raté un truc ou c'est pas encore tout à fait prêt ?
Effectivement, j'ai parlé trop vite; je croyais que c'était d'ores et déjà opérationnel, mais c'est pour la fin du mois :)
Le 14 févr. 2018 à 13:58, Remy Dernat a écrit :
On 14/02/2018 12:24, Benoit Mortier wrote:
Le 14/02/2018 à 12:20, Breizh a écrit :
Bonjour,
Le Wed, 14 Feb 2018 11:20:41 +0100, Benoit Mortierbenoit.mortier@opensides.be a écrit :
tout ca c'est tres joli mais ca parle que du web et neglige tout les autres services qui on besoin de certificats ssl pour fonctionner.
de plus lets encrypt change tout les 90 jours si je me souveint bien donc totalement inutilisable dans d'autres contextes
Effectivement, il faut du web pour le renouvellement, mais cela n'empêche absolument pas l'utilisation pour d'autres services, en utilisant un serveur web léger pour le renouvellement, ou l'option standalone de certbot, par exemple. Je m'en sers personnellement pour un serveur IRC (en utilisant le Nginx du site web se trouvant sur le même serveur) et mon serveur de mail (avec Lighttpd), d'ailleurs.
je me voit mal avec des process http sur chaque machine qui contient des certificats et tout ca a faire passer par le firewall etc dans des environements professionels
de plus on est quand meme pas sur de la perenite de lets encrypt, pas que celle des registrar soit meilleure :)
Bonjour,
Je ne comprend pas cette dernière remarque, ni celle d'avant d'ailleurs. Lets encrypt ne risque pas de mourir; il est juste supporté par tous les cadors du Web et d'ailleurs https://letsencrypt.org/sponsors/ .
Sur la première remarque : https://letsencrypt.org/docs/faq/ On peut faire un certificat validé pour le domaine entier, ça accepte les wildcards, donc il suffit d'une seule machine dédiée au renouvellement. A part si vous avez besoin de valider l'organisation (OV) ou si vous avez besoin d'un certificat étendu (EV), ça fonctionne.
Sur la limite de 90 jours, il y a de plusieurs méthodes pour renouveler ça automatiquement, et entre nous, je trouve ça plutôt réconfortant.
Rémy.
bonne apres-midi
Liste de diffusion du FRsAG http://www.frsag.org/
-- Rémy Dernat Ingénieur d'Etudes MBB/ISE-M _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour,
Je ne comprend pas cette dernière remarque, ni celle d'avant d'ailleurs. Lets encrypt ne risque pas de mourir; il est juste supporté par tous les cadors du Web et d'ailleurs https://letsencrypt.org/sponsors/ .
Alors c'est marrant : mon ublock origin bloque ABSOLUMENT toutes les images des sponsors. Va falloir que je vois pourquoi tiens.
Blague mise à part : Let's Encrypt n'est pas dénué de critiques. Le fait qu'un certain nombres de cadors soutiennent le projet n'a jamais été gage de confiance absolue. Il suffirait que le projet souffre d'un déficit d'image pour une raison x ou y pour que ces gens là se retirent rapidement pour ne pas être associés au problème. Il y a aussi des arguments économiques.
Plus généralement, l'argument principal qui revient est : ce n'est pas la 'communauté' qui gère le truc (d'ailleurs la responsabilité des intervenants n'est pas très claire). On aime bien quand c'est ISO, IANA, RIPE ou IETF qui gère un truc comme ça, ce sont des organisations assez ouvertes. (cf DNSSEC) mais qui mettent plus de temps à s'imposer (un RFC, c'est looooong à faire accoucher).
Sur un registre plus technique, on peut citer le fait que n'importe qui peut désormais obtenir un certificat SSL pour son petit site de phishing, ce qui le rend beaucoup plus 'crédible' au yeux du grand public (en mode cadenas vert = confiance aveugle).
Ajoutons à cela que sur certains navigateurs, le punnycode permet de feinter l'adresse affichée dans la barre d'adresse et on a un joli bingo. Pour exemple avec apple.com : https://www.xudongz.com/blog/2017/idn-phishing/
Faille depuis contournée par les navigateurs récents mais qui met son navigateur à jour en 2018 ? C'est tellement 2000's.
Sur la première remarque : https://letsencrypt.org/docs/faq/ On peut faire un certificat validé pour le domaine entier, ça accepte les wildcards, donc il suffit d'une seule machine dédiée au renouvellement. A part
Petite précision : le wildcard n'est dispo que sur l'env de test. Il passera en prod le 27/02/2018. Notons au passage que la validation exigera ... du DNS ! (et plus du web).
si vous avez besoin de valider l'organisation (OV) ou si vous avez besoin d'un certificat étendu (EV), ça fonctionne.
Il faudrait revenir aux fondamentaux, TLS ca peut servir à 3 choses : * Chiffrer les communications (DV est parfait pour ça avec un score A+ sur SSLLabs/A sur Cryptcheck - coucou Aeris) * Authentifier le serveur : il faut OV/EV pour ça mais honnêtement, à part chez les geeks, je crois que tout le monde s'en fout (cf le nombre de gens qui bypassent les alertes de sécurité TLS et qu'on doit forcer à grand coup de HSTS). * Authentifier l'utilisateur : ça semble, pour une raison qui m'échappe, plus trop dans l'air du temps. C'était marrant pourtant.
Sur la limite de 90 jours, il y a de plusieurs méthodes pour renouveler ça automatiquement, et entre nous, je trouve ça plutôt réconfortant.
Clairement et la durée maximale des certs OV/EV est désormais de 29 mois.
Je génère plein de certificats avec let's encrypt que je n'utilise parfois plus. Le plus souvent, je pense à les révoquer mais les avoir qui se désactivent tout seuls au bout de 3 mois me simplifie grandement la vie.
Julien
Ma première question fait débat...on continue :-) On sait tous que les certificats fournis par DigiCert et autres autorités de certification fournissent une assurance pouvant vous/nous indemniser à hauteur de centaines de milliers d'euros. Quelqu'un a-t-il eu besoin un jour de faire valoir cette assurance ? Comment peut-on prouver que la faute vient de l'autorité de certification pour être indemniser ? Il semble que tout ce joue dans la qualité des hashage des PKI et de la rigueur de la CA a bien vérifier l'identité du demandeur du certificat. Si les grands sponsors de Letsencrypt ont fait les choses "bien". Les hashages sont sérieux, le risque de casse est donc très faible (ou aussi faible que celle d'une CA payante type DigiCert) Donc outre le problème de SNI, wildcard et de validation d'ACME par le Web (qui n'est peut-être pas des plus simples lorsque l'on prend un certificat LetsEncrypt pour son serveur de Mail...et si le courrielleur reconnait LetsEncrypt), il semble que sur le plan purement technique (cad PKI) il y ait peut de différence entre LetsEncrypt et un Thawte par exemple......reste l'assurance Je ne sais pas si commercialement cela un impact pour vous dans la vente des certificats à vos clients.
Le 14 février 2018 à 15:03, JC PAROLA contact@sels-ingenierie.com a écrit :
On sait tous que les certificats fournis par DigiCert et autres autorités de certification fournissent une assurance pouvant vous/nous indemniser à hauteur de centaines de milliers d'euros.
Quelqu'un a-t-il eu besoin un jour de faire valoir cette assurance ?
Comment peut-on prouver que la faute vient de l'autorité de certification pour être indemniser ?
J'ai posté sur ce sujet en septembre dernier : https://www.frsag.org/pipermail/frsag/2017-September/008821.html
TL;DR : les garanties financières vendues avec les certificats ne valent rien.
On Wed, Feb 14, 2018 at 11:20:41AM +0100, Benoit Mortier wrote:
Le 14/02/2018 à 11:03, Julien Escario a écrit :
Peut-être que LetsEncrypt est la voie que tout le monde doit pendre ? Mais du coup comment achete-t-on des certificats pour la validation d'organisation ou la validation étendue ?
Pouvez vous me donner votre avis et votre positionnement sur ce sujet ?
Pourquoi vouloir des certificats EV ou OV ? Pour avoir le nom de sa boite dans la barre d'adresse ? Je doute que cela fasse une grande différence pour le end-user.
Il serait nettement préférable de passer chaque déploiement dans ssllabs pour s'assurer que plus rien ne traîne en SSL2/3 ou TLSv1 et de régler une bonne fois pour toute les millions de sites en mixed content. Sans compter les security headers qu'on aimerait bien voir un jour correctement mis pour éviter les XSS et autres injections, à commencer par le HSTS.
Et si on veux 'faire les choses bien' et offrir de vraies garanties de sécurité (attention, je n'ai pas dit que c'était suffisant), on peut pousser jusqu'à HPKP.
Si on rajoute à ça que let's encrypt fournira des wildcard dans quelques jours [1], je vois mal quel intérêt ont encore les autorités commerciales.
tout ca c'est tres joli mais ca parle que du web et neglige tout les autres services qui on besoin de certificats ssl pour fonctionner.
de plus lets encrypt change tout les 90 jours si je me souveint bien donc totalement inutilisable dans d'autres contextes
J'utilise let's encrypt pour le web/mail/... et généralement, tous les services accessibles en ligne. Pour les autres contextes, style industriel ou a accès restreint, en général, il n'y a pas besoin d'un certificat signé par une autorité. De quels autres contextes parlez-vous ?
tout ca c'est tres joli mais ca parle que du web et neglige tout les autres services qui on besoin de certificats ssl pour fonctionner.
Quasiment aucun autre protocole ne supporte correctement SNI d'où la raison pour laquelle le sujet n'est que rarement évoqué.
de plus lets encrypt change tout les 90 jours si je me souveint bien donc totalement inutilisable dans d'autres contextes
Ah ? On fait du let's encrypt sur pleins de services : IMAP, SMTP, XMPP, SIP et j'en passe. On est pas obligés de faire la validation par ACME challenge hein, il y a d'autres méthodes (DNS notamment mais il faut un serveur DNS qui soit supporté niveau API).
Julien
2018-02-14 11:20 GMT+01:00 Benoit Mortier benoit.mortier@opensides.be:
Le 14/02/2018 à 11:03, Julien Escario a écrit :
Peut-être que LetsEncrypt est la voie que tout le monde doit pendre ?
Mais du
coup comment achete-t-on des certificats pour la validation d'organisation ou la
validation
étendue ?
Pouvez vous me donner votre avis et votre positionnement sur ce sujet ?
Pourquoi vouloir des certificats EV ou OV ? Pour avoir le nom de sa
boite dans
la barre d'adresse ? Je doute que cela fasse une grande différence pour
le end-user.
Il serait nettement préférable de passer chaque déploiement dans ssllabs
pour
s'assurer que plus rien ne traîne en SSL2/3 ou TLSv1 et de régler une
bonne fois
pour toute les millions de sites en mixed content. Sans compter les security headers qu'on aimerait bien voir un jour
correctement
mis pour éviter les XSS et autres injections, à commencer par le HSTS.
Et si on veux 'faire les choses bien' et offrir de vraies garanties de
sécurité
(attention, je n'ai pas dit que c'était suffisant), on peut pousser
jusqu'à HPKP.
Si on rajoute à ça que let's encrypt fournira des wildcard dans quelques
jours
[1], je vois mal quel intérêt ont encore les autorités commerciales.
tout ca c'est tres joli mais ca parle que du web et neglige tout les autres services qui on besoin de certificats ssl pour fonctionner.
de plus lets encrypt change tout les 90 jours si je me souveint bien donc totalement inutilisable dans d'autres contextes
Tous mes certifs LE sont générés sur une seul machine avec dehydrated :
- Un hook nsupdate pour valider les chalenges DNS-01. - Un hook post-update pour pousser les certifs mis à jour avec ansible (+ redémarrage des services si nécessaire).
Les clés privées ne changent pas (donc pas de soucis pour HPKP, DANE etc…)
Bonne journee
Benoit Mortier CEO OpenSides "logiciels libres pour entreprises" : http://www.opensides.eu/ Promouvoir et défendre le Logiciel Libre http://www.april.org/ Main developer in FusionDirectory : http://www.fusiondirectory.org/ Official French representative for OPSI : http://opsi.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour
Peut-être que LetsEncrypt est la voie que tout le monde doit pendre ? Mais du coup comment achete-t-on des certificats pour la validation d'organisation ou la validation étendue ?
Pouvez vous me donner votre avis et votre positionnement sur ce sujet ?
Pourquoi vouloir des certificats EV ou OV ? Pour avoir le nom de sa boite dans la barre d'adresse ? Je doute que cela fasse une grande différence pour le end-user.
Il serait nettement préférable de passer chaque déploiement dans ssllabs pour s'assurer que plus rien ne traîne en SSL2/3 ou TLSv1 et de régler une bonne fois pour toute les millions de sites en mixed content. Sans compter les security headers qu'on aimerait bien voir un jour correctement mis pour éviter les XSS et autres injections, à commencer par le HSTS.
Et si on veux 'faire les choses bien' et offrir de vraies garanties de sécurité (attention, je n'ai pas dit que c'était suffisant), on peut pousser jusqu'à HPKP.
Si on rajoute à ça que let's encrypt fournira des wildcard dans quelques jours [1], je vois mal quel intérêt ont encore les autorités commerciales.
Petite note : avec DNSSEC et DANE, on pourra, un jour, mettre directement la clé publique dans le DNS. En fait, on peut déjà, c'est juste que les browsers ne le supportent pas.
C’était supporté par par DANE/TLSA Validator jusqu'a ce que Ferefox 57… donc globalement à part pour les 5 gus qui ont encore Firefox 52 ESR, c'est effectivement pas supporté coté navigateur. Mais ça pourrait se dire que ça pourrait se résoudre rapidement (1)…
Sauf que le gros problème, c'est que DANE ne sert à rien si le résolveur DNS qui fait DNSSEC n'est pas au plus prêt des users. C'est à dire la machine qui fait la résolution DNS et qui donne la clé, est la même que celle que demande la résolution et la clé (comprendre sans réseau externe entre). Sinon on s'expose au MITM (cf le cas de Bouygues Telecom en 3G/4G sur ses forfaits BandYou). Auquel cas le MITM pourra juste être détecté mais pas empêché : On pourra toujours mettre un résolveur DNS menteur, intercepter et détourner les requêtes pour les adresser audit DNS menteur et répondre ce qu'on veut (éventuellement en cassant la vérification DNSSEC et donc DANE).
Autant dire que c'est pas utilisable par une extrême majorité des utilisateurs, qui utilisent des résolveur DNS distants (soit ceux du FAI sot ceux de google).
Et la seule alternative (moins bien) qui pourrait quand même dépanner si on ne peur pas avoir un résolveur DNS local à sa machine (device mobile, filtrage réseau qui empercherait le résolveur de fonctionner) est toute aussi contraignante sur certains réseaux : Un lien VPN chiffré entre sa machine locale et son résolveur DNS, hébergé sur le serveur VPN (sur une machine de confiance, dans un réseau de confiance).
L'idée de départ de DANE est bonne. Mais sa dépendance au DNS que la plupart des gens délèguent au FAI, et les verrous des appareil mobiles font que c'est difficilement utilisable en pratique, sauf à pouvoir respecter la contrainte « résolveur local », qui exclut directement les users finaux et les devices mobiles, et tous les gens derrière des réseaux très filtrés
1. Enfin, ce serait vrai seulement si les devs des navigateurs passaient plus de temps à améliorer la sécurité qu'à rajouter des mécanismes de tracking pour faire des graphiques sur les sites les plus visités par leurs users, à présenter à leurs hiérarchie…
Julien
1 : https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.htm... _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-
Benoit Mortier -
Breizh -
davenull＠tuxfamily.org -
David Ponzone -
Jacques Belin -
JC PAROLA -
Jonathan Leroy -
Julien Escario -
Landry Minoza -
Mathieu Arnold -
Remy Dernat