Toc toc un support de chez Gandi ?
Bonjour la liste, c'est une bouteille à la mer : Y a t il quelqu'un de chez Gandi sur cette liste ? Gandi m'a fourni un certificat SSL Std pour un domain sans le sous domaine www. C'est à dire que le certificat est valide pour domain.tld mais pas www.domain.tld Même en régénérant le certificat en utilisant leur ligne de commande pour générer la requête. C'est une première depuis que le service existe ! Pas de réponse à mon ticket depuis hier. Le chat en ligne ne fonctionne pas. Le telephone répond qu'il faut utiliser le formulaire en ligne ... sont ils eux aussi devenus décérébrés, pardon je veux dire, inaccessibles ? En tout cas ils sont devenus complètement hors sol en un temps record ! NB : Aller voir ailleurs n'est pas encore le projet. Merci d'avance Théo VARIER
Hello je n'utilise plus Gandi (merci l'augmentation des tarifs !) mais de mémoire, pour avoir domain.tld ET www.domain.tld il faut générer un CSR en www.domain.tld Le 13/03/2024 à 15:37, Théo VARIER via FRsAG a écrit :
Bonjour la liste, c'est une bouteille à la mer :
Y a t il quelqu'un de chez Gandi sur cette liste ?
Gandi m'a fourni un certificat SSL Std pour un domain sans le sous domaine www. C'est à dire que le certificat est valide pour domain.tld mais pas www.domain.tld Même en régénérant le certificat en utilisant leur ligne de commande pour générer la requête.
C'est une première depuis que le service existe !
Pas de réponse à mon ticket depuis hier.
Le chat en ligne ne fonctionne pas.
Le telephone répond qu'il faut utiliser le formulaire en ligne ... sont ils eux aussi devenus décérébrés, pardon je veux dire, inaccessibles ?
En tout cas ils sont devenus complètement hors sol en un temps record !
NB : Aller voir ailleurs n'est pas encore le projet.
Merci d'avance
Théo VARIER
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
bonsoir, Ce problème me dit quelque chose… J’ai déjà eu la même chose. Je pense aussi que tu t’es trompé sur le CSR. De mon expérience, le meilleur moyen pour accélérer ton ticket, c’est de les interpeller sur Twitter, ils sont très réactifs. A l'instar des autres, je quitte peu à peu grandi… Je migre tous mes clients NDD vers Infomaniak. -- Kevin Le 13 mars 2024 à 17:45, Pierre DOLIDON <sn4ky@sn4ky.net> a écrit :
Hello je n'utilise plus Gandi (merci l'augmentation des tarifs !) mais de mémoire, pour avoir domain.tld ET www.domain.tld il faut générer un CSR en www.domain.tld Le 13/03/2024 à 15:37, Théo VARIER via FRsAG a écrit :
Bonjour la liste, c'est une bouteille à la mer : Y a t il quelqu'un de chez Gandi sur cette liste ? Gandi m'a fourni un certificat SSL Std pour un domain sans le sous domaine www. C'est à dire que le certificat est valide pour domain.tld mais pas www.domain.tld Même en régénérant le certificat en utilisant leur ligne de commande pour générer la requête. C'est une première depuis que le service existe ! Pas de réponse à mon ticket depuis hier. Le chat en ligne ne fonctionne pas. Le telephone répond qu'il faut utiliser le formulaire en ligne ... sont ils eux aussi devenus décérébrés, pardon je veux dire, inaccessibles ? En tout cas ils sont devenus complètement hors sol en un temps record ! NB : Aller voir ailleurs n'est pas encore le projet. Merci d'avance Théo VARIER _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/ _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Le 13/03/2024 à 23:57, Pierre-Elliott Bécue a écrit :
Kevin <kevin@labecot.fr> wrote on 13/03/2024 at 19:51:44+0100:
A l'instar des autres, je quitte peu à peu grandi… Je migre tous mes clients NDD vers Infomaniak. Peut-on dire qu'on ressort Gandis de cette histoire ?
(oui je sors)
Excellente !
On peut le dire, mais Gandi Raton ?
:))) Que son fromage est plein de trous ! J'étais rs-423 chez eux (sic). La dernière fois que j'ai sorti un NDD de gandi, il n'y a pas très longtemps (ils sont en cheville avec local ou solocal, je ne sais plus), ils m'ont encore mis la misère, de vraies méthodes d'agrume (orange reste mon record avec 43 email + recours à l'AFNIC). Ils osaient me sortir que puisqu'ils étaient partenaires avec l'un des bouclars ci-dessus, la procédure était plus compliquée, ralentie, différente, etc. une vraie bande de tordus pas pros. Tout est chez OVH depuis longtemps, économique et zéroproblémo. -- Stéphane Rivière Ile d'Oléron - France
Bonjour à tous, Merci pour toutes vos réponses, les drôles (ils se reconnaîtront), et la hors sujet wildcard très documentée (il se reconnaitra) ... Merci pour votre soutien. Vos réponses ont été des encouragements plus que des éclaircissements Alors je vous donne des nouvelles : Très tôt ce matin une réponse du support est tombée, ... à coté de la plaque mais enfin j'avais un interlocuteur. Après un échange de plusieurs mails pour ré expliquer la situation, la conclusion semble être que la procédure de commande est faussée par l'existence d'un hébergement gandi actuellement actif avec certificat sur ce domaine. Oui, l'idée c'est que je prépare un hébergement ailleurs et que j'ai besoin d'un nouveau certificat. Il semble qu'il y ait une collision entre ma nouvelle demande certificat pour mettre ailleurs et la conf automagique attachée à l'hébergement Gandi encore actif. C'est pas toujours évident d'être dans deux états en même temps dans le même système d'information, ça je peux comprendre. J'ai même demandé la re-génération du certificat en précisant explicitement l'Alternative Name avec le www. dans la requête comme pour un multi domaine, mais ça a fait pchitt , le certificat livré ne le comporte pas. Tant pis pour le Gandi raton ;) faute d'une solution simple de Gandi dans l'aprem je ferais autrement. Malheureusement Stéphane, tu as raison. Et si tu ajoutes leur augmentation tarifaire complètement délirante, qu'un gars de leur support (chat) m'a justifiée cet été en vantant leur support de qualité supérieur et leur présence dans leurs bureaux parisiens ... WTF Bref à part pour quelques clients, je fais comme toi : tout vers OVH ... C'est dommage, j'aimais bien l'idée d'avoir les noms et les certificats ailleurs que mes hébergements, et j'aimais bien Gandi. Vu l'emmerdement à bouger les trucs, je ne suis pas sûr d'en ressortir Grandi ;) Pour le SSL, outre Let's Encrypt, cette page donne une assez bonne idée du paysage : https://www.httpcs.com/fr/certificats-ssl -- Théo VARIER
Le 14 mars 2024 à 12:00, Stéphane Rivière <stef@genesix.org> a écrit :
On peut le dire, mais Gandi Raton ?
:))) Que son fromage est plein de trous !
J'étais rs-423 chez eux (sic). La dernière fois que j'ai sorti un NDD de gandi, il n'y a pas très longtemps (ils sont en cheville avec local ou solocal, je ne sais plus), ils m'ont encore mis la misère, de vraies méthodes d'agrume (orange reste mon record avec 43 email + recours à l'AFNIC). Ils osaient me sortir que puisqu'ils étaient partenaires avec l'un des bouclars ci-dessus, la procédure était plus compliquée, ralentie, différente, etc. une vraie bande de tordus pas pros.
Tout est chez OVH depuis longtemps, économique et zéroproblémo.
-- Stéphane Rivière Ile d'Oléron - France
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Le Thu, Mar 14, 2024 at 12:38:56PM +0100, Théo VARIER via FRsAG a écrit:
Bref à part pour quelques clients, je fais comme toi : tout vers OVH ... C'est dommage, j'aimais bien l'idée d'avoir les noms et les certificats ailleurs que mes hébergements, et j'aimais bien Gandi.
Pour les domaines, je te conseille BookMyName. Moins cher qu'OVH, tout aussi français, et ils ne font que du domaine, eux. L'interface est un peu à l'ancienne, mais en terme de rapidité, ça n'a rien à voir avec les bouses de gandi ou ovh... Ça juste marche très bien, toutes les options existent sans limitation, et si besoin il existe aussi une API.
Pour le SSL, outre Let's Encrypt, cette page donne une assez bonne idée du paysage : https://www.httpcs.com/fr/certificats-ssl
Il y en a d'autres du type Let's Encrypt aussi; https://github.com/acmesh-official/acme.sh?tab=readme-ov-file#supported-ca À part sur des équipements sur lesquels tu ne peux pas automatiser la mise à jour des certificats, et sur lesquels la durée de vie de 90 jours est franchement courte et t'oblige à le faire à la main 5 fois par an, je ne vois plus aucun avantage de nos jours à prendre des certificats payants. Les validations EV (barre verte) ne sont plus indiquées par les navigateurs depuis plusieurs années, le wildcard ou le multi-domaines sont faisables par les CA listés ci-dessus... Et les assurances... C'est du vent marketing. Le seul cas que je peux voir où il faut encore débourser des sous pour du certificat, ce sont pour des cas très spécifiques, comme pour la santé: https://esante.gouv.fr/produits-services/certificats-logiciels Mais pour des simples sites web, je ne vois plus de cas d'usage (à part le déploiement une fois par an uniquement, ou des éventuelles raisons de conformité à un référentiel de sécurité -- je ne m'étendrai pas sur le sujet). Arnaud.
Le 14/03/2024 à 13:13, Arnaud Launay via FRsAG a écrit : …
À part sur des équipements sur lesquels tu ne peux pas automatiser la mise à jour des certificats, et sur lesquels la durée de vie de 90 jours est franchement courte et t'oblige à le faire à la main 5 fois par an, je ne vois plus aucun avantage de nos jours à prendre des certificats payants.
… La mise à jour automatique des certificats LE est un cheval de Troie. On trouve facilement des certificats pour 10 euros et quelques centimes et avec ça on est tranquille pour un an ; pour moi cela vaut le coût.
Bonjour Laurent,
La mise à jour automatique des certificats LE est un cheval de Troie.
acme.sh avec les bonnes options n'est pas un cheval de troie + acmemgr.sh pour gérer en masse des centaines de domaines = santé bonheur.
On trouve facilement des certificats pour 10 euros et quelques centimes et avec ça on est tranquille pour un an ; pour moi cela vaut le coût.
La vente de certifs n'est-il pas un ignoble racket ? L'infrastructure LE est (imho) une merveille. Fonctionnalités, résilience, bac à sable... J'aimerai bien avoir la même chose pour les certifs de mails (pour le chiffrement) mais ça n'a pas l'air d'actualité... -- Stéphane Rivière Ile d'Oléron - France
Le 14/03/2024 à 14:20, Stéphane Rivière a écrit :
Bonjour Laurent,
La mise à jour automatique des certificats LE est un cheval de Troie.
acme.sh avec les bonnes options n'est pas un cheval de troie + acmemgr.sh pour gérer en masse des centaines de domaines = santé bonheur.
On trouve facilement des certificats pour 10 euros et quelques centimes et avec ça on est tranquille pour un an ; pour moi cela vaut le coût.
La vente de certifs n'est-il pas un ignoble racket ?
L'infrastructure LE est (imho) une merveille. Fonctionnalités, résilience, bac à sable...
J'aimerai bien avoir la même chose pour les certifs de mails (pour le chiffrement) mais ça n'a pas l'air d'actualité...
Bonjour Stéphane, Mon niveau de confiance à propos de acmemgr.sh est proportionnel à celui que j'ai vis à vis de soweb.io lui même indexé sur celui que j'ai envers son gérant (que je connais personnellement) : maximal ! Cependant, je suis complètement paranoïaque pour la sécurité des serveurs que je gère et, compte tenu de mon tarif horaire, même dans sa version la plus avantageuse pour mes clients, il faudrait que je parvienne à contrôler acmemgr.sh et acme.sh (qui n'est pas produit par soweb.io il me semble) en moins de 0h06:50 par rapport au coût d'un certificat payant ; ce qui est largement au dessus de mes capacités :-) Cela dit, je suis d'accord sur le fait que la vente de certifs est un ignoble racket, d'autant plus que ggl a réussi à imposer https tout azimut, y compris pour des blogs diffusant des informations totalement publiques, ce qui est une infamie rien qu'au niveau écologique ! Laurent Barme
Laurent Barme <2551@barme.fr> wrote on 14/03/2024 at 15:19:04+0100:
Cela dit, je suis d'accord sur le fait que la vente de certifs est un ignoble racket, d'autant plus que ggl a réussi à imposer https tout azimut, y compris pour des blogs diffusant des informations totalement publiques, ce qui est une infamie rien qu'au niveau écologique !
Je suis ravi qu'on sécurise les connexions et la confidentialité des accès contre un overhead de quelques % (qui baisse avec le temps), quitte à ce que pour satisfaire les exigences écologiques des autres on essaie plutôt d'arrêter de coller des libs JS de plusieurs Mo sur les pages web et d'autres qui balourdent tout autant de volumes en publicités. Le gain écologique serait une dizaine de fois supérieur et notre confort en serait renforcé. Mais bon, YMMV -- PEB
Le 14/03/2024 à 16:43, Pierre-Elliott Bécue a écrit :
Laurent Barme <2551@barme.fr> wrote on 14/03/2024 at 15:19:04+0100:
Cela dit, je suis d'accord sur le fait que la vente de certifs est un ignoble racket, d'autant plus que ggl a réussi à imposer https tout azimut, y compris pour des blogs diffusant des informations totalement publiques, ce qui est une infamie rien qu'au niveau écologique ! Je suis ravi qu'on sécurise les connexions et la confidentialité des accès contre un overhead de quelques % (qui baisse avec le temps), quitte à ce que pour satisfaire les exigences écologiques des autres on essaie plutôt d'arrêter de coller des libs JS de plusieurs Mo sur les pages web et d'autres qui balourdent tout autant de volumes en publicités.
Le gain écologique serait une dizaine de fois supérieur et notre confort en serait renforcé.
Mais bon, YMMV Tout à fait d'accord sur la gabegie des librairies JS et des pubs. A noter qu'il est complètement inutile de "sécuriser" toutes les connexions ni de protéger la confidentialité des accès aux messages publicitaires. De plus le surcoût des échanges sécurisés par un certificat SSL s'applique aussi au dessus de ces librairies JS et publicités :-(
On Thu, Mar 14, 2024 at 11:10 AM Laurent Barme <2551@barme.fr> wrote:
Le 14/03/2024 à 16:43, Pierre-Elliott Bécue a écrit :
Laurent Barme <2551@barme.fr> wrote on 14/03/2024 at 15:19:04+0100:
Cela dit, je suis d'accord sur le fait que la vente de certifs est un ignoble racket, d'autant plus que ggl a réussi à imposer https tout azimut, y compris pour des blogs diffusant des informations totalement publiques, ce qui est une infamie rien qu'au niveau écologique ! Je suis ravi qu'on sécurise les connexions et la confidentialité des accès contre un overhead de quelques % (qui baisse avec le temps), quitte à ce que pour satisfaire les exigences écologiques des autres on essaie plutôt d'arrêter de coller des libs JS de plusieurs Mo sur les pages web et d'autres qui balourdent tout autant de volumes en publicités.
Le gain écologique serait une dizaine de fois supérieur et notre confort en serait renforcé.
Mais bon, YMMV Tout à fait d'accord sur la gabegie des librairies JS et des pubs. A noter qu'il est complètement inutile de "sécuriser" toutes les connexions ni de protéger la confidentialité des accès aux messages publicitaires.
Est-ce que ce n'est pas une protection contre une attaque MITM qui pourrait injecter n'importe quel JS dans un site en remplaçant une pub? En termes de confidentialité, les pubs qui me sont montrées dépendent de mes centres d'intérêt, intercepter toutes les pubs pourrait permettre de faire un profil de l'utilisateur potentiellement. -- Mehdi
Le 14/03/2024 à 19:54, Mehdi AMINI a écrit :
On Thu, Mar 14, 2024 at 11:10 AM Laurent Barme <2551@barme.fr <mailto:2551@barme.fr>> wrote:
Le 14/03/2024 à 16:43, Pierre-Elliott Bécue a écrit : > Laurent Barme <2551@barme.fr <mailto:2551@barme.fr>> wrote on 14/03/2024 at 15:19:04+0100: >> Cela dit, je suis d'accord sur le fait que la vente de certifs est un >> ignoble racket, d'autant plus que ggl a réussi à imposer https tout >> azimut, y compris pour des blogs diffusant des informations totalement >> publiques, ce qui est une infamie rien qu'au niveau écologique ! > Je suis ravi qu'on sécurise les connexions et la confidentialité des > accès contre un overhead de quelques % (qui baisse avec le temps), > quitte à ce que pour satisfaire les exigences écologiques des autres on > essaie plutôt d'arrêter de coller des libs JS de plusieurs Mo sur les > pages web et d'autres qui balourdent tout autant de volumes en > publicités. > > Le gain écologique serait une dizaine de fois supérieur et notre confort > en serait renforcé. > > Mais bon, YMMV Tout à fait d'accord sur la gabegie des librairies JS et des pubs. A noter qu'il est complètement inutile de "sécuriser" toutes les connexions ni de protéger la confidentialité des accès aux messages publicitaires.
Est-ce que ce n'est pas une protection contre une attaque MITM qui pourrait injecter n'importe quel JS dans un site en remplaçant une pub?
Ne faudrait-il pas aussi pour cela qu'il y ai aussi une corruption du DNS ? Quoiqu'il en soit pour les sites qui ne dépendent pas de librairies JS externe et qui ne détiennent pas d'information sensible ni confidentielles, la sécurisation SSL est juste inutile.
En termes de confidentialité, les pubs qui me sont montrées dépendent de mes centres d'intérêt, intercepter toutes les pubs pourrait permettre de faire un profil de l'utilisateur potentiellement.
Ne t'inquiète pas pour ça. Ton profil utilisateur est déjà certainement bien capté par ailleurs :-)
Laurent Barme <2551@barme.fr> wrote on 14/03/2024 at 19:09:22+0100:
Le 14/03/2024 à 16:43, Pierre-Elliott Bécue a écrit :
Laurent Barme <2551@barme.fr> wrote on 14/03/2024 at 15:19:04+0100:
Cela dit, je suis d'accord sur le fait que la vente de certifs est un ignoble racket, d'autant plus que ggl a réussi à imposer https tout azimut, y compris pour des blogs diffusant des informations totalement publiques, ce qui est une infamie rien qu'au niveau écologique ! Je suis ravi qu'on sécurise les connexions et la confidentialité des accès contre un overhead de quelques % (qui baisse avec le temps), quitte à ce que pour satisfaire les exigences écologiques des autres on essaie plutôt d'arrêter de coller des libs JS de plusieurs Mo sur les pages web et d'autres qui balourdent tout autant de volumes en publicités.
Le gain écologique serait une dizaine de fois supérieur et notre confort en serait renforcé.
Mais bon, YMMV Tout à fait d'accord sur la gabegie des librairies JS et des pubs. A noter qu'il est complètement inutile de "sécuriser" toutes les connexions ni de protéger la confidentialité des accès aux messages publicitaires.
Si tu penses vraiment, par exemple, qu'il est inutile de sécuriser la connexion web à un blog, ou la connexion web vers des libs JS tierces, ou…, eh bien je suis inquiet pour tes fondamentaux en sécurité numérique et pour tes clients. -- PEB
Le 14/03/2024 à 22:54, Pierre-Elliott Bécue a écrit :
Si tu penses vraiment, par exemple, qu'il est inutile de sécuriser la connexion web à un blog, ou la connexion web vers des libs JS tierces,
Je n'utilise pas de libs JS tierces. Si, si, c'est possible :-)
ou…, eh bien je suis inquiet pour tes fondamentaux en sécurité numérique et pour tes clients.
Si tu penses qu'un certificat SSL te protège te tout…
Laurent Barme <2551@barme.fr> wrote on 14/03/2024 at 23:10:55+0100:
Le 14/03/2024 à 22:54, Pierre-Elliott Bécue a écrit :
Si tu penses vraiment, par exemple, qu'il est inutile de sécuriser la connexion web à un blog, ou la connexion web vers des libs JS tierces,
Je n'utilise pas de libs JS tierces. Si, si, c'est possible :-)
Mais même celle que tu sers toi-même a tout intérêt à être servie à l'end user via une connexion sécurisée.
ou…, eh bien je suis inquiet pour tes fondamentaux en sécurité numérique et pour tes clients.
Si tu penses qu'un certificat SSL te protège te tout…
Tu as bien conscience que c'est tout sauf un bon argument ? C'est un peu comme dire "un manteau ne protège pas de tout, et en fabriquer pollue, donc n'en portons pas". -- PEB
Le Thu, Mar 14, 2024 at 01:39:31PM +0100, Laurent Barme a écrit:
La mise à jour automatique des certificats LE est un cheval de Troie.
Je n'ai rien compris. Il faudrait que tu développes.
On trouve facilement des certificats pour 10 euros et quelques centimes et avec ça on est tranquille pour un an ; pour moi cela vaut le coût.
Oui, avec les renouvellements qui sont oubliés, les sites qui sont en carafe et où c'est la panique pour trouver le type avec la CB qui va bien, et les X serveurs où la mise à jour a été oubliée, effectivement, le faire à la main, c'est mieux. Rassure-moi, on n'est pas vendredi, mais c'était un troll ? Arnaud.
Le 14/03/2024 à 15:36, Arnaud Launay via FRsAG a écrit :
Le Thu, Mar 14, 2024 at 01:39:31PM +0100, Laurent Barme a écrit:
La mise à jour automatique des certificats LE est un cheval de Troie. Je n'ai rien compris. Il faudrait que tu développes. C'est assez simple pourtant. La mise à jour des certificats est faite par un traitement que tu importes et ne maitrises pas, dont la génération de la clé privée ; question sécurité, c'est moyen.
On trouve facilement des certificats pour 10 euros et quelques centimes et avec ça on est tranquille pour un an ; pour moi cela vaut le coût. Oui, avec les renouvellements qui sont oubliés, les sites qui sont en carafe et où c'est la panique pour trouver le type avec la CB qui va bien, et les X serveurs où la mise à jour a été oubliée, effectivement, le faire à la main, c'est mieux. Quel drôle de façon de concevoir l'administration d'un serveur !
Rassure-moi, on n'est pas vendredi, mais c'était un troll ?
C'est mignon la coutume du vendredi. C'est sympa pour justifier les échanges sur des sujets plus distrayant que sérieux mais l'utiliser comme argument pour critiquer un point de vue, c'est petit. Ah et puis demain, je ne serai pas disponible.
On 14/03/2024 19:16, Laurent Barme wrote:
Le 14/03/2024 à 15:36, Arnaud Launay via FRsAG a écrit :
Le Thu, Mar 14, 2024 at 01:39:31PM +0100, Laurent Barme a écrit:
La mise à jour automatique des certificats LE est un cheval de Troie. Je n'ai rien compris. Il faudrait que tu développes. C'est assez simple pourtant. La mise à jour des certificats est faite par un traitement que tu importes et ne maitrises pas, dont la génération de la clé privée ; question sécurité, c'est moyen.
Le protocole ACME ne t'empêche pas de générer ta clef privée en local. Si ça n'était pas le cas, ça serait complètement stupide et dangereux, en effet.
Rassure-moi, on n'est pas vendredi, mais c'était un troll ? C'est mignon la coutume du vendredi. C'est sympa pour justifier les échanges sur des sujets plus distrayant que sérieux mais l'utiliser comme argument pour critiquer un point de vue, c'est petit.
Je ne pense pas que la remarque soit une, c'est juste que tu nous as habitué à mieux. Il existe une foulitude de logiciels qui font du ACME, dont certains qui ne font que quelques centaines de lignes. Facile à auditer.
Le Fri, Mar 15, 2024 at 07:58:05AM +0100, Léo El Amri via FRsAG a écrit:
Le protocole ACME ne t'empêche pas de générer ta clef privée en local. Si ça n'était pas le cas, ça serait complètement stupide et dangereux, en effet.
Absolument. Tu peux même générer ta clef directement à partir d'openssl sans passer par la couche d'abstraction du logiciel (ici on utilise acme.sh, et j'en suis ravi). Couche qui crée de toute façon la clef en local aussi, avec le random local, et ça ne sort pas du serveur non plus. La génération de la clef et du CSR est faite en locale, et ce qui est fait par le cloud © ® ™ c'est - la vérification du domaine pour le wildcard ou de l'url pour un certificat plus restreint - la signature du certificat par l'autorité - l'envoi du certificat signé vers ton serveur, en chiffré TLS (ce qui n'est même pas strictement nécessaire, puisqu'il s'agit de la partie publique du certificat) Finalement, c'est exactement la même chose qu'avec Comodo ou autre.
Rassure-moi, on n'est pas vendredi, mais c'était un troll ? C'est mignon la coutume du vendredi. C'est sympa pour justifier les échanges sur des sujets plus distrayant que sérieux mais l'utiliser comme argument pour critiquer un point de vue, c'est petit. Je ne pense pas que la remarque soit une, c'est juste que tu nous as habitué à mieux.
C'est ça. J'ai rajouté la ligne après avoir écrit le reste, parce que j'avais du mal à croire que je lisais du Barme. Du coup, je me suis dit que pour une fois, il avait peut-être envie de se détendre... Apparemment, j'avais tort :( Arnaud.
Finalement, c'est exactement la même chose qu'avec Comodo ou autre.
+1000 Et même mieux car le service LE est remarquable (fiable, bac à sable, etc.) et il est offert à la communauté. Dans l'absolu, tout ce qui est permis est cassable par les états, donc TLS cassé sinon pas autorisé. TLS permet de sécuriser les transactions commerciales via un chiffrement autorisé par les chiens de garde et c'est déjà suffisant pour le biz. Considérant que les Google & Co exigent du TLS pour le référencement et qu'il est nécessaire pour les transactions commerciales. Un grand merci à LE, acme.sh & co de nous proposer des services et fonctionnalités auditables pour un niveau commercial.
Je ne pense pas que la remarque soit une, c'est juste que tu nous as habitué à mieux. Comme tout le monde, moi le premier, Laurent a ses lubies et ça permet de se reposer les bonnes questions ou de détailler les bonnes réponses :)
-- Stéphane Rivière Ile d'Oléron - France
Le 15/03/2024 à 11:14, Arnaud Launay via FRsAG a écrit :
Le Fri, Mar 15, 2024 at 07:58:05AM +0100, Léo El Amri via FRsAG a écrit:
Le protocole ACME ne t'empêche pas de générer ta clef privée en local. Si ça n'était pas le cas, ça serait complètement stupide et dangereux, en effet. Absolument. Tu peux même générer ta clef directement à partir d'openssl sans passer par la couche d'abstraction du logiciel (ici on utilise acme.sh, et j'en suis ravi). Couche qui crée de toute façon la clef en local aussi, avec le random local, et ça ne sort pas du serveur non plus.
La génération de la clef et du CSR est faite en locale, et ce qui est fait par le cloud © ® ™ c'est
- la vérification du domaine pour le wildcard ou de l'url pour un certificat plus restreint - la signature du certificat par l'autorité - l'envoi du certificat signé vers ton serveur, en chiffré TLS (ce qui n'est même pas strictement nécessaire, puisqu'il s'agit de la partie publique du certificat)
Finalement, c'est exactement la même chose qu'avec Comodo ou autre. Merci pour ces précisions ; j'avoue que cela ne me saute pas aux yeux quand je survole les 8009 lignes de shell d'acme.sh :-)
Rassure-moi, on n'est pas vendredi, mais c'était un troll ? C'est mignon la coutume du vendredi. C'est sympa pour justifier les échanges sur des sujets plus distrayant que sérieux mais l'utiliser comme argument pour critiquer un point de vue, c'est petit. Je ne pense pas que la remarque soit une, c'est juste que tu nous as habitué à mieux. C'est ça. J'ai rajouté la ligne après avoir écrit le reste, parce que j'avais du mal à croire que je lisais du Barme. Du coup, je me suis dit que pour une fois, il avait peut-être envie de se détendre...
Absolument ! J'avais vraiment besoin de me détendre. Il est clair que mes communications un peu précipitées d'avant ce weekend étaient pour le moins maladroites. Et justement je reviens d'un petit séjour à Londres, loin de mes préoccupations informatiques habituelles : British Museum, Natural History Museum, National Gallery, pubs, full english breakfast, cream teas, et tout et tout. Ca va beaucoup mieux :-). Néanmoins, j'ai quelques arguments à (mieux) présenter qui pourront je l'espère éclairer mon point de vue et sans doute susciter des réponses qui complèteront ma compréhension des aspects techniques qui m'échappent. Je reviendrai sur ces sujets dès que j'aurai un peu de temps pour le faire correctement…
Apparemment, j'avais tort :(
Arnaud. _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Laurent Barme <2551@barme.fr> wrote on 14/03/2024 at 13:39:31+0100:
Le 14/03/2024 à 13:13, Arnaud Launay via FRsAG a écrit : …
À part sur des équipements sur lesquels tu ne peux pas automatiser la mise à jour des certificats, et sur lesquels la durée de vie de 90 jours est franchement courte et t'oblige à le faire à la main 5 fois par an, je ne vois plus aucun avantage de nos jours à prendre des certificats payants.
…
La mise à jour automatique des certificats LE est un cheval de Troie.
Pas vraiment. Ou alors il va falloir définir ce que tu entends par cheval de Troie.
On trouve facilement des certificats pour 10 euros et quelques centimes et avec ça on est tranquille pour un an ; pour moi cela vaut le coût.
-- PEB
Le 14/03/2024 à 16:37, Pierre-Elliott Bécue a écrit :
Laurent Barme <2551@barme.fr> wrote on 14/03/2024 at 13:39:31+0100:
Le 14/03/2024 à 13:13, Arnaud Launay via FRsAG a écrit : …
À part sur des équipements sur lesquels tu ne peux pas automatiser la mise à jour des certificats, et sur lesquels la durée de vie de 90 jours est franchement courte et t'oblige à le faire à la main 5 fois par an, je ne vois plus aucun avantage de nos jours à prendre des certificats payants.
…
La mise à jour automatique des certificats LE est un cheval de Troie. Pas vraiment. Ou alors il va falloir définir ce que tu entends par cheval de Troie. Tu as raison : c'est /potentiellement/ un cheval de Troie.
Ce n'est sans doute pas le cas mais je ne peux pas m'en assurer. Et cela me gène d'autant plus que cela concerne un sujet critique pour la sécurité et, pour autant que je m'en souvienne, un processus exécuté par root.
On trouve facilement des certificats pour 10 euros et quelques centimes et avec ça on est tranquille pour un an ; pour moi cela vaut le coût.
Alors, aux dernières nouvelles, Let's Encrypt fournit des API. Nous avons ensuite la liberté d'utiliser le client de notre choix pour communiquer avec. Il est tout à fait possible d'auditer le code desdits clients vu qu'une grande majorité sont Open Source et disponibles sur GitHub ou autre plateforme. Et d'ailleurs, rien ne nous oblige, lors de l'utilisation de Let's Encrypt, de faire la génération des certificats ailleurs que sur les machines de production qui les utiliseront. Déporter cette tâche ailleurs est même souvent une plutôt bonne idée. Personnellement, je ne suis pas fan de laisser un accès Internet sortant peu filtré sur des serveurs de production... Le jeudi 14 mars 2024 à 19:28, Laurent Barme <2551@barme.fr> a écrit :
Le 14/03/2024 à 16:37, Pierre-Elliott Bécue a écrit :
Laurent Barme <2551@barme.fr> wrote on 14/03/2024 at 13:39:31+0100:
Le 14/03/2024 à 13:13, Arnaud Launay via FRsAG a écrit : …
À part sur des équipements sur lesquels tu ne peux pas automatiser la mise à jour des certificats, et sur lesquels la durée de vie de 90 jours est franchement courte et t'oblige à le faire à la main 5 fois par an, je ne vois plus aucun avantage de nos jours à prendre des certificats payants. … La mise à jour automatique des certificats LE est un cheval de Troie. Pas vraiment. Ou alors il va falloir définir ce que tu entends par cheval de Troie. Tu as raison : c'est _potentiellement_ un cheval de Troie. Ce n'est sans doute pas le cas mais je ne peux pas m'en assurer. Et cela me gène d'autant plus que cela concerne un sujet critique pour la sécurité et, pour autant que je m'en souvienne, un processus exécuté par root. On trouve facilement des certificats pour 10 euros et quelques centimes et avec ça on est tranquille pour un an ; pour moi cela vaut le coût. ------------------------- _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Le 14/03/2024 à 19:47, William FERRES a écrit :
Alors, aux dernières nouvelles, Let's Encrypt fournit des API. Nous avons ensuite la liberté d'utiliser le client de notre choix pour communiquer avec. C'est pareil, le temps que je passerais à développer un traitement utilisant ces API n'est pas justifiable par rapport à une dépense annuel d'une dizaine d'euros.
Il est tout à fait possible d'auditer le code desdits clients vu qu'une grande majorité sont Open Source et disponibles sur GitHub ou autre plateforme.
Oui, c'est théoriquement /possible/ d'auditer un code "open source" mais en pratique non. Du moins cela me prendrait plus de temps que de le réécrire moi-même.
Et d'ailleurs, rien ne nous oblige, lors de l'utilisation de Let's Encrypt, de faire la génération des certificats ailleurs que sur les machines de production qui les utiliseront. Déporter cette tâche ailleurs est même souvent une plutôt bonne idée. Personnellement, je ne suis pas fan de laisser un accès Internet sortant peu filtré sur des serveurs de production...
Le jeudi 14 mars 2024 à 19:28, Laurent Barme <2551@barme.fr> a écrit :
Le 14/03/2024 à 16:37, Pierre-Elliott Bécue a écrit :
Laurent Barme<2551@barme.fr> wrote on 14/03/2024 at 13:39:31+0100:
Le 14/03/2024 à 13:13, Arnaud Launay via FRsAG a écrit : …
À part sur des équipements sur lesquels tu ne peux pas automatiser la mise à jour des certificats, et sur lesquels la durée de vie de 90 jours est franchement courte et t'oblige à le faire à la main 5 fois par an, je ne vois plus aucun avantage de nos jours à prendre des certificats payants.
…
La mise à jour automatique des certificats LE est un cheval de Troie.
Pas vraiment. Ou alors il va falloir définir ce que tu entends par cheval de Troie.
Tu as raison : c'est /potentiellement/ un cheval de Troie.
Ce n'est sans doute pas le cas mais je ne peux pas m'en assurer. Et cela me gène d'autant plus que cela concerne un sujet critique pour la sécurité et, pour autant que je m'en souvienne, un processus exécuté par root.
On trouve facilement des certificats pour 10 euros et quelques centimes et avec ça on est tranquille pour un an ; pour moi cela vaut le coût.
-------------------------------------------------------------------------------- _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
On 14/03/2024 20:04, Laurent Barme wrote:
Le 14/03/2024 à 19:47, William FERRES a écrit :
Alors, aux dernières nouvelles, Let's Encrypt fournit des API. Nous avons ensuite la liberté d'utiliser le client de notre choix pour communiquer avec. C'est pareil, le temps que je passerais à développer un traitement utilisant ces API n'est pas justifiable par rapport à une dépense annuel d'une dizaine d'euros.
Dépense à multiplier par le nombre de certificats nécessaires pour tous tes services (sans parler du temps nécessaire à aller les mettres à jour manuellement). A moins que tu n'utilises un unique certificat wildcard mais je doute qu'un gars soucieux de la sécurité de ses clients comme toi ne fasse cela.
Il est tout à fait possible d'auditer le code desdits clients vu qu'une grande majorité sont Open Source et disponibles sur GitHub ou autre plateforme.
Oui, c'est théoriquement /possible/ d'auditer un code "open source" mais en pratique non. Du moins cela me prendrait plus de temps que de le réécrire moi-même.
Du coup selon la même logique j'imagine que tu n'utilises pas de serveur web open-source ? Ni de firewall open-source ? Ni de système d'exploitation opensource ? Et que tu as réimplémenté tout ça puisque ça risque de prendre plus de temps à auditer par toi même qu'a réécrire ?
Du coup selon la même logique j'imagine que tu n'utilises pas de serveur web open-source ? Ni de firewall open-source ? Ni de système d'exploitation opensource ? Et que tu as réimplémenté tout ça puisque ça risque de prendre plus de temps à auditer par toi même qu'a réécrire ?
:))) Bonne pioche. OpenSSL est-il sûr (vu que ses 300000 lignes sont codées par des singes¹) ? Et ma génération de diffie-hellman est-elle correcte ? Linux est-il un gruyère sans trous ? La vie n'est pas simple et le paradis n'existe pas. La preuve, à Madagascar, les pingouins sont psychopathes. ¹ https://news.ycombinator.com/item?id=7556407 (pas récent, mais c'est l'idée). -- Stéphane Rivière Ile d'Oléron - France
A mon job-1 j’avais créé un CT dédié à cette tâche et qui allait pousser les certificats à coup de SCP sur les vm, qu’elles soient prod, preprod ou interne. Ainsi même des VM non ouvertes sur internet pouvaient avoir du SSL ce qui est, pour de nombreux services, bien plus pratique :) Aussi, pas besoin de fait du challenge HTTP -le plus connu-. Perso j’adore le challenge DNS. Au moins pas besoin d’ouvrir des flux vers mes serveurs. Et mon client LE préféré est : getssl —> https://github.com/srvrco/getssl — Kevin
Le 14 mars 2024 à 19:47, William FERRES via FRsAG <frsag@frsag.org> a écrit :
Alors, aux dernières nouvelles, Let's Encrypt fournit des API. Nous avons ensuite la liberté d'utiliser le client de notre choix pour communiquer avec.
Il est tout à fait possible d'auditer le code desdits clients vu qu'une grande majorité sont Open Source et disponibles sur GitHub ou autre plateforme.
Et d'ailleurs, rien ne nous oblige, lors de l'utilisation de Let's Encrypt, de faire la génération des certificats ailleurs que sur les machines de production qui les utiliseront. Déporter cette tâche ailleurs est même souvent une plutôt bonne idée. Personnellement, je ne suis pas fan de laisser un accès Internet sortant peu filtré sur des serveurs de production...
Le jeudi 14 mars 2024 à 19:28, Laurent Barme <2551@barme.fr> a écrit :
Le 14/03/2024 à 16:37, Pierre-Elliott Bécue a écrit :
Laurent Barme <2551@barme.fr> <mailto:2551@barme.fr> wrote on 14/03/2024 at 13:39:31+0100:
Le 14/03/2024 à 13:13, Arnaud Launay via FRsAG a écrit : …
À part sur des équipements sur lesquels tu ne peux pas automatiser la mise à jour des certificats, et sur lesquels la durée de vie de 90 jours est franchement courte et t'oblige à le faire à la main 5 fois par an, je ne vois plus aucun avantage de nos jours à prendre des certificats payants.
…
La mise à jour automatique des certificats LE est un cheval de Troie. Pas vraiment. Ou alors il va falloir définir ce que tu entends par cheval de Troie. Tu as raison : c'est potentiellement un cheval de Troie.
Ce n'est sans doute pas le cas mais je ne peux pas m'en assurer. Et cela me gène d'autant plus que cela concerne un sujet critique pour la sécurité et, pour autant que je m'en souvienne, un processus exécuté par root.
On trouve facilement des certificats pour 10 euros et quelques centimes et avec ça on est tranquille pour un an ; pour moi cela vaut le coût.
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/ _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Et d'ailleurs, rien ne nous oblige, lors de l'utilisation de Let's Encrypt, de faire la génération des certificats ailleurs que sur les machines de production qui les utiliseront. Déporter cette tâche ailleurs est même souvent une plutôt bonne idée.
+1 Un serveur de clés est une bonne pratique (les milis et autres services utilisent ce principe). Ici, via acmemgr.sh + acme.sh, qui sont isolés sur une instance dédiée, les clés sont générées puis maintenues et dispatchées via ssh à travers le réseau privé qui relie les serveurs et instances. -- Stéphane Rivière Ile d'Oléron - France
Laurent Barme <2551@barme.fr> wrote on 14/03/2024 at 19:28:45+0100:
Tu as raison : c'est potentiellement un cheval de Troie.
Ce n'est sans doute pas le cas mais je ne peux pas m'en assurer. Et cela me gène d'autant plus que cela concerne un sujet critique pour la sécurité et, pour autant que je m'en souvienne, un processus exécuté par root.
Il existe une pelletée de clients libres/open source qui sont donc revus et fiables. Et tu peux déporter la régénération de certs hors de ta prod. -- PEB
Le 14/03/2024 à 22:45, Pierre-Elliott Bécue a écrit :
Laurent Barme <2551@barme.fr> wrote on 14/03/2024 at 19:28:45+0100:
Tu as raison : c'est potentiellement un cheval de Troie.
Ce n'est sans doute pas le cas mais je ne peux pas m'en assurer. Et cela me gène d'autant plus que cela concerne un sujet critique pour la sécurité et, pour autant que je m'en souvienne, un processus exécuté par root. Il existe une pelletée de clients libres/open source qui sont donc revus et fiables. Mais bien sûr, si c'est "open source" alors c'est forcément revu et fiable !
As-tu déjà seulement essayé de "revoir" des développements "open source" ? Attention, je ne dis pas que les développements open source ne sont pas fiables. Et tout cas, ils ne sont surement pas moins fiables que les autres.
Laurent Barme <2551@barme.fr> wrote on 14/03/2024 at 23:17:10+0100:
Le 14/03/2024 à 22:45, Pierre-Elliott Bécue a écrit :
Laurent Barme <2551@barme.fr> wrote on 14/03/2024 at 19:28:45+0100:
Tu as raison : c'est potentiellement un cheval de Troie.
Ce n'est sans doute pas le cas mais je ne peux pas m'en assurer. Et cela me gène d'autant plus que cela concerne un sujet critique pour la sécurité et, pour autant que je m'en souvienne, un processus exécuté par root. Il existe une pelletée de clients libres/open source qui sont donc revus et fiables. Mais bien sûr, si c'est "open source" alors c'est forcément revu et fiable !
As-tu déjà seulement essayé de "revoir" des développements "open source" ?
Vu que c'est une de mes activités quotidiennes de packager du travail libre dans une distribution, je t'affirme que oui. Et je t'affirme que la vitesse de repérage de vulns ou de compromission de code dans des logiciels en source ouverte est globalement bien plus solide que ce que tu ne pourrais pondre toi-même, ou que dans un soft privé mais payant. Et je pense que tu devrais aussi arrêter de raconter n'importe quoi sur des sujets que tu ne connais manifestement pas.
Attention, je ne dis pas que les développements open source ne sont pas fiables. Et tout cas, ils ne sont surement pas moins fiables que les autres.
-- PEB
Vu que c'est une de mes activités quotidiennes de packager du travail libre dans une distribution, je t'affirme que oui. Et je t'affirme que la vitesse de repérage de vulns ou de compromission de code dans des logiciels en source ouverte est globalement bien plus solide que ce que tu ne pourrais pondre toi-même, ou que dans un soft privé mais payant.
Clairement ! À ceci près : "que ce que tu ne pourrais pondre toi-même". Ce n'est pas toujours exact. L'emploi d'une méthode et d'un langage issue de l'industrie permettrait d'augmenter la qualité et de réduire le temps de dev. Mais la communauté du libre n'est pas dans cette culture car on code d'abord avec le ou les langages que l'on maîtrise et (parfois) qui nous correspond. Un exemple histoire d'étayer. https://www.adacore.com/academia/projects/ironsides-secure-dns-server On utilise ce langage depuis longtemps et on a réellement divisé nos temps de dev par 3 (vs C++ sur du dev Gtk par exemple) et nettement augmenté la sûreté de fonctionnement. j'ai rien contre le C et dérivés cela dit. Juste une observation. Il y a une prise de conscience, avec Rust, qui reste toutefois encore à des années lumières du langage en question, mais c'est un pas dans la bonne direction ! -- Stéphane Rivière Ile d'Oléron - France
Bonjour le réseau, Connaissez-vous une autre société alternative à ovh avec l'offre type Exchange 50Go ou 300Go. parce que la demande du mot de passe incessante sur Outlook ca deviens pénible. Si vous avez une solution je suis preneur. Merci de vôtres réponses Nes ALADAG SARL NES2J 55 rue Jacquart 51100 Reims Mail : nes2j@free.fr -----Message d'origine----- De : Arnaud Launay via FRsAG <frsag@frsag.org> Envoyé : jeudi 14 mars 2024 13:13 À : frsag@frsag.org Objet : [FRsAG] Re: Toc toc un support de chez Gandi ? Le Thu, Mar 14, 2024 at 12:38:56PM +0100, Théo VARIER via FRsAG a écrit:
Bref à part pour quelques clients, je fais comme toi : tout vers OVH ... C'est dommage, j'aimais bien l'idée d'avoir les noms et les certificats ailleurs que mes hébergements, et j'aimais bien Gandi.
Pour les domaines, je te conseille BookMyName. Moins cher qu'OVH, tout aussi français, et ils ne font que du domaine, eux. L'interface est un peu à l'ancienne, mais en terme de rapidité, ça n'a rien à voir avec les bouses de gandi ou ovh... Ça juste marche très bien, toutes les options existent sans limitation, et si besoin il existe aussi une API.
Pour le SSL, outre Let's Encrypt, cette page donne une assez bonne idée du paysage : https://www.httpcs.com/fr/certificats-ssl
Il y en a d'autres du type Let's Encrypt aussi; https://github.com/acmesh-official/acme.sh?tab=readme-ov-file#supported-ca À part sur des équipements sur lesquels tu ne peux pas automatiser la mise à jour des certificats, et sur lesquels la durée de vie de 90 jours est franchement courte et t'oblige à le faire à la main 5 fois par an, je ne vois plus aucun avantage de nos jours à prendre des certificats payants. Les validations EV (barre verte) ne sont plus indiquées par les navigateurs depuis plusieurs années, le wildcard ou le multi-domaines sont faisables par les CA listés ci-dessus... Et les assurances... C'est du vent marketing. Le seul cas que je peux voir où il faut encore débourser des sous pour du certificat, ce sont pour des cas très spécifiques, comme pour la santé: https://esante.gouv.fr/produits-services/certificats-logiciels Mais pour des simples sites web, je ne vois plus de cas d'usage (à part le déploiement une fois par an uniquement, ou des éventuelles raisons de conformité à un référentiel de sécurité -- je ne m'étendrai pas sur le sujet). Arnaud. _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Bonjour Arnaud,
Pour les domaines, je te conseille BookMyName. Moins cher qu'OVH, tout aussi français, et ils ne font que du domaine, eux. L'interface est un peu à l'ancienne, mais en terme de rapidité, ça n'a rien à voir avec les bouses de gandi ou ovh...
Oui, l'interface de bookmyname est peut être moche mais elle est super rapide... En termes de prix, en gras les moins chers... trucbidulemachin.fr *5,38* HT chez bookmyname et 5,59 HT chez OVH trucbidulemachin.com 11,53 HT chez bookmyname et *9,59 *HT chez OVH Perso, on apprécie énormément la très riche API d'OVH qui nous permet de tout gérer avec un seul paradigme. Quand à l'interface du backoffice OVH, elle s'est améliorée question vitesse (et heureusement).
Ça juste marche très bien, toutes les options existent sans limitation, et si besoin il existe aussi une API.
Bon à savoir.
Pour le SSL, outre Let's Encrypt, cette page donne une assez bonne idée du
Super synthèse, merci !
Il y en a d'autres du type Let's Encrypt aussi;
https://github.com/acmesh-official/acme.sh?tab=readme-ov-file#supported-ca
À part sur des équipements sur lesquels tu ne peux pas automatiser la mise à jour des certificats, et sur lesquels la durée de vie de 90 jours est franchement courte et t'oblige à le faire à la main 5 fois par an, je ne vois plus aucun avantage de nos jours à prendre des certificats payants.
+1000 Et pour se reposer, il y a ça aussi https://github.com/sowebio/acmemgr.sh Qui s'appuie sur l'excellent script que tu as cité au dessus... -- Stéphane Rivière Ile d'Oléron - France
Le Thu, Mar 14, 2024 at 02:15:26PM +0100, Stéphane Rivière a écrit:
En termes de prix, en gras les moins chers...
Désolé, j'utilise mutt en simple texte, je n'ai pas les fioritures ;-)
trucbidulemachin.fr 5,38 HT chez bookmyname et 5,59 HT chez OVH trucbidulemachin.com 11,53 HT chez bookmyname et 9,59 HT chez OVH
Oui mais c'est incomplet ton truc ! Avec un beau tableau à lire en police à chasse fixe et en HT: | TLD | registrar | création | renouvellement | | com | ovh | 9.59 | 12.59 | | com | bmn | 11.53 | 11.53 | | fr | ovh | 5.59 | 7.79 | | fr | bmn | 5.38 | 5.93 | Donc le .com est rentable chez BMN au bout d'un an et 303 jours... Arnaud.
Désolé, j'utilise mutt en simple texte, je n'ai pas les fioritures ;-)
Respect.
Donc le .com est rentable chez BMN au bout d'un an et 303 jours... Merci de m'avoir corrigé, effectivement, la première année est toujours moins chère que les suivantes !
-- Stéphane Rivière Ile d'Oléron - France
Le jeu. 14 mars 2024 à 13:14, Arnaud Launay via FRsAG <frsag@frsag.org> a écrit :
Le Thu, Mar 14, 2024 at 12:38:56PM +0100, Théo VARIER via FRsAG a écrit:
Bref à part pour quelques clients, je fais comme toi : tout vers OVH ... C'est dommage, j'aimais bien l'idée d'avoir les noms et les certificats ailleurs que mes hébergements, et j'aimais bien Gandi.
Pour les domaines, je te conseille BookMyName. Moins cher qu'OVH, tout aussi français, et ils ne font que du domaine, eux. L'interface est un peu à l'ancienne, mais en terme de rapidité, ça n'a rien à voir avec les bouses de gandi ou ovh...
BMN s'est enfin décidé à ouvrir son API à tout le monde ?
Ça juste marche très bien, toutes les options existent sans limitation, et si besoin il existe aussi une API.
Pour le SSL, outre Let's Encrypt, cette page donne une assez bonne idée du paysage : https://www.httpcs.com/fr/certificats-ssl
Il y en a d'autres du type Let's Encrypt aussi;
https://github.com/acmesh-official/acme.sh?tab=readme-ov-file#supported-ca
À part sur des équipements sur lesquels tu ne peux pas automatiser la mise à jour des certificats, et sur lesquels la durée de vie de 90 jours est franchement courte et t'oblige à le faire à la main 5 fois par an, je ne vois plus aucun avantage de nos jours à prendre des certificats payants.
Les validations EV (barre verte) ne sont plus indiquées par les navigateurs depuis plusieurs années, le wildcard ou le multi-domaines sont faisables par les CA listés ci-dessus... Et les assurances... C'est du vent marketing.
Le seul cas que je peux voir où il faut encore débourser des sous pour du certificat, ce sont pour des cas très spécifiques, comme pour la santé: https://esante.gouv.fr/produits-services/certificats-logiciels
Mais pour des simples sites web, je ne vois plus de cas d'usage (à part le déploiement une fois par an uniquement, ou des éventuelles raisons de conformité à un référentiel de sécurité -- je ne m'étendrai pas sur le sujet).
Arnaud. _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Le Thu, Mar 14, 2024 at 09:25:42PM +0100, Mickael MONSIEUR a écrit:
Pour les domaines, je te conseille BookMyName. Moins cher qu'OVH, tout aussi français, et ils ne font que du domaine, eux. L'interface est un peu à l'ancienne, mais en terme de rapidité, ça n'a rien à voir avec les bouses de gandi ou ovh... BMN s'est enfin décidé à ouvrir son API à tout le monde ?
À ma connaissance, la partie insert/delete dans le domaine, oui. La partie création/achat de domaines, non. Mais il suffit de leur demander poliment pour y avoir accès... En gros, c'est un "détournement" de leur API de dyndns, qui est une API light: https://fr.faqs.bookmyname.com/frfaqs/dyndns Qui permet du add / remove sur les valeurs dans le domaine. Mais effectivement l'API complète n'est disponible en théorie qu'à partir de 300 domaines. Sauf que contrairement à OVH, il y a des humains derrière, avec qui il est possible de discuter. OVH, j'attends toujours un retour de leur service commercial pour une question que je leur ai posé il y a un mois et demi. Si tu ne rentres pas dans la case de ce qui est proposé sur le site web, c'est fini, le hors process, ils sont perdus -- et au lieu de répondre "désolé on fera pas", ils font les morts. Classe. Arnaud.
Et dire que tout ça est parti de mon correcteur ;p En tout cas ca a bien réveillé la liste ! — Kevin
Le 14 mars 2024 à 13:41, Samuel Marty <samuel.marty@uvsq.fr> a écrit :
Excellent, je sais enfin pourquoi je me suis inscrit à cette liste !
Merci
Le 14/03/2024 à 09:19, merlin8282 _ a écrit :
Peut-on dire qu'on ressort Gandis de cette histoire ?
On peut le dire, mais Gandi Raton ?
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/ --
Liste de diffusion du %(real_name)s http://www.frsag.org/
On Wed 13 Mar 2024 23:57:13 GMT, Pierre-Elliott Bécue wrote:
Kevin <kevin@labecot.fr> wrote on 13/03/2024 at 19:51:44+0100:
A l'instar des autres, je quitte peu à peu grandi… Je migre tous mes clients NDD vers Infomaniak.
Peut-on dire qu'on ressort Gandis de cette histoire ?
(oui je sors)
En tous cas pas indemnes. -- Alarig
Alarig Le Lay via FRsAG <frsag@frsag.org> wrote on 20/03/2024 at 09:48:08+0100:
On Wed 13 Mar 2024 23:57:13 GMT, Pierre-Elliott Bécue wrote:
Kevin <kevin@labecot.fr> wrote on 13/03/2024 at 19:51:44+0100:
A l'instar des autres, je quitte peu à peu grandi… Je migre tous mes clients NDD vers Infomaniak.
Peut-on dire qu'on ressort Gandis de cette histoire ?
(oui je sors)
En tous cas pas indemnes.
Oh I see where you're going at <3 -- PEB
Coucou, Le Wed, 13 Mar 2024 19:51:44 +0100, Kevin <kevin@labecot.fr> a écrit :
A l'instar des autres, je quitte peu à peu grandi… Je migre tous mes clients NDD vers Infomaniak.
Perso j'ai pris un domaine chez eux après en avoir longuement entendu parlé en bien. He beh je ne referai pas deux fois cette erreur. Commande bloquée sans explication ; impossible donc de disposer du domaine en temps utile ; personne à l'assistance avant des jours ; pour à la fin sortir un blablah sans intérêt. Par ailleurs la console web de gestion ne donne pas grand chose à gérer mais ressemble essentiellement à un gros supermarché qui essaye de me refourguer des services dont je n'ai pas besoin (alors que le service que j'avais payé était en l'air). Bref ; on ne m'y reprendra pas. François -- François Poulain <fpoulain@metrodore.fr>
Coucou, Le Fri, 15 Mar 2024 12:07:40 +0100, François Poulain <fpoulain@metrodore.fr> a écrit :
Bref ; on ne m'y reprendra pas.
Last but not least, décidé à changer de registrar (pour Gandi ... /o\), j'ai eu le droit à 7 jours de délais d'acceptation du transfert. François -- François Poulain <fpoulain@metrodore.fr>
Bonjour Théo, Je n'utilise plus gandi, mais que ce soit chez eux ou ailleurs, il te faut un wildcard si tu veux que ton certif prenne tous les CNAME possibles, cad, *.<ndd>.<tld> ce n'est donc pas /"une première depuis que le service existe" / et c'est bien indiqué sur leur site il me semble https://www.gandi.net/fr/certificates/p/ssl-certificate-wildcard tu peux aussi jeter un coup d'oeil à: https://www.infomaniak.com/fr/support/faq/2312/guide-de-demarrage-certificat... https://letsencrypt.org/fr/docs/faq/ https://www.digitalocean.com/community/tutorials/how-to-create-let-s-encrypt... https://www.webhi.com/how-to/fr/generer-certificats-ssl-wildcard-lets-encryp... https://letsencrypt.org/fr/docs/challenge-types/ cdlt, isAAAc On 13/03/2024 15:37, Théo VARIER via FRsAG wrote:
Bonjour la liste, c'est une bouteille à la mer :
Y a t il quelqu'un de chez Gandi sur cette liste ?
Gandi m'a fourni un certificat SSL Std pour un domain sans le sous domaine www. C'est à dire que le certificat est valide pour domain.tld mais paswww.domain.tld Même en régénérant le certificat en utilisant leur ligne de commande pour générer la requête.
C'est une première depuis que le service existe !
Pas de réponse à mon ticket depuis hier.
Le chat en ligne ne fonctionne pas.
Le telephone répond qu'il faut utiliser le formulaire en ligne ... sont ils eux aussi devenus décérébrés, pardon je veux dire, inaccessibles ?
En tout cas ils sont devenus complètement hors sol en un temps record !
NB : Aller voir ailleurs n'est pas encore le projet.
Merci d'avance
Théo VARIER
_______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Bonsoir, On Wed, 13 Mar 2024 19:39:06 +0100 isAAAc <isaaac@krashboyz.org> wrote:
You don't often get email from isaaac@krashboyz.org. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Bonjour Théo,
Je n'utilise plus gandi,
mais que ce soit chez eux ou ailleurs, il te faut un wildcard si tu veux que ton certif prenne tous les CNAME possibles, cad, *.<ndd>.<tld>
Tu es sur ? Pour moi, un certificat wildcard, il matche "*" (au sens regexp). Mais la demande de Theo, c'est d'avoir domain.tld et www.domain.tld, rien de plus, et ca normalement, ca se fait en renseignant correctement les SAN. Ca ne couvrira pas www1.domain.tld, mais je n'ai pas l'impression que ca sera un probleme. Paul
participants (20)
-
Alarig Le Lay -
Antoine Millet -
Arnaud Launay -
François Poulain -
isAAAc -
Kevin -
Kevin Labécot
-
Laurent Barme -
Léo El Amri -
Mehdi AMINI -
merlin8282 _ -
Mickael MONSIEUR -
nes2j＠free.fr -
Paul Rolland (ポール・ロラン) -
Pierre DOLIDON -
Pierre-Elliott Bécue -
Samuel Marty -
Stéphane Rivière -
Théo VARIER -
William FERRES