Pourquoi un nom de domaine ? Par exemple pour sécuriser le web…

J’utilisais auparavant un nom de domaine gratuit enregistré chez Dyn. Tout fonctionnait bien. Pourquoi changer ?

Après un premier billet sur la messagerie, je vais donner cette fois-ci l’exemple du web sécurisé (HTTPS), qui ne fonctionne vraiment bien dans les navigateurs qu’avec un « vrai » nom de domaine. J'en profiterai aussi pour aborder un aspect complémentaire lié à la messagerie.

This article has been translated to English.

Comme dans le billet relatif à la configuration initiale du DNS, j’appelle « new.example » le domaine acheté et « old.dyn.example » le domaine gratuit précédemment utilisé.

Quand on va sur un site sécurisé (banque, messagerie…), reconnaissable par le protocole HTTPS et le verrou qui s’affiche, le site fournit au navigateur web un certificat qui l’identifie de façon unique. Ce certificat est chiffré de telle sorte que seul le véritable site soit en mesure de l’émettre, et qu’il y ait une autorité de confiance qui puisse l’approuver. Ce dernier point est vérifié localement par le navigateur, qui intègre en standard un certificat spécial pour chaque autorité de confiance.

Il est impossible pour un site web de fournir un certificat qui satisfasse un navigateur web sans passer par une autorité de confiance, puisque le navigateur web ne trouve alors aucun certificat d’une autorité de confiance qui puisse confirmer la validité du certificat du site ! Il affiche alors une page d’avertissement qui décourage fortement l’utilisateur à confirmer sa volonté de visiter la page.

C’est un problème contournable pour quelqu’un qui connaît suffisamment le site pour garantir au navigateur qu’il peut faire confiance à ce certificat, mais on ne peut compter sur le fait que les visiteurs ordinaires accepteront cette manipulation.

Évidemment, les autorités de confiance se font toutes payer pour délivrer des certificats valides… Toutes ? Non ! Car une autorité de certification résiste encore et toujours à la mercantilisation du web :-P (Allez, j’arrête, sinon je vais finir par recevoir une ordonnance de cessation et d’abstention…).

StartSSL est un service qui permet d’obtenir gratuitement un certificat, certes limité, pour un domaine que l’on possède. Le certificat délivré par StartSSL est valable un an et doit être renouvelé (gratuitement) chaque année. StartSSL ne fonctionne qu’avec un vrai domaine, pas un sous-domaine ; or, un « domaine gratuit » n’est en réalité qu’un sous-domaine qui nous est prêté par le véritable propriétaire du domaine (sous domaine « old » du domaine « dyn.example » dans mon exemple), d’où la nécessité d’avoir acquis le domaine concerné.

En suivant les excellentes explications de geek85.net (ironiquement, son certificat n'est pas valide…), j’ai très facilement mis en place mon certificat.

Il faut tout d’abord s’inscrire auprès de StartSSL, ce qui se conclut par l’enregistrement dans le navigateur web d’un certificat personnel (encore un autre type de certificat…), permettant ensuite de s’identifier sur le site de manière très sécurisée, ce qu’il faut faire.

Il faut ensuite déclarer le domaine « new.example ». Via le « Control Panel », accéder au « Validations Wizard », dans lequel il faut choisir « Domain Name Validation ». C’est ici qu’on renseigne le nom du domaine, puis l’adresse électronique avec laquelle se feront tous les échanges dans le cadre des processus de validation et certification. À cette étape, il est d’un grand secours d’avoir déjà paramétré sa messagerie pour accepter les messages à destination du domaine « new.example » ; en effet, le choix de l’adresse électronique n’est pas libre et doit se faire parmi des propositions standard telle « hostmaster@new.example ». Il suffit ensuite de suivre les indications fournies.

Web sécurisé

Vient enfin la création du certificat. Il faut pour cela aller dans « Certificates Wizard » puis y choisir « Web Server SSL/TLS Certificate ». Remplir le nom de domaine, ainsi qu’un alias au choix (et obligatoire) ; il est bien sûr possible d’entrer le sempiternel www, mais puisqu’un seul alias est possible (pour du HTTPS certifié par StartSSL), mieux vaut bien réfléchir aux usages futurs ! Suivre les instructions… J’ai fait le choix de laisser StartSSL générer pour moi la clé privée, car mon accès HTTPS ne protège pas grand chose ; mais si vous avez vraiment des données confidentielles protégées par HTTPS, mieux vaut ne pas déléguer cette étape. À la fin du processus, j’obtiens deux fichiers, que j’enregistre sur mon serveur :

/etc/ssl/startssl/new.example_web.key.pem
/etc/ssl/startssl/new.example_web.crt.pem

Puis je complète avec quelques fichiers utiles, que je génère à l’aide des commandes suivantes :

cd /etc/ssl/startssl/
wget -qO - https://www.startssl.com/certs/ca.pem https://www.startssl.com/certs/sub.class1.server.ca.pem >startssl_ca+subclass1.crt.pem
cat new.example_web.crt.pem new.example_web.key.pem >new.example_web.crt+key.pem
cat new.example_web.crt.pem startssl_ca+subclass1.crt.pem >new.example_web+startssl_ca+subclass1.crt.pem
cat new.example_web+startssl_ca+subclass1.crt.pem new.example_web.key.pem >new.example_web+startssl_ca+subclass1.crt+key.pem

Les fichiers dont le nom comporte « key » doivent être gardés secrets.

Il faut ensuite modifier la configuration du serveur web pour utiliser ces certificats. J’ai récemment effectué une migration depuis Apache (sur lequel j’utilisais un certificat auto-signé, donc non reconnu par les navigateurs) vers Nginx. J’ai pris la peine d’intégrer mon certificat auto-signé dans les navigateurs que j’utilise, donc pour les adresses qui restent sur l’ancien domaine, je continue d’utiliser l’ancien certificat, puisque de toute façon le nouveau certificat n’est pas valide pour l’ancien domaine. Voilà à quoi ressemble globalement ma configuration Nginx :


server {
server_name old.dyn.example;
listen 80;
listen 443 ssl;
ssl_certificate /etc/ssl/certs/apache.pem;
ssl_certificate_key /etc/ssl/certs/apache.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 10m;

location / {
return 301 $scheme://new.example$request_uri;
}

location /reste-sur-le-vieux-domaine {
… configuration habituelle …
}
location /reste-aussi {
… configuration habituelle …
}
}
server {
listen 80 default_server;
listen 443 default_server ssl;
ssl_certificate /etc/ssl/startssl/new.example_web+startssl_ca+subclass1.crt.pem;
ssl_certificate_key /etc/ssl/startssl/new.example_web.key.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 10m;
keepalive_timeout 70;

}

Une fois la configuration terminée, elle peut être vérifiée comme indiqué sur le site jasoncodes.com :

echo HEAD / | openssl s_client -connect new.example:443 -quiet >/dev/null

Je désigne explicitement le domaine testé au lieu de laisser localhost pour lever toute ambigüité car mon serveur répond pour plusieurs domaines. Si tout se passe bien, on obtient un résultat qui ressemble à ça :

depth=2 …

verify return:0

En cas d'erreur, ça ressemblera plutôt à ça :

depth=0 …


verify return:1

Une fois cette vérification locale effectuée, le serveur web, vu de l'extérieur, peut être testé à nouveau et plus complètement, par ssllabs.com. Pour ma part, j'obtiens la note A :-)

Messagerie sécurisée

Comme suggéré par le site jasoncodes.com, le même certificat peut aussi être utilisé pour Exim (STARTTLS sur SMTP) et Courier (STARTTLS sur IMAP, IMAPS, POP3S), simplement en exécutant les commandes suivantes :

ln -s /etc/ssl/startssl/new.example_web+startssl_ca+subclass1.crt.pem /etc/exim4/exim.crt
ln -s /etc/ssl/startssl/new.example_web.key.pem /etc/exim4/exim.key

ln -s /etc/ssl/startssl/new.example_web+startssl_ca+subclass1.crt+key.pem /etc/courier/imapd.pem
ln -s /etc/ssl/startssl/new.example_web+startssl_ca+subclass1.crt+key.pem /etc/courier/pop3d.pem

Attention : Maintenant que le chiffrement est activé, il est important de surveiller que le certificat reste valide. J’ai donc suivi l’excellent conseil du site biapy.com et mis en place l’outil de surveillance de l’échéance de validité des certificats utilisés.

Mises à jour :

  • 2014-12-11 — Spécification du paramètre Nginx ssl_protocols pour se protéger du vilain caniche (« poodle » en anglais).
  • 2015-10-07 — Exim a besoin de la chaîne de certification complète pour que son certificat soit accepté par les clients.

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.

La discussion continue ailleurs

URL de rétrolien : http://yalis.fr/cms/index.php/trackback/39

Fil des commentaires de ce billet