Visualiser les certificats existants :

cerbot certificates

Il vaut mieux créer un certificat par domaine, plutôt qu’un pour tous les domaines (ce qui est le cas par défaut si non précisé) Pour créer un nouveau certificat pour un domaine précis :

sudo certbot --apache -d example.com --rsa-key-size 4096

Les fichiers se retrouvent dans /etc/letsencrypt/archive/ et sont linkés dans /etc/letsencrypt/live/

Pour rajouter un domaine à un certificat existant :

certbot --expand -d example.com,new.example.com

Pour supprimer un certificat, il semble qu’il n’y ait d’autre moyen que de supprimer les dossiers concernés dans les dossiers live, archive et renewal (dans /etc/letsencrypt/ )

Pour renouveler tous les certificats :

certbot renew

Pour renouveler seulement un domaine précis, au choix :

certbot certonly -d example.com

Vérifier la longueur d’une clé en appel direct d’un site web :

echo | openssl s_client -connect example:443 2>/dev/null | openssl x509 -text -noout | grep "Public-Key"

Côté client

Le fichier qui contient tous les hôtes qu’un client ssh connaît est /home/$USER/.ssh/known_hosts. Si il y a un conflit de clés (clé d’un serveur renouvelée par exemple), on peut supprimer uniquement la ligne concernant le serveur en question, dont il faut connaitre le hostname : ssh-keygen -R HOSTNAME

Si on souhaite créer une clé d’authentification RSA (ou DSA), on peut le faire via la commande ssh-keygen -t rsa -b 4096 -C "Commentaire pour ditinguer la clé" (ou ssh-keygen -t dsa pour l’algo DSA, bien que ce soit aujourd’hui moins conseillé). Il est possible de créer une passphrase pour ces clés. Les fichiers créés le seront par défaut à l’emplacement ~/.ssh/id_rsa pour la clé privée et ~/.ssh/id_rsa.pub pour la clé publique. Ces clés peuvent servir pour se connecter sans mot de passe à un serveur ssh. Le commentaire se retrouve à la fin de la clé publique.

Le programme utilisé pour gérer la liste des clés utilisables pour l’authentification par clé est ssh-agent. La clé à l’emplacement par défaut est toujours référencée par ssh-agent. On peut gérer ce programme via la commande ssh-add. Par exemple ssh-add -L liste les clés référencées, ssh-add -D supprime toutes les clés référencées, ssh-add /path/to/id_rsa référence la clé en question et ssh-add -d /path/to/id_rsa supprime uniquement cette clé.

Pour que tous les terminaux partagent le même agent, il faut placer ceci dans son .bashrc (et peut-être le .profile) (source) :

	export SSH_AUTH_SOCK=~/.ssh/ssh-agent.$HOSTNAME.sock
	ssh-add -l 2>/dev/null >/dev/null
	if [ $? -ge 2 ]; then
	  ssh-agent -a "$SSH_AUTH_SOCK" >/dev/null
	fi

Côté serveur

Les clés publiques/privées du serveur sont créées à l’installation du serveur SSH. Elles se trouvent par défaut à /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_dsa_key.pub, /etc/ssh/ssh_host_rsa_key et /etc/ssh/ssh_host_rsa_key.pub.

Pour accepter les connections par clé RSA, le serveur doit avoir les directives RSAAuthentication yes PubkeyAuthentication yes #AuthorizedKeysFile %h/.ssh/authorized_keys dans le fichier de configuration du serveur /etc/ssh/sshd_config.

Comme l’indique la 3ème directive ci-dessus, les clés (publiques) acceptées pour chaque user sur le serveur doivent se trouver dans le fichier /home/$USER/.ssh/authorized_keys. Ce paramètre peut-être modifié en décommentant cette ligne et en mettant un emplacement différent.
Une des manières de l’ajouter, depuis le poste client, est de rentrer la commande ssh-copy-id -i /path/to/id_rsa -p port user@serveur. La paramètre -i est facultatif, en son absence ce sera l’emplacement par défaut qui sera utilisé.
On peut également le copier à la main sur le serveur, en copiant la clé publique correspondante à l’emplacement indiqué dans le fichier de conf.