Aujourd’hui, les grandes entreprises et administrations publiques hésitent entre continuer à utiliser des logiciels propriétaires ou basculer vers les Logiciels Libres. Pourtant, la plupart des logiciels libres sont capables de bien traiter les données issues des logiciels propriétaire, et parfois avec une meilleur compatibilité.
C’est alors la barrière de la prise en main qui fait peur, et pourtant...
Les logiciels libres
L’aspect « Logiciel Libre » permet une évolution rapide et une plus grande participation des utilisateurs. Les aides et tutoriels foisonnent sur Internet ou sont directement inclus dans le logiciel lui-même.
Enfin, les concepteurs sont plus proches des utilisateurs, ce qui rend les logiciels libres plus agréable à utiliser et conviviaux.
Grâce à la disponibilité des logiciels libres, vous trouverez facilement des services de support techniques et la licence n’est plus un frein à l’utilisation de ces logiciels par votre personnel.
Notre support technique concerne essentiellement les logiciels libres, que ce soit sous forme de services ponctuels ou de tutoriels.
Ce court RFC
normalise un mécanisme d'authentification lors d'une session
ACME, permettant de
prouver, via TLS et ALPN, qu'on contrôle effectivement
le domaine pour lequel on demande un
certificat.
Le protocole ACME
(RFC 8555) laisse le choix entre plusieurs
mécanismes d'authentification pour répondre aux défis du serveur
ACME « prouvez-moi que vous contrôlez réellement le domaine pour lequel vous me
demandez un certificat ! ». Le RFC 8555 propose un défi fondé sur HTTP
(http-01
), dans sa section 8.3, et un défi
utilisant le DNS
(dns-01
), dans sa section 8.4. Notez que le
défi HTTP est fait en clair, sans HTTPS. Or, outre la sécurité
de TLS,
certains utilisateurs d'ACME auraient bien voulu une solution
purement TLS, notamment pour les cas où la terminaison de TLS et
celle de HTTP sont faites par deux machines différentes (CDN, répartiteurs de charge TLS,
etc.)
D'où le nouveau défi normalisé par ce RFC, tls-alpn-01
. Il
repose sur le mécanisme ALPN, qui avait été normalisé dans le RFC 7301. Déjà mis en œuvre dans des
AC comme Let's
Encrypt, il permet une vérification plus solide. Ce type
de défi figure maintenant dans le
registre des types de défis ACME. Notez qu'il existait déjà
un type utilisant TLS, tls-sni-01 / tls-sni-02
,
mais qui avait des
failles, autorisant un utilisateur d'un serveur TLS à obtenir
des certificats pour d'autres domaines du même
serveur. tls-sni
est aujourd'hui abandonné.
Les détails du mécanisme figurent dans la section 3 de notre
RFC. Le principe est que le serveur ACME se connectera en TLS au
nom de domaine indiqué
en envoyant l'extension ALPN avec le nom d'application
acme-tls/1
et vérifiera dans le
certificat la présence d'un
token, choisi aléatoirement par le serveur ACME,
token que le client ACME avait reçu sur le canal
ACME. (Ce nom d'application, acme-tls/1
est
désormais dans le
registre des applications ALPN.)
Bien sûr, c'est un peu plus compliqué que cela. Par exemple,
comme le client ACME va devenir le
serveur TLS lors du défi, il lui faut un
certificat. La section 3 du RFC explique les
règles auxquelles doit obéir ce certificat :
- Auto-signé, puisqu'on n'est pas encore authentifié auprès de
l'AC,
- Un
subjectAlternativeName
(RFC 5280) qui a comme valeur le nom de domaine à
valider,
- Une extension
acmeIdentifier
(mise dans
le
registre des extensions aux certificats PKIX), qui doit
être marquée comme critique, pour éviter que des clients TLS
passant par là et n'ayant rien à voir avec ACME s'en servent, et
dont la valeur est l'autorisation ACME (RFC 8555, section 8.1).
Le client ACME doit ensuite configurer ce qu'il faut sur son serveur
TLS pour que ce soit ce certificat qui soit retourné lors d'une
connexion TLS où le SNI vaut le domaine à valider et où ALPN
vaut
acme-tls/1
. Il annonce alors au serveur
ACME qu'il est prêt à répondre au défi. Le serveur ACME se connecte
au serveur TLS (créé par le client ACME) et fait les vérifications
nécessaires (nom de domaine dans le certificat, nom qui doit être un
A-label, donc en Punycode,
et extension du certificat
acmeIdentifier
contenant la valeur indiquée par le serveur ACME lors du défi).
Une fois la vérification faite, le serveur ACME raccroche : ces
certificats ne sont pas conçus pour échanger de vraies données sur
la session TLS créée. D'ailleurs, les certificats auto-signés créés
pour le type de défi tls-alpn-01
ne permettent
pas d'authentification au sens du RFC 5280. Pour la même raison, le client TLS (créé par le
serveur ACME) n'est pas obligé d'aller jusqu'au bout de
l'établissement de la
session TLS.
La section 5 de notre RFC fait le point sur quelques suppositions
faites au sujet de la mise en œuvre de TLS, suppositions importantes
pour ACME. D'abord, si plusieurs organisations ou personnes
partagent la même adresse IP, ce qui est
courant en cas d'hébergement plus ou moins mutualisé, ACME compte
bien que leurs configurations TLS soient séparées, pour éviter
qu'une de ces entités puisse obtenir un certificat pour une autre,
hébergée au même endroit (cf. annexe A du RFC, qui décrit le
comportement surprenant de certains hébergeurs.) ACME espère
également que les serveurs TLS vont respecter le RFC 7301 en rejetant l'application
acme-tls/1
s'ils ne la connaissent
pas. (Certains programmeurs paresseux ont peut-être fait en sorte
que le serveur TLS accepte n'importe quelle application signalée en
ALPN.)
L'AC Let's Encrypt
accepte
déjà ce type de défi depuis juillet 2018. (Le RFC est en retard par
rapport au déploiement effectif.) Le client ACME dehydrated permet d'utiliser
le nouveau type de défi. Cet
article utilise nginx côté serveur,
avec son module SSL PreRead, qui permet
d'aiguiller une requête en fonction de l'ALPN, mais,
personnellement, je n'ai pas réussi (ça peut être un problème avec
la gestion des modules dans le paquetage
Debian de nginx, gestion quasiment pas
documentée.)
Côté serveur, on a aussi ce qu'il faut dans Apache, avec le module
mod_md
(cf. plus précisement ce point
de la documentation.)
Côté client ACME, d'autres clients gèrent ce type de défi, mais
pas encore certbot (cf. le ticket #6724
.)
RFC 9562: Universally Unique IDentifiers (UUIDs)
- 12 mai -
Ce RFC normalise les UUID, une famille d'identificateurs uniques, obtenus sans registre central. Il remplace l'ancienne norme, le RFC 4122, avec (...)
RFC 9490: Report from the IAB Workshop on Management Techniques in Encrypted Networks (M-TEN)
- 9 mai -
Aujourd'hui, l'essentiel du trafic sur l'Internet est chiffré, et pour d'excellentes raisons. Pas question de revenir là-dessus, mais, ceci dit, il (...)
RFC 9557: Date and Time on the Internet: Timestamps with Additional Information
- 29 avril -
Ce RFC modifie légèrement le format des estampilles temporelles du RFC 3339, changeant à la marge une définition et, surtout, permettant d'y attacher (...)
RFC 9567: DNS Error Reporting
- 27 avril -
Lorsqu'un résolveur DNS détecte un problème avec une zone, l'empêchant de résoudre les noms dans cette zone, il n'avait pas de moyen simple et (...)
RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)
- 8 avril -
Ces deux nouveaux types d'enregistrement DNS, SVCB et sa variante HTTPS, permettent de donner des informations supplémentaires à un client réseau (...)