Activer HTTPS sur vos serveurs

Chris Palmer

Matt Gaunt

Cette page fournit des conseils pour configurer HTTPS sur vos serveurs, y compris les étapes suivantes:

• Créer une paire de clés publique/privée RSA de 2 048 bits.
• Générer une requête de signature de certificat (CSR) qui intègre votre clé publique.
• Partager votre CSR avec votre autorité de certification (CA) pour recevoir un certificat final ou une chaîne de certificats.
• Installer votre certificat final dans un emplacement non accessible sur le Web, tel que /etc/ssl (Linux et Unix) ou l'emplacement requis par IIS (Windows).

Générer des clés et des demandes de signature de certificat

Dans cette section, nous utilisons le programme de ligne de commande openssl, fourni avec la plupart des systèmes Linux, BSD et Mac OS X, pour générer des clés privées et publiques, ainsi qu'une CSR.

Générer une paire de clés publique/privée

Pour commencer, générez une paire de clés RSA de 2 048 bits. Une clé plus courte peut être fracturée par des attaques par force brute, et les clés plus longues utilisent des ressources inutiles.

Utilisez la commande suivante pour générer une paire de clés RSA:

openssl genrsa -out www.example.com.key 2048

Vous obtenez le résultat suivant:

Generating RSA private key, 2048 bit long modulus
.+++
.......................................................................................+++
e is 65537 (0x10001)

Générer une requête de signature de certificat

À cette étape, vous incorporez votre clé publique et des informations sur votre organisation et votre site Web dans une requête de signature de certificat (CSR). La commande openssl vous demande les métadonnées requises.

En exécutant la commande suivante :

openssl req -new -sha256 -key www.example.com.key -out www.example.com.csr

Vous obtenez le résultat suivant:

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) [AU]:CA
State or Province Name (full name) [Some-State]:California
Locality Name (for example, city) []:Mountain View
Organization Name (for example, company) [Internet Widgits Pty Ltd]:Example, Inc.
Organizational Unit Name (for example, section) []:Webmaster Help Center Example
Team
Common Name (e.g. server FQDN or YOUR name) []:www.example.com
Email Address []:[e-mail]

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

Pour vous assurer de la validité de la CSR, exécutez la commande suivante:

openssl req -text -in www.example.com.csr -noout

La réponse doit se présenter comme suit:

Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=CA, ST=California, L=Mountain View, O=Google, Inc.,
OU=Webmaster Help Center Example Team,
CN=www.example.com/emailAddress=[e-mail]
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:ad:fc:58:e0:da:f2:0b:73:51:93:29:a5:d3:9e:
                    f8:f1:14:13:64:cc:e0:bc:be:26:5d:04:e1:58:dc:
                    ...
                Exponent: 65537 (0x10001)
        Attributes:
            a0:00
    Signature Algorithm: sha256WithRSAEncryption
         5f:05:f3:71:d5:f7:b7:b6:dc:17:cc:88:03:b8:87:29:f6:87:
         2f:7f:00:49:08:0a:20:41:0b:70:03:04:7d:94:af:69:3d:f4:
         ...

Envoyer votre CSR à une autorité de certification

Les différentes autorités de certification (AC) vous demandent de leur envoyer vos CSR de différentes manières. Il peut s'agir, par exemple, d'utiliser un formulaire sur son site Web ou d'envoyer la CSR par e-mail. Certaines autorités de certification ou leurs revendeurs peuvent même automatiser tout ou partie du processus, y compris, dans certains cas, la génération de paires de clés et de CSR.

Envoyez la requête de signature de certificat à votre autorité de certification et suivez ses instructions pour recevoir votre certificat ou votre chaîne de certificats final.

Les différentes autorités de certification facturent des montants différents pour le service de validation de votre clé publique.

Vous pouvez également mapper votre clé sur plusieurs noms DNS, y compris plusieurs noms distincts (par exemple, tous les noms example.com, www.example.com, example.net et www.example.net) ou des noms génériques tels que *.example.com.

Remarque :Dans les certificats génériques, le caractère générique ne s'applique qu'à un seul libellé DNS. Un certificat valide pour *.example.com fonctionne pour foo.example.com et bar.example.com, mais pas pour foo.bar.example.com.

Copiez les certificats sur tous vos serveurs frontaux dans un emplacement non accessible sur le Web, tel que /etc/ssl (Linux et Unix) ou l'emplacement requis par IIS (Windows).

Activer le protocole HTTPS sur vos serveurs

Activer HTTPS sur vos serveurs est une étape essentielle pour assurer la sécurité de vos pages Web.

• Utilisez l'outil de configuration du serveur de Mozilla pour configurer votre serveur pour la prise en charge de HTTPS.
• Testez régulièrement votre site avec le test du serveur SSL de Qualys et assurez-vous d'obtenir au moins un A ou un A+.

À ce stade, vous devez prendre une décision opérationnelle cruciale. Choisissez l'une des options suivantes:

• Attribuez une adresse IP distincte à chaque nom d'hôte à partir duquel votre serveur Web diffuse du contenu.
• Utilisez l'hébergement virtuel basé sur le nom.

Si vous avez utilisé des adresses IP distinctes pour chaque nom d'hôte, vous pouvez prendre en charge HTTP et HTTPS pour tous les clients. Toutefois, la plupart des opérateurs de sites utilisent l'hébergement virtuel basé sur le nom pour conserver les adresses IP et parce qu'il est plus pratique en général.

Si le service HTTPS n'est pas encore disponible sur vos serveurs, activez-le maintenant (sans rediriger HTTP vers HTTPS). Pour en savoir plus, consultez la section Rediriger HTTP vers HTTPS. Configurez votre serveur Web pour qu'il utilise les certificats que vous avez achetés et installés. Le générateur de configuration de Mozilla peut vous être utile.

Si vous disposez de nombreux noms d'hôte ou sous-domaines, chacun d'eux doit utiliser le bon certificat.

Avertissement :Si vous avez déjà effectué ces étapes, mais que vous utilisez HTTPS uniquement pour rediriger les clients vers HTTP, arrêtez de le faire. Consultez la section suivante pour vous assurer que HTTPS et HTTP fonctionnent correctement.

Remarque :À terme, vous devez rediriger les requêtes HTTP vers HTTPS et utiliser HTTP Strict Transport Security (HSTS). Toutefois, cela doit se produire plus tard dans le processus de migration. Pour en savoir plus, consultez Rediriger HTTP vers HTTPS et Activer HTTP Strict Transport Security et les cookies sécurisés.

Vérifiez maintenant, et régulièrement tout au long de la durée de vie de votre site, votre configuration HTTPS à l'aide du test du serveur SSL de Qualys. Votre site doit obtenir une note A ou A+. Traitez tout élément qui entraîne une note inférieure comme un bug et restez vigilant, car de nouvelles attaques contre les algorithmes et les protocoles sont en permanence développées.

Rendre les URL intrasites relatives

Maintenant que vous diffusez votre site à la fois en HTTP et en HTTPS, tout doit fonctionner aussi facilement que possible, quel que soit le protocole. Un facteur important est l'utilisation d'URL relatives pour les liens intrasites.

Assurez-vous que les URL intrasites et les URL externes ne dépendent pas d'un protocole spécifique. Utilisez des chemins d'accès relatifs ou omettez le protocole, comme dans //example.com/something.js.

La diffusion d'une page contenant des ressources HTTP à l'aide de HTTPS peut entraîner des problèmes. Lorsqu'un navigateur rencontre une page sécurisée qui utilise des ressources non sécurisées, il avertit les utilisateurs que la page n'est pas complètement sécurisée. Certains navigateurs refusent de charger ou d'exécuter les ressources HTTP, ce qui entraîne l'échec de la page. Toutefois, vous pouvez inclure des ressources HTTPS dans une page HTTP sans risque. Pour en savoir plus sur la résolution de ces problèmes, consultez la section Corriger le contenu mixte.

Le suivi de liens HTTP vers d'autres pages de votre site peut également dégrader l'expérience utilisateur de HTTPS vers HTTP. Pour résoudre ce problème, rendez vos URL intrasites aussi relatives que possible, en les rendant à protocole relatif (sans protocole, commençant par //example.com) ou à hôte relatif (commençant simplement par le chemin d'accès, comme /jquery.js).

À faire

<h1>Welcome To Example.com</h1>
<script src="/jquery.js"></script>
<link rel="stylesheet" href="/assets/style.css"/>
<img src="/images/logo.png"/>;
<p>A <a href="/2014/12/24">new post on cats!</a></p>

Utilisez des URL relatives intrasites.

À faire

<h1>Welcome To Example.com</h1>
<script src="//example.com/jquery.js"></script>
<link rel="stylesheet" href="//assets.example.com/style.css"/>
<img src="//img.example.com/logo.png"/>;
<p>A <a href="//example.com/2014/12/24/">new post on cats!</a></p>

Vous pouvez également utiliser des URL intrasites à protocole relatif.

À faire

<h1>Welcome To Example.com</h1>
<script src="/jquery.js"></script>
<link rel="stylesheet" href="/assets/style.css"/>
<img src="/images/logo.png"/>;
<p>A <a href="/2014/12/24">new post on cats!</a></p>
<p>Check out this <a href="https://foo.com/"><b>other cool site.</b></a></p>

Dans la mesure du possible, utilisez des URL HTTPS pour les liens vers d'autres sites.

Mettez à jour vos liens à l'aide d'un script, et non manuellement, pour éviter de faire des erreurs. Si le contenu de votre site se trouve dans une base de données, testez votre script sur une copie de développement de la base de données. Si le contenu de votre site ne se compose que de fichiers simples, testez votre script sur une copie de développement des fichiers. Ne déployez les modifications en production qu'après avoir passé le contrôle qualité, comme d'habitude. Vous pouvez utiliser le script de Bram van Damme ou un outil similaire pour détecter les contenus mixtes sur votre site.

Lorsque vous créez des liens vers d'autres sites (plutôt que d'inclure des ressources à partir d'eux), ne modifiez pas le protocole. Vous n'avez aucun contrôle sur le fonctionnement de ces sites.

Pour faciliter la migration des grands sites, nous vous recommandons d'utiliser des URL relatives au protocole. Si vous n'êtes pas sûr de pouvoir déployer entièrement HTTPS, forcer votre site à utiliser HTTPS pour toutes les sous-ressources peut avoir des conséquences négatives. Il est probable qu'il y ait une période pendant laquelle le protocole HTTPS vous semblera nouveau et étrange, et le site HTTP doit continuer à fonctionner comme d'habitude. Au fil du temps, vous terminerez la migration et verrouillerez le protocole HTTPS (voir les deux sections suivantes).

Si votre site dépend de scripts, d'images ou d'autres ressources diffusées par un tiers, comme un CDN ou jquery.com, deux options s'offrent à vous:

• Utilisez des URL à protocole relatif pour ces ressources. Si le tiers ne diffuse pas le protocole HTTPS, demandez-lui de le faire. La plupart le font déjà, y compris jquery.com.
• Diffuser les ressources à partir d'un serveur que vous contrôlez, qui propose à la fois HTTP et HTTPS. C'est souvent une bonne idée, car vous contrôlez mieux l'apparence, les performances et la sécurité de votre site, et vous n'avez pas à faire confiance à un tiers pour assurer la sécurité de votre site.

Attention :Vous devez également modifier les URL intrasites dans vos feuilles de style, votre code JavaScript, vos règles de redirection, vos balises <link> et vos déclarations CSP, et pas seulement dans vos pages HTML.

Rediriger HTTP vers HTTPS

Pour indiquer aux moteurs de recherche d'utiliser HTTPS pour accéder à votre site, placez un lien canonique en haut de chaque page à l'aide de balises <link rel="canonical" href="https://…"/>.

Activer le protocole Strict Transport Security et les cookies sécurisés

À ce stade, vous êtes prêt à verrouiller l'utilisation de HTTPS:

• Utilisez HTTP Strict Transport Security (HSTS) pour éviter le coût de la redirection 301.
• Définissez toujours l'indicateur "Sécurisé" sur les cookies.

Tout d'abord, utilisez Strict Transport Security pour indiquer aux clients qu'ils doivent toujours se connecter à votre serveur via HTTPS, même lorsqu'ils suivent une référence http://. Cela permet de contrer des attaques telles que le dénudage SSL et d'éviter le coût aller-retour de l'301 redirect que nous avons activé dans Redirection HTTP vers HTTPS.

Remarque :Les clients qui ont listé votre site en tant qu'hôte HSTS connu sont susceptibles de échouer de manière irrécupérable si votre site présente une erreur dans sa configuration TLS (par exemple, un certificat expiré). Le HSTS est conçu explicitement de cette manière pour s'assurer que les pirates informatiques ne peuvent pas inciter les clients à accéder au site sans HTTPS. N'activez pas le protocole HSTS tant que vous n'êtes pas certain que le fonctionnement de votre site est suffisamment robuste pour éviter de déployer HTTPS avec des erreurs de validation de certificat.

Pour activer HSTS, définissez l'en-tête Strict-Transport-Security. La page HSTS de l'OWASP contient des liens vers des instructions pour différents types de logiciels de serveur.

La plupart des serveurs Web offrent une fonctionnalité similaire pour ajouter des en-têtes personnalisés.

Remarque :max-age est mesuré en secondes. Vous pouvez commencer par des valeurs faibles et augmenter progressivement max-age à mesure que vous vous familiarisez avec l'exploitation d'un site HTTPS uniquement.

Il est également important de s'assurer que les clients n'envoient jamais de cookies (par exemple, pour l'authentification ou les préférences du site) via HTTP. Par exemple, si le cookie d'authentification d'un utilisateur était exposé en texte brut, votre garantie de sécurité pour l'ensemble de sa session serait détruite, même si vous avez tout fait correctement.

Pour éviter cela, modifiez votre application Web afin qu'elle définisse toujours l'indicateur "Sécurisé" sur les cookies qu'elle définit. Cette page de l'OWASP explique comment définir l'indicateur Secure dans plusieurs frameworks d'applications. Chaque framework d'application dispose d'un moyen de définir l'indicateur.

La plupart des serveurs Web proposent une fonctionnalité de redirection simple. Utilisez 301 (Moved Permanently) pour indiquer aux moteurs de recherche et aux navigateurs que la version HTTPS est canonique, et redirigez vos utilisateurs vers la version HTTPS de votre site à partir de HTTP.

Classement des résultats de recherche

Google considère le protocole HTTPS comme un indicateur positif de qualité de recherche. Google publie également un guide sur la méthode à suivre pour transférer, déplacer ou migrer votre site tout en conservant son classement dans les résultats de recherche. Bing publie également des consignes pour les webmasters.

Performances

Lorsque les couches de contenu et d'application sont bien configurées (consultez les livres de Steve Souders pour obtenir des conseils), les problèmes de performances TLS restants sont généralement faibles par rapport au coût global de l'application. Vous pouvez également réduire et amortir ces coûts. Pour obtenir des conseils sur l'optimisation du protocole TLS, consultez High Performance Browser Networking (Haute performance de la mise en réseau du navigateur) d'Ilya Grigorik, ainsi que les livres OpenSSL Cookbook (Cookbook OpenSSL) et Bulletproof SSL And TLS (SSL et TLS à toute épreuve) d'Ivan Ristic.

Dans certains cas, TLS peut améliorer les performances, principalement en rendant HTTP/2 possible. Pour en savoir plus, consultez la conférence de Chris Palmer sur les performances HTTPS et HTTP/2 lors du Chrome Dev Summit 2014.

En-têtes Referer

Lorsque les utilisateurs suivent des liens depuis votre site HTTPS vers d'autres sites HTTP, les agents utilisateur n'envoient pas l'en-tête "Referer". Si c'est le cas, plusieurs solutions s'offrent à vous:

• Les autres sites doivent passer au protocole HTTPS. Si les sites référents ont terminé la section Activer HTTPS sur vos serveurs de ce guide, vous pouvez remplacer les liens de votre site par les leurs, en passant de http:// à https:// ou en utilisant des liens relatifs au protocole.
• Pour contourner divers problèmes liés aux en-têtes "Referer", utilisez la nouvelle norme Referrer Policy.

Attention :Selon la RFC HTTP, les clients NE DOIVENT PAS inclure de champ d'en-tête "Referer" dans une requête HTTP (non sécurisée) si la page référente est transférée à l'aide d'un protocole sécurisé.

Revenus publicitaires

Les opérateurs de sites qui monétisent leur site en diffusant des annonces veulent s'assurer que la migration vers HTTPS ne réduit pas les impressions d'annonces. Toutefois, en raison de problèmes de sécurité liés au contenu mixte, un <iframe> HTTP ne fonctionne pas sur une page HTTPS. Tant que les annonceurs ne publient pas via HTTPS, les opérateurs de sites ne peuvent pas migrer vers HTTPS sans perdre de revenus publicitaires. Mais tant que les opérateurs de sites ne migrent pas vers HTTPS, les annonceurs ont peu de motivation à publier des annonces via HTTPS.

Pour sortir de cette impasse, vous pouvez commencer à utiliser des annonceurs qui proposent des services publicitaires via HTTPS et demander aux annonceurs qui ne diffusent pas du tout de contenu HTTPS de le faire au moins en option. Vous devrez peut-être différer l'opération Rendre les URL IntraSite relatives jusqu'à ce qu'un nombre suffisant d'annonceurs interagissent correctement.