Traduction de la page https://workaround.org/ispmail/jessie/create-certificate

(Si vous n'êtes pas familiarisé avec l'abbréviation « TLS » : c'est le successeur de SSL.)

L'Internet est la plus belle invention depuis le pain en tranches mais il est devenu un endroit infernal, plus qu'il ne l'a jamais été. Nous avons affaire à grande échelle à des script kiddies, des services secret incontrôlés et des organisations criminelles. Il est totalement hors de question de faire tourner des services non chiffrés sur Internet. Je considère qu'un mot de passe envoyé en clair sur Internet est immédiatement perdu. Nous allons donc créer une clé de chiffrement et certificat pour Postfix (SMTP), Dovecot (IMAP/POP3) et Roundcube (Webmail/HTTPS).

Avertissement : N'utilisez pas des certificats différents pour Postfix et Dovecot. Le client de Mail de MacOS refuserait la connexion avec des messages d'erreur trompeurs, et il est possible que d'autres clients de Mail se plaignent également.

Il existe deux facteurs de sécurités liés à un certificat de chiffrement :

(a) – La sécurité cryptographique

C'est un problème mathématique l'idée est de créer une fonction à sens unique qui rend facile le déchiffrement des données si vous connaissez la clé, mais qui rend virtuellement impossible de casser le chiffrement sans connaître cette clé. Depuis quelques années l'algorithme SHA1 était renommé, mais grâce aux révélations d'Edward Snowden nous savons qu'il peut être cassé trop facilement. Donc il est conseillé d'utiliser au moins SHA256 (qui fait partie de l'algorithme SHA2). De même les signatures RSA ne doivent plus être crées en 1024 bits mais plutôt en 4096 bits. Créer des clés et des certificats sûrs est relativemement facile, nous avons les outils pour ça.

(b) – La confiance

L'idée de confiance dans un certificat est différente. Le problème est que même si votre certificat est « mathématiquement » bon, vous ne savez pas avec qui vous communiquez. Vous pouvez en fait être en communication avec une toute autre personne que celle avec qui vous croyez communiquer. C'est le problème que l'on appelle en anglais man-in-the-middle (littéralement l'attaque de l'homme du milieu). Et ce n'est pas ce que vous voulez. (voyez également mon article creating your own certificate authority).

Note du traducteur : Le terme PKI qui revient souvent ci-dessous est un sigle anglais pour « Public Key Infrastructure » (que l'on pourrait traduire par infrastructure de clés publiques). Il désigne des sociétés externes (auxquelles vous faites implicitement confiance), qui vont vérifier l'authenticité de certificat SSL/TLS. Ces PKI sont souvent aussi désignés comme CA pour Certification Authorities c'est à dire autorités de certification.

J'ai traduit sur ce site divers documents concernant SSL et l'usage des certificats, dont le guide de Marcus Redivo qui décrit en détail la création d'un certificat auto-signé et de son utilisation. Les étapes de création y sont détaillées, chaque option de création y est discutée ainsi que la procédure pour créer un certificat racine d'autorité qui permette de signer les certificats SSL des serveurs. Y sont bien entendu abordés les avantages, inconvénients et limites de ces certificats maison. C'est un complément aux informations fournies par Christoph Haas. Un document simple permettant de vous familiariser avec les grandes lignes de SSL/TLS sans entrer dans les détails techniques se trouve sur le site de Seb Sauvage.

Christoph a lui aussi créé un document sur la création de sa propre autorité de certification vers lequel il donne un lien ci-dessus. Je ne l'ai pas encore traduit.

Vous avez donc à faire un choix, soit acheter un certificat, soit en créer un vous-même. Voici le pour et le contre de chaque choix :

Note : Quelle que soit la méthode que vous utilisez créez toujours la clé sur votre propre serveur. Ne faites jamais confiance à une clé créée par quelqu'un d'autre. Laisser créer la clé par un tiers pourrait sembler plus simple, parce que vous pourriez oublier une étape. Mais l'autre partie connaîtrait votre clé secrète et pourrait en théorie intercepter vos échanges chiffrés. J'expliquerai comment faire ça dans les règles dans les sections qui vont suivre. Choisissez juste votre option et suivez les instructions.

Option 1 : Auto-signé

L'option la plus simple. Lancez simplement cette commande sur votre serveur et vous aurez un certificat valable pour tous les usages avec une durée de validité de dix ans :

openssl req -newkey rsa:4096 -nodes -sha512 -x509 -days 3650 -nodes -out /etc/ssl/certs/mailserver.pem -keyout /etc/ssl/private/mailserver.pem

Pendant la création on va vous demander plusieurs informations. Entrez ce que vous voulez. Le seul champ de saisie important est le Common Name qui doit contenir le nom pleinement qualifié par lequel vous voulez que votre serveur soit connu sur Internet. Pleinement qualifié signifie nom d'hôte + nom de domaine.

Assurez-vous que la clé privée soit seulement lisible par l'utilisateur root :

chmod go= /etc/ssl/private/mailserver.pem

Option 2 : Auto-signé avec votre propre PKI

Cette technique est un peu meilleure que l'utilisation d'un simple certificat autosigné. Mais vos utilisateurs ou vos clients doivent installer votre certificat racine manuellement pour établir une relation de confiance avec votre PKI à la fois dans leur navigateur et leurs clients de mail.

Je vous suggère d'installer le paquet easy-rsa et d'en lire la documentation :

zless /usr/share/doc/easy-rsa/README-2.0.gz

Si ce sujet intéresse suffisamment de monde je développerai la façon de gérer votre propre autorité de certificatin en utilisant easy-rsa.

Option 3 : certificat gratuit de StartSSL

Il s'agit presque toujours de la meilleur solution. Cela ne coûte pas d'argent et vous donnera un certificat de confiance de base que la plupart des navigateurs et clients de mail accepteront.

Créez un fichier de clé de 4096 bit :

openssl genrsa -out /etc/ssl/private/mailserver.pem 4096

Créez un fichier de requête de signature (CSR) pour cette clé :

openssl req -new -key /etc/ssl/private/mailserver.pem -out /etc/ssl/certs/mailserver.csr

Pendant la création on va vous demander plusieurs informations. Entrez ce que vous voulez. Le seul champ de saisie important est le Common Name qui doit contenir le nom pleinement qualifié par lequel vous voulez que votre serveur soit connu sur Internet. Pleinement qualifié signifie nom d'hôte + nom de domaine.

Maintenant allez sur le site de StartSSL  StartCom et enregristrez vous pour obtenir un compte. Commencez par utiliser le « Validation Wizard » pour commencer par valider votre adresse mail. Ensuite utilisez de nouveau le « Validation Wizard » pour valider le domaine que vous voulez utiliser pour votre serveur de mail.

Ensuite utilisez le « Certificates Wizard » pour créer un « Web Server SSL/TLS certificate ». Choisissez votre domaine de mail et copiez le contenu de votre fichier CSR (/etc/ssl/certs/mailserver.csr) que vous avez créé au préalable et vous allez recvoir votre certificat. Placez ce fichier à cet emplacement /etc/ssl/certs/mailserver.pem et donnez-lui les permissions qui conviennent :

chmod go= /etc/ssl/private/mailserver.pem

En plus de la configuration d'Apache décrite ci-dessous assurez-vous d'installer également la chaine de certification. Un exemple de configuration est donné dans la documentation StartSSL.

Note du traducteur de décembre 2017 : dans son tableau Christoph cite Let's Encrypt  qui est l'alternative actuelle à StartSSL qui vient d'annoncer il y a quelques jours l'arrêt de son activité de PKI. Je suppose qu'il a reproduit les informations des anciens guides, puisque lorsqu'il a écrit son guide, let's Encrypt et StartSSL étaient encore actifs tous les deux.

Option 4 : Certificat payant

Êtes-vous certain de vouloir faire ça ? Alors recherchez simplement sur le Web les mots « SSL certificats » et envoyez la monnaie à n'importe quelle autorité de certification.

La clé et la requête de certificat sont à créer comme décrit ci-dessus dans l'option 3.

Utilisez le fichier de requête CSR pour demander un certificat de la part de l'autorité de certification SSL. Placez ce fichier de certificat dans /etc/ssl/certs/mailserver.pem et réglez les permissions :

chmod go= /etc/ssl/private/mailserver.pem

Augmenter la sécurité TLS

De fait vous devriez interdire les communications utilisant des méthodes de chiffrement potentiellement non-sûres. Il existe une sorte d'attaque du chiffrement qui consiste à vous faire croire que vous n'utilisez pas des techniques de chiffrement modernes pour en réalité vous faire redescendre en SSL, version 2 ou 3. C'est ce qu'on appelle l'attaque POODLE (l'article Wikipedia français étant très léger, pour plus d'information voyez l'article en anglais). Il vaut mieux donc lancer la commande…

postconf 'smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3'

…pour interdire les communications utlisant les protocoles « pre-snowden » qui peuvent être contournés pour vous attaquer. (Merci à Guillaume pour cette précision.)