La configuration suivante active le "chiffrement fort" telle qu'il est défini ci-dessus, et s'inspire du document de la Fondation Mozilla sur les prérequis de Server Side TLS :

• SSL 3.0 et TLS 1.0 étant vulnérables à certaines attaques connues contre le protocole, ils ont été entièrement retirés.
• Actuellement (en août 2016), la désactivation de TLS 1.1 est facultative ; TLS 1.2 fournit des options de chiffrement plus évoluées, mais la version 1.1 n'est pas encore considérée comme obsolète. La désactivation de TLS 1.1 peut cependant juguler des attaques contre certaines implémentations dépassées de TLS.
• La directive SSLHonorCipherOrder permet de s'assurer que ce sont les préférences de chiffrement du serveur qui seront suivies, et non celles du client.
• La désactivation de SSLCompression permet de prévenir les attaques oracle sur la compression TLS (en autres CRIME).
• La désactivation de SSLSessionTickets permet de s'assurer que la qualité de la confidentialité persistante (Forward Secrecy) ne sera pas compromise, même si le serveur n'est pas redémarré régulièrement.

C'est votre version d'OpenSSL installée qui détermine la liste des algorithmes de chiffrement supportés par la directive SSLCipherSuite, et non le serveur. Pour pouvoir utiliser certains d'entre eux, vous devrez peut-être mettre à jour votre version d'OpenSSL.

Dans ce cas bien évidemment, une directive SSLCipherSuite au niveau du serveur principal qui restreint le choix des suites de chiffrement aux versions les plus fortes ne conviendra pas. mod_ssl peut cependant être reconfiguré au sein de blocs Location qui permettent d'adapter la configuration générale à un répertoire spécifique ; mod_ssl peut alors forcer automatiquement une renégociation des paramètres SSL pour parvenir au but recherché. Cette configuration peut se présenter comme suit :

Les réponses OCSP sont stockées dans le cache d'agrafage SSL. Alors que les réponses ont une taille de quelques centaines à quelques milliers d'octets, mod_ssl supporte des réponses d'une taille jusqu'à environ 10 ko. Dans notre cas, le nombre de certificats est conséquent et la taille du cache (32768 octets dans l'exemple ci-dessus) doit être augmentée. En cas d'erreur lors du stockage d'une réponse, le message AH01929 sera enregistré dans le journal.

Veuillez vous référer à la documentation de la directive SSLStaplingForceURL.

Vous pouvez vérifier si un certificat spécifie un répondeur OCSP en utilisant la commande openssl comme suit :

$ openssl x509 -in ./www.example.com.crt -text | grep 'OCSP.*http'
OCSP - URI:http://ocsp.example.com

Si un URI OCSP est fourni et si le serveur web peut communiquer directement avec lui sans passer par un mandataire, aucune modification supplémentaire de la configuration n'est requise. Notez que les règles du pare-feu qui contrôlent les connexions sortantes en provenance du serveur web devront peut-être subir quelques ajustements.

Si aucun URI OCSP n'est fourni, contactez votre autorité de certification pour savoir s'il en existe une ; si c'est le cas, utilisez la directive SSLStaplingForceURL pour la spécifier dans la configuration du serveur virtuel qui utilise le certificat.

Ajoutez la directive SSLUseStapling Off à la configuration des serveurs virtuels pour lesquels l'agrafage OCSP doit être désactivé.

De nombreuses directives permettent de gérer les temps de réponse et les erreurs. Référez-vous à la documentation de SSLStaplingFakeTryLater, SSLStaplingResponderTimeout, et SSLStaplingReturnResponderErrors.

AH02217: ssl_stapling_init_cert: Can't retrieve issuer certificate!

Afin de pouvoir supporter l'agrafage OCSP lorsqu'un certificat de serveur particulier est utilisé, une chaîne de certification pour ce certificat doit être spécifiée. Si cela n'a pas été fait lors de l'activation de SSL, l'erreur AH02217 sera enregistrée lorsque l'agrafage OCSP sera activé, et les clients qui utilisent le certificat considéré ne recevront pas de réponse OCSP.

Veuillez vous référer à la documentation des directives SSLCertificateChainFile et SSLCertificateFile pour spécifier une chaîne de certification.

Lorsque vous connaissez tous vos clients (comme c'est en général le cas au sein d'un intranet d'entreprise), vous pouvez imposer une authentification basée uniquement sur les certificats. Tout ce dont vous avez besoin pour y parvenir est de créer des certificats clients signés par le certificat de votre propre autorité de certification (ca.crt), et d'authentifier les clients à l'aide de ces certificats.

Pour forcer les clients à s'authentifier à l'aide de certificats pour une URL particulière, vous pouvez utiliser les fonctionnalités de reconfiguration de mod_ssl en fonction du répertoire :

La clé du problème consiste à vérifier si une partie du certificat client correspond à ce que vous attendez. Cela signifie en général consulter tout ou partie du nom distinctif (DN), afin de vérifier s'il contient une chaîne connue. Il existe deux méthodes pour y parvenir ; on utilise soit le module mod_auth_basic, soit la directive SSLRequire.

La méthode du module mod_auth_basic est en général incontournable lorsque les certificats ont un contenu arbitraire, ou lorsque leur DN ne contient aucun champ connu (comme l'organisation, etc...). Dans ce cas, vous devez construire une base de données de mots de passe contenant tous les clients autorisés, comme suit :

Le mot de passe utilisé dans cet exemple correspond à la chaîne de caractères "password" chiffrée en DES. Voir la documentation de la directive SSLOptions pour plus de détails.

/C=DE/L=Munich/O=Snake Oil, Ltd./OU=Staff/CN=Foo:xxj31ZMTZzkVA
/C=US/L=S.F./O=Snake Oil, Ltd./OU=CA/CN=Bar:xxj31ZMTZzkVA
/C=US/L=L.A./O=Snake Oil, Ltd./OU=Dev/CN=Quux:xxj31ZMTZzkVA

Lorsque vos clients font tous partie d'une même hiérarchie, ce qui apparaît dans le DN, vous pouvez les authentifier plus facilement en utilisant la directive SSLRequire, comme suit :

On suppose dans ces exemples que les clients de l'intranet ont des adresses IP dans la gamme 192.168.1.0/24, et que la partie de l'intranet à laquelle vous voulez autoriser l'accès depuis l'Internet est /usr/local/apache2/htdocs/subarea. Ces lignes de configuration doivent se trouver en dehors de votre hôte virtuel HTTPS, afin qu'elles s'appliquent à la fois à HTTP et HTTPS.