4 230
modifications
(Page créée avec « <pre> $# gpg --with-wkd-hash -k <id-clé/mail> </pre> Devrait vous retourner quelque chose ressemblant à ça : <pre> pub rsa2048 2017-05-26 [SC] 7EBA8211BFF531EE... ») |
Aucun résumé des modifications |
||
(12 versions intermédiaires par le même utilisateur non affichées) | |||
Ligne 1 : | Ligne 1 : | ||
[[Category:serveur]] | |||
[[category:security]] | |||
=Côté client= | |||
<pre> | <pre> | ||
$ | #$ gpg --with-wkd-hash -k me@domain1.tld | ||
</pre> | </pre> | ||
Ligne 7 : | Ligne 11 : | ||
pub rsa2048 2017-05-26 [SC] | pub rsa2048 2017-05-26 [SC] | ||
7EBA8211BFF531EE59E25CBD99FD9BFE6F9B8951 | 7EBA8211BFF531EE59E25CBD99FD9BFE6F9B8951 | ||
uid [ultimate] you < | uid [ultimate] you <me@domain1.tld> | ||
s8y7oh5xrdpu9psba3i5ntk64ohouhga@domain1.tld | s8y7oh5xrdpu9psba3i5ntk64ohouhga@domain1.tld | ||
uid [ultimate] you2 < | uid [ultimate] you2 <me@domain2.tld> | ||
s8y7oh5xrdpu9psba3i5ntk64ohouhga@domain2.tld | s8y7oh5xrdpu9psba3i5ntk64ohouhga@domain2.tld | ||
sub rsa2048 2017-05-26 [E] | sub rsa2048 2017-05-26 [E] | ||
Ligne 15 : | Ligne 19 : | ||
sub rsa2048 2017-05-26 [A] | sub rsa2048 2017-05-26 [A] | ||
</pre> | </pre> | ||
Le but est de récupérer l'ID de 32 caractères issu de l'empreinte SHA1 encodé en Z-base32 de la partie locale de l'email (avant le @). <br>Ici l'ID est '''s8y7oh5xrdpu9psba3i5ntk64ohouhga''' (c'est le même dans les deux cas uniquement parce que les deux emails sont me@). | |||
<br><br> | |||
=Côté serveur= | |||
Ce wiki ne couvre que la mise a disposition de clé en WKD en direct-mode, qui nécessitera que vos clés soient accessibles à l'url <code>http://domain1.tld/.well-known/openpgpkey/hu/</code> (et réciproque avec domain2.tld).<br> | |||
Le advanced-mode est un peu plus complexe et nécessité un certificat SSL trusted (letsencrypt par exemple) pour un sous-domaine <code>openpgpkey.domain1.tld</code> (et réciproque avec domain2.tld).<br> | |||
Notez que pour le direct-mode, assurez-vous que le sous-domaine <code>openpgpkey.domain1.tld</code> n'existe pas et que votre dns ne répond pas aux wildcards. Si vous utilisez les wildcards, il faut insérer dans la zone dns un champt <code>TXT RR</code> vide pour le sous-domaine <code>openpgpkey</code>.<br> | |||
Note : vous pouvez aussi utiliser un serveur externe en mode advanced : <code>openpgpkey.domain1.tld. 300 IN CNAME wkd.keys.openpgp.org.</code> | |||
<br><br> | |||
Sur la racine de votre serveur web, créez le chemin de répertoire suivant : <code>.well-known/openpgpkey/hu/</code> <br> | |||
Placez ensuite un fichier vide dans <code>.well-known/openpgpkey/policy</code> | |||
<br><br> | |||
Essayez d'accéder au fichier policy via <code>http://domain1.tld/.well-known/openpgpkey/policy</code>.<br> | |||
Si cela fonctionne, modifiez la configuration de votre serveur afin de configurer le dossier <code>.well-known/openpgpkey/hu/</code> (nécessite les mods apache2 mod_mime et mod_headers): | |||
<pre> | |||
<Directory "/path/to/.well-known/openpgpkey/hu/"> | |||
ForceType application/octet-stream | |||
Header always set Access-Control-Allow-Origin "*" | |||
</Directory> | |||
</pre> | |||
Il ne vous reste plus qu'à exporter votre clé publique sur votre site web de manière qu'elle soit accessible à l'URL <code>https://domain.tld/.well-known/openpgpkey/hu/s8y7oh5xrdpu9psba3i5ntk64ohouhga</code> et <code>https://domain2.tld/.well-known/openpgpkey/hu/s8y7oh5xrdpu9psba3i5ntk64ohouhga</code><br> | |||
Notez que la clé doit être sous le format binaire et non pas ASCII armored. | |||
<br> | |||
Le plus simple est d'exporter votre clé sous le bon nom de fichier, puis de le transférer par exemple avec scp : | |||
<pre> | |||
gpg --export me@domain1.tld > s8y7oh5xrdpu9psba3i5ntk64ohouhga | |||
scp s8y7oh5xrdpu9psba3i5ntk64ohouhga webuser@domain1:/path/to/.well-known/openpgpkey/hu/ | |||
</pre> | |||
Assurez-vous évidemment que les permissions permettent bien au serveur web de lire le fichier. | |||
Pour plus d'informations : | |||
* https://wiki.gnupg.org/WKD | |||
* https://wiki.gnupg.org/WKDHosting |