14.4.4. Certificats signés par une autorité de certification (publiquement approuvés)¶

Les certificats auto-signés conviennent lorsque vous contrôlez les deux extrémités. Si, au contraire, des clients quelconques (navigateurs, téléphones, logiciels tiers) doivent se connecter à la caméra sans qu’on leur ait demandé de faire confiance à un certificat personnalisé, le certificat doit être signé par une autorité de certification (CA) publique à laquelle ces clients font déjà confiance. Le code TLS sur la caméra est identique au cas auto-signé – load_cert_chain avec un certificat et une clé au format DER – seule la manière dont vous obtenez ce certificat change.

Le point le plus important : vous générez vous-même la clé privée et elle ne quitte jamais votre machine. L’autorité de certification ne la voit jamais. Ce que vous envoyez à l’autorité de certification est une demande de signature de certificat (CSR) – un petit fichier contenant votre clé publique et votre nom de domaine – et ce que vous recevez en retour est un certificat (votre clé publique et votre nom, signés par l’autorité de certification). La clé et le certificat sont deux fichiers distincts produits par deux étapes distinctes ; l’autorité de certification ne manipule jamais que la moitié publique.

Le déroulement général, entièrement effectué sur une machine normale (jamais sur la caméra) :

Obtenez un nom de domaine. Les autorités de certification publiques certifient un nom DNS que vous contrôlez (par exemple cam.example.com) ; elles n’émettent pas pour une adresse IP brute ni pour un nom local uniquement comme mycam.

Générez une clé et une CSR. Une seule commande OpenSSL produit la clé privée et la CSR correspondante. Utilisez le même type de clé que pour un certificat auto-signé (voir Concepts : confiance, clés et format de fichier) ; ECDSA P-256 est recommandé.

ECDSA P-256 – recommandé

openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 \
    -nodes -keyout domain.key -out domain.csr \
    -subj "/CN=cam.example.com" \
    -addext "subjectAltName=DNS:cam.example.com"

ECDSA P-384 – plus robuste, plus volumineux/plus lent

openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:secp384r1 \
    -nodes -keyout domain.key -out domain.csr \
    -subj "/CN=cam.example.com" \
    -addext "subjectAltName=DNS:cam.example.com"

RSA-2048 – compatibilité maximale

openssl req -new -newkey rsa:2048 \
    -nodes -keyout domain.key -out domain.csr \
    -subj "/CN=cam.example.com" \
    -addext "subjectAltName=DNS:cam.example.com"

Gardez domain.key secret – c’est le fichier de clé que vous finirez par placer sur la caméra. domain.csr est le fichier que vous remettez à l’autorité de certification ; il ne contient aucun secret.

Soumettez la CSR et prouvez que vous contrôlez le domaine. C’est ici que les deux voies courantes diffèrent :
- Une autorité de certification ACME automatisée comme Let’s Encrypt, pilotée par un outil tel que certbot ou acme.sh, effectue les étapes 2 et 3 à votre place : elle génère la clé, construit la CSR, répond automatiquement au défi (HTTP-01 : servir un jeton sur le port 80 du domaine, ou DNS-01 : publier un enregistrement TXT dans son DNS) et écrit les fichiers finalisés.
- Une autorité de certification commerciale (achetée directement ou via un revendeur de domaine/hébergement) : vous collez le texte de domain.csr dans un formulaire web, puis prouvez le contrôle en répondant à un courriel de validation, en publiant un enregistrement DNS, ou en plaçant un fichier sur un serveur web de ce domaine. Une fois la validation effectuée, vous téléchargez les fichiers émis.
Récupérez les fichiers émis. Pour comprendre ce que vous recevez, il est utile de savoir que les certificats forment une chaîne de confiance : le certificat de votre domaine est signé par une autorité de certification intermédiaire, qui est elle-même signée par une autorité de certification racine. Chaque maillon se porte garant de celui qui se trouve en dessous. Vous obtenez :
- Votre clé privée (de l’étape 2). L’autorité de certification ne l’a jamais eue ; elle reste sur votre machine et est la clé que vous finirez par placer sur la caméra.
- Le certificat feuille – aussi appelé certificat d’entité finale ou serveur. C’est le certificat de votre domaine spécifique (cam.example.com) : il contient votre clé publique et votre nom, et est signé par l’intermédiaire de l’autorité de certification. C’est le certificat que la caméra présente pour s’identifier.
- Un ou plusieurs certificats d’autorité de certification intermédiaires (la « chaîne » ou le « lot CA »). Une autorité de certification ne signe pas votre feuille directement avec sa racine – la clé de la racine est conservée hors ligne et fortement protégée – elle signe donc avec un intermédiaire, lui-même signé par la racine. L’intermédiaire est le maillon qui relie votre feuille à la racine.
Le certificat racine est l”ancre de confiance : un certificat auto-signé appartenant à l’autorité de certification qui se trouve au sommet de la chaîne. Il ne vous est pas fourni et vous ne le déployez jamais, car chaque client le possède déjà – les systèmes d’exploitation, les navigateurs, les téléphones et les environnements d’exécution des langages sont livrés avec un « magasin de confiance » intégré de certificats racine. Un client fait confiance à votre feuille en parcourant la chaîne : il fait déjà confiance à la racine, la racine se porte garante de l’intermédiaire, et l’intermédiaire se porte garant de votre feuille. (C’est exactement le rôle que joue votre unique server.der / cafile dans le cas auto-signé – là, c’est vous qui êtes votre propre racine.)

Un fichier fullchain est simplement la feuille et le ou les intermédiaires concaténés en un seul fichier, la feuille en premier, délibérément sans la racine (envoyer la racine est inutile – un client ne fait confiance qu’aux racines qu’il possède déjà). Un serveur normal présente toute cette fullchain afin que n’importe quel client puisse la parcourir. La caméra ne le peut pas : elle charge et présente un seul certificat – la feuille – et ne peut pas envoyer en plus le ou les certificats intermédiaires que l’autorité de certification vous a fournis.

Noms de fichiers que vous verrez réellement : un outil ACME tel que certbot écrit privkey.pem (votre clé), cert.pem (la feuille seule), chain.pem (le ou les intermédiaires seuls) et fullchain.pem (feuille + intermédiaire(s)). Une autorité de certification commerciale vous donne généralement un .crt pour la feuille et un .ca-bundle pour le ou les intermédiaires, le .key étant celui que vous avez généré vous-même.
Convertissez et copiez. Convertissez la clé privée et le certificat feuille en DER et copiez-les sur la caméra exactement comme dans Certificats auto-signés. La caméra les présente ensuite comme son certificat de serveur et les clients standard acceptent automatiquement la connexion, car ils font déjà confiance à l’autorité de certification – aucune configuration côté client n’est nécessaire.

Astuce

En pratique, le fait que la caméra ne présente que la feuille (et jamais les intermédiaires) se traduit ainsi :

Les clients qui ont déjà l’intermédiaire de l’autorité de certification en cache – ce qui est généralement le cas des navigateurs grand public et des bibliothèques HTTPS – complètent la chaîne eux-mêmes et se connectent sans problème.
Les clients qui comptent sur le serveur pour fournir l’intermédiaire échoueront à la négociation avec la caméra.

Si chaque client possible doit réussir, ne terminez pas le TLS public directement sur la caméra. Placez devant elle une passerelle / un proxy inverse qui présente la chaîne complète au monde extérieur, et faites en sorte que le proxy atteigne la caméra via le flux auto-signé décrit ci-dessus.