Différences

Ci-dessous, les différences entre deux révisions de la page.

--- tuto:ipasserelle:authentification:changer_le_certificat [30/08/2011 12:54]
dani
+++ tuto:ipasserelle:authentification:changer_le_certificat [08/12/2015 15:33] (Version actuelle)
dani [Changer le certificat SSL utilisé sur SME]
@@ Ligne 1: / Ligne 1: @@
 ====== Changer le certificat SSL utilisé sur SME ======
-Sur SME, par défaut, tout les services nécessitant un certificat SSL utilisent le même, auto-signé et re-générer tout 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é par PHPki)
+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éré un wildcard (c-a-d qui sera valable pour tout 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
+  * 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
@@ Ligne 37: / Ligne 37: @@
 sv t /service/httpd-e-smith
 </code>
-  * Il ne reste plus qu'à relancer tout les services de mails (pour qu'il utilise le nouveau certificat également
+  * Il ne reste plus qu'à relancer tous les services de mails (pour qu'ils utilisent le nouveau certificat également)
 <code bash>
+expand-template /var/service/qpsmtpd/ssl/cert.pem
 signal-event email-update
+sv t /service/dovecot
+sv t /service/qpsmtpd
+sv t /service/sqpsmtpd
 </code>
-  * et tout les autres services qui utilisent un certificat
+  * et tous les autres services qui utilisent un certificat
 <code bash>
-signal-event ldap-update
+sv t /service/ldap
+sv t /service/ejabberd
 </code>
-Il ne reste qu'à vérifier que tout fonctionne comme prévu, et que tout les services utilisent bien le nouveau certificat
+Il ne reste qu'à vérifier que tout fonctionne comme prévu, et que tous les services utilisent bien le nouveau certificat
 ====== Certificat avec autorité intermédiaire ======
-Certains certificat 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**:
+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**:
 <code bash>
@@ Ligne 55: / Ligne 63: @@
 expand-template /etc/httpd/conf/httpd.conf
 sv t /service/httpd-e-smith
-</code>
-Voilà qui règle le soucis pour apache, reste à le régler pour les service de mail et LDAP (et tout autre service qui pourrait utiliser le certificat, comme ejabberd etc...). Pour cela, il faut créer un template-custom:
-<code bash>
-mkdir -p /etc/e-smith/templates-custom/home/e-smith/ssl.pem/
-cat <<'EOF' > /etc/e-smith/templates-custom/home/e-smith/ssl.pem/60CertificateChainFile
-{
-    $OUT = '';
-    my $chain_file = $modSSL{CertificateChainFile};
-    return unless $chain_file;
-    open(CCF, $chain_file) or die "Could not open CertificateChainFile file: $!";
-    my @chain_file = <CCF>;
-    chomp @chain_file;
-    $OUT = join "\n", @chain_file;
-    close CCF;
-}
-EOF
 expand-template /home/e-smith/ssl.pem/pem
 </code>
-Voilà, maintenant, le fichier pem (concaténation du certificat et de la clef privée contient également le(s) certificats intermédiaires, les clients pourront donc valider toute la chaine, il ne reste qu'à relancer les services:
+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:
 <code bash>