🤖

企業ネットワークで独自証明書が必要なワケ：プロキシサーバーがHTTPSを中継する仕組み

に公開
ChatGPT で書いた
tech

1. 職場のプロキシサーバーは何をしているのか

多くの企業では社内ネットワークの出口にプロキシサーバーを置いている。このプロキシサーバーがインターネットに行く通信を中継し、セキュリティ的なフィルタリングや監査をするわけ。

たとえば、GitHub Copilot みたいな外部サービスに HTTPS 通信でアクセスしようとすると、まずはこのプロキシサーバーを経由していく。

2. HTTPS 通信を「中継する」だけではなく「復号・再暗号化」している

HTTPS は暗号化されていて、通常なら「第三者が通信内容を見れない」のがメリットだ。ところが企業によっては、「通信内容を検査しないとセキュリティリスクがある」と考えている場合も多い。そこでプロキシサーバーは「Man-in-the-Middle (中間者) 的な動き」をする。

  1. ユーザーのマシン → プロキシサーバー
    • プロキシサーバーが自前の証明書（独自認証局で署名されたもの）を提示して通信を暗号化する。
  2. プロキシサーバー → 外部サーバー（例えば GitHub Copilot サーバー）
    • プロキシサーバーが外部サーバーの正規の証明書を検証して、プロキシサーバー自身が改めて暗号化してアクセスする。

要は、プロキシサーバーが社内からの HTTPS 通信をいったん復号し、検査したりログを取ってから、外部サーバーに再度暗号化して接続している。こうすることで企業としてはセキュリティチェックや情報漏洩監査ができる。

3. なぜ独自の証明書をインストールしないとエラーになるのか

3.1 信頼されていないと「証明書エラー」が起こる

プロキシサーバーが使う証明書は、企業内で運用している独自の認証局(CA)が発行したもの。
でも、ユーザーのマシンや一般のブラウザや Node.js は、その独自認証局を最初から知らない。知らないということは「正体不明の証明書」として扱われる。

結果、エラーが発生する例はこんなメッセージ:

  • unable to verify the first certificate
  • SSL certificate problem: self signed certificate in certificate chain など

3.2 「独自認証局を信頼する」よう登録する

この問題を解決するには、ユーザーのマシン側が「この証明書は信頼していい」という情報を知る必要がある。具体的には:

  • ブラウザに企業の独自CA証明書をインストールして「社内CAは信頼可能」とする
  • Node.js の場合は NODE_EXTRA_CA_CERTS などの環境変数で独自CAの証明書を追加する
  • OS全体の証明書ストアにインポートしておく（管理者権限が必要になることが多い）

こうすることで、「プロキシサーバーが提示してくる独自CAで署名された証明書」の検証が通り、エラーがなくなる。

4. 通信と暗号化の流れ（Mermaid.js でイメージ図）

以下は、ユーザーのマシン(U)・職場のプロキシサーバー(P)・GitHub Copilot APIサーバー(G) の三者で起こる通信の流れを示す例。実際のシーケンスをシンプルに図にしている。

sequenceDiagram
    participant U as ユーザーのマシン
    participant P as 職場のプロキシサーバー
    participant G as GitHub Copilot APIサーバー

    Note over U,P: (1) ユーザーのマシンから HTTPS 通信を発行
    U->>P: HTTPS 接続要求 (1) 
    Note left of U: <b>TLSハンドシェイク</b><br>サーバ証明書を検証
    
    Note over P: (2) プロキシサーバーは外部と通信
    P->>G: HTTPS 接続要求 (2)
    Note right of P: <b>TLSハンドシェイク</b><br>実際のGitHub Copilot<br>サーバ証明書を検証

    Note over G: (3) GitHub Copilot APIサーバーからサーバ証明書送付
    G-->>P: サーバ証明書 + TLSハンドシェイク (3)

    Note over P: (4) プロキシサーバー側で復号＆検査後、再暗号化
    P-->>U: 職場独自CAで署名された証明書を提示 (4)
    Note right of U: ここでユーザーのマシンは<br>「職場独自CAを信頼」している必要がある

    Note over U: (5) TLS暗号化セッション確立
    U-->>P: 暗号化通信 (5)
    
    Note over P: (6) P と G 間の暗号化通信
    P-->>G: 暗号化通信 (6)

ここでのポイントは、プロキシサーバーが自前のCAで署名した証明書をユーザーに渡すところ。企業独自の認証局をユーザーのマシンが信頼していないとエラーになる。

5. 証明書は何を証明しているのか

HTTPS のサーバー証明書は、「誰がどんなドメインに対して正当な権利を持っているのか」を認証局(CA)が保証する仕組み。

  • 普段使われるのは、信頼できる有名な認証局(Globalsign, Digicert, Let's Encryptなど)から発行された証明書
  • 企業内の環境だと、会社が独自に認証局を建てて運営するケースがある
  • 独自CAで署名されたサーバー証明書をユーザーが受け取ったときに、ユーザー側がその独自CAを認識していないと「誰だよコイツ？」となってしまう

6. まとめ

  • なぜ企業環境で独自証明書が必要なのか？
    • プロキシサーバーがHTTPS通信を復号し、再暗号化して社内クライアントに返す仕組みだから。
  • 独自証明書を入れないとどうなる？
    • クライアントから見れば「未知の発行元」の証明書になり、検証エラーが出る。
  • どうやって対処する？
    • ブラウザやOS、Node.jsに企業の独自CAを信頼させる（証明書を追加インストールする）ことでエラーを回避できる。

企業のセキュリティポリシーとしては、通信の中身を確認しつつ、外部サーバーとの暗号化通信も維持したい、という両立のためにこの仕組みがある。ちょっと面倒だけど、企業内でのインターネット利用ではよくある話なので、覚えておくといろいろ役に立つ。

Discussion