Apache 2.4. Virtual hosts sous Windows en HTTPS / SSL avec des certificats auto signés. Création et automatisation par macro

Introduction

C’est à présent incontournable, bien au delà des gains en performances possibles et des nouvelles fonctionnalités avec le protocole HTTP 2, exploitable uniquement en HTTPS/SSL (Secure Socket Layer), Google l’a annoncé : HTTPS Everywhere ! (vidéo YouTube). Les robots de Google, Google Analytics… délaisseront petit à petit les sites Web qui tournent encore avec le protocole non sécurisé HTTP.

Migrer son site en production en "live" ! Non, bien entendu, il y a quand même une phase de migration plus ou moins importante à réaliser. Si vous développez en local sur votre PC windows avec des hôtes virtuels en HTTP (Apache 2.4 / PHP, création et automatisation des virtual hosts avec le module des macros (mod_macro)), ces hôtes virtuels peuvent être définis en HTTPS/SSL de la même manière par macro avec Apache 2.4.

Il faut juste bien comprendre la mécanique des certificats, pas évidente du tout au premier abord pour un néophyte (comme l’auteur de ce papier).

Dans le domaine de la production, les certificats SSL (payants ou non, tout dépend du type de certificat) sont délivrés par une liste d’autorités de confiance connues des navigateurs (Chrome, Firefox, Internet Explorer…), par exemple Global Sign.

Un petit dessin pour comprendre le mécanisme qui peut être schématisé ainsi :

Les autorités de confiance qui délivrent les certificats SSL sont connues par les navigateurs grâce à un certificat public (par autorité). Ces certificats sont stockés dans le magasin des certificats des autorités de confiance racines du client (Windows…).
Pour un domaine donné, une clé privée pour le serveur Apache est créée. Le choix de l’algorithme de cryptographie (SHA-256…) revient au détenteur du domaine.
Une demande de signature de certificat (Common Signing Request) associée à cette clé privée est adressée à une autorité de certification.
En retour (moyennant paiement selon le type de certificat), l’autorité de certification signe et renvoie un certificat public SSL qui devra être installé dans le serveur Apache. Le certificat public délivré est couplé avec la clé privée, les deux sont indissociables, ils vont de pair.

Comment simuler une telle mécanique en local sur son PC pour ses domaines virtuels en HTTPS/SSL ? Réponse : avec OpenSSL (Open Secure Socket Layer) et les certificats auto-signés (self signed certificates).

La société fantôme SQLPAC jouera le rôle d’autorité de certification (CA : Certification Authority).

Grosso modo, pour le domaine virtuel HTTPS/SSL sqlpac.ppd :

Un certificat public pour l’autorité de certification SQLPAC (sqlpac-ca.cer) est généré puis importé dans le magasin de certificats des autorités de confiance du client.
Une clé privée associée au domaine sqlpac.ppd est créée sur le serveur Apache.
Associée à cette clé privée, une demande de signature de certificat (Common Signature Request - CSR) est générée.
La signature est réalisée par l’autorité de confiance SQLPAC avec en retour le certificat public destiné au serveur Apache pour le domaine sqlpac.ppd.

Dans la suite de cet article, 3 hôtes virtuels sont implémentés en local sur le PC Windows

C:\Windows\system32\drivers\etc\hosts

# localhost name resolution is handled within DNS itself.
#	127.0.0.1       localhost
#	::1             localhost

127.0.0.1	www.sqlpac.dvt
127.0.0.1	www.sqlpac.ppd
127.0.0.1	www.sqlpac.dbg

Le répertoire d’installation du serveur Apache 2.4 est identifié par la variable %APACHE_HOME%.

% set APACHE_HOME=D:\software\apache\apache-2.4

Création d’un certificat auto signé (self signed) avec OpenSSL

OpenSSL (Open Secure Socket Layer) est utilisé afin de générer les certificats et clés nécessaires pour l’autorité de certification (SQLPAC) et le domaine virtuel *.sqlpac.ppd.

OpenSSL est disponible dans la distribution Apache 2.4 lorsqu’elle est téléchargée depuis Apache Haus (Downloads - Apache 2.4 Server Binaries).

openssl est installé dans le répertoire %APACHE_HOME%/bin.

Sous Windows, le fichier de configuration d’OpenSSL doit être spécifié avec la variable %OPENSSL_CONF%, dans le cas contraire, openssl cherche son fichier openssl.cnf par défaut dans des répertoires inexistants (/usr/local/ssl…)

%APACHE_HOME%> set OPENSSL_CONF=%APACHE_HOME%\conf\openssl.cnf

4 étapes :

Génération d’une clé privée RSA pour l’autorité de certification (CA - Certificate Authority), ici sqlpac.
Génération d’un certificat public pour l’autorité de certification sqlpac et qui sera à destination du magasin des certificats des autorités de confiance des clients (Chrome, Firefox…).
Création de la clé privée du domaine sqlpac.ppd sur le serveur Apache et de la demande de signature du certificat associée (CSR - Certificate Signing Request).
Signature et génération du certificat public du domaine sqlpac.ppd pour le serveur Apache par l’autorité de certification SQLPAC.

Génération de la clé privée RSA pour l’autorité de certification SQLPAC (sqlpac.ca.key)

SQLPAC va jouer le rôle d’autorité de certification lors de la signature des certificats.

Une clé privée RSA pour SQLPAC d’une longueur de 2048 bytes, longueur préconisée par Google, est créée et sauvegardée dans le fichier %APACHE_HOME%\certificates\sqlpac.ca.key. Dans une invite de commandes DOS en tant qu’administrateur :

%APACHE_HOME%> set OPENSSL_CONF=%APACHE_HOME%\conf\openssl.cnf

%APACHE_HOME%> .\bin\openssl genrsa -out .\certificates\sqlpac.ca.key 2048
          Generating RSA private key, 2048 bit long modulus
.........+++++
........................+++++
e is 65537 (0x10001)

Dans cette configuration, aucun mot de passe (passphrase) n’est appliqué sur la clé RSA, pour appliquer un mot de passe si besoin il y a, ajouter le flag cypher -des3 ou -aes256, le mot de passe est demandé à la génération de la clé.

Génération du certificat public de l’autorité de certification SQLPAC à destination des clients (sqlpac-ca.cer)

Le certificat public de l’autorité SQLPAC (sqlpac-ca.cer) est généré en lui associant la clé privée RSA précédemment créée. C’est ce fichier qui sera importé dans le magasin de certificats des autorités de confiance racines du client :

%APACHE_HOME%> set OPENSSL_CONF=%APACHE_HOME%\conf\openssl.cnf
          
%APACHE_HOME%> .\bin\openssl req -x509 -new -nodes
                             -key .\certificates\sqlpac.ca.key
                             -sha256
                             -days 3650
                             -out .\certificates\sqlpac-ca.cer
                             -subj "/O=SQLPAC/CN=SQLPAC CA - Certification authority/OU=SQLPAC CA - Certification authority"

La syntaxe de base pour nos besoins est simple.

-x509 : demande de génération d’un certificat X.509.
-days 3650 : période avant expiration du certificat, ici 10 ans.
-sha256 : l’algorithme d’encryption SHA-256 est utilisé, par défaut c’est l’algorithme SHA-1, plus faible d’un point de vue sécurité.
-new : génération d’une nouvelle clé publique.
-nodes : pas de phrase secrète.
-key .\certificates\sqlpac.ca.key : fichier de la clé RSA privée de l’autorité de certification (SQLPAC).
-out .\certificates\sqlpac-ca.cer : fichier en sortie du certificat public de l’autorité SQLPAC.
-subj "/O=SQLPAC/CN=SQLPAC CA - Certification authority" : applique l’organisation (/O=SQLPAC) et le nom commun (/CN=SQLPAC CA - Certification authority). Lorsqu’ils ne sont pas spécifiés, openssl demande leur saisie.

C’est le nom commun (CN) qui donne le libellé du certificat public dans le magasin des certificats.

Création de la clé privée pour Apache et de la demande de signature associée (CSR)

À cette étape :

Le certificat privé pour Apache avec une nouvelle clé est créée (sqlpac.ppd.key). Le certificat est associé au domaine sqlpac.ppd.
Une demande de signature est émise en même temps (sqlpac.ppd.csr) pour ce certificat privé. La demande est alors traitée par l’hébergeur vers les autorités nécessaires en fonction de ses procédures internes afin d’obtenir en retour le certificat public pour Apache correspondant. Ici ce n’est pas le cas, le certificat va être auto signé en local par SQLPAC avec openssl.

%APACHE_HOME%> set OPENSSL_CONF=%APACHE_HOME%\conf\openssl.cnf
          
%APACHE_HOME%> .\bin\openssl req -new -sha256 -nodes
                             -out .\certificates\sqlpac.ppd.csr
                             -newkey rsa:2048 -keyout .\certificates\sqlpac.ppd.key
                             -subj "/O=SQLPAC/CN=sqlpac.ppd"
           
           Generating a RSA private key
....+++++
...+++++
writing new private key to '.\certificates\sqlpac.ppd.key'

Le paramètre CN DOIT être rigoureusement identique au paramètre ServerName qui sera défini plus tard dans la configuration Apache !

CN=sqlpac.ppd

Signature du certificat et obtention du certificat public pour Apache

Une fois la demande de signature générée (sqlpac.ppd.csr), la signature est alors réalisée par l’autorité SQLPAC avec en sortie le certificat public pour Apache (sqlpac.ppd.crt).

%APACHE_HOME%> set OPENSSL_CONF=%APACHE_HOME%\conf\openssl.cnf
          
%APACHE_HOME%> .\bin\openssl x509 -req
                                  -in .\certificates\sqlpac.ppd.csr
                                  -CAkey .\certificates\sqlpac.ca.key
                                  -CA .\certificates\sqlpac-ca.cer
                                  -CAcreateserial -CAserial .\certificates\sqlpac.ppd.serial
                                  -out .\certificates\sqlpac.ppd.crt
                                  -days 3650
                                  -sha256
                                  -extfile .\certificates\sqlpac.ppd.sslv3.txt

-in .\certificates\sqlpac.ppd.csr : en entrée la demande de signature.
-CAkey .\certificates\sqlpac.ca.key : la clé privée RSA de l’autorité de certification CA (SQLPAC).
-CA .\certificates\sqlpac-ca.cer : le certificat public de l’autorité de certification CA (SQLPAC).
-CAcreateserial -CAserial .\certificates\sqlpac.ppd.serial : optionnel, génération d’un numéro de série.
-out .\certificates\sqlpac.ppd.crt : en sortie, le certificat public signé pour Apache.

Le fichier sqlpac.ppd.sslv3.txt donné en entrée avec l’argument -extfile est TRÈS important, il donne des paramètres pour SSL v3 et surtout il spécifie les domaines alternatifs (sqlpac.ppd, *.sqlpac.ppd, www.sqlpac.ppd…). Si le certificat est défini pour sqlpac.ppd sans spécifier les noms alternatifs possibles (*.sqlpac.ppd…), www.sqlpac.ppd est alors par exemple rejeté dans la communication HTTPS/SSL.

.\certificates\sqlpac.ppd.sslv3.txt

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = sqlpac.ppd
DNS.2 = *.sqlpac.ppd

La signature est confirmée à l’exécution de la commande :

Signature ok
subject=/O=SQLPAC/CN=sqlpac.ppd
Getting CA Private Key

Pour visualiser le contenu du certificat public signé pour Apache :

%APACHE_HOME% > .\bin\openssl x509 -in .\certificates\sqlpac.ppd.crt -noout -text
           
           Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            88:bf:87:10:df:1e:6b:7f
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: O=SQLPAC, CN=SQLPAC CA - Certification authority, OU=SQLPAC CA - Certification authority
        Validity
            Not Before: Apr 12 14:45:43 2019 GMT
            Not After : Apr  9 14:45:43 2029 GMT
        Subject: O=SQLPAC, CN=sqlpac.ppd
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:95:59:0f:14:ca:19:a8:0e:66:24:0a:c2:e3:e9:
                    ca:a2:67:b4:a3:a2:58:20:a2:bc:2b:59:fd:6b:eb:
                    ...
           
        X509v3 extensions:
            X509v3 Authority Key Identifier:
                keyid:A7:2D:A7:E6:1A:12:5C:8C:35:45:06:86:F3:CD:62:11:01:AD:0A:EF

            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Key Usage:
                Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
            X509v3 Subject Alternative Name:
                DNS:sqlpac.ppd, DNS:*.sqlpac.ppd
    Signature Algorithm: sha256WithRSAEncryption
         4f:67:c9:36:16:92:fe:e0:5f:6b:03:5f:a7:3d:ae:79:a5:65:
           ....

Configuration du serveur Apache pour SSL

Pour activer la couche HTTPS/SSL avec Apache 2.4, activer le module SSL dans le fichier de configuration httpd.conf :

%APACHE_HOME%\conf\httpd.conf

LoadModule ssl_module modules/mod_ssl.so

Embarquer la configuration SSL définie dans le fichier %APACHE_HOME%\conf\extra\httpd-ssl.conf avec la directive Include :

%APACHE_HOME%\conf\httpd.conf

<IfModule ssl_module>
Include conf/extra/httpd-ssl.conf

SSLRandomSeed startup builtin
SSLRandomSeed connect builtin
</IfModule>

Dans le fichier de configuration %APACHE_HOME%\conf\extra\httpd-ssl.conf, des options supplémentaires pour le SSL sont définies, notamment le port d’écoute (par défaut 443) :

%APACHE_HOME%\conf\extra\httpd-ssl.conf

Listen 443

Mettre en commentaire l’intégralité de la configuration du virtual host par défaut proposée dans le fichier %APACHE_HOME%\conf\extra\httpd-ssl.conf, il n’est pas nécessaire que le serveur Apache charge cette configuration.

%APACHE_HOME%\conf\extra\httpd-ssl.conf

# <VirtualHost _default_:443>

#   General setup for the virtual host
# DocumentRoot "${SRVROOT}/htdocs"
# ServerName www.example.com:443
# ...
# </VirtualHost>

Configuration SSL pour le virtual host www.sqlpac.ppd

Le virtual host www.sqlpac.ppd en HTTPS/SSL est défini dans un nouveau fichier de configuration %APACHE_HOME%\conf\extra\httpd-ssl-sqlpac-ppd.conf, configuration sourcée avec la directive Include:

%APACHE_HOME%\conf\httpd.conf

<IfModule ssl_module>
  Include conf/extra/httpd-ssl-sqlpac-ppd.conf
</IfModule>

Dans le fichier de configuration %APACHE_HOME%\conf\extra\httpd-ssl-sqlpac-ppd.conf, le port 443 est donné.

SSLEngine est à on.
SSLProtocol est à all -SSLv2 : tous les protocoles SSL sauf SSL v2.
La clé privée est donnée avec la directive SSLCertificateKeyFile.
Le certificat public signé est donné avec le paramètre SSLCertificateFile.

%APACHE_HOME%\conf\extra\httpd-ssl-sqlpac-ppd.conf

<VirtualHost *:443>

  DocumentRoot "D:/www/preproduction"
  ServerName sqlpac.ppd:443
  ServerAlias www.sqlpac.ppd:443
  
  ErrorLog "${SRVROOT}/logs/www.sqlpac.ppd.ssl-error.log"
  CustomLog "${SRVROOT}/logs/www.sqlpac.ppd.ssl-access.log" common
  CustomLog "${SRVROOT}/logs/ssl_request.log" \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

  SSLEngine on

  SSLProtocol all -SSLv2
  SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
  SSLCertificateFile "${SRVROOT}/certificates/sqlpac.ppd.crt"
  SSLCertificateKeyFile "${SRVROOT}/certificates/sqlpac.ppd.key"
  
  <Directory "D:/www/preproduction">
      Options -Indexes +FollowSymLinks
      Options +ExecCGI
      AllowOverride All
      Require all granted
  </Directory>
  
  FcgidInitialEnv PHPRC "D:/software/scripts/php-7.3.4"
  AddHandler fcgid-script .php .inc .html
  FcgidWrapper "D:/software/scripts/php-7.3.4/php-cgi.exe" .php
  FcgidWrapper "D:/software/scripts/php-7.3.4/php-cgi.exe" .inc
  FcgidWrapper "D:/software/scripts/php-7.3.4/php-cgi.exe" .html	

</VirtualHost>

Redémarrer le serveur Apache.

Avant de tenter d’ouvrir des pages en HTTPS dans un navigateur sur le domaine www.sqlpac.ppd, et au delà des messages d’erreur que les logs d’Apache pourraient donner, par exemple une non correspondance entre le CN défini dans le certificat et le paramètre ServerName pour le virtual host :


[Thu Apr 11 14:13:02.688664 2019] [ssl:warn] [pid 4844:tid 612] AH01906: sqlpac.ppd:443:0 server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Thu Apr 11 14:13:02.690663 2019] [ssl:warn] [pid 4844:tid 612] AH01909: sqlpac.ppd:443:0 server certificate does NOT include an ID which matches the server name

openssl dispose d’options pour réaliser un test préliminaire simple en tant que client et vérifier ainsi le bon fonctionnement du protocole HTTPS/SSL sur www.sqlpac.ppd:443 :

%APACHE_HOME%> set OPENSSL_CONF=%APACHE_HOME%\conf\openssl.cnf
          
%APACHE_HOME%> .\bin\openssl s_client -connect www.sqlpac.ppd:443
                   CONNECTED(000001C8)
depth=0 O = SQLPAC, CN = sqlpac.ppd
...
Certificate chain
 0 s:/O=SQLPAC/CN=sqlpac.ppd
   i:/O=SQLPAC/CN=sqlpac.ppd
---

Server certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

subject=/O=SQLPAC/CN=sqlpac.ppd
issuer=/O=SQLPAC/CN=sqlpac.ppd
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: D86843A3D71C8458470C6A04FA0D44933EF254AA4C1D2251BB218FF329FC6A94
    Session-ID-ctx:
    Master-Key: C785DDFDA1616E638B536AAA5312DD833A8F1A3D70EBFBF2186FE4149AFF7A0627F4D949E766426F8F9FD95D15C50068
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:

Configuration des navigateurs

Le virtual host www.sqlpac.ppd:443 répond bien en HTTPS/SSL, alors c’est le moment d’ouvrir une page en HTTPS.

Chrome râle et indique que la connexion n’est pas privée. Le certificat est pour lui invalide : l’erreur ERR_CERT_AUTHORITY_INVALID est levée.

Rien de bien grave, comme il s’agit d’un certificat auto signé, la clé publique sqlpac-ca.cer de l’autorité de certification (SQLPAC) générée précédémment doit être importée dans le magasin des certificats pour les "Autorités de certification racines de confiance".

Cette opération peut être réalisée, soit depuis les paramètres de Google Chrome, soit directement depuis la Console Microsoft de gestion (Microsoft Management Console) :

MMC Fichier Ajouter/Supprimer un composant logiciel enfichableCertificats

Importer la clé publique de l’autorité SQLPAC sqlpac-ca.cer dans le magasin "Autorités de certification racines de confiance" à partir du menu contextuel Certificats Autorités de certification racines de confiance Certificats Toutes les tâches Importer… :

Redémarrer Chrome et réouvrir la page de test en HTTPS. C’est à présent tout bon, et aussi pour FireFox et Internet Explorer. Tout bon, enfin presque… La page est délivrée en HTTPS/SSL mais les navigateurs détectent des choses, c’est le sujet du paragraphe qui suit.

Mixed Content : en route pour le debug et la migration vers du 100% HTTPS / SSL

Chrome affiche bien désormais le cadenas dans la barre d’adresse indiquant que la connexion est sécurisée et en cliquant sur le cadenas que le certificat est valide :

En revanche, là commence le debug pour migrer à 100% vers HTTPS/SSL, il peut y avoir ce qu’on appelle du "Mixed Content", si la page a été effectivement servie avec HTTPS/SSL, des scripts (Javascript, CSS…) peuvent être encore appelés par cette page avec le protocole HTTP.

Les outils de développement du navigateur donnent toutes les informations nécessaires. CtrlMajI pour ouvrir les outils de développement avec Chrome, puis sélectionner l’onglet "Security" :

Cliquer sur "View N requests in Network Panel" pour lister le contenu bloqué, et donc les ressources non délivrées par HTTPS/SSL :

Un point d’exclamation peut s’afficher en lieu et place du cadenas dans la barre d’adresses.

Dans ce cas de figure, la page a bien été délivrée en HTTPS/SSL, le certificat est valide mais des erreurs plus sérieuses sont remontées au niveau du "Mixed Content".

Des images, des feuilles de styles, des pages cibles dans les formulaires, des scripts Javascript… propres au domain sqlpac.ppd sont appelés avec un codage en dur du protocole HTTP. Là commence sérieusement les travaux de debug et de mise en conformité pour du 100% HTTPS/SSL. Comme dans le cas précédent, les outils de développement de Chrome donnent toutes les informations :

Rien de plus à ajouter ici, car on rentre dans la conception et le développement et ce n’est pas le propos.

Industrialisation du multi virtual hosts en HTTPS/SSL

L’article Apache 2.4 / PHP, création et automatisation des virtual hosts avec le module des macros (mod_macro) aborde l’automatisation des virtual hosts avec le module des macros afin de disposer de plusieurs virtual hosts en HTTP, chaque virtual host utilisant une version de PHP spécifique.

De la même manière, une macro Apache 2.4 peut prendre en charge la définition de ces virtual hosts en HTTPS/SSL.

La clé publique sqlpac-ca.cer est déjà ajoutée au magasin des certificats pour les autorités de certification racines de confiance.

Pour chaque domaine virtuel, la clé privée et le certificat public d’Apache, signé par SQLPAC, sont générés : dans toutes les étapes, prendre garde aux paramètres CN afin qu’il reflète bien la règle CN=ServerName Apache.

Domaine virtuel	CN	Clé privée Apache	CSR Apache	Certificat public Apache
`www.sqlpac.dvt`	`sqlpac.dvt`	`sqlpac.dvt.key`	`sqlpac.dvt.csr`	`sqlpac.dvt.crt`
`www.sqlpac.ppd`	`sqlpac.ppd`	`sqlpac.ppd.key`	`sqlpac.ppd.csr`	`sqlpac.ppd.crt`
`www.sqlpac.dbg`	`sqlpac.dbg`	`sqlpac.dbg.key`	`sqlpac.dbg.csr`	`sqlpac.dbg.crt`

La macro VSSLHost ci-dessous automatise alors la définition des virtual hosts en HTTPS/SSL. Le port (443) est donné en paramètre de la macro au cas où.

<Macro VSSLHost $domain $port $docroot>
  <VirtualHost *:$port>

    DocumentRoot "$docroot"
    ServerName $domain
    ServerAlias www.$domain
    ErrorLog "logs/www.$domain.ssl-error.log"
    CustomLog "logs/www.$domain.ssl-access.log" common
    
    SSLEngine on
    SSLProtocol all -SSLv2
    SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
    SSLCertificateFile "${SRVROOT}/certificates/$domain.crt"
    SSLCertificateKeyFile "${SRVROOT}/certificates/$domain.key"
    
    Alias /pubs $docroot/referentiel/docs
    
    <Directory "$docroot">;
        Options -Indexes +FollowSymLinks
        Options +ExecCGI
        AllowOverride All
        Require all granted
    </Directory>

    FcgidInitialEnv PHPRC "D:/software/scripts/php-$phpversion"
    AddHandler fcgid-script .php .inc .html
    FcgidWrapper "${PHPHOME}/php-$phpversion/php-cgi.exe" .php
    FcgidWrapper "${PHPHOME}/php-$phpversion/php-cgi.exe" .inc
    FcgidWrapper "${PHPHOME}/php-$phpversion/php-cgi.exe" .html
  
  </VirtualHost>
</Macro>

Vérifier que le module des macros (macro_module) est actif dans le serveur Apache :

%APACHE_HOME%\conf\httpd.conf

LoadModule macro_module modules/mod_macro.so

Un nouveau fichier de configuration %APACHE_HOME%\conf\extra\sqlpac.sslvhosts.conf est sourcé par le serveur Apache :

%APACHE_HOME%\conf\httpd.conf

<IfModule ssl_module>
  Include conf/extra/sqlpac.sslvhosts.conf
</IfModule>

Dans ce fichier de configuration %APACHE_HOME%\conf\extra\sqlpac.sslvhosts.conf, la macro VSSLHost est définie et appelée pour chaque virtual host :

%APACHE_HOME%\conf\extra\sqlpac.sslvhosts.conf

Define PHPHOME "D:/software/scripts"

<Macro VSSLHost $domain $port $docroot $phpversion>
  <VirtualHost *:$port>
    ...
  </VirtualHost>
</Macro>    

Use VSSLHost sqlpac.dvt 443 "D:\www\dev" "7.3.4"
Use VSSLHost sqlpac.ppd 443 "D:\www\preproduction" "7.3.1"
Use VSSLHost sqlpac.dbg 443 "D:\www\productiondbg" "7.0"

UndefMacro VSSLHost

Et c’est terminé. À cette étape, les 2 protocoles HTTP et HTTPS/SSL sont actifs pour chaque virtual host. La désactivation complète du protocole HTTP est à étudier plus tard lorsque la migration vers HTTPS/SSL est terminée.

Conclusion

Les macros avec Apache 2.4 sont encore une fois bien utiles pour développer en local et réaliser une migration vers HTTPS/SSL en toute quiétude et non directement en production.

Les créations de certificates auto signés sont un peu fastidieuses, mais lorsque la mécanique est comprise il n’y a plus rien d’insurmontable à leur mise en place.