Postfix/TLS - Paramétrer les certificats

Ce paragraphe explique quels types de certificats sont nécessaires pour utiliser postfix avec TLS. Les certificats (et peut être les clefs) peuvent être obtenus auprès de tierces parties, qui peuvent être une autorité de certification commerciale ou votre FAI. Tout le long vous aurez besoin de certificats acceptés par d'autres entités sur internet, vous avez donc à être d'accord sur les entités de certifications, quelque soit leurs types.

certificat serveur

Pour utiliser SMTP avec TLS en mode serveur, votre serveur DOIT avoir une paire de clefs (privée et publique).
Puisque la clé publique doit être distribuée de façon ou d'autre au client, elle est envoyée du serveur au client pendant la négociation de départ. Cependant,au début de la négociation, le client ne peut pas savoir que la clef publique appartient réellement au serveur et n'est pas contrefaite. Par conséquent un troisième composant est nécessaire : le certificat d'une autorité de certification (CA), qui est envoyé combiné avec la clef publique. Ce certificat de serveur contient le nom de votre hote. Le client contrôlera alors la signature du CA sur la clef publique pour décider si le certificat (et la clef publique) sont authentiques.
Ainsi pour le serveur nous avons besoin:
- 1 clef privée de serveur
- 1 clef publique de serveur signée par une autorité de certification, certifiant que la clef publique appartient à votre hôte
- 1 certificat CA avec la clef publique du CA
Pour cette liste je veux absolument préciser que le nombre de composants utilisés est 1, parce que vous devez en avoir 1, vous ne pouvez pas en avoir ni moins ni plus!

Politique de certificat serveur

A partir de maintenant vous avez à vous décider sur la politique. Le client qui va se connecter sur votre hôte va comparer le nom dans le certificat de votre serveur à son FQDN (Fully Qualified Domain Name). Si ils correspondent, l'identité de votre serveur est prouvée.
Pour voir, si le certificat lui-même est authentique, le client lui-même doit avoir le certificat du CA. Ainsi, si vous voulez le rendre facilement accessible à d'autres, parties inconnues, vous devez avoir un certificat issu d'un CA connu et digne de confiance. Rappelez vous que votre serveur ne peut avoir qu'un certificat à la fois.
Il y a des fournisseurs commerciaux (Thawte, Verisign, pour n'en citer que quelques uns), leurs certificats CA sont bien distribués. Je ne sais pas pour les autres pays mais en Allemagne le organisation de la recherche reseaux (DFN) a commencé un programme pour les universités.
Si vous ne portez pas d'importance à ceci (vous pourrez le changer plus tard), vous pouvez devenir votre propre CA et distribuer vos certificat de CA aux parties qui devront le connaitre, et vous êtes prêts. Ce n'est pas difficile de le faire.
Le cours tres bref de Lutz pour être votre propre CA (toujours en anglais ..)

Utiliser les certificats

Pour rendre la clef et les certificats utilisables par Postfix/TLS, ils doivent être au format "PEM". Puis vous avez à indiquer à postfix où les trouver:
- La clef privée:

smtpd_tls_key_file = /etc/postfix/key.pem

comme la clef publique est publique y compris le certificat (tout le monde peut la récupérer), une personne disposant d'une copie de votre clef privée peut usurper votre identitée. Ce n'est pas si facile que ça, du fait qu'il doit être capable d'intercepter ou de rediriger les paquets envoyés vers votre serveur, mais j'ai déja vu bien de choses arriver. Donc protégez cette clef avec :

chown root /etc/postfix/key.pem ; chmod 400 /etc/postfix/key.pem

Une autre possibilité de protection est la 'phrase clef'. Ceci est toutefois un problème, du fait que vous ayez à le taper à chaque fois que le server est démarré. Ceci a des inconvenients : premièrement vous devez le taper dans postfix à chaque fois que vous le redémarrez. Deuxièmement les process smtpd sont lancés indépendamment à partir de master, dans ce cas master doit passer la 'phrase clef' aux clients d'une façon ou d'une autre. Tout cela fait que je pense que cette méthode n'est pas pratique et donc n'est pas supportée par le programme.

- Le certificat serveur : ce certificat n'est pas secret, du fait qu'il est présenté à chaque client de toutes façons, ainsi nommez le juste a postfix :

smtpd_tls_cert_file = /etc/postfix/cert.pem

Si vous voulez vous pouvez concaténer la clef privée et le certificat dans le même fichier.

- Le certificat CA: pour avoir également le certificat CA disponible, écrivez le dans un fichier et donnez le nom à postfix/TLS. Nous reviendrons plus tard sur ce fichier.

smtpd_tls_CAfile = /etc/postfix/CAcert.pem

Avec ces certificats vous devez être en mesure de faire tourner Postfix/TLS.

Postfix/TLS en mode client

Quand il se connecte à un serveur offrant TLS postfix peut présenter un certificat client de lui même. Du fait de la réalisation actuelle, seulement un certificat ne peut être contrôlé, ainsi il devrait être émis depuis votre propre nom d'hôte. Par défaut aucun certificat n'est présenté, à moins que vous placiez explicitement le certificat dans la configuration. Vous pouvez utiliser le même certificat que pour le serveur:

smtp_tls_key_file = /etc/postfix/key.pem
chown root /etc/postfix/key.pem ; chmod 400 /etc/postfix/key.pem

smtp_tls_cert_file = /etc/postfix/cert.pem
smtp_tls_CAfile = /etc/postfix/CAcert.pem

Certificats clients:

Une des raisons pour laquelle j'ai fait ce travail est que je voulais faire du relayage basé sur les certificats clients. Le client présente un certificat d'un CA, qui est unique et ne peut être usurpé.
Des clients peuvent avoir plusieus certificats émis par diffèrents CA. Lors de la connexion le serveur passera au client la liste de CA qu'il connait (les certificats de CA) et le client peut alors choisir le certificat à passer. Avec Netscape cela signifie qu'une fenêtre est ouverte et seulement le certificat client est listé.
Donc si vos clients ont déjà des certificats émanant de sources de confiances ce n'est pas nécessaire de se créer des problémes. Vous avez juste à récupérer les certificats CA et les rendre disponibles à Postfix/TLS. Si ce n'est pas suffisant, vous pouvez toujours devenir votre propre CA pour créer facilement vos certificats clients pour vos usagers (qui sont naturellement inutiles en dehors de votre portée)

Lister les certificats CA

Vous avez deux possibilité de faire ceci:
1- Concaténez les certificats CA au fichier smtp[d]_tls_CAfile que vous avez créé. Ce fichier n'est certainement pas très lisible mais a l'avantage d'être lu par smtpd avant le changement dans la cage chroot et par conséquent fonctionne en mode chrooté.
2- Vous pouvez ajouter les certificats CA dans plusieurs fichiers avec des noms adéquats dans un répertoire de certificats spécifié par:
smtpd_tls_CApath = /etc/postfix/certs
N'oubliez pas de faire un $OPENSSL_HOME/bin/c_rehash /etc/postfix/certs après tout changement, car les tables de hachages sont utilisées pour trouver le bon certificat CA. Cette methode ne doit pas fonctionner en mode chrooté.

Ajouter des certificats client:

Les certificats de client sont délivrés pour un DN (Distinguished Name) (Nom Complet) composé de la compagnie, service, le nom, l'email... Du fait qu'ils peuvent contenir des blancs, des @, des signes et des colonnes, il est tout à fait difficile de les manipuler avec les outils standards de postfix.
Une chose tout à fait pratique est que chaque certificat de client a une " empreinte digitale " il est extrêmement difficile truquer que (à ma connaissance, elle pourrait prendre des années même sur les ordinateurs rapides). Je dois faire encore plus de recherche au sujet de la sécurité de l'empreinte digitale, mais au moins pour relayer cela doit être suffisament sécurisé. Je trouverai plus facilement une machine avec une mauvaise sécurité pour envoyer mon spam au lieu de truquer un certificat de client avec une empreinte digitale assortie (que d'ailleurs je ne connais pas depuis l'extérieur, même depuis l'interieur vous pouvez protéger la base "d'empreintes digitales" par un chmod 400)