Ça pénalise les incompétents ? Je ne vois pas où est le problème, d'autant plus que nous subissons les incompétents à longueur de journée
Non, ça pénalise ceux qui, compétents ou non, récupèrent une adresse IP dont le précédent utilisateur était incompétent ou spammeur, et qui se retrouve dans une blacklist :
qui n’est jamais mise à jour ;
dont il faut payer pour être délisté ;
dont le gérant est aux abonnés absents ;
j’en passe et des meilleures.
(Au passage, il s’agit de violations flagrantes du RFC 6471, qui donne les « bonnes pratiques » que les opérateurs de DNSBL devraient respecter.)
Et je ne parle même pas du cas des DNSBL qui n’hésitent pas à blacklister un /24 entier juste parce qu’une adresse dans le bloc a été utilisée par un spammeur. Au diable les dommages collatéraux, après tout le spam c’est une guerre.
Ah oui, et puis il y a aussi ceux qui blacklistent les adresses que les FAI allouent à leurs abonnés. Rien à foutre de l’auto-hébergement, on est en guerre que je vous dis.
Bref, ça n’a rien à voir avec la compétence de l’administrateur du serveur. Au contraire, si tu rejettes un serveur sur la seule base de la présence de son adresse dans une blacklist, tu dis clairement que tu te moques éperdument des compétences de l’administrateur : peu importe que sa configuration soit irréprochable, que SPF, DKIM et DMARC soient parfaitement mis en œuvre, que tous les RFC relatifs au courrier électronique soient respectés… l’adresse a le malheur d’être blacklistée, c’est tout ce qui compte pour toi.
Si tu voulais pénaliser les « incompétents », nul besoin de blacklist : rejettes ceux dont le serveur est mal configuré (par exemple ceux qui annoncent dans le HELO un nom d’hôte inexistant dans la zone DNS, comme c’est précisément le cas de l’auteur du message initial) et ne respecte pas les RFC.
Libre à toi de penser que quelqu’un dont l’adresse est blacklistée est un incompétent. Pour ma part, je pense qu’un administrateur qui pense avoir fait son travail de lutte contre le spam en ayant délégué cette tâche à une DNSBL est un incompétent à qui on n’aurait jamais du confier l’administration d’un serveur mail.
Maintenant je ne vois pas comment mettre un enregistrement A sur freecadfrance.freecad-france.com.
C’est auprès de ton hébergeur DNS (1 and 1 apparemment) que ça se gère, pas sur ton serveur.
Est ce qu'un sous domaine suffirait ? Ou dois-je supprimer toute occurences de ce hostname dans les fichiers de configurations ?
Ce qui compte est que le nom d’hôte (celui annoncé par Postfix dans le HELO) corresponde à un nom publié dans le DNS et associé à une IP.
En l’état, ta machine s’annonce comme freecadfrance.freecad-france.com, mais ce nom n’existe pas dans ta zone DNS. L’adresse IP est directement associée au domaine freecad-france.com.
De deux choses l’une : ou bien tu configures Postfix pour s’annoncer comme freecad-france.com (option myhostname), ou bien tu ajoutes un A (et un AAAA, puisque tu sembles avoir une connectivité IPv6) dans ta zone DNS pour le nom freecadfrance.freecad-france.com.
RDNS_NONE Delivered to internal network by a host with no rDNS
Ici, le récepteur tente un Foward-Confirmed Reverse DNS : il cherche le nom associé à l’adresse IP de ta machine (reverse DNS), puis il cherche à résoudre ce nom pour vérifier qu’il retombe bien sur l’IP de ta machine (forward confirmation).
Dans ton cas, ça donne ça :
# Reverse DNS
dig -x 163.172.187.210
;; ANSWER SECTION:
210.187.172.163.in-addr.arpa. 60 IN PTR 210-187-172-163.rev.cloud.scaleway.com.
# Forward confirmation
dig 210-187-172-163.rev.cloud.scaleway.com. A
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 60737
« Idéalement » (entre guillemets parce que l’intérêt du FCrDNS dans la lutte contre le spam est discutable), il faudrait que le reverse DNS renvoie le nom de ta machine (freecad-france.com).
Le problème, c’est que le reverse DNS dépend entièrement de ton hébergeur. Certains permettent de le modifier à sa guise, d’autres non.
Tu n’es pas forcément obligé de le faire. Avec un peu de chance, l’adresse de ton serveur est « propre », et sera acceptée par les serveurs de live.com sans action de ta part.
C’est seulement si l’adresse a une mauvaise réputation (parce qu’elle a précédemment été utilisée par des spammeurs, généralement) que tu peux avoir besoin de la faire blanchir. Dans ce cas, les serveurs de live.com t’en informeront lorsque tu tenteras (toi ou un de tes utilisateurs, si tu n’es pas le seul à utiliser ton serveur) de contacter un utilisateur de live.com (du coup, si tu as une connaissance avec un compte live.com tu peux tenter de lui envoyer un message et voir si « ça passe »).
Indépendamment de Live.com, tu peux aussi évaluer la réputation générale de ton adresse IP en vérifiant sa présence dans les principales blacklists.
comment savoir si je n’ai pas le même problème avec yahou, chaudmail, etc ?
D’expérience, avec un enregistrement SPF correct et des mails sortants signés par DKIM, je n’ai pas eu de problèmes ni avec GMail, ni avec Yahoo.
Dans le cas de Microsoft (Live.com, feu Hotmail), ni SPF ni DKIM n’ont été suffisants, il a fallu que je demande explicitement à blanchir l’adresse IP de mon serveur via leur service Smart Network Data Service.
Oui, ça pue, mais je reconnais au moins à Microsoft qu’ils offrent quand la même la possibilité de blanchir une adresse simplement en en faisant la demande. Je ne peux pas en dire autant d’autres fournisseurs (plus modestes comparés aux gros poissons que sont GMail/Yahoo/Live) qui rejettent des serveurs sur la base de DNS blacklists arbitraires d’où il est quasiment impossible, pour certaines, de faire retirer une adresse.
dans ton cas, tu lui dit que le serveur ayant le A ou le MX du domaine ou l'IP 163.172.187.210
J’ajouterai que dans le cas présent, le a et le mx sont inutiles, et alourdissent la tâche du validateur SPF. Après avoir demandé et obtenu l’enregistrement SPF, il doit à présent demander les enregistrements A et MX, puis les enregistrements A correspondants au MX, afin d’avoir la liste complète des adresses contre lesquelles vérifier l’adresse de l’émetteur.
Pour une installation simple, mono-serveur, autant spécifier directement et uniquement les adresses IP (v4 et v6) du serveur via les champs ip4 et ip6, et éviter ainsi toute indirection :
v=spf1 ip4:x.x.x.x ip6:y:y:y:y:y:y:y:y ~all
(Et si tu es sûr — vraiment sûr — de ne jamais envoyer de mail via une autre machine, remplacer le ~all par -all pour informer les serveurs tiers qu’ils ne doivent pas hésiter à rejeter purement et simplement tout message venant d’ailleurs.)
Ça me paraissait être juste un délire de geek parano, mais tu as raison cela peut aider les créateurs de paquets !
L’intérêt des sources signées, c’est que ça permet au moins de vérifier que la release n provient bien de la même personne que la release n−1 (puisqu’elle est signée avec la même clef).
Certes, je ne peux pas pour autant vérifier que ces releases viennent bien de toi (à moins d’avoir pu vérifier ta clef via un canal séparé, comme la toile de confiance), mais rien qu’avoir l’assurance que c’est bien le même développeur derrière chaque release est déjà appréciable (et à vrai dire ça me paraît plus important que de savoir qui est ce développeur et est-ce qu’il s’appelle vraiment François Mazen).
c’est pas mal aussi de fournir un fichier .desktop pour l’intégration du programme dans les menus de l’environnement de bureau ; certains empaqueteurs prennent le temps d’écrire eux-même un tel fichier quand le développeur upstream ne le fournit pas, mais autant leur mâcher le travail.
Fournis ton application en code source avec les fichiers qui vont bien (LICENSE, README, INSTALL, etc).
J’abonde en ce sens. Et j’ajouterais, pêle-mêle :
ne pas donner uniquement un lien vers le dépôt Git/SVN/whatever pour le téléchargement des sources, mais fournir des tarballs pour chaque release (vst-preset-generator-X.Y.Z.tar.gz) ;
tagger les releases dans le système de contrôle de version ;
toutes les informations utiles pour compiler doivent être dans les sources elles-mêmes (dans le README ou dans un fichier annexe genre INSTALL, HOWTO_BUILD ou assimilé), et non pas uniquement sur le site web du projet ;
ces fichiers devraient idéalement être placés à la racine du projet, pas au fin fond du répertoire des sources (src/how_to_compile.txt) ;
si tu penses avoir besoin de donner des consignes particulières aux « empaqueteurs » (ceux qui vont prendre ton projet et en faire un paquet pour leur distribution), ne pas hésiter à leur laisser un fichier README.PACKAGERS ou assimilé.
Si tu as un problème avec un programme qui utilise « encore-un-autre-format-de-timestamp », c’est que c’est un programme qui ne passe pas par syslog pour écrire ses logs (s’il passait par syslog, il utiliserait automatiquement le même format que tous les autres programmes utilisant syslog).
La question est : pourquoi un programme qui a son propre système de log se mettrait subitement, en présence de systemd, à renoncer à son propre système et à se mettre à juste écrire sur la sortie standard ?
Le problème posé par un tel programme vient entièrement du fait qu’il n’utilise pas le démon journalisateur du système,¹ peu importe que le démon en question soit syslog ou journald. Conséquemment, journald ne changera rien à l’histoire, tu devras toujours te dépatouiller avec les journaux de ce programme avec cet-autre-format-de-timestamp.
Je sais que c’est difficile à croire, mais non, systemd ne résoud pas automagiquement tous les problèmes (et il ne fait pas revenir l’être aimé non plus).
¹ Il peut y avoir de bonnes raisons à ça, là n’est pas la question.
Le problème pour un dévelopeur c'est que tellement de couches ont été empilées que gethostbyname() devient dangereux à utiliser
Déjà, si le développeur utilise gethostbyname, le premier problème est qu’il a au moins quinze ans de retard. Cette fonction était déjà deprecated à la sortie de POSIX.1-2001.
Du coup, il est 100 fois plus propre de modifier gethostbyname() pour envoyer un simple message à un resolveur local et d'attendre la réponse plutôt que d'allouer de la mémoire, ouvrir des fichiers et des sockets, etc… Et comme on ne veut absolument pas que le resolveur local soit en panne, autant le mettre dans systemd :)
Ah bon. Moi je trouve 100 fois plus propre d’écrire nameserver 127.0.0.1 dans /etc/resolv.conf et d’installer un quelconque résolveur DNS standard en écoute sur localhost. Pas besoin ni de modifier gethostbyname, ni d’ajouter une fonction de résolution DNS à un programme dont ce n’est pas le job.
Que systemd se contente de démarrer et monitorer le résolveur DNS, ça c’est son boulot.
en juin 2015, un utilisateur a pu obtenir des certificats SSL pour Github et même après avoir été mis au courant, WoSign n'a pas révoqué automatiquement tous les certificats délivrés à tort
C’est même pire que ça. Ils ont bien pris la peine de chercher les certificats qu’ils avaient émis à tort, en ont trouvé (33 au total, après les ont-ils tous trouvé c’est une autre question), et ont consciemment décidé d’attendre que les titulaires de ces certificats leur demandent de les révoquer.
Some certificates are revoked after getting report from subscriber, but some still valid, if any subscriber think it must be revoked and replaced new one, please contact us in the system, thanks.
« Si vous avez profité d’une faille de notre système pour obtenir frauduleusement un certificat, merci de vous signaler à l’accueil pour demander sa révocation. Merci de votre coopération. »
C’est à se demander s’ils savent à quoi est supposé servir une autorité de certification…
Mozilla ne considérera plus les audits de la branche Hong Kong de Ernst & Young comme valables (ce qui n'est pas anodin, Ernst & Young étant parmi les plus grosses boîtes d'audit du monde).
Ne pas se lancer dans une diatribe sur la merditude complète de ce système de CA pourries et de pseudo-audits remplis de phrases toutes faites qui ne prouvent rien… Surtout ne pas se lancer… ne pas se lancer…
Pfiou, heureusement que c’est l’heure d’aller manger, sinon je me serais lancé.
Sauf erreur de ma part (IANAL, tout ça…), la règle générale est donnée par l’article L611-7 du code de la propriété intellectuelle. En gros :
si développer un logiciel fait partie intégrante de ton travail, c’est l’employeur qui possède les droits sur le logiciel ;
dans le cas contraire, si le développement ne fait pas partie de tes activités habituelles (ce qui a priori est ton cas : ton travail en tant que prof est d’enseigner, pas de développer), le logiciel t’appartient, sauf si tu l’as développé dans le cadre de tes fonctions (ce qui a priori est ton cas si on t’a demandé de le faire), auquel cas l’employeur peut éventuellement se l’approprier.
Les règles précises applicables à ton cas doivent être cherchées dans les conventions collectives, les accords d’entreprises, et en définitive le contrat de travail.
Mon Dieu la quantité de désinformation dans ce message ><
DNSSec impose un roulement régulier de ta clef de signature.
C’est recommandé mais en aucun cas imposé. La seule chose qui est réellement imposé est le renouvellement des signatures elles-mêmes, qui ne sont valides que pour un intervalle de temps donné.
la signature de zone, renouvelée toutes les 2h
la ZSK, renouvelé tous les 90j, qui signe ta zone DNS
la KSK, renouvelé 1× par an
PERSONNE ne t’impose ces délais de renouvellement. Tu les choisis, toi et toi seul.
Le RFC 6781 donne à titre indicatif, pour la durée de validité des signatures, une plage allant de « quelques jours » à « plusieurs mois ».
Ces clefs ne doivent absolument pas sortir de ton parc et sont extrêmement critiques. Il est donc impossible de mettre ça sur ton serveur DNS primaire, qui est en DMZ et exposé sur le net, donc potentiellement attaquable.
Encore une fois, tu t’imposes ça. Il y a d’autres possibilités, par exemple opter pour un compromis avec une ZSK disponible sur le serveur primaire (via un HSM plutôt que directement sur le serveur pour ceux qui ont les moyens) pour re-signer périodiquement la zone, seule la KSK restant hors-ligne.
C’est d’ailleurs la principale raison d’avoir une ZSK et une KSK séparées (non, ça non plus ce n’est pas « imposé » par DNSSEC). Si tu les considères toutes les deux comme également critiques, devant absolument être hors ligne, autant se simplifier la vie et se contenter d’une seule clef.
Le problème avec LE, c’est que ton frontal web va du coup se mettre à renouveller des certificats (peu importe la sécurité du token ou de la clef du certificat ici), et que le changement de ces certificats nécessitent de mettre à jour les entrées TLSA de ton DNS.
Seulement si tu choisis ① d’épingler les certificats plutôt que les clefs publiques (j’ai déjà dit plus haut que ça n’apportait rien dans le cas où tu épingles au niveau terminal, et que c’est déconseillé par le RFC 7671) et ② de renouveller les clefs à chaque renouvellement de certificat, ce que RIEN NE T’OBLIGE À FAIRE (je ne suis pas le seul à te l’avoir dit, et ne viens pas dire « ouais mais c’est pas le comportement par défaut des clients », quand on monte des usine à gaz comme tu sembles aimer le faire, gérer soi-même les CSR avec un client ACME n’est pas hors de portée).
NB: Pour les taquins qui signaleraient que DNSSec impose des rollovers de 2h alors que LE en impose des de 90j, le choix des 2h est une obligation technique et non un choix arbitraire.
Si, ton choix des 2h est une obligation totalement arbitraire que tu t’imposes à toi-même.
DNS est basé sur UDP.
Pour information, DNS fonctionne aussi bien sur UDP que sur TCP (seuls les administrateurs restés bloqués dans les années 90 continuent à croire que le DNS ne passe que sur UDP), et l’utilisation de TCP est même de plus en plus fréquente (en partie à cause/grâce à DNSSEC justement, qui augmente considérablement la taille des réponses).
et ne peut donc pas envoyer de paquets de plus de 548 octets
D’une, TCP existe (cf. ci-dessus), et de deux, même en UDP, EDNS(0) permet de spécifier des tailles de paquets supérieures.
donc DNSSec est obligé d’utiliser des tailles de clefs volontairement faibles (1024 bits et moins)
En général, on est plutôt sur du 2048-bit pour les KSK et 1024-bit pour les ZSK — et encore, la tendance est à la généralisation du 2048-bit même pour la ZSK (par exemple, la nouvelle ZSK 2048-bit de la racine vient d’être pré-publiée, et devrait bientôt entrer en service).
On a bien compris que tu n’aimais pas Let’s Encrypt. On t’oblige à l’utiliser alors que ce n’est pas compatible avec les choix arbitraires que tu as fait (et qui sont les seuls bons choix possibles, évidemment — quiconque ne fait pas les mêmes choix que toi est un inconscient qui n’y connais rien en sécurité, non mais c’est qui le crypto-terroriste ici ?), donc c’est le Mal.
C’est bon, on a compris, plus la peine de raconter n’importe quoi pour faire passer le message. ><
Et oui, je parlais aussi de moi. Malheureusement, Let’s Encrypt reste la seule solution viable pour les non-pro (je n’ai pas 400 boules par an à claquer dans un certificat, surtout quand je gère au moins une 10aine de domaine et une 100aine de certificats)
Donc tu es bien content de trouver Let’s Encrypt pour économiser 400 boules par an, mais parce que ça ne correspond pas exactement à tes besoins, tu ne rates pas la moindre occasion de cracher ta haine sur ce projet qui te pourrit la vie.
Plus haut tu dis carrément qu’il faut « taper sur Let’s Encrypt » pour avoir ce qu’il te faut (gratuitement bien sûr — payer pour un service, non mais et puis quoi encore)…
Hé ho, tu sais quand même que Let’s Encrypt ne te doit rien du tout, Môssieur le crypto-terroriste individuel auto-radicalisé qui monte des usine-à-gaz mais qui trouve openssl req trop compliqué à utiliser ?
OK, donc quand tu te plaignais de ces gens qui montent des usines à gaz pour utiliser Let’s Encrypt sans comprendre que ce n’est pas adapté à du large scale… tu parlais de toi en fait ?
D’ailleurs ton exemple est erroné puisque le CN devrait être identique à au moins un des SAN indiqués, généralement même le 1er.
NON. Ça c’est pour la compatibilité avec de très vieux clients qui ne connaissent rien d’autre que le CN et qui ne tiennent pas compte des SAN. L’utilisation du champ CN pour identifier le serveur est deprecated (cf RFC 6125).
(Et de toute façon dans le cas d’une CSR destinée à Let’s Encrypt peu importe, puisque la CA ignore complètement le CN fourni dans la requête. Le CN présent dans mon fichier de config est un reliquat de l’époque où je signais moi-même mes certificats.)
Et il te manque aussi la gestion des paramètres d’utilisation de la clef (avec sa compatibilité Netscape).
Ça c’est l’autorité de certification qui les ajoute au moment de signer la requête. (Tu peux les mettre d’emblée dans la requête si tu veux mais je ne connais aucune CA qui accepte de recopier bêtement les extensions de la requête dans le certificat final.)
DANE-TA/EE n’est encore implémenté nul part malheureusement :'(
Mais TLSA, si tu pin sur le certificat, permet de s’affranchir des CA moisies, vu que si un faux certificat est émis (y compris par ta CA), il ne validera pas TLSA.
Faudrait savoir, en quoi TLSA permet de s’affranchir des CA moisies si ce n’est « implémenté nulle part » ?
(Au passage, c’est faux. Il y a des implémentations de DANE fonctionnelles, même si aucun navigateur ne les intègre par défaut. Et Victor Dukhovni, qui a implémenté DANE dans Postfix, travaillait aux dernières nouvelles à ajouter le support de DANE directement dans OpenSSL, où ça pourra bénéficier à pléthore d’applications.)
Un pin sur ta clef ne te protège plus d’une compromission de ladite clef
Un pin sur le certificat ne te protège pas davantage contre ce cas, celui qui a mis la main sur ta clef pourra potentiellement s’en servir tant que la signature de l’enregistrement TLSA n’aura pas expirée.
Et il est plus facile pour un humain de valider l’empreinte du certificat (dispo nativement et facilement dans les détails du certificat de ton navigateur) que celle de la clef associée (beaucoup plus difficile d’accès).
Ah ouais quand même. Donc c’est trop dur pour un administrateur système d’invoquer openssl req correctement, par contre tu attends d’un simple utilisateur qu’il compare lui-même, manuellement, l’empreinte du certificat telle que présentée par le navigateur avec celle qu’il sera aller chercher dans le DNS.
Je te laisse mettre ici la ligne de commande openssl pour générer un CSR multi-domaine avec SAN et extensions X.509 corrects. On va rigoler…
Ça a l’intérêt de justement dégager la notion de CA
Quoi, le fait d’épingler le certificat entier ? Pas du tout, ça ne sert à rien. Le principe de l’enregistrement DANE-EE est justement que seule la clef publique du certificat compte, toutes les autres informations portées par le certificat doivent être ignorées et remplacées par les informations fournies par l’enregistrement TLSA lui-même (le nom de l’enregistrement donne le nom du serveur, et la durée de validité de la signature DNSSEC associée donne la durée de validité de la clef épinglée). Dans ces conditions, épingler le certificat n’apporte rien de plus qu’épingler la clef publique.
Dit autrement, c’est le principe même de l’enregistrement DANE-EE qui permet(trait) de dégager la notion de CA, pas le fait d’épingler le certificat au lieu de la clef publique.
Donc de désactiver la gestion de la clef par LE :P
Encore une fois, je n’ai pas dit autre chose.
Et je rappelle à toute fin utile que la décision de changer de clef à chaque renouvellement n’est pas une décision de l’autorité de certification Let’s Encrypt. C’est une décision purement locale qui est du seul ressors du client, Let’s Encrypt n’impose rien du tout sur ce point.
Je veux dire par là que ton serveur de renouvellement, nécessairement en DMZ par design (ACME challenge) va devoir modifier les entrées TLSA.
Pas si tu épingles la clef publique et que tu ne changes pas de clef à chaque renouvellement — ce que tu es parfaitement libre de faire.
Donc comprendre comment la générer proprement (SAN, SHA-2…), faire la danse de la pluie et sacrifier 2 caisses de poulets lors de l’invocation openssl correspondante…
Tu dois toujours avoir un épinglage d’avance : si tu utilises actuellement la clef N, tu dois publier l’épinglage N et N+1.
Voire même N (clef actuellement en service, sur le serveur), N+1 (future clef, à l’abri hors-ligne), et clef de secours (stockée dans une grotte gardée par des orques, d’où tu ne la sors qu’en cas de pépin).
Le 1er point fait que tu dois avoir une clef prête à l’avance que tu peux déjà publier dans ton épinglage et que tu utiliseras pour la génération de certificat suivante. Très complexe avec la plupart des clients Let’s Encrypt
Je ne peux pas parler pour tous les clients, mais je réfute que ce soit « très complexe » avec le client Certbot. Il suffit de générer soi-même la clef et la requête de certificat (ce que tu devais faire de toute façon avec une CA plus traditionnelle), et d’utiliser l’option --csr de Certbot.
et ça demande dans tous les cas une bonne maîtrise de X.509
Pas plus que pour travailler avec une CA traditionnelle — avec laquelle tu dois déjà générer toi-même la CSR (si tu utilises une CA qui te génère la clef pour toi et te la donne en même temps que le certificat, euh comment dire…)
Et donc se passer totalement du renouvelement de la clef de Let’s Encrypt :)
Complètement d’accord là-dessus, je n’ai d’ailleurs pas dit autre chose, que ce soit dans ma réponse ci-dessus ou dans mon dernier journal sur Let’s Encrypt.
donc que la phase de renouvelement du certificat ou de la clef devrait impliquer le renouvelement des entrées DNS correspondantes…
Le renouvellement du certificat (pas de la clef) n’implique le renouvellement des enregistrements TLSA que si tu épingles le certificat lui-même (selector à 0) au lieu de la clef publique (selector à 1)… ce qui est déconseillé (même si pas très fortement) par le RFC 7671 : dans le cas où tu épingles au niveau terminal (DANE-EE au lieu de DANE-TA), il est conseillé d’épingler la clef publique plutôt que le certificat entier. (Et si tu épingles à un niveau intermédiaire, la question des renouvellements échappe totalement à ton contrôle de toute façon.)
donc votre serveur web ayant un contrôle root sur votre zone DNSSec…
Pas nécessairement. Mon serveur n’a pas les clefs de signature de ma zone DNS.
pour revenir sur les 90 jours de validité, il me semble avoir lu sur le site d'aeris que s'était incompatible avec HSTS.
Non. La durée de validité du certificat n’a aucun impact sur HSTS. HSTS dit juste « ce site ne doit être accédé qu’à travers une connexion HTTPS », sans aucune référence au certificat.
Là où la durée de validité peut poser problème, c’est avec HPKP, où l’on épingle la clef publique du certificat dans un en-tête HTTP. Avec HPKP, il devient nécessaire d’anticiper le changement de clef afin de pouvoir publier à l’avance la nouvelle clef (sinon on « casse l’épingle », empêchant ceux qui avaient déjà visité le site de revenir tant que la période d’épinglage n’est pas passée).
À ma connaissance, la plupart des clients ACME ne sont pas compatibles avec HPKP, du moins par défaut. En effet, ils génèrent une nouvelle clef à chaque renouvellement de certificat, sans laisser la possibilité de pré-publier la future clef dans les en-têtes HPKP.
Néanmoins, il est toujours possible de générer soi-même à l’avance la future clef, et donc de prendre en charge la pré-publication des épingles.
Évidemment, le risque de mauvaise manipulation (publication d’une mauvaise épingle ?) n’est pas négligeable… ce qui est un argument supplémentaire en faveur de l’automatisation. Encore une fois, si tu ne fais ça qu’une fois tous les trois ans, tu n’es pas incité à avoir une procédure robuste.
(Et j’ai personnellement l’impression que pas mal d’administrateurs en herbe voudraient des certificats valables trois ans précisément pour ne pas avoir à « se prendre la tête » avec ça trop souvent, ce qui veut bien dire que c’est quelque chose de trop pénible et/ou difficile pour eux… Mais dans ce cas, augmenter la validité du certificat pour avoir à le renouveler moins souvent n’est qu’une façon de balayer la poussière sous le tapis… ça donne un peu de tranquillité sur le coup mais le problème n’a pas disparu pour autant.)
[^] # Re: Ce ne sont pas forcément les "gros" qui posent problème…
Posté par gouttegd . En réponse au message Mails considérés comme spam par gmail : config, spf, mime, ipv4/v6 ? . Évalué à 3. Dernière modification le 14 octobre 2016 à 14:42.
Non, ça pénalise ceux qui, compétents ou non, récupèrent une adresse IP dont le précédent utilisateur était incompétent ou spammeur, et qui se retrouve dans une blacklist :
(Au passage, il s’agit de violations flagrantes du RFC 6471, qui donne les « bonnes pratiques » que les opérateurs de DNSBL devraient respecter.)
Et je ne parle même pas du cas des DNSBL qui n’hésitent pas à blacklister un /24 entier juste parce qu’une adresse dans le bloc a été utilisée par un spammeur. Au diable les dommages collatéraux, après tout le spam c’est une guerre.
Ah oui, et puis il y a aussi ceux qui blacklistent les adresses que les FAI allouent à leurs abonnés. Rien à foutre de l’auto-hébergement, on est en guerre que je vous dis.
Bref, ça n’a rien à voir avec la compétence de l’administrateur du serveur. Au contraire, si tu rejettes un serveur sur la seule base de la présence de son adresse dans une blacklist, tu dis clairement que tu te moques éperdument des compétences de l’administrateur : peu importe que sa configuration soit irréprochable, que SPF, DKIM et DMARC soient parfaitement mis en œuvre, que tous les RFC relatifs au courrier électronique soient respectés… l’adresse a le malheur d’être blacklistée, c’est tout ce qui compte pour toi.
Si tu voulais pénaliser les « incompétents », nul besoin de blacklist : rejettes ceux dont le serveur est mal configuré (par exemple ceux qui annoncent dans le HELO un nom d’hôte inexistant dans la zone DNS, comme c’est précisément le cas de l’auteur du message initial) et ne respecte pas les RFC.
Libre à toi de penser que quelqu’un dont l’adresse est blacklistée est un incompétent. Pour ma part, je pense qu’un administrateur qui pense avoir fait son travail de lutte contre le spam en ayant délégué cette tâche à une DNSBL est un incompétent à qui on n’aurait jamais du confier l’administration d’un serveur mail.
[^] # Re: mail-tester
Posté par gouttegd . En réponse au message Mails considérés comme spam par gmail : config, spf, mime, ipv4/v6 ? . Évalué à 4.
C’est ça. Le même nom que celui annoncé par Postfix (une fois que tu l’auras configuré en ce sens).
[^] # Re: mail-tester
Posté par gouttegd . En réponse au message Mails considérés comme spam par gmail : config, spf, mime, ipv4/v6 ? . Évalué à 4.
C’est auprès de ton hébergeur DNS (1 and 1 apparemment) que ça se gère, pas sur ton serveur.
Ce qui compte est que le nom d’hôte (celui annoncé par Postfix dans le HELO) corresponde à un nom publié dans le DNS et associé à une IP.
En l’état, ta machine s’annonce comme
freecadfrance.freecad-france.com, mais ce nom n’existe pas dans ta zone DNS. L’adresse IP est directement associée au domainefreecad-france.com.De deux choses l’une : ou bien tu configures Postfix pour s’annoncer comme
freecad-france.com(optionmyhostname), ou bien tu ajoutes un A (et un AAAA, puisque tu sembles avoir une connectivité IPv6) dans ta zone DNS pour le nomfreecadfrance.freecad-france.com.Ici, le récepteur tente un Foward-Confirmed Reverse DNS : il cherche le nom associé à l’adresse IP de ta machine (reverse DNS), puis il cherche à résoudre ce nom pour vérifier qu’il retombe bien sur l’IP de ta machine (forward confirmation).
Dans ton cas, ça donne ça :
« Idéalement » (entre guillemets parce que l’intérêt du FCrDNS dans la lutte contre le spam est discutable), il faudrait que le reverse DNS renvoie le nom de ta machine (
freecad-france.com).Le problème, c’est que le reverse DNS dépend entièrement de ton hébergeur. Certains permettent de le modifier à sa guise, d’autres non.
[^] # Re: Ce ne sont pas forcément les "gros" qui posent problème…
Posté par gouttegd . En réponse au message Mails considérés comme spam par gmail : config, spf, mime, ipv4/v6 ? . Évalué à 5.
Tu n’es pas forcément obligé de le faire. Avec un peu de chance, l’adresse de ton serveur est « propre », et sera acceptée par les serveurs de live.com sans action de ta part.
C’est seulement si l’adresse a une mauvaise réputation (parce qu’elle a précédemment été utilisée par des spammeurs, généralement) que tu peux avoir besoin de la faire blanchir. Dans ce cas, les serveurs de live.com t’en informeront lorsque tu tenteras (toi ou un de tes utilisateurs, si tu n’es pas le seul à utiliser ton serveur) de contacter un utilisateur de live.com (du coup, si tu as une connaissance avec un compte live.com tu peux tenter de lui envoyer un message et voir si « ça passe »).
Indépendamment de Live.com, tu peux aussi évaluer la réputation générale de ton adresse IP en vérifiant sa présence dans les principales blacklists.
# Ce ne sont pas forcément les "gros" qui posent problème…
Posté par gouttegd . En réponse au message Mails considérés comme spam par gmail : config, spf, mime, ipv4/v6 ? . Évalué à 2.
D’expérience, avec un enregistrement SPF correct et des mails sortants signés par DKIM, je n’ai pas eu de problèmes ni avec GMail, ni avec Yahoo.
Dans le cas de Microsoft (Live.com, feu Hotmail), ni SPF ni DKIM n’ont été suffisants, il a fallu que je demande explicitement à blanchir l’adresse IP de mon serveur via leur service Smart Network Data Service.
Oui, ça pue, mais je reconnais au moins à Microsoft qu’ils offrent quand la même la possibilité de blanchir une adresse simplement en en faisant la demande. Je ne peux pas en dire autant d’autres fournisseurs (plus modestes comparés aux gros poissons que sont GMail/Yahoo/Live) qui rejettent des serveurs sur la base de DNS blacklists arbitraires d’où il est quasiment impossible, pour certaines, de faire retirer une adresse.
[^] # Re: comprendre le but du SPF
Posté par gouttegd . En réponse au message Mails considérés comme spam par gmail : config, spf, mime, ipv4/v6 ? . Évalué à 4.
J’ajouterai que dans le cas présent, le
aet lemxsont inutiles, et alourdissent la tâche du validateur SPF. Après avoir demandé et obtenu l’enregistrement SPF, il doit à présent demander les enregistrements A et MX, puis les enregistrements A correspondants au MX, afin d’avoir la liste complète des adresses contre lesquelles vérifier l’adresse de l’émetteur.Pour une installation simple, mono-serveur, autant spécifier directement et uniquement les adresses IP (v4 et v6) du serveur via les champs
ip4etip6, et éviter ainsi toute indirection :(Et si tu es sûr — vraiment sûr — de ne jamais envoyer de mail via une autre machine, remplacer le
~allpar-allpour informer les serveurs tiers qu’ils ne doivent pas hésiter à rejeter purement et simplement tout message venant d’ailleurs.)[^] # Re: Sources signées
Posté par gouttegd . En réponse au journal Comment distribuer un logiciel pour GNU/Linux ?. Évalué à 6.
L’intérêt des sources signées, c’est que ça permet au moins de vérifier que la release n provient bien de la même personne que la release n−1 (puisqu’elle est signée avec la même clef).
Certes, je ne peux pas pour autant vérifier que ces releases viennent bien de toi (à moins d’avoir pu vérifier ta clef via un canal séparé, comme la toile de confiance), mais rien qu’avoir l’assurance que c’est bien le même développeur derrière chaque release est déjà appréciable (et à vrai dire ça me paraît plus important que de savoir qui est ce développeur et est-ce qu’il s’appelle vraiment François Mazen).
[^] # Re: Ne te prend pas la tête
Posté par gouttegd . En réponse au journal Comment distribuer un logiciel pour GNU/Linux ?. Évalué à 5.
J’ai cité .tar.gz parce que c’est le premier qui me vient à l’esprit, mais ça peut être du .tar.gz, du .tar.bz2, du .tar.xz, peu importe.
[^] # Re: Ne te prend pas la tête
Posté par gouttegd . En réponse au journal Comment distribuer un logiciel pour GNU/Linux ?. Évalué à 10.
J’oubliais :
.desktoppour l’intégration du programme dans les menus de l’environnement de bureau ; certains empaqueteurs prennent le temps d’écrire eux-même un tel fichier quand le développeur upstream ne le fournit pas, mais autant leur mâcher le travail.[^] # Re: Ne te prend pas la tête
Posté par gouttegd . En réponse au journal Comment distribuer un logiciel pour GNU/Linux ?. Évalué à 10.
J’abonde en ce sens. Et j’ajouterais, pêle-mêle :
vst-preset-generator-X.Y.Z.tar.gz) ;READMEou dans un fichier annexe genreINSTALL,HOWTO_BUILDou assimilé), et non pas uniquement sur le site web du projet ;src/how_to_compile.txt) ;README.PACKAGERSou assimilé.[^] # Re: Quoi d’intéressant?
Posté par gouttegd . En réponse au journal [Bookrmark] How to troll systemd in one blog post. Évalué à 10. Dernière modification le 30 septembre 2016 à 12:11.
Si tu as un problème avec un programme qui utilise « encore-un-autre-format-de-timestamp », c’est que c’est un programme qui ne passe pas par syslog pour écrire ses logs (s’il passait par syslog, il utiliserait automatiquement le même format que tous les autres programmes utilisant syslog).
La question est : pourquoi un programme qui a son propre système de log se mettrait subitement, en présence de systemd, à renoncer à son propre système et à se mettre à juste écrire sur la sortie standard ?
Le problème posé par un tel programme vient entièrement du fait qu’il n’utilise pas le démon journalisateur du système,¹ peu importe que le démon en question soit syslog ou journald. Conséquemment, journald ne changera rien à l’histoire, tu devras toujours te dépatouiller avec les journaux de ce programme avec cet-autre-format-de-timestamp.
Je sais que c’est difficile à croire, mais non, systemd ne résoud pas automagiquement tous les problèmes (et il ne fait pas revenir l’être aimé non plus).
¹ Il peut y avoir de bonnes raisons à ça, là n’est pas la question.
[^] # Re: Quoi d’intéressant?
Posté par gouttegd . En réponse au journal [Bookrmark] How to troll systemd in one blog post. Évalué à 10. Dernière modification le 29 septembre 2016 à 20:45.
Déjà, si le développeur utilise
gethostbyname, le premier problème est qu’il a au moins quinze ans de retard. Cette fonction était déjà deprecated à la sortie de POSIX.1-2001.Ah bon. Moi je trouve 100 fois plus propre d’écrire
nameserver 127.0.0.1dans/etc/resolv.confet d’installer un quelconque résolveur DNS standard en écoute sur localhost. Pas besoin ni de modifiergethostbyname, ni d’ajouter une fonction de résolution DNS à un programme dont ce n’est pas le job.Que systemd se contente de démarrer et monitorer le résolveur DNS, ça c’est son boulot.
[^] # Re: A faire une fois dans sa vie
Posté par gouttegd . En réponse à la dépêche Linux From Scratch 7.10 : Vous êtes aux commandes. Évalué à 5.
À une époque c’est ce qu’on disait de la compilation du noyau… Qui le fait encore aujourd’hui — et qui a encore une vraie raison de le faire ?
(Perso c’est presque uniquement par habitude que je continue à compiler moi-même le noyau.)
# Révocation des certificats frauduleux à la demande des fraudeurs
Posté par gouttegd . En réponse au journal Qui traite des autorités SSL WoSign, Startcom et du peu de professionnalisme qui a causé leur perte. Évalué à 10.
C’est même pire que ça. Ils ont bien pris la peine de chercher les certificats qu’ils avaient émis à tort, en ont trouvé (33 au total, après les ont-ils tous trouvé c’est une autre question), et ont consciemment décidé d’attendre que les titulaires de ces certificats leur demandent de les révoquer.
« Si vous avez profité d’une faille de notre système pour obtenir frauduleusement un certificat, merci de vous signaler à l’accueil pour demander sa révocation. Merci de votre coopération. »
C’est à se demander s’ils savent à quoi est supposé servir une autorité de certification…
Ne pas se lancer dans une diatribe sur la merditude complète de ce système de CA pourries et de pseudo-audits remplis de phrases toutes faites qui ne prouvent rien… Surtout ne pas se lancer… ne pas se lancer…
Pfiou, heureusement que c’est l’heure d’aller manger, sinon je me serais lancé.
[^] # Re: certificat gratuit, quelques oublis dans ta liste
Posté par gouttegd . En réponse au journal Qui traite des autorités SSL WoSign, Startcom et du peu de professionnalisme qui a causé leur perte. Évalué à 6. Dernière modification le 28 septembre 2016 à 11:10.
C’est vrai, ça fait déjà une semaine qu’elle est sortie, je suis à la bourre. ;)
Edit: Rah zut, carbonisé. ><
[^] # Re: certificat gratuit, quelques oublis dans ta liste
Posté par gouttegd . En réponse au journal Qui traite des autorités SSL WoSign, Startcom et du peu de professionnalisme qui a causé leur perte. Évalué à 3.
Pour information, quelle version de Firefox ?
Chez-moi-ça-marche™ avec Firefox 45.4.0 et WebKit je.sais.plus.combien.
Apparemment les certificats signés avec SHA-512 sont déjà connus pour avoir posé quelques problèmes, et chez Mozilla la question s’est posée de ne pas les supporter.
[^] # Re: Hello
Posté par gouttegd . En réponse au message Qui est l'éditeur de mon logiciel ?. Évalué à 5. Dernière modification le 27 septembre 2016 à 12:03.
Sauf erreur de ma part (IANAL, tout ça…), la règle générale est donnée par l’article L611-7 du code de la propriété intellectuelle. En gros :
Les règles précises applicables à ton cas doivent être cherchées dans les conventions collectives, les accords d’entreprises, et en définitive le contrat de travail.
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par gouttegd . En réponse au message Let's Encrypt en prod en entreprise. Évalué à 7.
Mon Dieu la quantité de désinformation dans ce message ><
C’est recommandé mais en aucun cas imposé. La seule chose qui est réellement imposé est le renouvellement des signatures elles-mêmes, qui ne sont valides que pour un intervalle de temps donné.
PERSONNE ne t’impose ces délais de renouvellement. Tu les choisis, toi et toi seul.
Le RFC 6781 donne à titre indicatif, pour la durée de validité des signatures, une plage allant de « quelques jours » à « plusieurs mois ».
Encore une fois, tu t’imposes ça. Il y a d’autres possibilités, par exemple opter pour un compromis avec une ZSK disponible sur le serveur primaire (via un HSM plutôt que directement sur le serveur pour ceux qui ont les moyens) pour re-signer périodiquement la zone, seule la KSK restant hors-ligne.
C’est d’ailleurs la principale raison d’avoir une ZSK et une KSK séparées (non, ça non plus ce n’est pas « imposé » par DNSSEC). Si tu les considères toutes les deux comme également critiques, devant absolument être hors ligne, autant se simplifier la vie et se contenter d’une seule clef.
Seulement si tu choisis ① d’épingler les certificats plutôt que les clefs publiques (j’ai déjà dit plus haut que ça n’apportait rien dans le cas où tu épingles au niveau terminal, et que c’est déconseillé par le RFC 7671) et ② de renouveller les clefs à chaque renouvellement de certificat, ce que RIEN NE T’OBLIGE À FAIRE (je ne suis pas le seul à te l’avoir dit, et ne viens pas dire « ouais mais c’est pas le comportement par défaut des clients », quand on monte des usine à gaz comme tu sembles aimer le faire, gérer soi-même les CSR avec un client ACME n’est pas hors de portée).
Si, ton choix des 2h est une obligation totalement arbitraire que tu t’imposes à toi-même.
Pour information, DNS fonctionne aussi bien sur UDP que sur TCP (seuls les administrateurs restés bloqués dans les années 90 continuent à croire que le DNS ne passe que sur UDP), et l’utilisation de TCP est même de plus en plus fréquente (en partie à cause/grâce à DNSSEC justement, qui augmente considérablement la taille des réponses).
D’une, TCP existe (cf. ci-dessus), et de deux, même en UDP, EDNS(0) permet de spécifier des tailles de paquets supérieures.
En général, on est plutôt sur du 2048-bit pour les KSK et 1024-bit pour les ZSK — et encore, la tendance est à la généralisation du 2048-bit même pour la ZSK (par exemple, la nouvelle ZSK 2048-bit de la racine vient d’être pré-publiée, et devrait bientôt entrer en service).
On a bien compris que tu n’aimais pas Let’s Encrypt. On t’oblige à l’utiliser alors que ce n’est pas compatible avec les choix arbitraires que tu as fait (et qui sont les seuls bons choix possibles, évidemment — quiconque ne fait pas les mêmes choix que toi est un inconscient qui n’y connais rien en sécurité, non mais c’est qui le crypto-terroriste ici ?), donc c’est le Mal.
C’est bon, on a compris, plus la peine de raconter n’importe quoi pour faire passer le message. ><
/plonk
[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par gouttegd . En réponse au message Let's Encrypt en prod en entreprise. Évalué à 7.
Donc tu es bien content de trouver Let’s Encrypt pour économiser 400 boules par an, mais parce que ça ne correspond pas exactement à tes besoins, tu ne rates pas la moindre occasion de cracher ta haine sur ce projet qui te pourrit la vie.
Plus haut tu dis carrément qu’il faut « taper sur Let’s Encrypt » pour avoir ce qu’il te faut (gratuitement bien sûr — payer pour un service, non mais et puis quoi encore)…
Hé ho, tu sais quand même que Let’s Encrypt ne te doit rien du tout, Môssieur le crypto-terroriste individuel auto-radicalisé qui monte des usine-à-gaz mais qui trouve
openssl reqtrop compliqué à utiliser ?[^] # Re: L’automatisation, c’est bon, mangez-en
Posté par gouttegd . En réponse au message Let's Encrypt en prod en entreprise. Évalué à 3.
OK, donc quand tu te plaignais de ces gens qui montent des usines à gaz pour utiliser Let’s Encrypt sans comprendre que ce n’est pas adapté à du large scale… tu parlais de toi en fait ?
[^] # Re: 90 jours, et alors?
Posté par gouttegd . En réponse au message Let's Encrypt en prod en entreprise. Évalué à 3. Dernière modification le 22 septembre 2016 à 15:30.
NON. Ça c’est pour la compatibilité avec de très vieux clients qui ne connaissent rien d’autre que le CN et qui ne tiennent pas compte des SAN. L’utilisation du champ CN pour identifier le serveur est deprecated (cf RFC 6125).
(Et de toute façon dans le cas d’une CSR destinée à Let’s Encrypt peu importe, puisque la CA ignore complètement le CN fourni dans la requête. Le CN présent dans mon fichier de config est un reliquat de l’époque où je signais moi-même mes certificats.)
Ça c’est l’autorité de certification qui les ajoute au moment de signer la requête. (Tu peux les mettre d’emblée dans la requête si tu veux mais je ne connais aucune CA qui accepte de recopier bêtement les extensions de la requête dans le certificat final.)
[^] # Re: 90 jours, et alors?
Posté par gouttegd . En réponse au message Let's Encrypt en prod en entreprise. Évalué à 3.
Faudrait savoir, en quoi TLSA permet de s’affranchir des CA moisies si ce n’est « implémenté nulle part » ?
(Au passage, c’est faux. Il y a des implémentations de DANE fonctionnelles, même si aucun navigateur ne les intègre par défaut. Et Victor Dukhovni, qui a implémenté DANE dans Postfix, travaillait aux dernières nouvelles à ajouter le support de DANE directement dans OpenSSL, où ça pourra bénéficier à pléthore d’applications.)
Un pin sur le certificat ne te protège pas davantage contre ce cas, celui qui a mis la main sur ta clef pourra potentiellement s’en servir tant que la signature de l’enregistrement TLSA n’aura pas expirée.
Ah ouais quand même. Donc c’est trop dur pour un administrateur système d’invoquer
openssl reqcorrectement, par contre tu attends d’un simple utilisateur qu’il compare lui-même, manuellement, l’empreinte du certificat telle que présentée par le navigateur avec celle qu’il sera aller chercher dans le DNS.Avec dans le fichier
req.cfg:Vas-y, rigole dans ton coin. Moi ça fait déjà quelques messages que tu ne me fais plus rire.
[^] # Re: 90 jours, et alors?
Posté par gouttegd . En réponse au message Let's Encrypt en prod en entreprise. Évalué à 3.
Quoi, le fait d’épingler le certificat entier ? Pas du tout, ça ne sert à rien. Le principe de l’enregistrement DANE-EE est justement que seule la clef publique du certificat compte, toutes les autres informations portées par le certificat doivent être ignorées et remplacées par les informations fournies par l’enregistrement TLSA lui-même (le nom de l’enregistrement donne le nom du serveur, et la durée de validité de la signature DNSSEC associée donne la durée de validité de la clef épinglée). Dans ces conditions, épingler le certificat n’apporte rien de plus qu’épingler la clef publique.
Dit autrement, c’est le principe même de l’enregistrement DANE-EE qui permet(trait) de dégager la notion de CA, pas le fait d’épingler le certificat au lieu de la clef publique.
Encore une fois, je n’ai pas dit autre chose.
Et je rappelle à toute fin utile que la décision de changer de clef à chaque renouvellement n’est pas une décision de l’autorité de certification Let’s Encrypt. C’est une décision purement locale qui est du seul ressors du client, Let’s Encrypt n’impose rien du tout sur ce point.
Pas si tu épingles la clef publique et que tu ne changes pas de clef à chaque renouvellement — ce que tu es parfaitement libre de faire.
OK, en fait tu trolles.
Fin de la discussion pour moi.
[^] # Re: 90 jours, et alors?
Posté par gouttegd . En réponse au message Let's Encrypt en prod en entreprise. Évalué à 4.
Voire même N (clef actuellement en service, sur le serveur), N+1 (future clef, à l’abri hors-ligne), et clef de secours (stockée dans une grotte gardée par des orques, d’où tu ne la sors qu’en cas de pépin).
Je ne peux pas parler pour tous les clients, mais je réfute que ce soit « très complexe » avec le client Certbot. Il suffit de générer soi-même la clef et la requête de certificat (ce que tu devais faire de toute façon avec une CA plus traditionnelle), et d’utiliser l’option
--csrde Certbot.Pas plus que pour travailler avec une CA traditionnelle — avec laquelle tu dois déjà générer toi-même la CSR (si tu utilises une CA qui te génère la clef pour toi et te la donne en même temps que le certificat, euh comment dire…)
Complètement d’accord là-dessus, je n’ai d’ailleurs pas dit autre chose, que ce soit dans ma réponse ci-dessus ou dans mon dernier journal sur Let’s Encrypt.
Le renouvellement du certificat (pas de la clef) n’implique le renouvellement des enregistrements TLSA que si tu épingles le certificat lui-même (selector à 0) au lieu de la clef publique (selector à 1)… ce qui est déconseillé (même si pas très fortement) par le RFC 7671 : dans le cas où tu épingles au niveau terminal (DANE-EE au lieu de DANE-TA), il est conseillé d’épingler la clef publique plutôt que le certificat entier. (Et si tu épingles à un niveau intermédiaire, la question des renouvellements échappe totalement à ton contrôle de toute façon.)
Pas nécessairement. Mon serveur n’a pas les clefs de signature de ma zone DNS.
[^] # Re: 90 jours, et alors?
Posté par gouttegd . En réponse au message Let's Encrypt en prod en entreprise. Évalué à 5.
Non. La durée de validité du certificat n’a aucun impact sur HSTS. HSTS dit juste « ce site ne doit être accédé qu’à travers une connexion HTTPS », sans aucune référence au certificat.
Là où la durée de validité peut poser problème, c’est avec HPKP, où l’on épingle la clef publique du certificat dans un en-tête HTTP. Avec HPKP, il devient nécessaire d’anticiper le changement de clef afin de pouvoir publier à l’avance la nouvelle clef (sinon on « casse l’épingle », empêchant ceux qui avaient déjà visité le site de revenir tant que la période d’épinglage n’est pas passée).
À ma connaissance, la plupart des clients ACME ne sont pas compatibles avec HPKP, du moins par défaut. En effet, ils génèrent une nouvelle clef à chaque renouvellement de certificat, sans laisser la possibilité de pré-publier la future clef dans les en-têtes HPKP.
Néanmoins, il est toujours possible de générer soi-même à l’avance la future clef, et donc de prendre en charge la pré-publication des épingles.
Évidemment, le risque de mauvaise manipulation (publication d’une mauvaise épingle ?) n’est pas négligeable… ce qui est un argument supplémentaire en faveur de l’automatisation. Encore une fois, si tu ne fais ça qu’une fois tous les trois ans, tu n’es pas incité à avoir une procédure robuste.
(Et j’ai personnellement l’impression que pas mal d’administrateurs en herbe voudraient des certificats valables trois ans précisément pour ne pas avoir à « se prendre la tête » avec ça trop souvent, ce qui veut bien dire que c’est quelque chose de trop pénible et/ou difficile pour eux… Mais dans ce cas, augmenter la validité du certificat pour avoir à le renouveler moins souvent n’est qu’une façon de balayer la poussière sous le tapis… ça donne un peu de tranquillité sur le coup mais le problème n’a pas disparu pour autant.)