Cette page a été traduite par l'API Cloud Translation.

Activer HTTPS sur vos serveurs

Chris Palmer

Matt Gaunt

Cette page fournit des conseils pour configurer HTTPS sur vos serveurs, y compris procédez comme suit:

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 requête de signature de certificat avec votre autorité de certification afin de recevoir une réponse finale un certificat ou une chaîne de certificats.
L'installation de votre certificat final dans un emplacement non accessible sur le Web, tel que /etc/ssl (Linux et Unix) ou partout où le serveur IIS l'exige (Windows).

Générer des clés et des requêtes de signature de certificat

Cette section utilise le programme de ligne de commande OpenSSL Linux, BSD et Mac OS X, pour générer des clés privées et publiques et 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 les 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

Au cours de cette étape, vous allez intégrer votre clé publique et les informations sur votre organisation et votre site Web dans une demande de signature de certificat ou CSR. 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

Génère 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 garantir 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

Différentes autorités de certification vous demandent de leur soumettre vos CSR. de différentes manières. Il peut s'agir, par exemple, d'utiliser un formulaire sur leur site Web ou d'envoyer par e-mail. Certaines autorités de certification, ou leurs revendeurs, peuvent même automatiser une partie du processus, y compris, dans certains cas, la paire de clés et la génération d’une 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 demande finale un certificat ou une chaîne de certificats.

Les montants facturés pour le service de cautionnement varient d'une autorité de certification à l'autre pour votre clé publique.

Il existe également des options pour mapper votre clé à plusieurs noms DNS, y compris plusieurs noms distincts (par exemple, example.com, www.example.com, example.net, et www.example.net) ou "caractère générique" tels que *.example.com.

Copiez les certificats sur tous vos serveurs front-end dans un tels que /etc/ssl (Linux et Unix) ou partout où IIS (Windows) nécessite de l'IA générative.

Activer le protocole 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 du serveur de Mozilla pour configurer votre serveur pour HTTPS. de l'assistance.
Tester régulièrement votre site avec l'outil Qualys Testez et vérifiez que le serveur SSL vous obtenez au moins un A ou un A+.

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

Dédiez une adresse IP distincte à chaque nom d'hôte sur lequel 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. Cependant, la plupart des opérateurs de site utilisent l'hébergement virtuel 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. Consultez la section Rediriger HTTP vers HTTPS. pour en savoir plus). Configurez votre serveur Web pour utiliser les certificats que vous achetés et installés. Il se peut que les paramètres de configuration générateur utiles.

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

À présent, et de façon régulière tout au long de la durée de vie de votre site, vérifiez votre avec Qualys' Test du serveur SSL Votre site doit obtenir la note A ou A+. Traiter tout ce qui cause une note inférieure comme un bogue et rester diligent, car les nouvelles attaques contre les algorithmes et les protocoles sont toujours en cours de développement.

Rendre les URL intrasites relatives

Maintenant que vous diffusez votre site à la fois sur HTTP et HTTPS, tout doit fonctionner le plus facilement possible, quel que soit le protocole. Un facteur important consiste à utiliser 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 dans //example.com/something.js.

Diffuser une page contenant des ressources HTTP à l'aide de HTTPS peut causer des problèmes. Lorsqu'un navigateur rencontre une page sécurisée utilisant des ressources non sécurisées, il avertit les utilisateurs que la page n'est pas entièrement sécurisé, et certains navigateurs refusent de charger ou d'exécuter le code les ressources, ce qui fait planter la page. Toutefois, vous pouvez inclure le protocole HTTPS d'une page HTTP. Pour en savoir plus sur la résolution de ces problèmes, consultez Corriger un contenu mixte

En suivant des liens HTTP vers d'autres pages de votre site, vous pouvez également revenir à une version antérieure l'expérience utilisateur du protocole HTTPS au HTTP. Pour résoudre ce problème, définissez vos URL intrasites sous la forme relatives que possible, en les rendant soit sur le protocole relatif (sans en commençant par //example.com) ou relatif à l'hôte (en commençant par 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>

<ph type="x-smartling-placeholder"></ph> Utilisez des URL intrasites 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>

<ph type="x-smartling-placeholder"></ph> 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>

<ph type="x-smartling-placeholder"></ph> Dans la mesure du possible, utilisez des URL HTTPS pour les liens vers d'autres sites.

Pour éviter toute erreur, mettez à jour vos liens à l'aide d'un script et non manuellement. Si votre contenu de votre site se trouve dans une base de données, testez votre script sur une copie de développement du base de données. Si le contenu de votre site se compose uniquement de fichiers simples, testez votre script sur une copie de développement des fichiers. Déployez les modifications en production les modifications sont validées lors du contrôle qualité, comme à l'accoutumée. Vous pouvez utiliser le script de Bram van Damme. ou un outil similaire pour détecter du contenu mixte sur votre site.

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

Pour faciliter la migration des sites volumineux, nous vous recommandons d'utiliser des URL à protocole relatif. Si vous n'êtes pas encore sûr de pouvoir déployer entièrement le protocole HTTPS, ce qui oblige votre site à utiliser HTTPS pour toutes les sous-ressources peut se retourner contre vous. Il y a probablement une période de Le protocole HTTPS est nouveau et bizarre pour vous, alors que le site HTTP doit quand même fonctionner. qu'avant. 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 provenant d'un tiers tiers, comme un CDN ou jquery.com, vous avez deux options:

Utilisez des URL à protocole relatif pour ces ressources. Si le tiers ne fait pas utiliser HTTPS, demandez-lui de le faire. C'est déjà le cas pour la plupart, y compris jquery.com.
Livrez les ressources à partir d'un serveur que vous contrôlez, qui propose à la fois des protocoles HTTP et HTTPS. C'est souvent une bonne idée, car vous aurez alors de contrôler l'apparence, les performances et la sécurité de votre site de faire confiance à un tiers pour assurer la sécurité de votre site.

Rediriger HTTP vers HTTPS

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

Activer Strict Transport Security et sécuriser les cookies

À ce stade, vous êtes prêt à « bloquer » l'utilisation du protocole HTTPS:

Utiliser le mécanisme HSTS (HTTP Strict Transport Security) pour éviter le coût du code 301 .
Définissez toujours l'indicateur sécurisé sur les cookies.

Utilisez d'abord Strict Transport Security pour indiquer aux clients qu'ils doivent toujours se connecter à votre serveur via HTTPS, lorsque vous suivez une référence http://. Cela permet de déjouer les attaques telles que Suppression SSL Cela évite le coût aller-retour du 301 redirect que nous avons activé dans Rediriger HTTP vers HTTPS.

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

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

Il est également important de s'assurer que les clients n'envoient jamais de cookies (comme (authentification ou préférences de site) via HTTP. Par exemple, si l'utilisateur d’authentification n’étaient pas exposées en texte brut, votre garantie de sécurité pour toute la session est détruite, même si vous avez fait tout le reste c'est bien ça !

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

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

Classement des résultats de recherche

Google considère le HTTPS comme étant une qualité de recherche positive. indicateur. Google publie également un guide permettant de savoir comment transférer, déplacer ou faire migrer site tout en maintenant son classement dans les résultats de recherche. Bing publie également des consignes aux webmasters.

Performances

Lorsque les couches de contenu et d'application sont bien réglées (reportez-vous à Steve Souders' livres pour obtenir des conseils), le protocole TLS les problèmes de performances sont généralement minimes par rapport au coût global application. Vous pouvez également réduire et amortir ces coûts. Pour obtenir des conseils sur TLS consultez l'article High Performance Browser Networking (Mise en réseau de navigateurs hautes performances) Ilya Grigorik, ainsi que celui d'Ivan Ristic OpenSSL Cookbook et SSL et TLS pare-feu.

Dans certains cas, TLS peut améliorer les performances, principalement en raison HTTP/2 possible. Pour plus d'informations, consultez Chris Palmer's nous parlerons des performances de HTTPS et HTTP/2 Chrome Dev Summit 2014

En-têtes d'URL de provenance

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

Les autres sites doivent passer au protocole HTTPS. Si les sites référents remplissent les Activer le protocole HTTPS sur vos serveurs de dans ce guide, vous pouvez remplacer les liens http:// de votre site par les leurs https:// ou utiliser des liens à protocole relatif.
Pour contourner différents problèmes liés aux en-têtes de provenance, utilisez le nouveau Norme de règle de provenance.

Revenus publicitaires

Les opérateurs de sites qui monétisent leur site en diffusant des annonces veulent s'assurer la migration vers le protocole HTTPS ne réduit pas le nombre d'impressions d'annonces. Toutefois, en raison de la diversité des problèmes de sécurité du contenu, un <iframe> HTTP ne fonctionne pas sur une page HTTPS. Les opérateurs de sites ne peuvent pas migrer vers le protocole HTTPS tant que les annonceurs n'ont pas effectué la publication via HTTPS sans perdre de revenus publicitaires. mais tant que les opérateurs de site n'ont pas migré vers HTTPS, les annonceurs sont peu enclins à publier le protocole HTTPS.

Pour mettre fin à cette obsolescence, vous pouvez faire appel à des annonceurs proposer des services publicitaires via HTTPS, et demander aux annonceurs qui n'utilisent pas le protocole HTTPS pour en faire au moins une option. Vous devrez peut-être différer Rendez les URL intranet relatives jusqu'à ce que suffisamment d'annonceurs interagissent correctement.