Activer HTTPS sur vos serveurs

Chris Palmer
Chris Palmer

Cette page explique comment 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 demande de signature de certificat (CSR) qui intègre votre clé publique ;
  • Partagez votre requête de signature de certificat avec votre autorité de certification 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 partout où IIS l'exige (Windows)

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

Cette section utilise 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 requête de signature de certificat.

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 cassée par des attaques par force brute, et les clés plus longues utilisent des ressources inutiles.

Exécutez 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

Au cours de cette étape, vous allez intégrer 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

Permet d'obtenir ce qui suit:

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 []:webmaster@example.com

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

Pour vérifier la validité de la requête de signature de certificat, 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=webmaster@example.com
        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 requête de signature de certificat à une autorité de certification

Chaque autorité de certification (CA) vous demande de lui envoyer vos requêtes de signature de certificat de différentes manières. Il peut s'agir, par exemple, d'utiliser un formulaire sur leur site Web ou d'envoyer la requête de signature de certificat par e-mail. Certaines autorités de certification, ou leurs revendeurs, peuvent même automatiser une partie ou la totalité du processus, y compris, dans certains cas, la génération de paires de clés et de requête de signature de certificat.

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

Chaque autorité de certification facture des montants différents pour le service de garantie de votre clé publique.

Il existe également des options permettant de mapper votre clé sur plusieurs noms DNS, y compris avec plusieurs noms distincts (par exemple, tous les noms d'example.com, www.example.com, example.net et www.example.net), ou avec des noms "caractères génériques" tels que *.example.com.

Copiez les certificats sur tous vos serveurs frontaux à un emplacement non accessible sur le Web, tel que /etc/ssl (Linux et Unix) ou partout où IIS (Windows) l'exige.

Activer HTTPS sur vos serveurs

L'activation du protocole HTTPS sur vos serveurs est une étape essentielle pour assurer la sécurité de vos pages Web.

  • Utilisez l'outil de configuration de serveur de Mozilla pour configurer votre serveur afin qu'il soit compatible avec HTTPS.
  • Testez régulièrement votre site avec le test du serveur SSL de Qualys et assurez-vous d'obtenir au moins la réponse A ou la note 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 utilisez des adresses IP distinctes pour chaque nom d'hôte, vous pouvez utiliser HTTP et HTTPS pour tous les clients. Cependant, la plupart des opérateurs de sites utilisent l'hébergement virtuel basé sur le nom pour conserver les adresses IP, ce qui 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 utiliser 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, ils doivent tous utiliser le certificat approprié.

Désormais, et régulièrement pendant toute la durée de vie de votre site, vérifiez votre configuration HTTPS avec le test de serveur SSL de Qualys. Votre site doit obtenir un score A ou A+. Traitez comme un bug tout ce qui provoque une note inférieure et restez attentif, car de nouvelles attaques contre les algorithmes et les protocoles sont constamment développées.

Rendre les URL intrasite relatives

Maintenant que vous diffusez votre site à la fois via HTTP et HTTPS, tout doit fonctionner de manière optimale, quel que soit le protocole. Il est important d'utiliser des URL relatives pour les liens intrasite.

Assurez-vous que les URL intrasite et 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 autrement sécurisée à l'aide de ressources non sécurisées, il avertit les utilisateurs que celle-ci n'est pas totalement sécurisée. Certains navigateurs refusent de charger ou d'exécuter les ressources HTTP, ce qui entraîne le dysfonctionnement de la page. Toutefois, vous pouvez inclure en toute sécurité des ressources HTTPS dans une page HTTP. Pour en savoir plus sur la résolution de ces problèmes, consultez Corriger le contenu mixte.

Suivre des liens HTTP vers d'autres pages de votre site peut également faire passer l'expérience utilisateur de HTTPS à HTTP. Pour résoudre ce problème, faites en sorte que vos URL intrasite soient aussi relatives que possible, en les rendant relatives au protocole (sans protocole, commençant par //example.com) ou à l'hôte (en commençant par le chemin, 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 intrasite relatives.
À 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 intrasite à 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.

Pour éviter de faire des erreurs, modifiez vos liens à l'aide d'un script, et non manuellement. Si le contenu de votre site se trouve dans une base de données, testez votre script sur une copie de développement de cette 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 de ces fichiers. Transférez les modifications en production uniquement une fois qu'elles ont été validées par le contrôle qualité, comme d'habitude. Vous pouvez utiliser le script de Bram van Damme ou un script similaire pour détecter du contenu mixte sur votre site.

Lorsque vous créez des liens vers d'autres sites (au lieu d'inclure leurs ressources), ne modifiez pas le protocole. Vous n'avez aucun contrôle sur le fonctionnement de ces sites.

Afin de faciliter la migration pour les sites volumineux, nous vous recommandons d'utiliser des URL à protocole relatif. Si vous n'êtes pas certain de pouvoir déployer entièrement le protocole HTTPS, vous risquez de forcer votre site à l'utiliser pour toutes les sous-ressources. Il existe probablement une période pendant laquelle HTTPS est nouveau et étrange pour vous, et le site HTTP devrait continuer à fonctionner correctement. Au fil du temps, vous terminerez la migration et le verrouillage en HTTPS (voir les deux sections suivantes).

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

  • Utilisez des URL à protocole relatif pour ces ressources. Si le tiers ne diffuse pas HTTPS, demandez-lui de le faire. La plupart le font déjà, y compris jquery.com.
  • Diffusez 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 cela vous permet de mieux contrôler l'apparence, les performances et la sécurité de votre site, et vous n'avez pas besoin de faire confiance à un tiers pour assurer sa sécurité.

Redirection 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 des balises <link rel="canonical" href="https://…"/>.

Activer la fonctionnalité Strict Transport Security et les cookies sécurisés

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

  • Utilisez le mécanisme 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 à l'aide du protocole HTTPS, même lorsque vous suivez une référence http://. Cela permet de déjouer les attaques telles que la suppression SSL et d'éviter le coût aller-retour du 301 redirect que nous avons activé dans la section Rediriger HTTP vers HTTPS.

Pour l'activer, 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 serveur.

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

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

Pour éviter cela, modifiez votre application Web de manière à toujours définir l'indicateur Secure sur les cookies qu'elle définit. Cette page OWASP explique comment définir l'indicateur sécurisé dans plusieurs frameworks d'application. Chaque framework d'appl offre un moyen de définir l'indicateur.

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

Classement des résultats de recherche

Google utilise le protocole HTTPS comme indicateur positif de la qualité de la recherche. Google publie également un guide expliquant comment 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 réglées (consultez les livres de Steve Souders pour obtenir des conseils), les problèmes de performances TLS restants sont généralement minimes 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 TLS, consultez la page High Performance Browser Networking d'Ilya Grigorik, ainsi que OpenSSL Cookbook et BulletProof SSL And TLS d'Ivan Ristic.

Dans certains cas, TLS peut améliorer les performances, principalement à la suite de la mise en œuvre de HTTP/2. Pour en savoir plus, consultez la présentation de Chris Palmer sur les performances HTTPS et HTTP/2 lors du Chrome Dev Summit 2014.

En-têtes de pages de provenance

Lorsque les utilisateurs suivent des liens de votre site HTTPS vers d'autres sites HTTP, les user-agents n'envoient pas l'en-tête "Referer". Si cela pose problème, plusieurs solutions s'offrent à vous pour le résoudre:

  • Les autres sites doivent migrer vers le protocole HTTPS. Si les sites référents suivent la section Activer HTTPS sur vos serveurs de ce guide, vous pouvez remplacer les liens de votre site http:// par https:// ou utiliser des liens à protocole relatif.
  • Pour contourner divers problèmes liés aux en-têtes d'URL de provenance, utilisez la nouvelle norme de règle de référence.

Revenus publicitaires

Les opérateurs de sites qui monétisent leurs sites en diffusant des annonces souhaitent s'assurer que le passage au protocole HTTPS ne réduit pas le nombre d'impressions d'annonces. Toutefois, en raison de problèmes de sécurité du contenu mixte, un <iframe> HTTP ne fonctionne pas sur une page HTTPS. Tant que les annonceurs n'ont pas migré vers le protocole HTTPS, les opérateurs de sites ne peuvent pas passer au protocole HTTPS sans perdre de revenus publicitaires. Toutefois, tant que les opérateurs de sites n'ont pas migré vers le protocole HTTPS, les annonceurs n'ont que peu de motivations pour publier ce protocole.

Pour résoudre ce problème, vous pouvez commencer par faire appel à des annonceurs qui proposent des services publicitaires via HTTPS et demander aux annonceurs qui ne diffusent pas du tout HTTPS d'en faire au moins une option. Vous devrez peut-être différer l'étape Rendre les URL intrasite relatives jusqu'à ce qu'un nombre suffisant d'annonceurs interagissent correctement.