Comme http n'est pas sécurisé, il existe une solution plus sécurisée appelée https. Ce protocole https n'est rien d'autre que le protocole bien connu http, sous lequel on glisse une couche de sécurisation par chiffrement appelée TLS (pour Transport Layer Security). Parfois connu sous le nom de SSL (pour Secure Sockets Layer), SSL est en réalité l'ancêtre de TLS, la version précédente. On utilise donc aujourd'hui TLS pour sécuriser http et aboutir à https.

Fonctionnement du https

L'établissement d'une connexion https sécurisée par TLS nécessite la présence d'un certificat. Il existe des certificats de différents types :

  • Auto-signé : celui qui génère le certificat clame aussi que le certificat est valide. Cela peut-être une faiblesse dans le cas où une personne mal-intentionnée pourrait utiliser un certificat pour sécuriser une connexion : le fait que la connexion est sécurisée ne signifie par forcément que l'interlocuteur est honnête.

  • Signé par une autorité de certification reconnue : le certificat généré par l'interlocuteur a été signé par une autorité de certification reconnue (comme VeriSign) qui approuve le fait que le certificat appartient bien à la personne (physique ou morale) qui dit en être la propriétaire. L'autorité de certification est censée vérifier la légalité de la demande, et l'existence de la personne, avant de signer le certificat. Dans les faits, ces autorités de certification sont souvent critiquées par la légèreté de leurs procédures de vérification, et par le juteux business qu'elles génères : signer un certificat ne coûte rien, ou pas grand chose, mais les certificats signés sont facturés bien cher.

  • Signé par une autorité de certification communautaire : le certificat généré par l'interlocuteur a été signé par une autorité de certification communautaire (comme CAcert) qui approuve le fait que le certificat appartient bien à la personne qui dit en être propriétaire. Les contrôles effectués par CAcert sont des plus léger, CAcert ne faisant pas payer les certificats qu'elle signe, elle ne dispose pas de budget pour effectuer des contrôles poussés. Il faut donc s'en remettre à la confiance dans la communauté.

Une fois les certificats (auto-)signés disponibles, il faut les installer sur le serveur et modifier la configuration pour que les certificats soient pris en compte. On peut aussitôt les utiliser et commencer une connexion https sécurisée.

Si vous disposez déjà de certificat, alors vous n'avez rien de spécial à faire. Dans le cas contraire, vous pouvez générer des certificats auto-signés (vous seul affirmez que vos certificats sont valides) ou bien signé par une autorité de certification. CAcert est une autorité de certification animée par une communauté et propose de signer des certificats sans contrepartie financière. Vous pouvez facilement générer vos propres certificats en suivant ce mode d'emploi.

Acheter un certificat ssl

Vous pouvez acheter des certificats signés par une autorité de certification chez des vendeurs comme Gandi.

Le prix dépendra fortement du nombre d'adresses que vous voulez protéger. En effet, si vous achetez un certificat SSL pour votre domaine truc.org, la certification ne fonctionnera pas pour bidule.truc.org ni pour yolo.truc.org. Il faudra donc acheter des certificats multiples ou opter pour une wildcard (votre domaine plus tous les sous-domaines) mais ceci peut coûter très cher (à l'écriture de cet article, 120€/an).

Générer et utiliser des certificats auto-signés

La démarche se déroule suivant 4 étapes :

  1. générer le certificat (clé privée)
  2. générer la clé publique à certifier
  3. auto-signer la clé publique
  4. configurer votre serveur web pour qu'il utilise cette paire de clé.

On génère le certificat :

sudo openssl genrsa -out /etc/ssl/mondomaine.key 2048

(on peut choisir un autre chemin pour le fichier mondomaine.key, ceci est juste un exemple qui parrait assez rationnel cependant)

On protège la clé en mettant les bons droits

sudo chmod 400 /etc/ssl/mondomaine.key

On génère une demande de signature de certificat au format CSR (Certificat Signing Request)

sudo openssl req -new -key /etc/ssl/mondomaine.key -out /etc/ssl/mondomaine.csr

On peut utiliser ce fichier pour faire signer son certificat par une autorité de certification mais on peut aussi auto-signer ce certificat, ce qui nous interesse ici.

sudo openssl req -new -x509 -days 365 -in /etc/ssl/mondomaine.csr -signkey /etc/ssl/mondomaine.key -out /etc/ssl/mondomaine.crt

Ici, on choisi que le certificat expire dans 1 an mais on peut décider de ne pas mettre d'expiration. C'est quand même bien de penser à le changer régulièrement.

Répondre à l'ensemble des questions posées. Le nom de la machine doit être donné en réponse à Common Name. On peut utiliser un wildcard (joker) du type *.mondomaine.org pour que le certificat s'applique à un ensemble de sous-domaines.

Maintenant, pour que votre site web utilise ce chiffrement, il faut que le VirtualHost soit sous cette forme :

<VirtualHost *:443>
        SSLEngine on
        SSLCertificateFile    /etc/ssl/mondomaine.crt
        SSLCertificateKeyFile /etc/ssl/mondomaine.key
        SSLVerifyClient none
        [… le reste des configurations nécessaires]
</VirtualHost>

Il faut aussi penser à activer le module ssl pour apache

sudo a2enmod ssl
sudo service apache2 force-reload

puis s'assurer que dans le fichier /etc/apache2/ports.conf on y voit bien les lignes :

<IfModule ssl_module>
    Listen 0.0.0.0:443
</IfModule>

Utiliser des certificats libres : Let's Encrypt

TODO

Mise en place d'une PKI et gestion des certificats

Ce chapitre est honteusement pompée sur : le tutoriel chez Karma-Labs et cet ensemble de tutoriels.

Une Autorité de certification (AC ou CA chez nos amis grands-bretons) permet de signer des certificats. Lorsque l'on se connecte sur une page web dont le serveur a un certificat auto-signé, notre navigateur émet généralement un avertissement, prévenant que le certificat est autosigné, et que le navigateur ne peut donc pas s'assurer de l'identité du site web.

Chaque navigateur (et autres logiciels clients : pour le mail, et même les systèmes d'exploitation) ont une liste d'autorités de certifications qu'ils reconnaissent. Cette documentation vous propose de créer votre propre autorité de certification, et éventuellement de l'intégrer à vos différents clients, pour éviter de devoir ignorer l'avertissement à chaque fois que vous utiliserez un de vos serveurs.

ATTENTION Le système des autorités de certification fait qu'une fois une autorité de certification ajoutée dans un logiciel, celui-ci acceptera tous les certificats signés par celle-ci. Ainsi, vous pourrez signer un certificat pour n'importe-qui (Google, votre banque) qui sera reconnu dans votre navigateur. N'intégrez donc que des autorités gérées par des gens auxquels vous faites confiance.

NOTE Le système actuel vous « oblige » à faire confiance en des gens dont vous n'avez aucune idée du niveau de confiance que vous pouvez placer en eux. Vous pouvez vérifier cette liste d'autorités de certifications saisies par défaut, par exemple dans votre navigateur, pour regarder tous les gens en qui l'éditeur de votre navigateur a confiance.

Introduction — un peu de vocabulaire

L'outil de prédilection pour gérer une PKI et/ou des certificats x509 est openssl. Allez au minimum parcourir la page de manuel avant de vous lancer dans la création d'une PKI. Pour cela lancez la commande :

man openssl

Quelques abbréviations utilisées :

  • Public Key Infrastructure (PKI) : Infrastructure de gestion de clefs
  • Certificate Authority (CA) : Autorité de certification : c'est ce qu'on veut faire ici, qui permettra de signer et de révoquer des certificats.
  • Registration Authority (RA) : Autorité d'enregistrement : elle permet aussi de signer et révoquer les certificats, est signée par la CA, généralement pour protéger la CA.
  • Certificate : Certificat : clef publique et identifiant liés par une signature d'une CA.
  • Certificate Signing Request (CSR) : Requête de signature de certificat : requête contenant la clef publique et l'identifiant, que l'on transmet à la CA pour qu'elle en fasse un certificat en le signant.
  • Certificate Revocation List (CRL) : Liste de révocation de certificats : liste de certificats révoqués (donc plus valides) émise par une CA.

Maintenant, allez voir la page de man d'openssl. C'est pas une blague, juste faites-le.

Création de la PKI

Un peu de cuisine préliminaire

Dans tous les exemples, nous installons les fichiers de l'autorité de certification dans un répertoire /pki. Il est possible de le mettre ailleurs (par exemple, dans /root/pki), mais il faut limiter drastiquement l'accès à tous ces fichiers, en particulier les clefs privées.

Pour l'exemple, on se met en root. Premiére étape, on crée un répertoire accueillant la PKI, en limitant les droits sur tous les fichiers, puis des répertoires pour accueillir différents types de données :

mkdir /pki
cd /pki
mkdir crl certs etc
chmod -R 700 /pki

Deuxième étape, on crée les fichiers de configuration :

  • root-ca.conf contiendra la configuration pour la CA
  • signing-ca.conf contiendra la configuration pour la CA permettant de signer des certificats
  • server.conf contiendra la configuration pour faire des certificats serveur
  • email.conf contiendra la configuration pour faire des certificats personnels (pour le mail, par exemple)

Maintenant, on peut passer au vif du sujet…

Création de la CA racine

On crée les répertoires correspondants :

mkdir -p ca/root-ca/private ca/root-ca/db

Ensuite, on crée les bases de données :

cp /dev/null /pki/ca/root-ca/db/root-ca.db
cp /dev/null /pki/ca/root-ca/db/root-ca.db.attr
echo 01 > /pki/ca/root-ca/db/root-ca.crt.serial
echo 01 > /pki/ca/root-ca/db/root-ca.crl.serial

On lance la commande pour créer la requête :

openssl req -new -config /pki/etc/root-ca.conf -out /pki/ca/root-ca.csr -keyout /pki/ca/root-ca/private/root-ca.key

La sortie :

Generating a 2048 bit RSA private key
...........................................+++
....................................................................................................+++
writing new private key to '/pki/ca/root-ca/private/root-ca.key'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----

On va donc se retrouver avec une nouvelle (new) requête (req) de certificat dans /pki/ca/root-ca.csr (-out), avec la clef privée correspondante dans /pki/ca/root-ca/private/root-ca.key (-keyout), en suivant les directives du fichier de configuration /pki/etc/root-ca.conf (-config).

On va alors auto-signer (-selfsign) cette requête (/pki/ca/root-ca.csr), toujours avec le même fichier de configuration (/pki/etc/root-ca.conf) — en précisant les extensions de la section root_ca_ext (-extensions) :

openssl ca -selfsign -config /pki/etc/root-ca.conf -in /pki/ca/root-ca.csr -out /pki/ca/root-ca.crt -extensions root_ca_ext

On obtient alors le certificat (/pki/ca/root-ca.crt) de notre autorité racine (ca), et la sortie suivante :

Using configuration from /pki/etc/root-ca.conf
Enter pass phrase for /pki/ca/root-ca/private/root-ca.key:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 1 (0x1)
        Validity
            Not Before: Oct 19 18:17:00 2013 GMT
            Not After : Mar  6 18:17:00 2041 GMT
        Subject:
            domainComponent           = net
            domainComponent           = exemple
            organizationName          = Exemple
            organizationalUnitName    = Exemple Root CA
            commonName                = Exemple Root CA
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier: 
                …
            X509v3 Authority Key Identifier: 
                keyid:…

Certificate is to be certified until Mar  6 18:17:00 2041 GMT (10000 days)
Sign the certificate? [y/n]:y


1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

Mission accomplie, on peut passer à la création de la CA de signature.

Création de la CA de signature

Comme pour la CA racine, on va créer des nouveaux répertoires, et une nouvelle base de données :

mkdir -p /pki/ca/signing-ca/private /pki/ca/signing-ca/db
cp /dev/null /pki/ca/signing-ca/db/signing-ca.db
cp /dev/null /pki/ca/signing-ca/db/signing-ca.db.attr
echo 01 > /pki/ca/signing-ca/db/signing-ca.crt.serial
echo 01 > /pki/ca/signing-ca/db/signing-ca.crl.serial

De la même façon, on va créer une requête de certificat, en utilisant cette fois le fichier de configuration pour la CA de signature (/pki/etc/signing-ca.conf) :

openssl req -new -config /pki/etc/signing-ca.conf -out /pki/ca/signing-ca.csr -keyout /pki/ca/signing-ca/private/signing-ca.key

On va ensuite créer le certificat en le signant avec la CA racine, en utilisant les extensions pour la CA de signature :

openssl ca -config /pki/etc/root-ca.conf -in /pki/ca/signing-ca.csr -out /pki/ca/signing-ca.crt -extensions signing_ca_ext

La phrase de passe de la CA racine est demandée :

Using configuration from /pki/etc/root-ca.conf
Enter pass phrase for /pki/ca/root-ca/private/root-ca.key:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 2 (0x2)
        Validity
            Not Before: Oct 19 18:34:08 2013 GMT
            Not After : Mar  6 18:34:08 2041 GMT
        Subject:
            domainComponent           = net
            domainComponent           = exemple
            organizationName          = Exemple
            organizationalUnitName    = Exemple Signing CA
            commonName                = Exemple Signing CA
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            X509v3 Subject Key Identifier: 
                …
            X509v3 Authority Key Identifier: 
                keyid:…

Certificate is to be certified until Mar  6 18:34:08 2041 GMT (10000 days)
Sign the certificate? [y/n]:y


1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

Voilà. On a maintenant une autorité de certification racine, qui a signé une autorité de certification de signature, qui pourra elle-même signer des certificats serveur ou utilisateur.

Finitions

Il faut maintenant créer le .der, qui doit être diffusé à tous ceux qui veulent reconnaître cette autorité de certification :

openssl x509 -in /pki/ca/root-ca.crt -outform DER -out /pki/ca/root-ca.der

Il faut bien protéger tout ça, même si on met des passphrases. En particulier la clef de la CA racine ne doit jamais être compromise, ou c'est tout l'édifice qui s'écroule. Donc on en remet une petite couche :

chmod -R 700 /pki

Le seul fichier public est le /pki/ca/root-ca.der, qu'il faut largement diffuser (c'est la clef publique de la CA).

Création des listes de révocation

Pour la CA de signature :

openssl ca -gencrl -config /pki/etc/signing-ca.conf -out /pki/crl/signing-ca.crl

Il faut la régénérer de temps en temps, en particulier si on révoque un certificat. Pour la publier, on la convertit au format DER :

openssl crl -in /pki/crl/signing-ca.crl -out /pki/crl/signing-ca.der.crl -outform der

Chaîne de confiance

On génère un fichier contenant la « chaîne de confiance », c'est-à-dire les certificats de la racine et de l'autorité de signature :

cat /pki/ca/signing-ca.crt /pki/ca/root-ca.crt > /pki/ca/signing-ca-chain.pem

On peut alors copier ce fichier dans /etc/ssl/exemple-chain.pem pour que les différents serveurs y aient accès.

On peut aussi faire un fichier au format PKCS7, qui contient les certificats et les CRLs :

openssl crl2pkcs7 -in /pki/crl/signing-ca.crl -certfile /pki/ca/signing-ca.crt -certfile /pki/ca/root-ca.crt -out /pki/ca/signing-ca-chain.p7c -outform der

Installation du certificat de la PKI sur un client

L'idée générale est de fournir d'une manière ou d'une autre le fichier ca.der (et aucun autre !) au client. Ensuite il y a autant de méthodes que de clients.

Les méthodes décrites ici ont marché avec une version spécifique des clients, il faut adapter à la langue et à la version en cours du client. Si c'est vraiment complètement différent, demander à votre moteur de recherche préféré.

Pour les produits Mozilla (Firefox, Thunderbird, Iceweasel, Icedove,…)

Aller dans edit/preferences, dans l'onglet Advanced, cliquer sur view certificates, puis aller sur l'onglet Authorities, cliquer sur Import.

Aller chercher le fichier .der et valider. Cocher Trust this CA to identify web sites. Cocher aussi l'équivalent pour le mail pour thunderbird, puis valider.

Le certificat CA devrait apparaître dans la liste. Faites OK pour sortir.

Pour les produits KDE (Konqueror, KMail,…)

Aller dans Configuration/Configurer Konqueror. Aller dans la section Cryptographie, dans l'onglet Signataires, cliquer sur import.

Aller chercher le fichier .der et valider. Autoriser ou nom l'utilisation du certificat dans KMail puis valider pour sortir.

Pour Internet Explorer

Aller dans Outils/Options Internet, onglet contenu, cliquer sur Certificats. Aller dans l'onglet Autorités principales de confiance, et cliquer sur Importer... Suivre l'assistant et aller chercher le fichier .der (contrairement à ce qui est indiqué, il l'accepte...). Ceci fait, valider.

Génération, révocation et utilisation d'un certificat

Certificat serveur

L'exemple choisi est celui du certificat de www.exemple.net (alias exemple.net, alias machine.exemple.net).

Premièrement, il faut spécifier les subjectAltName (alias du serveur). Deux façons de faire :

NOTE : on ne sait pas où on est là. Sur le serveur ? quel répertoire ? quel fichier…

  • si on a un seul alias, on utilise la variable d'environnement $SAN :

    SAN="DNS=alias.exemple.net"

  • si on a plusieurs alias, il faut copier le fichier server.conf en nom-server.conf, puis commenter la ligne dans la section default et changer la fin du fichier par quelque chose du genre :

    […] subjectAltName = @alt_names

    [ alt_names ] DNS.1=exemple.net DNS.2=machine.exemple.net

On peut ensuite générer la requête et la clef privée (on ne met pas de passphrase ici, pour ne pas avoir à la saisir à chaque restart d'apache — valeur encrypt_key du fichier de configuration à no) :

openssl req -new -config /pki/etc/server.conf -out /pki/certs/www.exemple.net.csr -keyout /pki/certs/www.exemple.net.key

On se retrouve avec une requête pour :

Subject: DC=net, DC=exemple, O=Exemple, OU=Exemple - web, CN=www.exemple.net

ATTENTION : les 2 premiers niveaux de DC et le O doivent toujours être identiques pour des certificats chez moi.

On peut générer le certificat en le signant avec la clef privée de la CA de signature (en spécifiant les extensions server_ext qui correspondent aux options pour signer des certificats serveur) :

openssl ca -config /pki/etc/signing-ca.conf -in /pki/certs/www.exemple.net.csr -out /pki/certs/www.exemple.net.crt -extensions server_ext

Openssl demande la passphrase de la clef de la CA de signature, et génère le certicat signé. On peut alors utiliser ce certificat.

Révocation d'un certificat

La commande suivante permet de révoquer un certificat (avec la passphrase de la CA de signature) :

openssl ca -config /pki/etc/signing-ca.conf -revoke /pki/ca/signing-ca/01.pem -crl_reason superseded

À la prochaine génération de liste de révocation, le certificat révoqué sera alors inclus.

Gestion opérationnelle des certificats

Pour obtenir un .pem à partir du .crt :

openssl x509 -in /pki/certs/www.exemple.net.crt -out /etc/ssl/www.exemple.net.pem -outform PEM

Généralement, on va copier le certificat dans /etc/ssl/ et la clef dans /etc/ssl/private pour que les serveurs les chargent au démarrage.

Apache

Dans la configuration d'apache, ajouter pour le mode SSL :

NOTE : quel fichier ? quel répertoire ? on ne sait pas où on est.

SSLCertificateFile          /etc/ssl/www.exemple.net.pem
SSLCertificateKeyFile       /etc/ssl/private/www.exemple.net.key
SSLCertificateChainFile     /etc/ssl/exemple-chain.pem

Certificat www.exemple.net (/pki/ca/signing-ca/02.pem) :

Data:
    Version: 3 (0x2)
    Serial Number: 2 (0x2)
Signature Algorithm: sha256WithRSAEncryption
    Issuer: DC=net, DC=exemple, O=Exemple, OU=Exemple Signing CA, CN=Exemple Signing CA
    Validity
        Not Before: Oct 20 11:14:44 2013 GMT
        Not After : Oct 19 11:14:44 2016 GMT
    Subject: DC=net, DC=exemple, O=Exemple, OU=Exemple - web, CN=machine.exemple.net
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
            Public-Key: (2048 bit)
            Modulus:
                …
            Exponent: 65537 (0x10001)
    X509v3 extensions:
        X509v3 Key Usage: critical
            Digital Signature, Key Encipherment
        X509v3 Basic Constraints: 
            CA:FALSE
        X509v3 Extended Key Usage: 
            TLS Web Server Authentication, TLS Web Client Authentication
        X509v3 Subject Key Identifier: 
            …
        X509v3 Authority Key Identifier: 
            keyid:…

        X509v3 Subject Alternative Name: 
            DNS:exemple.net, DNS:www.exemple.net, DNS:machine.exemple.net
Signature Algorithm: sha256WithRSAEncryption
    …

Postfix

Certificat présenté par postfix pour les connexions TLS. À spécifier avec :

NOTE : c'est pas compréhensible ! Trop de mots et d'accronymes complexes. Faut préciser que l'on s'interesse aux mails au moins. Dire ce qu'est une connection TLS

smtpd_tls_cert_file=/etc/ssl/smtp.exemple.net.pem
smtpd_tls_key_file=/etc/ssl/private/smtp.exemple.net.key
smtpd_tls_CAfile=/etc/ssl/exemple-chain.pem

Et la même chose pour le client avec smtp_tls….

Data:
    Version: 3 (0x2)
    Serial Number: 4 (0x4)
Signature Algorithm: sha256WithRSAEncryption
    Issuer: DC=net, DC=exemple, O=Exemple, OU=Exemple Signing CA, CN=Exemple Signing CA
    Validity
        Not Before: Oct 20 13:41:28 2013 GMT
        Not After : Oct 19 13:41:28 2016 GMT
    Subject: DC=net, DC=exemple, O=Exemple, OU=Exemple - MTA, CN=machine.exemple.net
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
            Public-Key: (2048 bit)
            Modulus:
                …
            Exponent: 65537 (0x10001)
    X509v3 extensions:
        X509v3 Key Usage: critical
            Digital Signature, Key Encipherment
        X509v3 Basic Constraints: 
            CA:FALSE
        X509v3 Extended Key Usage: 
            TLS Web Server Authentication, TLS Web Client Authentication
        X509v3 Subject Key Identifier: 
            …
        X509v3 Authority Key Identifier: 
            keyid:…

        X509v3 Subject Alternative Name: 
            DNS:smtp.exemple.net, DNS:mx.exemple.net, DNS:machine.exemple.net
Signature Algorithm: sha256WithRSAEncryption
    …

Dovecot

Certificat utilisé pour l'imap. Ça se spécifie dans /etc/dovecot/conf.d/10-ssl.conf :

NOTE : pareil, préciser que c'est le mail et ce qu'est l'IMAP en 2 mots (protocole de réception et de synchronisation des mails avec le serveur)

ssl_cert = </etc/ssl/imap.exemple.net-chain.pem
ssl_key = </etc/ssl/private/imap.exemple.net.key

Avec :

cp /etc/ssl/imap.exemple.net.pem /etc/ssl/imap.exemple.net-chain.pem 
cat /etc/ssl/exemple-chain.pem >> /etc/ssl/imap.exemple.net-chain.pem

On peut alors redémarrer dovecot.

Data:
    Version: 3 (0x2)
    Serial Number: 5 (0x5)
Signature Algorithm: sha256WithRSAEncryption
    Issuer: DC=net, DC=exemple, O=Exemple, OU=Exemple Signing CA, CN=Exemple Signing CA
    Validity
        Not Before: Oct 20 13:41:41 2013 GMT
        Not After : Oct 19 13:41:41 2016 GMT
    Subject: DC=net, DC=exemple, O=Exemple, OU=Exemple - MDA, CN=machine.exemple.net
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
            Public-Key: (2048 bit)
            Modulus:
                …
            Exponent: 65537 (0x10001)
    X509v3 extensions:
        X509v3 Key Usage: critical
            Digital Signature, Key Encipherment
        X509v3 Basic Constraints: 
            CA:FALSE
        X509v3 Extended Key Usage: 
            TLS Web Server Authentication, TLS Web Client Authentication
        X509v3 Subject Key Identifier: 
            …
        X509v3 Authority Key Identifier: 
            keyid:…

        X509v3 Subject Alternative Name: 
            DNS:imap.exemple.net, DNS:machine.exemple.net
Signature Algorithm: sha256WithRSAEncryption
    …

Ejabberd

Certificat utilisé pour jabber. Il faut faire un seul PEM avec tout pour ejabberd :

NOTE : pareil, préciser que c'est la messagerie instantanée + faire un lien vers la page de doc de cela (?)

cp /pki/certs/xmpp.exemple.net.key /etc/ejabberd/ejabberd.pem
cat /etc/ssl/xmpp.exemple.net.pem >> /etc/ejabberd/ejabberd.pem
cat /etc/ssl/exemple-chain.pem >> /etc/ejabberd/ejabberd.pem

Et on peut ensuite redémarrer ejabberd.

Data:
    Version: 3 (0x2)
    Serial Number: 6 (0x6)
Signature Algorithm: sha256WithRSAEncryption
    Issuer: DC=net, DC=exemple, O=Exemple, OU=Exemple Signing CA, CN=Exemple Signing CA
    Validity
        Not Before: Oct 20 13:42:12 2013 GMT
        Not After : Oct 19 13:42:12 2016 GMT
    Subject: DC=net, DC=exemple, O=Exemple, OU=Exemple - Jabber, CN=machine.exemple.net
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
            Public-Key: (2048 bit)
            Modulus:
                …
            Exponent: 65537 (0x10001)
    X509v3 extensions:
        X509v3 Key Usage: critical
            Digital Signature, Key Encipherment
        X509v3 Basic Constraints: 
            CA:FALSE
        X509v3 Extended Key Usage: 
            TLS Web Server Authentication, TLS Web Client Authentication
        X509v3 Subject Key Identifier: 
            …
        X509v3 Authority Key Identifier: 
            keyid:…

        X509v3 Subject Alternative Name: 
            DNS:jabber.exemple.net, DNS:xmpp.exemple.net, DNS:machine.exemple.net, DNS:conference.jabber.exemple.net, DNS:irc.jabber.exemple.net
Signature Algorithm: sha256WithRSAEncryption
    …