Back

開発者のためのSSL証明書ガイド

開発者のためのSSL証明書ガイド

APIをデプロイし、ローカル環境では正常に動作していたのに、本番環境で証明書エラーが発生して動作しなくなる。証明書が一晩で期限切れになっていたのかもしれません。証明書チェーンが不完全だったのかもしれません。あるいは、誰かが年に一度手動で証明書を更新していて、ドキュメントを残していなかったシステムを引き継いだのかもしれません。

証明書の障害は実際の障害を引き起こします。Microsoft、Slackをはじめ、数え切れないほどの企業がこれを公に経験してきました。HTTPS対応のサイトやAPIをデプロイする開発者にとって、SSL証明書の理解は任意ではなく、基礎的なものです。

このガイドでは、証明書が実際に何であるか、最新のデプロイメントでどのように取得・更新されるか、そして業界が証明書の有効期間を短縮する中でシステムを稼働し続けるためのプラクティスについて説明します。

重要なポイント

  • TLS証明書は公開鍵をドメインのアイデンティティに紐付け、適切に機能するには完全な信頼チェーンが必要です
  • DV、OV、EV証明書は同一の暗号化を提供します—違いは検証プロセスにあり、セキュリティ強度ではありません
  • 証明書の有効期間が2029年までに47日に短縮されるため、ACMEによる自動更新は必須となります
  • 運用障害を防ぐため、証明書ピンニング、手動更新プロセス、CAのハードコーディングは避けてください

証明書とは実際に何か

TLS証明書は、公開鍵をアイデンティティ(通常はドメイン名)に紐付けます。ブラウザがサーバーに接続する際、証明書が有効で、期限切れではなく、信頼された認証局(CA)によって署名されていることを確認します。

信頼チェーンは次のように機能します:あなたの証明書は中間CAによって署名され、中間CAはブラウザやオペレーティングシステムがすでに信頼しているルートCAによって署名されています。いずれかのリンクが切れると—中間証明書の欠落、ルート証明書の期限切れ、ドメインの不一致—接続は失敗します。

証明書には、どのドメインやIPアドレスに対して有効かをリストするSubject Alternative Name(SAN)フィールドが含まれています。古いCommon Name(CN)フィールドは検証目的では非推奨です。最新のクライアントはSANを必要とします。

DV、OV、EV:実際に重要なこと

Domain Validation(DV)証明書は、ドメインを制御していることを証明します。検証は自動化されており、数秒で完了します。

Organization Validation(OV)およびExtended Validation(EV)は、法人の手動チェックを伴います。これらはコストが高く、時間もかかります。

実用的に重要なのは:暗号化は同一であるということです。EV証明書はかつて緑色のアドレスバーを表示していましたが、ブラウザはこのUI上の区別を削除しました。ほとんどの開発者にとって、Let’s EncryptのDV証明書で十分であり、無料です。

EV証明書の視覚的インジケーターに関する前提を構築しないでください—それらは廃止されています。

TLS証明書のライフサイクルと自動化

公開TLS証明書は短命であり、さらに短くなっています。Let’s Encryptは90日間の証明書を発行します。CA/Browser Forumはすでに、証明書の最大有効期間の段階的な短縮を承認しており、2026年に200日の上限から始まり、2029年までに47日に移行します。

これにより、証明書の自動発行と更新は任意ではなく必須となります。手動更新プロセスは規模に対応できません。

標準的なアプローチはACMEプロトコルを使用し、ライフサイクル全体を自動化します:

  1. ACMEクライアントが証明書をリクエスト
  2. CAがドメイン制御の証明を要求(HTTPまたはDNS経由)
  3. 自動的にチャレンジに応答
  4. CAが署名済み証明書を発行
  5. クライアントがインストールし、更新をスケジュール

Certbotは最も一般的なACMEクライアントですが、あらゆるスタックに対応する代替手段が存在します:acme.shはシェル環境向け、CaddyはACME組み込み、そしてNode.js、Go、Python用のライブラリがあります。

ACMEとLet’s Encryptのベストプラクティス

更新をデプロイメントパイプラインに統合し、並行して実行しないでください。証明書は人間の介入なしに自動的に更新されるべきです。

主要なプラクティス:

  • 早期更新:有効期限ではなく、30日以上残っている時点で更新をトリガー
  • 有効期限の監視:Kubernetes向けのcert-managerや、シンプルなcronベースのアラートなどのツールを使用
  • 更新のテスト:certbot renew --dry-runまたは同等のコマンドをCIで実行
  • CAロックインの回避:使用するCAについてハードコーディングした前提を置かない

秘密鍵は安全に保管してください。リポジトリにコミットしないでください。プラットフォームに適したシークレット管理を使用してください。

短期間およびIP TLS証明書

短期間証明書(数時間から数日)は、鍵が侵害された場合の露出期間を短縮します。一部の組織は24時間以下の有効期間の証明書を発行しています。

IP TLS証明書—ドメイン名ではなくIPアドレスの証明書—は、DNSが利用できない開発やDevOpsシナリオで重要です。Let’s Encryptは現在、ACME経由で短期間のIP証明書をサポートしており、自動化された短期間発行への広範な移行と整合しています。

ローカル開発では、mkcertのようなツールが、公開CAを介さずにローカルで信頼された証明書を作成します。

ポスト量子対応TLSへの準備

量子コンピュータは最終的に現在の暗号化アルゴリズムを破ります。大手プロバイダーはすでにハイブリッドポスト量子TLSを本番環境にデプロイしていますが、アプリケーション開発者が手動で設定する必要はありません。

アプリケーション開発者として、これを自分で実装する必要はありません。TLSライブラリを最新に保ち、現在の設定を使用し、SHA-1や2048ビット未満のRSA鍵などの非推奨アルゴリズムを避けてください。

移行はライブラリとインフラストラクチャレベルで行われます。あなたの仕事は、古い依存関係やハードコーディングされた前提でそれをブロックしないことです。

時代遅れになる前提

以下のパターンは避けてください:

  • 複数年の証明書を期待する:最大有効期間は短縮されています
  • CAのアイデンティティをハードコーディング:CAは信頼を失う可能性があり、ルートはローテーションします
  • 手動更新プロセス:スケールせず、静かに失敗します
  • 証明書ピンニング:証明書が変更される際に運用上の悪夢を生み出します
  • 証明書インベントリの無視:追跡していないものは更新できません

結論

最新のTLS証明書管理には自動化が必要です。業界は短い有効期間に向かっており、ACMEクライアント、更新パイプライン、監視は基本要件です。

Let’s Encryptまたは同様の自動化されたCAを使用してください。更新をデプロイメントプロセスに統合してください。証明書を追跡してください。ライブラリを最新に保ってください。これらのプラクティスにより、標準が進化し続ける中でHTTPSデプロイメントを確実に稼働させ続けることができます。

よくある質問

証明書の有効期限が切れると、ブラウザとクライアントはサーバーへの安全な接続の確立を拒否します。ユーザーは警告メッセージを見て、API呼び出しは失敗し、自動化されたシステムは動作しなくなります。最新のブラウザのほとんどは、ユーザーが続行することを許可するのではなく、アクセスを完全にブロックします。これが、早期トリガーによる自動更新が重要である理由です。

はい、Subject Alternative Names(SANs)を通じて可能です。単一の証明書は、SANフィールドに複数のドメインまたはサブドメインをリストできます。ワイルドカード証明書は、*.example.comのように単一レベルのすべてのサブドメインをカバーします。ただし、ワイルドカードにはDNSベースの検証が必要であり、ルートドメインは自動的にカバーされません。

短い有効期間は、秘密鍵が侵害された場合の露出時間を制限することでセキュリティを向上させます。また、自動化を強制し、人為的エラーを減らします。CA/Browser Forumは有効期間をさらに短くし、2029年までに47日にすることを推進しており、手動更新プロセスはますます実用的でなくなっています。

一般的には、いいえ。証明書ピンニングは、アプリケーションを特定の証明書または公開鍵にロックし、証明書がローテーションする際に深刻な運用上の問題を引き起こします。ピンニングを行った後、予期せず証明書を変更する必要がある場合、アプリケーションは動作しなくなります。Certificate Transparencyログなどの最新の代替手段は、運用リスクなしにセキュリティ上の利点を提供します。

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.

OpenReplay