VPN専用サイトの証明書：DNS-01かプライベートCAか

VPN専用サイトが証明書をどう取得すべきかは、公開DNSゾーンを管理しているか、ホスト名を公開ログに出してよいか、すべてのクライアントにプライベートな信頼の基点を配布できるか、という三つの条件で決まります。公開経路とプライベート経路はどちらも機能する錠前を生み出し、それぞれ別の問いに答えます。これらの条件を決めずに一方を選ぶと、意図しない公開証明書を抱えることになったり、半分のクライアントに拒否される内部証明書を抱えることになったりします。

証明書は名前を証明し、VPNと内部DNSが経路を提供します。

信頼された名前への二つの経路

DNS-01検証を用いる公開発行機関は、管理下のゾーンにあるTXTレコードを通じて名前の制御を証明するため、ウェブサービスが公開HTTP接続を受け入れる必要はありません。プライベートCAは内部名のリーフ証明書を発行し、デバイス管理を通じて信頼の基点を配布するため、公開ログが名前を知ることはありません。どちらも正当であり、選択は利便性ではなく三つの条件から導かれます。どちらの経路も、クライアントが必要とする経路やリゾルバのエントリを提供しません。

公開証明書はホスト名を証明書透明性ログにも公開します。名前自体が機密であれば、その開示は後から気づく副作用ではなく設計上の判断です。

サービスを公開せずにDNS-01を使う

チャレンジレコードはゾーン内の予約された接頭辞の下にあるTXTエントリで、発行機関は権威DNSからそれを読み取ります。そのレコードを作成・削除できるACMEクライアントとDNS連携を選び、更新権限は、ゾーンに対する範囲を限定したAPI資格情報か、検証のためだけに使う管理下のホストに狭く限定します。一つの証明書を更新するためにアプリケーションサーバーへ無制限のレジストラ資格情報を与えるのは、作業に必要な権限をはるかに超えています。複数の注文が同じ名前を共有する場合は、TXT値を別々に保ち、一方の後片付けが他方がまだ必要とする値を消さないようにします。

固定のスリープではなく、権威サーバーへの確認によって伝播を待ちます。伝播の挙動はプロバイダーごとに異なり、今日うまくいくスリープは明日の根拠になりません。

管理されたクライアントと意図的に私有の名前

管理対象のデバイスと意図的に私有の名前は内部CAによく合います。デバイス管理を通じて信頼された発行機関を配布し、そのうえで対象の名前のリーフ証明書を発行します。OSへの一度の取り込みはあらゆるブラウザーとアプリケーションについての普遍的な主張ではないため、各クライアントが実際にどのストアを使うかを確認してください。リーフのピン留めは明示的に支持される場合の別の選択肢で、リーフが変わるたびにもう一度信頼を更新する代償があります。

配布チャネルは鍵と同じくらい重要で、誰も導入しないルートは何も守りません。

更新は設計の一部です

どの経路を選んでも、更新には担当者と手順が必要です。検証の証拠を更新し、新しい素材を導入し、対応する仕組みでリスナーを再読み込みするという三つは別々の手順であり、ほとんどのACMEクライアントが自動化するのは最初の一つだけです。正しく更新されても決して読み込まれない証明書は、期限切れと同じ障害を生みます。

証明書はVPNの経路を導入せず、内部DNSレコードも作成しません。クライアントには名前をプライベートアドレスに対応づけるリゾルバと、そこへ到達する経路が依然として必要です。両方を持つクライアントから名前でサイトを試してください。

発行機関、検証方法、信頼の配布チャネル、再読み込みの仕組みを記録します。その四つが更新計画です。