14.4.4. Door een CA ondertekende (openbaar vertrouwde) certificaten

Zelfondertekende certificaten werken wanneer je beide kanten beheert. Als in plaats daarvan willekeurige clients (browsers, telefoons, software van derden) met de camera moeten verbinden zonder dat hun is verteld een aangepast certificaat te vertrouwen, moet het certificaat worden ondertekend door een openbare Certificate Authority (CA) die die clients al vertrouwen. De TLS-code op de camera is identiek aan het zelfondertekende geval – load_cert_chain met een certificaat en een sleutel in DER-vorm – alleen de manier waarop je dat certificaat verkrijgt verandert.

Het allerbelangrijkste punt: je genereert de private sleutel zelf en die verlaat je machine nooit. De CA ziet hem nooit. Wat je naar de CA stuurt is een certificate signing request (CSR) – een klein bestand met je publieke sleutel en je domeinnaam – en wat je terugkrijgt is een certificaat (je publieke sleutel en naam, ondertekend door de CA). De sleutel en het certificaat zijn twee aparte bestanden die in twee aparte stappen worden geproduceerd; de CA verwerkt alleen ooit de publieke helft.

De algemene flow, volledig uitgevoerd op een normale machine (nooit op de camera):

  1. Verkrijg een domeinnaam. Openbare CA’s certificeren een DNS-naam die je beheert (bijv. cam.example.com); ze geven geen certificaat uit voor een kaal IP-adres of een lokale naam zoals mycam.

  2. Genereer een sleutel en een CSR. Eén OpenSSL-commando produceert de private sleutel en de bijbehorende CSR. Gebruik hetzelfde sleuteltype als voor een zelfondertekend certificaat (zie Concepten: trust, sleutels en bestandsformaat); ECDSA P-256 wordt aanbevolen.

    ECDSA P-256 – aanbevolen:

    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 – sterker, groter/langzamer:

    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 – maximale compatibiliteit:

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

    Houd domain.key geheim – dit is het sleutelbestand dat je uiteindelijk op de camera zet. domain.csr is het bestand dat je aan de CA overhandigt; het bevat geen geheimen.

  3. Dien de CSR in en bewijs dat je het domein beheert. Hier verschillen de twee gangbare routes:

    • Een geautomatiseerde ACME-CA zoals Let’s Encrypt, aangestuurd door een tool als certbot of acme.sh, doet stap 2 en 3 voor je: hij genereert de sleutel, bouwt de CSR, beantwoordt de challenge automatisch (HTTP-01: serveer een token over poort 80 op het domein, of DNS-01: publiceer een TXT-record in zijn DNS) en schrijft de voltooide bestanden weg.

    • Een commerciële CA (rechtstreeks gekocht of via een domein-/hostingreseller): je plakt de domain.csr-tekst in een webformulier, en bewijst vervolgens controle door te antwoorden op een validatiemail, een DNS-record te publiceren of een bestand op een webserver voor dat domein te plaatsen. Eenmaal gevalideerd download je de uitgegeven bestanden.

  4. Verzamel de uitgegeven bestanden. Om te begrijpen wat je ontvangt, is het handig te weten dat certificaten een chain of trust vormen: het certificaat van je domein is ondertekend door een intermediate CA, die op zijn beurt is ondertekend door een root CA. Elke schakel staat in voor de schakel eronder. Je eindigt met:

    • Je private sleutel (uit stap 2). De CA heeft hem nooit gehad; hij blijft op je machine en is de sleutel die je uiteindelijk op de camera zet.

    • Het leaf-certificaat – ook wel het end-entity- of server-certificaat genoemd. Dit is het certificaat voor je specifieke domein (cam.example.com): het bevat je publieke sleutel en je naam, en is ondertekend door de intermediate van de CA. Dit is het certificaat dat de camera presenteert om zichzelf te identificeren.

    • Een of meer intermediate CA-certificaten (de “chain” of “CA bundle”). Een CA ondertekent je leaf niet rechtstreeks met zijn root – de sleutel van de root wordt offline en zwaar beveiligd bewaard – dus ondertekent hij met een intermediate, die zelf door de root is ondertekend. De intermediate is de schakel die je leaf met de root verbindt.

    Het root-certificaat is het trust anchor: een zelfondertekend certificaat dat aan de CA toebehoort en boven aan de keten staat. Je krijgt hem niet en je deployt hem nooit, omdat elke client hem al heeft – besturingssystemen, browsers, telefoons en taalruntimes worden geleverd met een ingebouwde “trust store” van rootcertificaten. Een client vertrouwt je leaf door de keten te doorlopen: hij vertrouwt de root al, de root staat in voor de intermediate, en de intermediate staat in voor je leaf. (Dit is precies de taak die je enkele server.der / cafile doet in het zelfondertekende geval – daar ben jij je eigen root.)

    Een fullchain-bestand is simpelweg de leaf en de intermediate(s) samengevoegd in één bestand, leaf eerst, opzettelijk zonder de root (het sturen van de root is zinloos – een client vertrouwt alleen roots die hij al heeft). Een normale server presenteert deze volledige fullchain zodat elke client hem kan doorlopen. De camera kan dat niet: hij laadt en presenteert één certificaat – de leaf – en kan niet ook de intermediate-certificaten sturen die de CA je gaf.

    Bestandsnamen die je daadwerkelijk zult zien: een ACME-tool zoals certbot schrijft privkey.pem (je sleutel), cert.pem (alleen de leaf), chain.pem (alleen de intermediate(s)) en fullchain.pem (leaf + intermediate(s)). Een commerciële CA geeft je meestal een .crt voor de leaf en een .ca-bundle voor de intermediate(s), waarbij de .key degene is die je zelf hebt gegenereerd.

  5. Converteer en kopieer. Converteer de private sleutel en het leaf-certificaat naar DER en kopieer ze naar de camera precies zoals op Zelfondertekende certificaten. De camera presenteert ze vervolgens als zijn servercertificaat en standaardclients accepteren de verbinding automatisch, omdat ze de CA al vertrouwen – er is geen configuratie aan de clientzijde nodig.

Tip

In de praktijk pakt het feit dat de camera alleen de leaf presenteert (en nooit de intermediates) als volgt uit:

  • Clients die de intermediate van de CA al in de cache hebben – gangbare browsers en HTTPS-bibliotheken doen dat meestal – voltooien de keten zelf en verbinden prima.

  • Clients die erop vertrouwen dat de server de intermediate aanlevert, mislukken in de handshake tegen de camera.

Als elke mogelijke client moet slagen, beëindig dan geen openbare TLS rechtstreeks op de camera. Plaats een gateway / reverse proxy ervoor die de volledige keten naar de buitenwereld serveert, en laat de proxy de camera bereiken via de hierboven beschreven zelfondertekende flow.