Étapes abordées dans cet article
- Créez une paire de clés publique/privée RSA de 2 048 bits.
- Générez 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.
- Installez votre certificat final à 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 requêtes 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/publiques et une requête de signature de certificat.
Générer une paire de clés publique/privée
Commençons par générer une paire de clés RSA de 2 048 bits. Une clé plus petite, telle que 1 024 bits, est insuffisamment résistante aux attaques par force brute. Une clé plus grande, telle que 4 096 bits, est en sursollicitation. Au fil du temps, la taille des clés augmente à mesure que le traitement informatique diminue. 2 048 est actuellement la valeur idéale.
La commande permettant de générer la paire de clés RSA est la suivante:
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 requête de signature de certificat, ou requête de signature de certificat. La commande openssl vous demande de manière interactive 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
Affiche 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 []: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 devrait 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 nécessitent différentes méthodes pour envoyer vos requêtes de signature de certificat. Ces méthodes peuvent inclure l'utilisation d'un formulaire sur leur site Web, l'envoi de la requête de signature de certificat par e-mail, ou autre chose. 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êtes 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.
Le service de garantie de votre clé publique varie en fonction de l'autorité de certification.
Vous pouvez également mapper votre clé sur plusieurs noms DNS, y compris plusieurs noms distincts (par exemple, tous les noms de "example.com", "www.example.com", "example.net" et "www.example.net") ou des noms "caractères génériques" tels que *.example.com.
Par exemple, une autorité canadienne propose actuellement les tarifs suivants:
- Standard: 16 $/an, valide pour example.com et www.example.com.
- Caractère générique: 150 $/an, valide pour example.com et *.example.com.
À ces prix, les certificats génériques sont économiques lorsque vous avez plus de neuf sous-domaines. Sinon, vous pouvez simplement acheter un ou plusieurs certificats à nom unique. (Si vous disposez de plus de cinq sous-domaines, un certificat générique peut vous être plus pratique lorsque vous activez HTTPS sur vos serveurs.)
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) les requiert.
Activer HTTPS sur vos serveurs
L'activation du protocole HTTPS sur vos serveurs est une étape essentielle dans la sécurité de vos pages Web.
- Utilisez l'outil de configuration du serveur de Mozilla pour configurer votre serveur afin qu'il soit compatible avec le protocole HTTPS.
- Testez régulièrement votre site avec le test de serveur SSL pratique de Qualys et assurez-vous d'obtenir au moins un score A ou 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 un hébergement virtuel basé sur le nom.
Si vous utilisiez des adresses IP distinctes pour chaque nom d'hôte, vous pouvez facilement accepter HTTP et HTTPS pour tous les clients.
Cependant, la plupart des opérateurs de site utilisent un hébergement virtuel basé sur le nom pour conserver les adresses IP, car il est généralement plus pratique. Le problème avec IE sous Windows XP et Android antérieurs à la version 2.3 est qu'ils ne comprennent pas l'indication du nom du serveur (SNI), qui est essentielle pour l'hébergement virtuel basé sur le nom HTTPS.
Un jour ou peut-être bientôt, les clients qui ne sont pas compatibles avec la SNI seront remplacés par un logiciel moderne. Surveillez la chaîne user-agent dans vos journaux de requêtes pour savoir quand suffisamment d'utilisateurs sont passés à des logiciels modernes. (Vous pouvez déterminer votre seuil, peut-être inférieur à 5%, ou inférieur à 1%.)
Si le service HTTPS n'est pas déjà disponible sur vos serveurs, activez-le dès maintenant (sans rediriger HTTP vers HTTPS ; voir ci-dessous). Configurez votre serveur Web pour qu'il utilise les certificats que vous avez achetés et installés. Le générateur de configuration pratique de Mozilla peut vous être utile.
Si vous avez de nombreux noms d'hôte ou sous-domaines, ils doivent chacun utiliser le certificat approprié.
Maintenant, et pendant toute la durée de vie de votre site, vérifiez votre configuration HTTPS à l'aide du test de serveur SSL pratique de Qualys. Votre site doit obtenir la note A ou A+. Traitez comme un bug tout ce qui peut entraîner une mauvaise note. (Le A d'aujourd'hui est le B de demain, car les attaques contre les algorithmes et les protocoles s'améliorent constamment !)
Rendre les URL intrasite relatives
Maintenant que vous diffusez votre site à la fois via HTTP et HTTPS, tout doit fonctionner le plus facilement possible, quel que soit le protocole. Un facteur important est l'utilisation d'URL relatives pour les liens intrasites.
Assurez-vous que les URL intrasite et externes sont indépendantes du protocole. En d'autres termes, assurez-vous d'utiliser des chemins d'accès relatifs ou d'omettre le protocole tel que //example.com/something.js.
Un problème survient lorsque vous diffusez une page via HTTPS qui inclut des ressources HTTP, appelées contenu mixte. Les navigateurs avertissent les utilisateurs que le protocole HTTPS a été perdu. En fait, dans le cas d'un contenu mixte actif (script, plug-ins, CSS, iFrames), il arrive souvent que les navigateurs ne chargent pas ou n'exécutent pas du tout le contenu, ce qui génère une page défectueuse. N'oubliez pas qu'il est parfaitement acceptable d'inclure des ressources HTTPS dans une page HTTP.
De plus, lorsque vous ajoutez des liens vers d'autres pages de votre site, les utilisateurs peuvent passer du protocole HTTPS au protocole HTTP.
Ces problèmes surviennent lorsque vos pages incluent des URL intrasite complètes qui utilisent le schéma http://.
<h1>Welcome To Example.com</h1> <script src="http://example.com/jquery.js"></script> <link rel="stylesheet" href="http://assets.example.com/style.css"/> <img src="http://img.example.com/logo.png"/>; <p>A <a href="http://example.com/2014/12/24/">new post on cats!</a></p>Évitez d'utiliser des URL intrasite complètes.
En d'autres termes, faites en sorte que les URL intrasite soient aussi relatives que possible: soit à protocole relatif (sans protocole, commençant par //example.com), soit à hôte relatif (en commençant uniquement par le chemin, comme /jquery.js).
<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.
<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.
<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>Utilisez des URL HTTPS pour les URL intersites (si possible).
Pour ce faire, utilisez un script, et non une main. 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 se compose de fichiers simples, testez votre script sur une copie de développement de ces fichiers. Comme d'habitude, déployez les modifications en production uniquement une fois qu'elles ont été transmises au contrôle qualité. 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, car 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 que vous puissiez déjà déployer entièrement le protocole HTTPS, forcer votre site à utiliser HTTPS pour toutes les sous-ressources peut avoir un effet négatif. Il est probable qu'il existe une période pendant laquelle le protocole HTTPS soit nouveau et étrange pour vous. Le site HTTP doit continuer de 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ées 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 de protocole 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 et qui fournit à la fois HTTP et HTTPS. C'est généralement une bonne idée de toute façon, car cela vous permet de mieux contrôler l'apparence, les performances et la sécurité de votre site. De plus, vous n'avez pas besoin de faire confiance à un tiers, ce qui est toujours agréable.
Redirection HTTP vers HTTPS
Vous devez placer un lien canonique en tête de page pour indiquer aux moteurs de recherche que HTTPS est le meilleur moyen d'accéder à votre site.
Ajoutez des balises <link rel="canonical" href="https://…"/> dans vos pages. Cela aide les moteurs de recherche à déterminer le meilleur moyen d'accéder à votre site.
Activer la règle Strict Transport Security et sécuriser les cookies
À 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 le drapeau 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 vaincre les attaques telles que la suppression de SSL et d'éviter le coût aller-retour du 301 redirect que nous avons activé dans Rediriger HTTP vers HTTPS.
Activez le mécanisme HSTS (HTTP Strict Transport Security) en définissant l'en-tête Strict-Transport-Security. La page HSTS de l'OWASP contient des liens vers les instructions de divers logiciels de 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 via HTTP (pour l'authentification ou les préférences de site, par exemple). Par exemple, si le cookie d'authentification d'un utilisateur est exposé en texte brut, la garantie de sécurité de l'ensemble de la session sera détruite, même si vous avez fait tout le reste correctement.
Par conséquent, modifiez votre application Web pour toujours définir l'indicateur sécurisé 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'application a un moyen de définir l'indicateur.
La plupart des serveurs web offrent 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 en tant qu'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 d'excellents conseils), les problèmes de performances TLS restants sont généralement minimes par rapport au coût global de l'application. De plus, vous pouvez réduire et amortir ces coûts. (Pour obtenir d'excellents conseils sur l'optimisation TLS et d'une manière générale, consultez l'article High Performance Browser Networking d'Ilya Grigorik.) Consultez également les pages OpenSSL Cookbook et BulletProof SSL and TLS d'Ivan Ristic.
Dans certains cas, TLS peut améliorer les performances, principalement en rendant HTTP/2 possible. Chris Palmer a présenté les performances HTTPS et HTTP/2 lors du Chrome Dev Summit 2014.
En-têtes de référents
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 peuvent suivre la section Activer HTTPS sur vos serveurs de ce guide, vous pouvez remplacer les liens
http://de votre site parhttps://, 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 provenance.
Étant donné que les moteurs de recherche migrent vers le protocole HTTPS, il est probable que vous verrez plus d'en-têtes de provenance lorsque vous migrerez vers HTTPS à l'avenir.
Revenus publicitaires
Les opérateurs 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, une <iframe> HTTP ne fonctionne pas sur une page HTTPS. Le problème d'action collective est complexe: tant que les annonceurs n'ont pas publié de contenu via HTTPS, les opérateurs de site ne peuvent pas migrer vers le protocole HTTPS sans perte de revenus publicitaires. Toutefois, tant que les opérateurs de site n'ont pas migré vers le protocole HTTPS, les annonceurs sont peu motivés pour publier le protocole HTTPS.
Les annonceurs doivent au moins proposer un service publicitaire via HTTPS (par exemple, en remplissant la section "Activer HTTPS sur vos serveurs" de cette page). C'est déjà le cas de nombreuses personnes. Vous devriez demander aux annonceurs qui ne diffusent pas du tout le protocole HTTPS de commencer. Vous pouvez différer l'exécution de l'étape Rendre les URL intrasite relatives jusqu'à ce que suffisamment d'annonceurs interagissent correctement.