SSL et TLS pour les services apache, postfix, ejabberd, courier
En tant qu’administrateur système, je gère de nombreux serveurs web, mail etc. Je dois les garder à jour aussi bien en terme de sécurité que sur les avancées technologiques.
Une des dernières tâches à laquelle je me suis attelé dans ce domaine est la configuration correcte de SSL/TLS sur chacun des services que j’héberge (pour ceux qui savent utiliser SSL/TLS)
J’ai donc créé des certificats pour chaque serveur ou service, et j’ai décidé de faire une petite documentation en français et en anglais expliquant comment cela fonctionne, à destination de mes amis et collègues geeks.
Il y a un certain nombre d’étapes à passer pour obtenir une configuration SSL/TLS correcte.
Dans cette documentation, je vous expliquerais comment configurer postfix, courier (pop et imap), ejabberd et apache en mode sécurisé SSL/TLS avec un certificat distribué par CACert.
La génération du certificat n’est pas abordée dans cette documentation. Pour cela, rendez-vous dans la page expliquant comment générer un certificat serveur avec CaCert.
Configuration de SSL/TLS pour chacun des services
Pour configurer SSL/TLS pour votre serveur, vous devez comprendre que le certificat est échangé avec d’autres machines, ces autres machines pouvant être d’autres serveurs de mail (pour SMTP avec TLS ou Jabber avec des connexions S2S chiffrées) ou des clients (de mail pop/imap ou https utilisant SSL/TLS). Lorsque le client se connecte à votre serveur, il utilise un nom d’hôte FQDN, et ce nom d’hôte DOIT correspondre au champ CN de votre certificat.
Configuration des DNS, Reverse et MX
Les DNS et DNS inverse de votre MX doivent être correctement configurés (ca n’a pas de rapport direct avec tls cela dit...)
Bien que cela n’ai pas de rapport particulier avec SSL/TLS, vous devez être conscient que votre serveur DNS, MX et DNS inverse doivent être configurés proprement lorsque vous souhaitez héberger un serveur MX : Si vous envoyez des mails vers Internet, votre configuration doit être parfaite si vous ne voulez pas être considéré comme un spammeur. Par exemple, si oberon.example.com, ayant l’adresse IP 192.168.1.1, est le MX du domaine example.com, vous devez avoir ceci dans votre configuration DNS :
oberon.example.net le champ DNS A doit être 192.168.1.1
example.com le champ DNS MX doit être oberon.example.net.
1.1.168.192.in-addr.arpa Le champs DNS PTR doit êtreoberon.example.net.
oberon.example.net Le serveur SMTP doit répondre avec un SMTP EHLO (ou HELO) : oberon.example.net
Si l’un ou l’autre de ces points n’est pas correct, vous serez probablement considéré comme un spammeur lorsque vous enverrez du mail vers d’autres domaines. Faites attention aussi lors de l’utilisation de serveur MX ou DNS secondaires : ils doivent répondre aux mêmes exigences ...
SMTP/SMTPD de Postfix : Le champ MX doit correspondre au nom CN du certificat
SSL/TLS sur un serveur SMTP peut s’utiliser de 3 manières différentes :
Un serveur SMTPD recevant du mail en tant que MX (Mail eXchanger) pour un domaine
Un serveur SMTPD recevant du mail destiné à être relayé comme serveur relai pour des clients (comme le logiciel Thunderbird)
Un client SMTP qui envoie du mail au MX d’autres domaines
Dans les 3 cas ci-dessus, les configuration du MX, des serveurs DNS et des champs CN des certificats doivent utiliser le même nom d’hôte FQDN, de telle sorte que les clients SMTP ou serveurs SMTPD qui vous parlerons ne seront pas perturbés par une configutration TLS bancale.
Voici un exemple sous forme d’extraits de configuration DNS (bind9) et SMTPD (main.cf postfix) qui vous montre comment réaliser ceci :
DNS: /etc/bind/primary/serverside.fr
IN MX 5 alice.metaconsult.fr.
DNS: /etc/bind/primary/metaconsult.fr
alice IN A 80.67.165.6
DNS: /etc/bind/primary/80.67.165.0
6 IN PTR alice.metaconsult.fr.
SMTP: /etc/postfix/master.cf
smtp inet n - - - 20 smtpd
smtps inet n - - - 20 smtpd -o smtpd_tls_wrappermode=yes
submission inet n - - - 20 smtpd
smtp unix - - - - 20 smtp
SMTP: /etc/postfix/main.cf
myhostname = alice.metaconsult.fr
myorigin = alice.metaconsult.fr
# TLS Configuration for SMTPD server :
smtpd_use_tls = yes
smtpd_tls_dcert_file = /etc/postfix/alice.metaconsult.fr.pem
smtpd_tls_dkey_file = $smtpd_tls_dcert_file
smtpd_tls_CApath = /etc/ssl/certs/
smtpd_tls_key_file = $smtpd_tls_dcert_file
smtpd_tls_cert_file = $smtpd_tls_dcert_file
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom
# TLS Configuration for SMTP client :
smtp_use_tls = yes
smtp_tls_dcert_file = $smtpd_tls_dcert_file
smtp_tls_dkey_file = $smtpd_tls_dcert_file
smtp_tls_CApath = $smtpd_tls_CApath
X509 : Résultat de la commande openssl x509 -in /etc/postfix/alice.metaconsult.fr.pem -text :
# Note : Ne pas oublier de renouveler ce certificat AVANT Le 17 Aout 2009 :)
Validity
Not Before: Aug 18 17:43:11 2007 GMT
Not After : Aug 17 17:43:11 2009 GMT
Subject: CN=alice.metaconsult.fr
JABBER : Les champs A ou SRV doivent correspondre au nom CN du certificat
Lorsque vous utilisez SSL/TLS sur votre serveur jabber, vos clients et les autres serveurs utiliseront probablement le DNS pour trouver quelle est l’adresse de votre serveur jabber. Si nous reprenons l’exemple du serveur example.com, ayant pour serveur jabber jabber.example.net, votre zone DNS devra ressembler à quelque chose comme cela (zone Bind) :
$ORIGIN example.com.
_jabber._tcp IN SRV 5 0 5269 jabber.example.net.
_xmpp-server IN SRV 5 0 5269 jabber.example.net.
_xmpp-client._tcp IN SRV 5 0 5222 jabber.example.net.
$ORIGIN example.net.
jabber IN A 192.168.1.12
Le certificat du serveur jabber.example.net DOIT donc avoir jabber.example.com comme champ CN. Voici un extrait de configuration pour ejabberd :
EJABBERD: extrait de la configuration /etc/ejabberd/ejabberd.cfg :
{listen,
[{5222, ejabberd_c2s, [{ip, {192, 168, 1, 12}},
{access, c2s},
starttls, {certfile, "/etc/ejabberd/jabber.example.net.pem"},
{shaper, c2s_shaper}]},
{5223, ejabberd_c2s, [{ip, {192, 168, 1, 12}}, {access, c2s},
tls, {certfile, "/etc/ejabberd/jabber.example.net.pem"},
{shaper, c2s_shaper}]},
X509: Résultat de la commande openssl x509 -in /etc/ejabberd/jabber.example.net.pem -text :
# Note : Ne pas oublier de renouveler ce certificat AVANT Le 17 Aout 2009 :)
Validity
Not Before: Aug 18 19:22:11 2007 GMT
Not After : Aug 17 19:22:11 2009 GMT
Subject: CN=jabber.example.net
APACHE : les Vhost HTTPS doivent correspondre au nom CN du certificat
Si vous utilisez apache-ssl, le champ CN de votre certificat DOIT correspondre au nom de votre domaine ou sous-domaine. Voici un exemple pour le domaine secure.example.com :
APACHE-SSL: Extrati de la configuration /etc/apache-ssl/httpd.conf :
Listen 192.168.1.13:443
LoadModule apache_ssl_module /usr/lib/apache/1.3/libssl.so
SSLCacheServerPath /usr/lib/apache-ssl/gcache
SSLCacheServerPort /var/run/gcache_port
SSLSessionCacheTimeout 15
# Ces lignes sont utiles si vous voulez utiliser l'authentification du certificat client :
SSLCACertificatePath /etc/ssl/certs
SSLVerifyClient 0
SSLVerifyDepth 10
SSLFakeBasicAuth
#
<VirtualHost 192.168.1.13:443>
SSLCertificateFile /etc/apache-ssl/secure.example.com.pem
SSLEnable
DocumentRoot /var/www/ssl/
</VirtualHost>
X509: Résultat de la commande openssl x509 -in /etc/apache-ssl/secure.example.com.pem -text :
# Note : Ne pas oublier de renouveler ce certificat AVANT Le 17 Aout 2009 :)
Validity
Not Before: Aug 18 19:32:34 2007 GMT
Not After : Aug 17 19:32:43 2009 GMT
Subject: CN=secure.example.com
COURIER : IMAP et POP doivent être configurés sur votre client de telle sorte que le nom DNS soit le CN du certificat
Plus tard ;)