Pratique de TLS et des certificats

1. OpenSSL

1.1. Récupérer, visualiser, transcoder, vérifier manuellement un certificat

Visualiser un certificat :

cat /etc/pki/tls/certs/localhost.crt

Mieux présenté avec openssl :

openssl x509 -text -noout -in /etc/pki/tls/certs/localhost.crt
        Version: 3 (0x2)
        Serial Number: 28890 (0x70da)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=--, ST=SomeState, L=SomeCity, O=SomeOrganization, OU=SomeOrganizationalUnit, CN=localhost.localdomain/emailAddress=root@localhost.localdomain
            Not Before: Sep 26 13:57:53 2016 GMT
            Not After : Sep 26 13:57:53 2017 GMT
        Subject: C=--, ST=SomeState, L=SomeCity, O=SomeOrganization, OU=SomeOrganizationalUnit, CN=localhost.localdomain/emailAddress=root@localhost.localdomain
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
            X509v3 Key Usage:
                Digital Signature, Non Repudiation, Key Encipherment
    Signature Algorithm: sha256WithRSAEncryption

Récupérer un certificat X509 en ligne :

openssl s_client -showcerts -connect
depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
verify return:1
depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign CloudSSL CA - SHA256 - G3
verify return:1
depth=0 C = US, ST = California, L = San Francisco, O = "Fastly, Inc.", CN =
verify return:1
Certificate chain
 0 s:/C=US/ST=California/L=San Francisco/O=Fastly, Inc./
   i:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign CloudSSL CA - SHA256 - G3
 1 s:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign CloudSSL CA - SHA256 - G3
   i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
Server certificate
subject=/C=US/ST=California/L=San Francisco/O=Fastly, Inc./
issuer=/C=BE/O=GlobalSign nv-sa/CN=GlobalSign CloudSSL CA - SHA256 - G3
No client certificate CA names sent
Server Temp Key: ECDH, prime256v1, 256 bits
SSL handshake has read 5535 bytes and written 373 bytes
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: 639EF6139293984B77BA686502009FA32EE55CA40892D3772ECE1559DE411BA6
    Master-Key: 69CDFB6E8807850C181CE54D66676762FE1B6E5F8FE79B2D8E9CB6782EF6E5BA4A58835BC5BE3FFCC7EC11EABEB48EFD
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    TLS session ticket lifetime hint: 1200 (seconds)
    TLS session ticket:
    0000 - 63 cc 77 4a 00 db 2c 42-2e 8f 76 23 dd a9 ae 53   c.wJ..,B..v#...S
    0010 - eb f3 5b 75 31 9c 7e dd-34 0e 27 9e c5 87 6f 3e   ..[u1.~.4.'...o>
    0020 - fb fd 08 7f 4c 97 d1 e6-88 67 32 e6 95 9e 70 ee   ....L....g2...p.
    0030 - 1c 8f f2 1a 98 b6 5e 20-3d b9 14 c3 c0 61 36 5b   ......^ =....a6[
    0040 - a6 05 43 fa bc 4c b3 58-8f a4 10 76 18 a0 11 12   ..C..L.X...v....
    0050 - 1b be 0d 04 48 85 a1 44-ea fb ad a0 3d 13 85 51   ....H..D....=..Q
    0060 - 1a fb f6 95 a1 1e 06 c2-e2 c7 ba 8b de 52 9e 1d   .............R..
    0070 - 64 56 db 5a c8 0b 82 43-84 6d a0 2f 0a ef 8e ef   dV.Z...C.m./....
    0080 - 73 64 b9 c7 c3 37 d0 ce-62 d5 44 0d fd cc 2f b4   sd...7..b.D.../.
    0090 - ea 34 8c a5 eb 0f 4b 0b-2b c9 bb 58 ec c8 44 e2   .4....K.+..X..D.

    Start Time: 1475086354
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)

Script de rapatriement en format PEM :

echo | openssl s_client -connect ${host}:${port} 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'

Par exemple :

bash 443 > cisco.pem

Affichage du certificat :

openssl x509 -in cisco.pem -text -noout

Transcodage PEM vers DER :

openssl x509 -inform PEM -in cisco.pem -outform DER -out cisco.der

Affichage du certificat encodé en format DER :

openssl x509 -inform DER -in cisco.der -text

Prise de connaissance du CA :

openssl x509 -inform DER -in cisco.pem -text | grep 'Issuer'
       Issuer: C=US, O=HydrantID (Avalanche Cloud Corporation), CN=HydrantID SSL ICA G2
                CA Issuers - URI:

Récupérer le CA :


Vérifier le certificat de l’entité manuellement :

openssl verify -CAfile hydsslg2.crt cisco.crt

1.2. Créer un certificat x509 auto-signé

Création de la clé privée server.key :

openssl genrsa -out server.key 2048
Generating RSA private key, 2048 bit long modulus
e is 65537 (0x10001)

chmod 440 server.key

Avec la clé privée, création d’un fichier de demande de signature de certificat (CSR Certificate Signing Request) :

openssl req -new -key server.key -out server.req
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.
Country Name (2 letter code) [XX]:BE
State or Province Name (full name) []:Brussels
Locality Name (eg, city) [Default City]:Brussels
Organization Name (eg, company) [Default Company Ltd]:Linux
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Auto-signature :

openssl x509 -req -days 365 -in server.req -signkey server.key -out server.crt
Signature ok
Getting Private key

Affichage du certificat :

openssl x509 -text -noout -in server.crt
        Version: 1 (0x0)
        Serial Number: 10940766965370417421 (0x97d569969d3b710d)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=BE, ST=Brussels, L=Brussels, O=Linux
            Not Before: Sep 28 18:31:12 2016 GMT
            Not After : Sep 28 18:31:12 2017 GMT
        Subject: C=BE, ST=Brussels, L=Brussels, O=Linux
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Exponent: 65537 (0x10001)
    Signature Algorithm: sha1WithRSAEncryption

1.3. Tester une liaison TLS

Arrêter le pare-feu :

# systemctl stop firewalld
# iptables -X
# iptables -F
# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

openssl s_server -accept 5000 -cert server.crt -key server.key -www -state

Tester la connexion :

curl ...

1.4. Créer un CA, signer des certificats (1)

1.5. Créer un CA, signer des certificats (2)

1.6. Révoquer un certificat

1.7. Créer un certificat pour une personne

2. Stunnel 4

3. Easy-RSA

easy-rsa - Simple shell based CA utilityx est un ensemble de script pour gérer les scripts d’une autorité de certification.

Terminologie utilisée

Pour éviter toute confusion, les termes suivants seront utilisés dans toute la documentation Easy-RSA. Les formulaires courts peuvent être remplacés par des formulaires plus longs si cela est pratique.

  • PKI : Infrastructure à clé publique. Cette section décrit l’ensemble des fichiers et des associations entre l’AC, les paires de clés, les requêtes et les certificats.
  • CA : Autorité de certification. C’est le “master cert” à la base d’une ICP.
  • cert : Certificat. Un certificat est une demande qui a été signée par un AC. Le certificat contient la clé publique, quelques détails décrivant le certificat lui-même et une signature numérique de l’AC.
  • request : Demande de certificat (en option’req’.) Il s’agit d’une demande de certificat qui est ensuite envoyée à une AC pour signature. Une demande contient les informations de certification souhaitées ainsi qu’une signature numérique de la clé privée.
  • paire de clés (keypair) : Une paire de clés est une paire de clés cryptographiques asymétriques. Ces clés sont divisées en deux parties : les clés publiques et les clés privées. La clé publique est incluse dans une demande et un certificat.

L’Autorité de certification (AC)

Le coeur d’une PKI est l’AC, ou Autorité de certification, et c’est aussi l’autorité la plus sensible en matière de sécurité. La clé privée de l’AC est utilisée pour signer tous les certificats émis, de sorte que sa sécurité est essentielle pour assurer la sécurité de l’ICP entière. Pour cette raison, il est fortement recommandé de conserver la structure de l’ICP de l’AC sur un système dédié à un tel usage sécurisé ; ce n’est pas une bonne idée de conserver l’ICP de l’AC mélangée à celle utilisée pour générer des certificats d’entité finale, comme des clients ou des serveurs (VPN ou serveurs Web).

Pour démarrer une nouvelle PKI, l’AC est d’abord créée sur l’environnement sécurisé. Selon les besoins de sécurité, cela peut être géré sous un compte verrouillé, un système dédié, ou même un système complètement hors ligne ou en utilisant des supports amovibles pour améliorer la sécurité (après tout, vous ne pouvez pas subir une intrusion en ligne si votre système ou PKI n’est pas en ligne). Les étapes exactes de création d’une AC sont décrites dans une section distincte. Lors de la création d’une nouvelle AC, la paire de clés de l’AC (clés privées et publiques) est créée, ainsi que la structure de fichier nécessaire à la signature des certificats émis.

Une fois qu’une AC a été créée, elle peut recevoir les demandes de certificat des entités finales. Ces certificats d’entité sont délivrés aux consommateurs de certificats X509, tels qu’un client ou un serveur d’un système VPN, Web ou de messagerie électronique. Les demandes de certificats et les certificats ne sont pas sensibles du point de vue de la sécurité et peuvent être transférés par n’importe quel moyen pratique, comme le courrier électronique, la clé USB, etc. Pour plus de sécurité, il est conseillé de vérifier que la demande reçue correspond à la copie de l’expéditeur, par exemple en vérifiant la somme de contrôle attendue par rapport à l’original de l’expéditeur.

Paires de clés et demandes

Les entités finales individuelles n’ont pas besoin d’une configuration complète de l’AC et n’auront qu’à créer une paire de clés et une demande de certificat associée. La clé privée n’est utilisée nulle part, sauf sur cette entité, et ne devrait jamais quitter ce système. Il est sage de sécuriser cette clé privée avec une phrase de passe forte, car en cas de perte ou de vol, le détenteur de la clé privée peut effectuer des connexions apparaissant comme le détenteur du certificat.

Une fois qu’une paire de clés est générée, la demande de certificat est créée et signée numériquement à l’aide de la clé privée. Cette demande sera envoyée à un AC pour signature et un certificat signé sera retourné.

Comment les demandes deviennent des certificats

Après qu’une AC ait signé la demande de certificat, un certificat signé est produit. Dans cette étape, la clé privée de l’AC est utilisée pour signer numériquement la clé publique de l’entité afin que tout système faisant confiance au certificat de l’AC puisse implicitement faire confiance au certificat nouvellement émis. Ce certificat signé est ensuite renvoyé à l’entité requérante. Le certificat émis n’est pas sensible du point de vue de la sécurité et peut être envoyé par des méthodes de transmission en texte clair.

Vérification d’un certificat délivré

Une fois que deux entités ont créé des paires de clés, envoyé leurs demandes à l’AC et reçu une copie de leurs certificats signés et du certificat de l’AC, elles peuvent s’authentifier mutuellement l’une l’autre. Ce processus n’exige pas que les deux entités aient préalablement échangé directement des renseignements sur la sécurité.

Lors du handshake TLS, chaque côté de la connexion présente sa propre chaîne de certification à l’extrémité distante. Chaque partie vérifie la validité du certificat reçu par rapport à sa propre copie du certificat de l’AC. En faisant confiance au CA root cert, le pair auquel ils s’adressent peut être authentifié.

L’extrémité distante prouve qu’il s’agit bien de l’entité identifiée par le certificat en signant un bit de données à l’aide de sa propre clé privée. Seul le détenteur de la clé privée est en mesure de le faire, ce qui permet à l’extrémité distante de vérifier l’authenticité du système auquel elle est connectée.

Etude de cas VPN “Road Warrior”

4. Mise en oeuvre d’HTTPS avec Apache 2

2.1. Installation de HTTPd Server sur Centos

Après une installation RHEL7 / Centos 7 :

yum install -y curl
yum groupinstall -y "Web Server"
echo "" >> /etc/hosts
echo "ServerName" >> /etc/httpd/conf/httpd.conf
systemctl enable httpd
systemctl start httpd
systemctl enable firewalld
systemctl start firewalld
firewall-cmd --permanent --add-service=http
firewall-cmd --reload

Examen des emplacements du logiciel

La commande rpm -ql donne la liste des fichiers du paquetage httpd :

rpm -ql httpd

Principalement, on retouve les emplacements (pour Centos/RHEL) :

  • /etc/httpd/ avec notamment le fichier principal de configuration httpd.conf : fichiers de configuration.
  • /etc/httpd/conf.d/ : fichiers de configuration supplémentaires (vhosts).
  • /usr/lib64/httpd/ modules et librairies.
  • /usr/sbin/ binaires : httpd, apachectl, etc.
  • /usr/share/doc/httpd-*/ : documentation.
  • /var/log/httpd/ : emplacement des logs par défaut.
  • /var/www/html/ : emplacement par défaut des pages à servir.

2.2. Configurer un hôte virtuel

Fichier de configuration

cat /usr/share/doc/httpd*/httpd-vhosts.conf
# Virtual Hosts
# Required modules: mod_log_config

# If you want to maintain multiple domains/hostnames on your
# machine you can setup VirtualHost containers for them. Most configurations
# use only name-based virtual hosts so the server doesn't need to worry about
# IP addresses. This is indicated by the asterisks in the directives below.
# Please see the documentation at
# <URL:>
# for further details before you try to setup virtual hosts.
# You may use the command line option '-S' to verify your virtual host
# configuration.

# VirtualHost example:
# Almost any Apache directive may go into a VirtualHost container.
# The first VirtualHost section is used for all requests that do not
# match a ServerName or ServerAlias in any <VirtualHost> block.
<VirtualHost *:@@Port@@>
DocumentRoot "@@ServerRoot@@/docs/"
ErrorLog "/var/log/httpd/"
CustomLog "/var/log/httpd/" common

<VirtualHost *:@@Port@@>
DocumentRoot "@@ServerRoot@@/docs/"
ErrorLog "/var/log/httpd/"
CustomLog "/var/log/httpd/" common

Mise en place d’un hôte virtuel HTTP

Mise en place pour l’hôte virtuel

Le principe consiste à adapter la copie de ce fichier d’exemple dans /etc/httpd/conf.d/ sous le nom

Pour rendre nos opérations plus souples, notamment si vous voulez choisir un autre nom de domaine, on propose de placer le nom de domaine en variable :


Résolution de nom locale

echo " ${httpdomain}" >> /etc/hosts

Création du dossier et des pages Web

mkdir -p /var/www/html/${httpdomain}
echo "${httpdomain} test page" > /var/www/html/${httpdomain}/index.html

Restauration de la policy Selinux sur le dossier créé

restorecon -Rv /var/www/html/${httpdomain}

Création du dossier et des fichiers pour les logs

mkdir -p /var/log/httpd
touch /var/log/httpd/${httpdomain}-error_log
touch /var/log/httpd/${httpdomain}-access_log

Configuration du vhost HTTP

cat << EOF > /etc/httpd/conf.d/${httpdomain}.conf
<VirtualHost *:80>
ServerAdmin webmaster@${httpdomain}
DocumentRoot /var/www/html/${httpdomain}
ServerName ${httpdomain}
ErrorLog /var/log/httpd/${httpdomain}-error_log
CustomLog /var/log/httpd/${httpdomain}-access_log common

Redémarrage du service

apachectl restart


curl ${httpdomain}
VirtualHost configuration:
*:80          (/etc/httpd/conf.d/
*:443         (/etc/httpd/conf.d/ssl.conf:56)


bash -x
#!/bin/bash in Centos7
access_log="/var/log/httpd/${host}-access_log common"
#Résolution de nom locale
echo " ${host}" >> /etc/hosts
#Création du dossier et des pages Web
mkdir -p ${location}/${host}
echo "${host} test page" > ${location}/${host}/index.html
#Restauration de la policy Selinux sur le dossier créé
restorecon -Rv ${location}/${host}
#Création du dossier et des fichiers pour les logs
mkdir -p /var/log/httpd
touch /var/log/httpd/${host}-error_log
touch /var/log/httpd/${host}-access_log
#Configuration du vhost
cat << EOF > /etc/httpd/conf.d/${host}.conf
<VirtualHost *:${port}>
ServerAdmin webmaster@${host}
DocumentRoot ${location}/${host}
ServerName ${host}
ErrorLog ${error_log}
CustomLog ${access_log}
#Activation et lancement du service
systemctl enable httpd
systemctl start httpd
systemctl restart httpd
curl ${host}

2.3. Configuration d’un vhost en HTTPS

Trois possibilités pour faire fonctionner HTTPS avec des certificats x509 :

  1. Générer un CSR et le soumettre à un CA (Autorité de Certification) : le plus fonctionnel et sûr, mais moins souple et le plus coûteux sur le plan financier et administratif.
  2. Générer un certificat auto-signé : coût nul, mais pose un problème de sécurité qui peut devenir indépassable pour certaines applications. Utile pour des environnement de développement ou pour assurer la confidentialité simplement.
  3. Let’s Encrypt : coût nul, facile à déployer, sûr.

Aussi, il s’agit de s’intéresser à la force des certificats et aux protocoles autorisés.

Différentes méthodes sont disponibles, certaines valides dans tous les cas ou uniquement sous cette distribution RHEL7/Centos7.

Toujours pour une question de souplesse, on propose de placer le nom de domaine en variable :


Force des certificats

“Red Hat Keypair Generation (c)” tout-en-un

L’utilitaire ``crypto-utils` crée les configurations HTTPS pour Apache.

yum install -y crypto-utils
genkey --help
Unknown option: help
Usage: genkey [options] servername
    --test   Test mode, faster seeding, overwrite existing key
    --genreq Generate a Certificate Signing Request (CSR)
    --makeca Generate a self-signed certificate for a CA
    --days   Days until expiry of self-signed certificate (default 30)
    --renew  CSR is for cert renewal, reusing existing key pair, openssl certs only
    --cacert Renewal is for a CA certificate, needed for openssl certs only
    --nss    Use the nss database for keys and certificates
    --gdb    For package maintainers, to trace into the nss utilities
genkey ${httpdomain}

Génération du certificat public et de la clé auto-signée

openssl req -nodes -x509 -newkey rsa:4096 -days 365 \
-out /etc/pki/tls/certs/${httpdomain}.crt \
-keyout /etc/pki/tls/private/${httpdomain}.key \
-subj "/C=BE/ST=Brussels/L=Brussels/O=IT/CN=${httpdomain}"

Génération d’un CSR en manuel

  • Génération d’un clé sécurisée et non sécurisée
  • Génération du CSR

Eventuellement, auto-signer la requête CSR avec sa propre clé.

Si plusieurs certificats sont à gérér en interne, il est peut être nécessaire d’implémenter une autorité de certification (CA).

Ansible : Module command

Fonctionne mais “brut de décoffrage”.

- name: Install nginx and python-openssl
      - nginx
      - python-openssl
    update_cache: yes
    cache_valid_time: 3600

- name: Create self-signed certificate, if configured.
  command: >
    openssl req -x509 -nodes -subj '/CN=localhost' -days 365
    -newkey rsa:4096 -sha256 -keyout  -out 
  notify: restart nginx

- name: "fix right on key file"
    name: ""
    mode: 0600
  notify: restart nginx

Ansible : Modules openssl_privatekey, openssl_csr, openssl_certificate

Beaucoup plus élégante.

- name: Generate an OpenSSL private key.
    path: ""
  notify: restart nginx

- name: Generate an OpenSSL CSR.
    path: ""
    privatekey_path: ""
    common_name: localhost
  notify: restart nginx

- name: Generate a Self Signed OpenSSL certificate.
    path: ""
    privatekey_path: ""
    csr_path: ""
    provider: selfsigned
  notify: restart nginx

- name: "fix right on key file"
    name: ""
    mode: 0600
  notify: restart nginx

Fichier de configuration du vhost HTTPS par défaut

A l’installation du groupe “Web Server” sous Centos7/RHEL7, un fichier /etc/httpd/conf.d/ssl.conf active par défaut un vhost HTTPS (yum install -y mod_ssl), celui sert par défaut les pages en HTTPS.

grep -v '^$\|^\s*\#' /etc/httpd/conf.d/ssl.conf
Listen 443 https
SSLPassPhraseDialog exec:/usr/libexec/httpd-ssl-pass-dialog
SSLSessionCache         shmcb:/run/httpd/sslcache(512000)
SSLSessionCacheTimeout  300
SSLRandomSeed startup file:/dev/urandom  256
SSLRandomSeed connect builtin
SSLCryptoDevice builtin
<VirtualHost _default_:443>
ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn
SSLEngine on
SSLProtocol all -SSLv2
SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
<Files ~ "\.(cgi|shtml|phtml|php3?)$">
    SSLOptions +StdEnvVars
<Directory "/var/www/cgi-bin">
    SSLOptions +StdEnvVars
BrowserMatch "MSIE [2-5]" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0
CustomLog logs/ssl_request_log \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

On peut le désactiver en renommant ce fichier autrement qu’en .conf.

mv /etc/httpd/conf.d/ssl.conf /etc/httpd/conf.d/ssl.conf.bak

Nouveau vhost HTTPS

Par rapport à une configuration HTTP simple, quelques directives comme SSLCertificateFile, SSLCertificateKeyFile ainsi que d’autres paramètres comme le port d’écoute TCP 443 sont à ajouter/adapter. On ajoutera cette entrée dans le fichier de configuration.

cat << EOF >> /etc/httpd/conf.d/
<VirtualHost *:443>
DocumentRoot /var/www/html/
ErrorLog /var/log/httpd/
CustomLog /var/log/httpd/ common
    SSLEngine on
    # 128-bit mini anti-beast
    # 128-bit mini PFS favorisé
    #SSLCipherSuite !EDH:!ADH:!DSS:!RC2:HIGH:MEDIUM:+3DES:+RC4
    # 128-bit securité maximale
    SSLCipherSuite !EDH:!ADH:!DSS:!RC4:HIGH:+3DES
    SSLProtocol all -SSLv2 -SSLv3
    SSLCertificateFile /etc/pki/tls/certs/
    SSLCertificateKeyFile /etc/pki/tls/private/

Vérifier la configuration.

apachectl configtest

Redémarrer le service et adapter le pare-feu.

apachectl reload
firewall-cmd --permanent --add-service=https
firewall-cmd --reload


VirtualHost configuration:
*:80          (/etc/httpd/conf.d/
*:443                  is a NameVirtualHost
         default server (/etc/httpd/conf.d/
         port 443 namevhost (/etc/httpd/conf.d/
         port 443 namevhost (/etc/httpd/conf.d/ssl.conf:56)

Vérification client/serveur HTTP.

curl test page

Vérification client/serveur HTTPS.

curl -k test page

Vérification du certificat.

openssl s_client -connect -state


Source :

bash -x
#!/bin/bash in Centos7
access_log="/var/log/httpd/${host}-access_log common"
#Résolution de nom locale
echo " ${host}" >> /etc/hosts
#Création du dossier et des pages Web
mkdir -p ${location}/${host}
echo "${host} test page" > ${location}/${host}/index.html
#Restauration de la policy Selinux sur le dossier créé
restorecon -Rv ${location}/${host}
#Création du dossier et des fichiers pour les logs
mkdir -p /var/log/httpd
touch ${error_log}
touch ${access_log}
#Configuration du vhost HTTPS
cat << EOF >> /etc/httpd/conf.d/${host}.conf
<VirtualHost *:${port}>
ServerAdmin webmaster@${host}
DocumentRoot ${location}/${host}
ServerName ${host}
ErrorLog ${error_log}
CustomLog ${access_log} common
    SSLEngine on
    SSLCipherSuite !EDH:!ADH:!DSS:!RC4:HIGH:+3DES
    SSLProtocol all -SSLv2 -SSLv3
    SSLCertificateFile /etc/pki/tls/certs/${host}.crt
    SSLCertificateKeyFile /etc/pki/tls/private/${host}.key
#Génération du certificat auto-signé
openssl req -nodes -x509 -newkey rsa:4096 \
-out /etc/pki/tls/certs/${host}.crt \
-keyout /etc/pki/tls/private/${host}.key \
-days 365 \
-subj "/C=BE/ST=Brussels/L=Brussels/O=webteam/CN=${host}"
#Activation et lancement du service
systemctl enable httpd
systemctl start httpd
systemctl restart httpd
curl https://${host}

Redirection HTTP vers HTTPS

Voir Let’s Encrypt.

Script vhost-creator

Pour la curiosité.

Source :

1.8. Let’s Encrypt en Centos 7 pour Apache

Source :

Installation du logiciel (Centos 7)

sudo yum - y install epel-release
sudo yum - y install snapd
sudo systemctl enable --now snapd.socket
sudo ln -s /var/lib/snapd/snap /snap
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

Démarrage rapide

certbot --apache
certbot --apache certonly
certbot renew --dry-run

Fonction Let’s Encrypt pour une installation silencieuse

https_installation() {
# Three times if DNS failure
certbot --apache --register-unsafely-without-email --agree-tos -d "${site_name}" -n || \
certbot --apache --register-unsafely-without-email --agree-tos -d "${site_name}" -n || \
certbot --apache --register-unsafely-without-email --agree-tos -d "${site_name}" -n
(crontab -l 2>/dev/null; echo "0 0,12 * * * python -c "import random; import time; time.sleep(random.random() * 3600)" && certbot renew") | crontab -

Laisser un commentaire