Le but de ce howto et de:

Générer une demande de certificat, placer le fichiers générés sur la machine.
Disclamer: Cette procédure est faite en avril 2018. Il est nécessaire de vérifier les bonnes pratiques avant toute chose ! Les normes concernant SSL changent constamment, à cause de nouveaux périphériques, ou encore de failles comblées.

La demande de certificat

Pour obtenir un certificat, peu importe l’usage (signature de code, web, applications) il est nécessaire de générer une demande de certificat.
Globalement la demande de certificat ne contient pas grand-chose mais, par mesure de précaution, utiliser le même fichier de configuration openssl à la génération de la csr et à la signature, permet d’éviter des erreurs.

Si la clef privée existe déjà, il n’est pas nécessaire de la regénérer (hors compromissions évidemment...)

$ openssl req 
    -new 
    -key ../nailyk.fr.key 
    -nodes -sha512 
    -out nailyk.fr.csr 
    -config ./ssl.conf

Si la clef a besoin d’être générée ou regénérée :

$ openssl req 
    -new 
    -newkey rsa:8192 
    -nodes -sha512 
    -keyout nailyk.fr.key 
    -out nailyk.fr.csr 
    -config ./ssl.conf

Un exemple du fichier ssl.conf est dans l'article sur l'autorité de certification
Ici on récupère donc le fichier .csr et, si besoin, le fichier .key. La certificate request va être transmise à la CA pour validation. Le fichier contenant la clef privée doit demeurer secret (il ne sera donc jamais demandé par la CA!).

Generating a 8192 bit RSA private key
...........................................................................++
......................................................................................................++
writing new private key to 'nailyk.fr.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
State or Province Name (full name) [France]:
Locality Name (eg, city) []:
Organizational Unit Name (eg, section) [nailyk]:
Common Name (eg, YOUR name, FQDN server) [nailyk.fr]:

Il est possible de vérifier le contenu de la demande avec :

$ openssl req 
    -text 
    -noout 
    -in ./nailyk.fr.csr | less

Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: ST=France, OU=nailyk, CN=nailyk.fr
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (8192 bit)
                Modulus:
                    00:d6:c1:4a:1b:9e:16:51:71:1b:39:65:d2:c3:1e:
                    [...]
                    21:0a:c6:13:ab
                Exponent: 65537 (0x10001)
        Attributes:
        Requested Extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Key Usage:
                Digital Signature, Non Repudiation, Key Encipherment
            X509v3 Subject Alternative Name:
                DNS:blog.nailyk.fr, DNS:www.nailyk.fr, DNS:www.blog.nailyk.fr
    Signature Algorithm: sha512WithRSAEncryption
         cb:bd:06:2d:96:a3:54:a0:cd:8e:4d:27:96:23:a2:c5:f3:95:
         [...]
         fc:3d:02:09:4b:df:bb:57:26:46:58:80:90:2f:3e:08

Signature par l'autorité de certification

Les CAs reconnues

Les CAs "reconnues" vont avoir différents processus pour la validation de la certificate request. Dans tous les cas il est important de vérifier les noms de domains, des alt-names, ainsi que de la durée du certificat. Une erreur à ce niveau peu causer des plantages de services.
Certaines CAs, comme Lets encyrpt, utilisent des outils qui permettent d’automatiser tout le processus. Ici le choix s’est porté sur dehydrated ( https://github.com/lukas2511/dehydrated ) client open source, disponible dans les dépots débian (>9), très facile d’utilisation et permettant, contrairement à certbot, l’utilisation d’alternatives names.
Dans tous les cas il ne faut jamais transmettre la clef privée à la CA. Elle doit rester privée, et est uniquement nécessaire pour signer les objets. CA reconnues veut dire qu'elle est integrée par l'editeur dans votre système d'exploitation/navigateur. Certaines ne sont pas "reconnues" partout...

Les CAs internes

Une CA interne permet une plus grand flexibilité, des durée de certificats plus longues, des algorithmes spécifiques, voir même des options de signatures qui ne peuvent pas être accessibles autrement.
Dans un environnement LDAP cela ne pose pas vraiment de problème, étant donné qu’il est facile de déployer une CA à grande échelle. Sur des machines, peu souvent connectées au réseau d’entreprise, cela peut représenter plus de difficultés.
A partir du moment où la CA est disponible sur le poste utilisateur, qu’elle soit interne ou intégrée à l’OS, ne changera rien pour l’utilisateur, et sera totalement transparent.

Pour tester la validité des certificats sur votre serveur: https://www.ssllabs.com/ssltest/

Sécurisation des fichiers:

Les fichiers de clef privée (.key) et serial (.srl) ne doivent être accessible en lecture que par les services qui en ont besoin (apache par exemple)
Les fichiers de certificats sont publiques, tout le monde doit pouvoir les lire.
Quand aux fichiers csr, une fois les certificats générés, ils ne sont plus utiles.

sous *unix:

(A adapter si vous utilisez un utilisateur par vhost)

# chmod 440 *.key *.srl
# chmod 444 *.crt
$ rm *.csr
# chown www-data:ssl-cert *.*

Fortement inspiré de / sources:

http://jeyg.info/des-certificats-signes-par-votre-autorite-de-certification-avec-openssl/
http://www.linux-france.org/prj/edu/archinet/systeme/ch24s03.html (obsolète)
http://techglimpse.com/sha256-hash-certificate-openssl/

Infos intéréssantes:

https://www.sslshopper.com/article-most-common-openssl-commands.html