Sur SME, par défaut, tous les services nécessitant un certificat SSL utilisent le même, auto-signé et re-générer tous les ans (valide un an). Il est souvent utile de le remplacer par un autre certificat. Cette page explique la procédure, qui est valable aussi bien pour un certificat officiel (acheté à Verisign ou équivalent), une autorité indépendante comme CAcert, ou encore une autorité privée (par exemple, gérée par PHPki)

• La première étape est bien sûre d'obtenir un certificat. S'il est signée par une CA privée, autant en générer un wildcard (c-a-d qui sera valable pour tous les sous-domaines du domaine principal), pour cela il faut lui donner *.domain.tld comme nom commun. Ensuite, il faut récupérer ce certificat et la clef privée associée au format PEM
• Nous allons maintenant placer ce certificat sur notre SME favorite
  • Il faut créer un nouveau fichier dans /home/e-smith/ssl.crt, par exemple /home/e-smith/ssl.crt/xxx.domain.tld.crt

export DOMAIN=$(db configuration get DomainName)
vim /home/e-smith/ssl.crt/xxx.$DOMAIN.crt

Puis y coller le certificat

• Maintenant, la même chose pour la clef privée

vim /home/e-smith/ssl.key/xxx.$DOMAIN.key

• On restreint l'accès à ce fichier

chmod 600 /home/e-smith/ssl.key/xxx.$DOMAIN.key

• On configure apache pour utiliser ce nouveau certificat

db configuration setprop modSSL crt /home/e-smith/ssl.crt/xxx.$DOMAIN.crt \
key /home/e-smith/ssl.key/xxx.$DOMAIN.key

• on régénère le fichier pem (qui est une concaténation du certificat et de la clef)

expand-template /home/e-smith/ssl.pem/pem

• On régénère la configuration d'apache et on vérifie que tout est OK

expand-template /etc/httpd/conf/httpd.conf
httpd -t

• Si aucune erreur n'est détectée, on peut relancer apache, qui utilisera le nouveau certificat

sv t /service/httpd-e-smith

• Il ne reste plus qu'à relancer tous les services de mails (pour qu'ils utilisent le nouveau certificat également)

expand-template /var/service/qpsmtpd/ssl/cert.pem
signal-event email-update
sv t /service/dovecot
sv t /service/qpsmtpd
sv t /service/sqpsmtpd

• et tous les autres services qui utilisent un certificat

sv t /service/ldap
sv t /service/ejabberd

Il ne reste qu'à vérifier que tout fonctionne comme prévu, et que tous les services utilisent bien le nouveau certificat

Bug traitant du sujet: http://bugs.contribs.org/show_bug.cgi?id=4450

Certains certificats ne sont pas directement signés par une autorité de confiance, mais par une CA intermédiaire (qui n'est pas inclus directement dans les navigateurs). C'est le cas par exemple des certificats RapidSSL (GeoTrust). Dans ce cas, impossible pour les clients (navigateurs, client de messagerie, client LDAP etc…) de vérifier l'authenticité du certificat présenté sans avoir ce certificat intermédiaire. Pour régler ce problème, il faut indiquer à apache le fichier de certification intermédiaire, par exemple, plaçons-le dans /home/e-smith/ssl.crt/chain.pem:

db configuration setprop modSSL CertificateChainFile /home/e-smith/ssl.crt/chain.pem
expand-template /etc/httpd/conf/httpd.conf
sv t /service/httpd-e-smith
expand-template /home/e-smith/ssl.pem/pem

Voilà, maintenant, le fichier pem (concaténation du certificat et de la clef privée) contient également le(s) certificat(s) intermédiaire(s), les clients pourront donc valider toute la chaîne, il ne reste qu'à relancer les services:

signal-event email-update
signal-event ldap-update