HTTP et HTTPS : requêtes, codes d'état et certificats

HTTP (HyperText Transfer Protocol) est le protocole du web : un client (le navigateur, curl, une application) envoie une requête à un serveur, qui renvoie une réponse avec un code d'état. HTTPS, c'est HTTP transporté dans une connexion TLS chiffrée et authentifiée par un certificat : le port passe de 80 à 443. Ce chapitre décortique une requête et une réponse, les méthodes, les codes et les versions du protocole, puis les certificats (publics ou internes) et la publication d'un intranet en HTTPS avec Nginx sous Debian 13.

Une requête, une réponse

Chloé Lambert teste l'intranet de Sorbier, servi par srv-intranet (192.168.21.10), avec curl en mode bavard. Les lignes qui commencent par > sont envoyées, celles qui commencent par < sont reçues.

$ curl -v https://intranet.sorbier.example/annuaire
* Connected to intranet.sorbier.example (192.168.21.10) port 443
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* Server certificate:
*  subject: CN=intranet.sorbier.example
*  issuer: CN=Sorbier-AC
> GET /annuaire HTTP/2
> Host: intranet.sorbier.example
> User-Agent: curl/8.14.1
> Accept: */*
>
< HTTP/2 200
< server: nginx
< content-type: text/html; charset=utf-8
< strict-transport-security: max-age=31536000
<
<!DOCTYPE html> ...

Une requête contient : une méthode (GET), un chemin (/annuaire), la version, puis des en-têtes (Host, User-Agent…), une ligne vide et, pour certaines méthodes, un corps (les données d'un formulaire, du JSON). Une réponse contient : la version, un code d'état (200), des en-têtes et le corps (la page).

HTTP est sans état : chaque requête est indépendante, le serveur ne se souvient de rien entre deux requêtes. C'est le cookie, envoyé par le serveur (Set-Cookie) puis renvoyé par le navigateur à chaque requête (Cookie), qui permet de rester connecté d'une page à l'autre (cours Authentification).

Les méthodes

Les API REST utilisent toutes ces méthodes (cours API REST) ; un site web classique se contente surtout de GET et POST.

Les codes d'état

Le premier chiffre donne la famille. En dépannage, il dit tout de suite qui est en cause : un code 4xx désigne une erreur côté client (la requête), un code 5xx une erreur côté serveur.

Les en-têtes à connaître

HTTP/1.1, HTTP/2, HTTP/3

HTTPS : ce que TLS apporte

HTTPS ajoute, sous HTTP, une couche TLS (Transport Layer Security) qui apporte trois garanties :

• la confidentialité : les échanges sont chiffrés, personne sur le trajet ne lit les mots de passe ni les pages ;
• l'intégrité : un échange modifié en route est détecté ;
• l'authentification du serveur : le certificat prouve que tu parles bien à intranet.sorbier.example, et pas à un imposteur.

La version actuelle est TLS 1.3 ; TLS 1.2 reste acceptable, les versions antérieures (TLS 1.0, 1.1, SSL) sont interdites. Le déroulé de la poignée de main TLS 1.3 et les algorithmes employés sont expliqués dans le chapitre TLS 1.3 et HTTPS du cours Cryptographie. Ici, on s'occupe de ce que l'administrateur manipule : le certificat.

Un point technique compte en exploitation : l'extension SNI (Server Name Indication). Le client envoie le nom du site dès le début de la poignée de main, avant tout chiffrement : un serveur qui héberge plusieurs sites sur la même adresse IP choisit ainsi le bon certificat. C'est ce qui permet à un reverse proxy de publier dix sites sur une seule adresse publique.

Le certificat, champ par champ

Un certificat X.509 associe une clé publique à une identité, et il est signé par une autorité de certification (AC) qui se porte garante de cette association (certificat et PKI).

Le navigateur fait confiance au certificat s'il peut remonter une chaîne de confiance : le certificat du serveur est signé par une AC intermédiaire, elle-même signée par une AC racine présente dans le magasin de confiance du système. Le serveur doit envoyer son certificat et les intermédiaires : un serveur qui n'envoie que son propre certificat fonctionne sur certains navigateurs (qui ont déjà l'intermédiaire en cache) et échoue sur d'autres.

Certificat public ou certificat interne ?

Le protocole ACME (RFC 8555) obtient et renouvelle un certificat sans intervention : le client prouve qu'il contrôle le nom, par un défi HTTP (déposer un fichier à une adresse précise du site, sur le port 80) ou un défi DNS (créer un enregistrement TXT _acme-challenge dans la zone). Le défi DNS permet d'obtenir un certificat pour un nom qui n'est pas joignable depuis Internet, comme intranet.sorbier.example. Sur pfSense, le paquet acme fait ce travail pour les certificats du reverse proxy (chapitre 9) ; sous Debian, certbot ou acme.sh.

Publier l'intranet en HTTPS avec Nginx

srv-intranet est un serveur Debian 13 avec Nginx 1.26. L'intranet est un site interne : son certificat vient de l'AC interne de Sorbier, Sorbier-AC, à laquelle tous les postes du domaine font déjà confiance.

1. Créer la clé et la demande de certificat sur srv-intranet :

sudo mkdir -p /etc/ssl/sorbier && cd /etc/ssl/sorbier
sudo openssl req -new -newkey rsa:3072 -noenc \
    -keyout intranet.key -out intranet.csr \
    -subj "/O=Sorbier Logistique/CN=intranet.sorbier.example" \
    -addext "subjectAltName=DNS:intranet.sorbier.example,DNS:srv-intranet.ad.sorbier.example"
sudo chmod 600 intranet.key

-noenc laisse la clé privée sans mot de passe, pour que Nginx démarre sans intervention ; elle est protégée par ses droits (lisible par root seulement).

2. Faire signer la demande par l'AC interne, depuis un serveur Windows du domaine, avec le modèle de serveur web publié sur l'AC (son nom court, sans espaces) :

certreq -submit -attrib "CertificateTemplate:SorbierServeurWeb" intranet.csr intranet.cer

certreq demande quelle autorité utiliser, puis enregistre le certificat signé dans intranet.cer. Copie-le sur srv-intranet, avec le certificat de l'AC, dans un fichier intranet.crt qui contient d'abord le certificat du serveur, puis celui de l'AC (format PEM).

3. Déclarer le site dans /etc/nginx/sites-available/intranet :

server {
    listen 80;
    server_name intranet.sorbier.example;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    http2 on;
    server_name intranet.sorbier.example;

    ssl_certificate     /etc/ssl/sorbier/intranet.crt;
    ssl_certificate_key /etc/ssl/sorbier/intranet.key;
    ssl_protocols       TLSv1.2 TLSv1.3;

    add_header Strict-Transport-Security "max-age=31536000" always;

    root  /var/www/intranet;
    index index.html;

    access_log /var/log/nginx/intranet.access.log;
    error_log  /var/log/nginx/intranet.error.log;

    location / {
        try_files $uri $uri/ =404;
    }
}

4. Activer et vérifier :

sudo ln -s /etc/nginx/sites-available/intranet /etc/nginx/sites-enabled/
sudo nginx -t                        # syntax is ok / test is successful
sudo systemctl reload nginx
curl -I https://intranet.sorbier.example

Le premier bloc server redirige tout le HTTP vers HTTPS (code 301). La directive http2 on; active HTTP/2 (elle remplace l'ancien paramètre http2 de la ligne listen, depuis Nginx 1.25). ssl_protocols refuse tout ce qui est plus ancien que TLS 1.2.

Tester un certificat en ligne de commande

# La chaîne présentée par le serveur, la version de TLS négociée
openssl s_client -connect intranet.sorbier.example:443 -servername intranet.sorbier.example </dev/null

# Les dates et les noms du certificat
openssl s_client -connect intranet.sorbier.example:443 -servername intranet.sorbier.example </dev/null 2>/dev/null \
    | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

# Sous Windows : tester le port, puis lire le certificat d'un site
Test-NetConnection intranet.sorbier.example -Port 443
curl.exe -vI https://intranet.sorbier.example

-servername envoie le SNI : sans lui, un serveur qui héberge plusieurs sites peut présenter un autre certificat que celui que tu veux tester. Pour un site public, le test en ligne SSL Labs note la configuration de A+ à F.

Exercices

server {
    listen 80;
    listen 443 ssl;
    server_name intranet;
    ssl_certificate     /var/www/intranet/cert.pem;
    ssl_certificate_key /var/www/intranet/cert.key;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
    root /var/www/intranet;
}