Let’s Encrypt : un CA gratuit à suivre

https://letsencrypt.org/ est soutenu par Netscape, l'EFF, Akamai, Cisco... et fournit par l'Internet Security Research Group (ISRG).

Pour Apache et Nginx, il faut un accès en ligne de commande pour le configurer.
Gratuit, il est annoncé comme plus simple à configurer et devrait fonctionner sur tous les clients (depuis le partenariat avec IdenTrust).

Leur FAQ annonce pour le moment cette date : 16 novembre 2015 pour l'ouverture générale (pour l'instant, ils sont en phase de test, et l'on obtient des certificats de tests, qui ne seront pas forcemmment compatibles avec bp de navigateurs car non signés par un CA reconnu).

La FAQ indique de plus:
Ces certificats seront des certificats standard de validation de domaine, donc utilisable par tout serveur qui possède un nom de domaine.
Ils prévoient par la suite la création de certificats pour encrypter les emails et signer du code (mais aucune date n'est encore annoncée).
Pas de certificats de type wildcard (ie pour *.example.com). Mais on peux avoir un certificat pour divers domaines, avec le mécanisme SAN (Subject Alternative Name).

Cf (de février 2016) : http://linuxfr.org/users/gouttegd/journaux/reparlons-de-let-s-encrypt

le principe de fonctionnement (X.509 pour TLS)

Source : https://letsencrypt.org/howitworks/

Un client (nommé certificate management agent) tourne sur le serveur et automatise un certain nombre de taches:

1. cet agent montre au CA que ce serveur web contole bien un domaine
2. cet agent gère les requetes, renouvellement et la révocation des certificats pour le domaine.

A cette date, le client ne tourne que sur Linux et BSD (testé sur Ubuntu LTS). La version pour windows utilisera bien sur PowerShell.

1. validation du domaine

La clef publique est utilisée pour que Let’s Encrypt identifie l'administrateur du serveur. Au 1er contact (entre cet agent et Let’s Encrypt) l'agent génère une nouvelle paire de clefs et montre au CA de Let’s Encrypt que le serveur gère le(s) domaine(s).

L'agent demande au CA comment va se faire la validation, et le CA va lui proposer en retour:

• une ou diverses solutions (via DNS ou via une URL) +
• l'annonce que l'agent doit s'authentifier avec sa paire de clefs privées.

L'agent se charge alors de résoudre l'une des solutions de validation proposée par le CA. Par ex, si l'agent peut utiliser la seconde solution proposée, il va créer un fichier avec le chemin requis, ici https://example.com/8303.
De plus, l'agent signe l'annonce envoyée par le CA avec sa clef privée. Une fois qu'il a fait ces deux taches, il contacte le CA pour lui indiquer qu'il est pret à terminer la validation.

Le CA vérifie alors le processus: il vérifie la signature de l'annonce, télécharge le fichier requis et en vérifie le contenu:

Si la signature de l'annonce est valide et que le contenu du fichier est ok, alors l'agent, identifié par la clef publique, est autorisé à gérer le certificat pour le domaine.

2. Emission et révocation du certificat

Une fois que l'agent a une paire de clefs autorisées, il va gérer automatiquement CSR, renouvellement et révocation des certificats, en envoyant des messages de gestion de certificat et en les signant avec la paire de clef autorisées.

gestion CSR (Certificate Signing Request)

Pour obtenir un certificat pour le domaine, l'agent crée une CSR (selon PKCS#10 v1.7 = rfc 2986) - ie il demande au CA de Let’s Encrypt la création d'un certificat pour example.com avec une cléf publique donnée.
La CSR comporte, comme d'habitude, une signature utilisant la cléf privée qui correspond à la clef publique contenue dans la CSR.
De plus, l'agent signe toute la CSR avec la clef autorisée pour le domaine concerné, de façon à prouver au CA qu'il est autorisé à gérer le process pour ce domaine.

Lorsque le CA recoit la demande, il vérifie les signatures ; si elles sont valides, il crée un certificat (pour le domaine example.com) avec la clef publique contenue dans la CSR et l'envoie à l'agent.

Gestion de la révocation

Fonctionnement similaire: l'agent signe la demande de révocation avec la paire de clef autorisée pour example.com, et le CA vérifie que cette demande est autorisée. Si ok, il publie les informations selon les procédés habituels (CRL, OCSP).

plus sur le web

https://letsencrypt.org/howitworks/

Support https://community.letsencrypt.org/

http://tools.ietf.org/html/rfc2986 décrit la syntaxe de la requète de certification et les specs draft du client sont à