14.4.4. CA-signierte (öffentlich vertrauenswürdige) Zertifikate

Selbstsignierte Zertifikate funktionieren, wenn Sie beide Enden kontrollieren. Falls stattdessen beliebige Clients (Browser, Telefone, Drittanbietersoftware) sich mit der Kamera verbinden müssen, ohne angewiesen zu werden, einem benutzerdefinierten Zertifikat zu vertrauen, muss das Zertifikat von einer öffentlichen Zertifizierungsstelle (CA) signiert sein, der diese Clients bereits vertrauen. Der TLS-Code auf der Kamera ist mit dem selbstsignierten Fall identisch – load_cert_chain mit einem Zertifikat und einem Schlüssel in DER-Form – nur die Art, wie Sie dieses Zertifikat beschaffen, ändert sich.

Der einzelne wichtigste Punkt: Sie erzeugen den privaten Schlüssel selbst, und er verlässt Ihren Rechner niemals. Die CA sieht ihn nie. Was Sie an die CA senden, ist eine Certificate Signing Request (CSR) – eine kleine Datei, die Ihren öffentlichen Schlüssel und Ihren Domainnamen enthält – und was Sie zurückerhalten, ist ein Zertifikat (Ihr öffentlicher Schlüssel und Name, signiert von der CA). Der Schlüssel und das Zertifikat sind zwei separate Dateien, die in zwei separaten Schritten erzeugt werden; die CA verarbeitet stets nur die öffentliche Hälfte.

Der allgemeine Ablauf, vollständig auf einem normalen Rechner durchgeführt (niemals auf der Kamera):

  1. Beschaffen Sie einen Domainnamen. Öffentliche CAs zertifizieren einen DNS-Namen, den Sie kontrollieren (z. B. cam.example.com); für eine reine IP-Adresse oder einen nur lokalen Namen wie mycam stellen sie nichts aus.

  2. Erzeugen Sie einen Schlüssel und eine CSR. Ein einziger OpenSSL-Befehl erzeugt den privaten Schlüssel und die passende CSR. Verwenden Sie denselben Schlüsseltyp wie bei einem selbstsignierten Zertifikat (siehe Konzepte: Vertrauen, Schlüssel und Dateiformat); ECDSA P-256 wird empfohlen.

    ECDSA P-256 – empfohlen:

    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 – stärker, größer/langsamer:

    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 Kompatibilität:

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

    Halten Sie domain.key geheim – dies ist die Schlüsseldatei, die Sie schließlich auf die Kamera legen werden. domain.csr ist die Datei, die Sie der CA übergeben; sie enthält keine Geheimnisse.

  3. Reichen Sie die CSR ein und weisen Sie nach, dass Sie die Domain kontrollieren. Hier unterscheiden sich die beiden gängigen Wege:

    • Eine automatisierte ACME-CA wie Let’s Encrypt, gesteuert durch ein Werkzeug wie certbot oder acme.sh, erledigt die Schritte 2 und 3 für Sie: Sie erzeugt den Schlüssel, baut die CSR, beantwortet die Challenge automatisch (HTTP-01: Bereitstellen eines Tokens über Port 80 auf der Domain, oder DNS-01: Veröffentlichen eines TXT-Eintrags im DNS) und schreibt die fertigen Dateien aus.

    • Eine kommerzielle CA (direkt gekauft oder über einen Domain-/Hosting-Reseller): Sie fügen den domain.csr-Text in ein Webformular ein und weisen dann die Kontrolle nach, indem Sie auf eine Validierungs-E-Mail antworten, einen DNS-Eintrag veröffentlichen oder eine Datei auf einem Webserver für diese Domain platzieren. Nach der Validierung laden Sie die ausgestellten Dateien herunter.

  4. Sammeln Sie die ausgestellten Dateien. Um zu verstehen, was Sie erhalten, hilft es zu wissen, dass Zertifikate eine Vertrauenskette bilden: Das Zertifikat Ihrer Domain wird von einer Intermediate-CA signiert, die wiederum von einer Root-CA signiert wird. Jedes Glied bürgt für das darunterliegende. Sie erhalten am Ende:

    • Ihren privaten Schlüssel (aus Schritt 2). Die CA hatte ihn nie; er bleibt auf Ihrem Rechner und ist der Schlüssel, den Sie schließlich auf die Kamera legen.

    • Das Leaf-Zertifikat – auch End-Entity- oder Server-Zertifikat genannt. Dies ist das Zertifikat für Ihre spezifische Domain (cam.example.com): Es enthält Ihren öffentlichen Schlüssel und Ihren Namen und ist vom Intermediate der CA signiert. Dies ist das Zertifikat, das die Kamera vorlegt, um sich zu identifizieren.

    • Ein oder mehrere Intermediate-CA-Zertifikate (die „Kette“ oder das „CA-Bundle“). Eine CA signiert Ihr Leaf nicht direkt mit ihrer Root – der Schlüssel der Root wird offline und stark geschützt aufbewahrt – sondern signiert mit einem Intermediate, das selbst von der Root signiert ist. Das Intermediate ist das Glied, das Ihr Leaf mit der Root verbindet.

    Das Root-Zertifikat ist der Vertrauensanker: ein selbstsigniertes Zertifikat, das der CA gehört und an der Spitze der Kette steht. Sie erhalten es nicht und stellen es niemals bereit, weil jeder Client es bereits besitzt – Betriebssysteme, Browser, Telefone und Sprachlaufzeitumgebungen werden mit einem eingebauten „Trust-Store“ von Root-Zertifikaten ausgeliefert. Ein Client vertraut Ihrem Leaf, indem er die Kette abläuft: Er vertraut der Root bereits, die Root bürgt für das Intermediate, und das Intermediate bürgt für Ihr Leaf. (Genau das ist die Aufgabe, die Ihre einzelne server.der / cafile im selbstsignierten Fall erfüllt – dort sind Sie Ihre eigene Root.)

    Eine fullchain-Datei ist einfach das Leaf und das/die Intermediate(s), zu einer Datei aneinandergehängt, Leaf zuerst, bewusst ohne die Root (die Root zu senden ist sinnlos – ein Client vertraut nur Roots, die er bereits besitzt). Ein normaler Server legt diese gesamte fullchain vor, damit jeder Client sie ablaufen kann. Die Kamera kann das nicht: Sie lädt und legt ein Zertifikat vor – das Leaf – und kann das/die Intermediate-Zertifikat(e), das/die die CA Ihnen gegeben hat, nicht zusätzlich senden.

    Dateinamen, die Ihnen tatsächlich begegnen werden: Ein ACME-Werkzeug wie certbot schreibt privkey.pem (Ihr Schlüssel), cert.pem (das Leaf allein), chain.pem (das/die Intermediate(s) allein) und fullchain.pem (Leaf + Intermediate(s)). Eine kommerzielle CA gibt Ihnen üblicherweise eine .crt für das Leaf und eine .ca-bundle für das/die Intermediate(s), wobei die .key diejenige ist, die Sie selbst erzeugt haben.

  5. Konvertieren und kopieren. Konvertieren Sie den privaten Schlüssel und das Leaf-Zertifikat nach DER und kopieren Sie sie genau wie unter Selbstsignierte Zertifikate auf die Kamera. Die Kamera legt sie dann als ihr Serverzertifikat vor, und Standard-Clients akzeptieren die Verbindung automatisch, weil sie der CA bereits vertrauen – keine clientseitige Konfiguration ist nötig.

Tipp

In der Praxis spielt sich das so ab, dass die Kamera nur das Leaf vorlegt (und niemals die Intermediates):

  • Clients, die das Intermediate der CA bereits zwischengespeichert haben – gängige Browser und HTTPS-Bibliotheken tun das üblicherweise – vervollständigen die Kette selbst und verbinden sich problemlos.

  • Clients, die sich darauf verlassen, dass der Server das Intermediate liefert, werden den Handshake gegen die Kamera nicht bestehen.

Falls jeder mögliche Client erfolgreich sein muss, terminieren Sie öffentliches TLS nicht direkt auf der Kamera. Setzen Sie ein Gateway / einen Reverse-Proxy davor, der die vollständige Kette der Außenwelt bereitstellt, und lassen Sie den Proxy die Kamera über den oben beschriebenen selbstsignierten Ablauf erreichen.