14.4.4. CA署名（公的に信頼された）証明書

自己署名証明書は、両端を自分で管理している場合に機能します。一方、任意のクライアント（ブラウザ、スマートフォン、サードパーティ製ソフトウェア）が、カスタム証明書を信頼するように指示されること なく カメラに接続しなければならない場合は、それらのクライアントがすでに信頼している公的な認証局（CA）によって証明書が署名されている必要があります。カメラ上のTLSコードは自己署名の場合と同一です。つまり、DER形式の証明書と鍵を使った load_cert_chain です。変わるのは、その証明書をどうやって入手するかだけです。

最も重要な点は次のとおりです。秘密鍵は自分で生成し、それは自分のマシンから決して外に出ません。 CAがそれを見ることはありません。CAに送るのは 証明書署名要求（CSR）であり、これは公開鍵とドメイン名を含む小さなファイルです。そして受け取るのは 証明書（公開鍵と名前にCAが署名したもの）です。鍵と証明書は、2つの別々の手順によって生成される2つの別々のファイルです。CAが扱うのは常に公開側の半分だけです。

一般的な流れは、すべて通常のマシン上で行います（決してカメラ上では行いません）:

  1. ドメイン名を取得します。 公開CAは、あなたが管理するDNS名（例: cam.example.com）を証明します。生のIPアドレスや mycam のようなローカルのみの名前に対しては発行しません。

  2. 鍵とCSRを生成します。 1つのOpenSSLコマンドで、秘密鍵とそれに対応するCSRが生成されます。自己署名証明書の場合と同じ鍵の種類を使用してください（概念: 信頼、鍵、ファイル形式 を参照）。ECDSA P-256が推奨されます。

    ECDSA P-256 -- 推奨:

    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 -- より強力だが、より大きく/遅い:

    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 -- 最大の互換性:

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

    domain.key は秘密にしておいてください。これが最終的にカメラに置く鍵ファイルです。domain.csr はCAに渡すファイルで、秘密情報は含まれていません。

  3. CSRを送信し、ドメインの管理権を証明します。 ここで2つの一般的な経路が分かれます:

    • Let's Encrypt のような自動化されたACME CAは、certbot や acme.sh のようなツールで駆動され、手順2と3を代行してくれます。鍵を生成し、CSRを構築し、チャレンジに自動的に応答し（HTTP-01: ドメインのポート80でトークンを配信する、またはDNS-01: そのDNSにTXTレコードを公開する）、完成したファイルを書き出します。

    • 商用CA（直接購入する場合や、ドメイン/ホスティングのリセラー経由で購入する場合）: domain.csr のテキストをWebフォームに貼り付け、検証メールへの返信、DNSレコードの公開、またはそのドメインのWebサーバーへのファイル配置によって管理権を証明します。検証が完了すると、発行されたファイルをダウンロードできます。

  4. 発行されたファイルを集めます。 受け取ったものを理解するには、証明書が 信頼の連鎖（チェーン） を形成することを知っておくと役立ちます。あなたのドメインの証明書は中間CAによって署名され、その中間CAはさらにルートCAによって署名されています。各リンクがその下のものを保証します。最終的に手に入るのは次のとおりです:

    • あなたの 秘密鍵（手順2より）。CAはこれを一度も持っていません。これは自分のマシンに残り、最終的にカメラに置く鍵です。

    • リーフ 証明書 -- エンドエンティティ 証明書または サーバー 証明書とも呼ばれます。これはあなたの特定のドメイン（cam.example.com）用の証明書で、あなたの公開鍵と名前を含み、CAの中間証明書によって署名されています。これはカメラが自身を識別するために提示する証明書です。

    • 1つ以上の 中間CA証明書（「チェーン」または「CAバンドル」）。CAはあなたのリーフをそのルートで直接署名しません。ルートの鍵はオフラインで厳重に保護されているためです。代わりに中間証明書で署名し、その中間証明書自体がルートによって署名されています。中間証明書は、あなたのリーフをルートまでつなぐリンクです。

    ルート 証明書は トラストアンカー です。これはチェーンの最上部に位置するCAに属する自己署名証明書です。これは渡されることもなく、決してデプロイすることもありません。なぜなら、すべてのクライアントがすでに持っているからです。オペレーティングシステム、ブラウザ、スマートフォン、言語ランタイムには、ルート証明書の組み込み「トラストストア」が付属しています。クライアントはチェーンをたどることであなたのリーフを信頼します。すでにルートを信頼しており、ルートが中間証明書を保証し、中間証明書があなたのリーフを保証するのです。（これはまさに、自己署名の場合に1つの server.der / cafile が果たす役割と同じです。そこでは あなた自身 が自分のルートなのです。）

    フルチェーン ファイルは単に、リーフと中間証明書を1つのファイルに連結したもので、リーフを先頭にし、意図的にルートを 含めません（ルートを送ることは無意味です。クライアントはすでに持っているルートしか信頼しません）。通常のサーバーは、どのクライアントもたどれるよう、このフルチェーン全体を提示します。カメラにはそれができません。カメラは 1つ の証明書、すなわちリーフを読み込んで提示するだけで、CAから渡された中間証明書を一緒に送ることはできません。

    実際に目にするファイル名: certbot のようなACMEツールは privkey.pem（あなたの鍵）、cert.pem（リーフ単体）、chain.pem（中間証明書単体）、fullchain.pem（リーフ + 中間証明書）を書き出します。商用CAは通常、リーフ用に .crt、中間証明書用に .ca-bundle を渡し、.key は自分で生成したものになります。

  5. 変換してコピーします。 自己署名証明書 とまったく同じように、秘密鍵とリーフ証明書をDERに変換してカメラにコピーします。するとカメラはそれらをサーバー証明書として提示し、標準的なクライアントはすでにCAを信頼しているため、接続を自動的に受け入れます。クライアント側の設定は不要です。

Tip

実際には、カメラがリーフのみを提示する（中間証明書は決して提示しない）ことで、次のような結果になります:

  • CAの中間証明書をすでにキャッシュしているクライアント（主要なブラウザやHTTPSライブラリは通常そうです）は、自分でチェーンを完成させて問題なく接続します。

  • 中間証明書の提供を サーバー に依存しているクライアントは、カメラに対するハンドシェイクに失敗します。

あらゆる可能なクライアントが成功しなければならない場合は、公開TLSをカメラ上で直接終端しないでください。カメラの前段にゲートウェイ/リバースプロキシを置き、外部にはフルチェーンを提供させ、そのプロキシが上記の自己署名フローでカメラに到達するようにします。