TLS証明書 - 暗号化全般

TLS証明書とは

TLS証明書（一般に「SSL証明書」とも呼ばれる）は、Webサイトの身元を証明し、ブラウザとサーバー間の暗号化通信（HTTPS）を実現するためのデジタル証明書です。ITU-T X.509という国際標準規格に従って構造が定義されており、IETFのRFC 5280がインターネット上でのX.509証明書とCRL（証明書失効リスト）のプロファイルを規定しています。

証明書という名前がついていますが、実体は「公開鍵」に「発行者（認証局）の電子署名」を紐付けたデータの集合です。証明書単体は公開情報であり、秘密鍵はサーバー側で厳重に保管されます。ブラウザは接続の都度この証明書を検証し、通信相手が本当に想定したドメインのサーバーであるかを確認します。

TLS証明書の役割：

• 身元証明：Webサイトが正当な運営者によるものであることを証明
• 通信の暗号化：ブラウザとサーバー間の通信を暗号化
• データの完全性：通信内容が改ざんされていないことを保証
• SEO効果：Googleはhttpsサイトを優遇

なお「TLS」と「SSL」は歴史的経緯から混同されやすい用語です。SSL（Secure Sockets Layer）はNetscapeが1990年代に開発したプロトコルで、SSL 3.0の脆弱性（POODLE攻撃など）を受けて後継のTLS（Transport Layer Security）に置き換えられました。現在主要ブラウザ・サーバーが対応しているのはTLS 1.2およびTLS 1.3（RFC 8446）のみで、SSL 2.0・3.0はすでに廃止（RFC 6176、RFC 7568）、TLS 1.0・1.1も2020年前後に主要ブラウザでサポート終了しています。「SSL証明書」という呼び方は業界慣習として残っていますが、技術的に発行・使用されているのはTLS証明書であると理解しておくと正確です。

仕組み・詳細解説

X.509証明書の内部構造

TLS証明書はASN.1（Abstract Syntax Notation One）というデータ形式で記述され、DER（バイナリ）またはPEM（Base64エンコードされたテキスト）でエンコードされます。証明書には主に以下のフィールドが含まれます。

フィールド	内容
Subject	証明対象のドメイン名（Common Name）や組織情報
Subject Alternative Name（SAN）	証明書が有効な追加のドメイン名やIPアドレス。現在は主要ブラウザがSANを必須で検証し、Common Nameのみの証明書は非推奨
Issuer	発行した認証局（CA）の情報
Validity（Not Before / Not After）	証明書の有効期間の開始・終了日時
Public Key	サーバーの公開鍵（RSAまたは楕円曲線鍵）
Signature Algorithm / Signature	発行者（CA）が証明書内容に対して施した電子署名とそのアルゴリズム

信頼の連鎖（Chain of Trust）

ブラウザやOSは、あらかじめ数十〜百数十の「ルート証明書」を信頼ストアに保持しています。しかしルート認証局が直接サーバー証明書に署名することは運用上ほぼなく、通常はルートCAが「中間CA」に署名し、中間CAがサーバー証明書に署名するという階層構造をとります。これにより、次のような検証チェーンが成立します。

ルート証明書（ブラウザ・OSに事前組込み、自己署名）
  └─ 中間証明書（ルートCAが署名）
       └─ サーバー証明書（中間CAが署名、実際にサイトが提示）

サーバーはこのうち「サーバー証明書」と「中間証明書」をセットで提示する必要があります（ルート証明書はクライアント側にすでにあるため送信不要）。この階層構造のおかげで、ルートCAの秘密鍵をオフライン（オフラインルート）で厳重に保管しつつ、日々の証明書発行は中間CAが担うという安全な運用が可能になっています。

TLSハンドシェイクにおける証明書の検証

証明書はTLSハンドシェイクの中で以下のように使われます（TLS 1.3の場合の概略）。

1. クライアントがClientHelloを送信し、対応可能な暗号スイートや鍵共有方式を提示
2. サーバーがServerHelloとともに自身のTLS証明書（＋中間証明書）を送付
3. クライアントは証明書チェーンを検証：署名の正当性、有効期限内か、SAN欄に接続先ホスト名が含まれるか、失効していないか（CRL/OCSP）を確認
4. 検証に成功すると、鍵交換（TLS 1.3では通常ECDHE：楕円曲線Diffie-Hellman）によりセッション鍵を導出し、以降のアプリケーションデータを対称鍵暗号（AES-GCMやChaCha20-Poly1305）で暗号化

ここで重要なのは、証明書自体は「本人確認」の役割のみを担い、通信の暗号化そのものは別途生成される一時的なセッション鍵（多くの場合ECDHEによる鍵交換で導出）が担うという点です。証明書の公開鍵は署名検証や鍵交換の認証に使われ、実際のデータ暗号化には使われません。

鍵長・署名アルゴリズムの推奨（2026年時点）

証明書に含まれる公開鍵の強度は、暗号として安全な期間の見積もりに直結します。米国NIST（SP 800-57 Part 1）やCA/Browser Forumのベースライン要件を踏まえると、実務では概ね以下が推奨されています。

アルゴリズム	推奨鍵長・曲線	備考
RSA	2048ビット以上（新規発行は3072ビット推奨の議論も）	CA/Browser Forumは2048ビット未満の新規発行を禁止。演算コストが比較的重い
ECDSA	P-256（secp256r1）またはP-384	同等の安全性強度をRSAより短い鍵長・少ない計算量で実現。ハンドシェイクの高速化に有利
署名ハッシュ	SHA-256以上	SHA-1署名は2017年前後にブラウザが不信任化済み。SHA-256が事実上の標準

実務ではRSAとECDSAのデュアル証明書（サーバーに両方を用意し、クライアントの対応状況に応じて出し分ける）を採用するCDN・大規模サービスも増えています。また、NISTは量子コンピュータの脅威に備えた耐量子計算機暗号（Post-Quantum Cryptography）の標準化を進めており、2024年にML-KEM（FIPS 203）、ML-DSA（FIPS 204）、SLH-DSA（FIPS 205）を標準として確定しました。TLS証明書の署名アルゴリズムそのものを耐量子仕様に置き換える動きは2026年時点ではまだ実験・移行段階（ハイブリッド鍵交換の先行導入が中心）ですが、長期的な計画としては把握しておく価値があります。

証明書の種類

検証レベル別

種類	検証内容	用途
DV（Domain Validation）	ドメイン所有権のみ	個人サイト、ブログ
OV（Organization Validation）	組織の実在性	企業サイト
EV（Extended Validation）	厳格な組織審査	金融、EC

ドメインカバレッジ別

• 単一ドメイン証明書：1つのFQDN（例：www.example.com）
• ワイルドカード証明書：サブドメインすべて（例：*.example.com）
• マルチドメイン証明書（SAN）：複数の異なるドメイン

AIエンジニアとしての実体験

マルチテナントAIサービスの構築で、動的にサブドメインを発行するシステムにワイルドカード証明書を導入しました。Let's Encryptを使用してコストを抑えつつ、自動更新を実現しています。

# certbot でワイルドカード証明書を取得（DNS認証）
sudo certbot certonly \
  --manual \
  --preferred-challenges dns \
  -d "*.example.com" \
  -d "example.com"

# DNS TXTレコードの設定後、認証を完了
# _acme-challenge.example.com に指定された値を設定

自動更新の設定

# cronでの自動更新
0 3 * * * /usr/bin/certbot renew --quiet --post-hook "systemctl reload nginx"

# systemd timerでの自動更新（推奨）
sudo systemctl enable certbot.timer
sudo systemctl start certbot.timer

メリット・デメリット（注意点）

メリット

• 通信の盗聴・改ざん防止：公共Wi-Fiなど信頼できないネットワーク経由でも、パスワードやフォーム入力内容が第三者に読み取られるリスクを大幅に低減できる
• なりすまし対策：フィッシングサイトが正規ドメインの証明書を取得することは（DV証明書であっても）ドメイン管理権の証明が必要なため一定のハードルになる
• ブラウザからの信頼表示・SEO優遇：HTTPS未対応サイトはChrome等で「保護されていない通信」と警告表示され、Googleの検索アルゴリズムでもHTTPSが評価要素の一つとされている
• HTTP/2・HTTP/3の前提条件：主要ブラウザはTLS上でのみHTTP/2・HTTP/3を有効化するため、パフォーマンス面の恩恵を受けるためにも実質必須
• 低コスト化・自動化の進展：Let's EncryptとACMEプロトコルの普及により、無料かつ自動で証明書を取得・更新できるようになった

デメリット・注意点

• 有効期限管理の負荷：証明書には必ず有効期限があり、更新を怠るとサイト全体がアクセス不能になる。自動更新の仕組みを組み込まないと運用リスクが恒常的に残る
• 秘密鍵の管理責任：証明書自体は公開情報だが、対になる秘密鍵が漏洩すると証明書の信頼性が根本から崩れる。漏洩時は失効申請（Revocation）と再発行が必須
• 「暗号化されている＝安全」という誤解：TLS証明書は通信経路の暗号化と身元確認のみを保証するものであり、Webアプリケーション自体の脆弱性（SQLインジェクション、XSS等）やDV証明書によるなりすましフィッシングサイトを防ぐものではない
• 処理コスト：TLSハンドシェイクや暗号処理にはCPUコストが発生する。近年のサーバー・ブラウザでは大きな問題にならないことが多いが、大量の同時接続を捌く環境ではECDSA採用やセッション再開（Session Resumption/0-RTT）などの最適化が検討対象になる
• 中間証明書の設定ミス：サーバー証明書のみを設定し中間証明書を含めないと、一部の環境（特にモバイルOSの古いバージョンや一部のAPIクライアント）で検証エラーとなることがある

混同されやすい用語・類似技術との違い

TLS証明書とSSL証明書

前述の通り、SSLはTLSの前身プロトコルであり、現在発行・利用されているのは技術的にはすべてTLS証明書です。「SSL証明書」は業界での慣用的な呼称として定着しているため、CA各社の製品名にも残っていますが、混乱を避けるため技術文書では「TLS証明書」と表記するのが正確です。

サーバー証明書とクライアント証明書

一般的に「TLS証明書」という場合はサーバー側が提示する証明書（サーバー証明書）を指します。一方、クライアント証明書はクライアント（利用者の端末やAPIクライアント）側が自身の身元を証明するために提示するもので、相互TLS認証（mTLS）で利用されます。マイクロサービス間通信やVPN、法人向けシステムのAPI認証などではmTLSが採用されることがあります。

CA発行証明書と自己署名証明書（Self-Signed Certificate）

自己署名証明書は、信頼された第三者（CA）ではなく自分自身の秘密鍵で署名した証明書です。暗号化通信自体は可能ですが、ブラウザの信頼ストアに登録されていないため「この接続ではプライバシーが保護されません」といった警告が表示されます。開発・検証環境や内部システムでは利用されますが、一般公開するWebサイトでは非推奨です。

コードサイニング証明書との違い

コードサイニング証明書は、実行ファイルやドライバなどのソフトウェアに対して発行元の身元と改ざんの有無を証明するための証明書で、Webサイトの身元証明を目的とするTLS証明書とは用途がまったく異なります。両者は同じX.509形式・PKI（公開鍵基盤）の仕組みを土台にしていますが、Extended Key Usageフィールドで用途が区別されており、TLSサーバー証明書をコードサイニングに流用することはできません。

証明書失効リスト（CRL）とOCSP

証明書の「有効期限」と「失効」は別概念です。有効期限内であっても、秘密鍵の漏洩などにより証明書が信頼できなくなった場合はCA側で「失効（Revoke）」処理が行われます。クライアントは失効状態をCRL（証明書失効リスト）またはOCSP（Online Certificate Status Protocol）で確認しますが、近年はOCSP Stapling（サーバー側が事前に失効確認結果を取得し証明書と一緒に提示する方式）が主流になりつつあります。

自社サーバー運用への応用

証明書の確認コマンド

# リモートサーバーの証明書確認
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | \
  openssl x509 -noout -dates -subject -issuer

# 証明書の有効期限確認スクリプト
check_expiry() {
  expiry=$(echo | openssl s_client -connect $1:443 -servername $1 2>/dev/null | \
    openssl x509 -noout -enddate | cut -d= -f2)
  echo "$1: $expiry"
}

秘密鍵・CSR生成時の注意点

証明書の安全性は、対になる秘密鍵の生成方法と保管方法に大きく依存します。実務では次の点に注意します。

# RSA 2048ビットの秘密鍵とCSR（証明書署名要求）を生成
openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.com.key -out example.com.csr \
  -subj "/CN=example.com"

# ECDSA（P-256）の秘密鍵とCSRを生成（RSAより高速・軽量）
openssl ecparam -name prime256v1 -genkey -noout -out example.com.key
openssl req -new -key example.com.key -out example.com.csr \
  -subj "/CN=example.com"

# 秘密鍵ファイルのパーミッションを制限（所有者のみ読み取り可）
chmod 600 example.com.key

• 鍵長・曲線の選択：新規発行するなら RSA 2048ビット以上、または ECDSA P-256 以上を選ぶ。1024ビットRSAや旧式のDSA鍵はすでに主要CAが発行を停止している
• 秘密鍵の保管：本番環境の秘密鍵はソースコードリポジトリにコミットしない。可能であればHSM（ハードウェアセキュリティモジュール）やクラウドのシークレットマネージャで管理する
• CSRのCommon Name／SAN：SAN欄に実際にアクセスされるすべてのホスト名（www有無、APIサブドメイン等）を含める。Common Nameのみでの発行は現在推奨されない
• 鍵の使い回しを避ける：証明書を更新するたびに新しい鍵ペアを生成するのが望ましい運用（certbot等のACMEクライアントは既定でこれを行う）

証明書選択のガイドライン

• 個人・小規模サイト：Let's Encrypt（無料、DV、ECDSA/RSAいずれも選択可）
• 企業サイト：商用CA（DigiCert、GlobalSign、Sectigoなど）のOV
• 金融・ECサイト：EV証明書を推奨。ブラウザのアドレスバー表示自体は簡素化されたが、審査の厳格さそのものが持つ信頼性・契約上の意味は維持されている
• 社内システム・マイクロサービス間通信：プライベートCA（自社構築またはHashiCorp Vault等のPKI機能）による内部証明書とmTLSの組み合わせ

関連する主要なRFC・標準規格

規格	内容
RFC 5280	インターネットX.509公開鍵基盤（PKI）の証明書・CRLプロファイル
RFC 8446	TLS 1.3プロトコル仕様
RFC 8555	ACME（Automatic Certificate Management Environment）プロトコル。Let's Encryptなどが採用
RFC 6960	OCSP（Online Certificate Status Protocol）
RFC 6962 / RFC 9162	Certificate Transparency（証明書発行の公開ログ化）
NIST SP 800-57	鍵長・暗号アルゴリズムの安全性強度に関する推奨事項
CA/Browser Forum Baseline Requirements	公的に信頼されるCAが遵守すべき発行基準（鍵長下限、有効期間上限など）

関連ブログ記事

最新動向（2026年）

証明書の短命化

Let's Encryptの90日証明書の普及に続き、業界全体で証明書有効期間の短縮が進んでいます。CA/Browser ForumではDV/OV証明書の最大有効期間を段階的に短縮する方針が議論されており、Appleなど大手ブラウザベンダーからは将来的に47日程度まで短縮する案も提示されています。有効期間が短くなるほど「鍵漏洩後に悪用され続ける期間」が短くなる一方、手動更新のオペレーションは現実的でなくなるため、ACMEクライアントによる自動更新の整備が前提条件になります。

ACME・自動化の標準化

RFC 8555で標準化されたACMEプロトコルによる証明書の自動発行・更新が事実上の業界標準となりました。Let's Encrypt以外にも、Google Trust ServicesやZeroSSL、商用CA各社もACME対応のエンドポイントを提供しており、certbot・acme.sh・各クラウドのロードバランサ組み込み機能など、選択肢が広がっています。大規模環境ではHashiCorp Vaultのようなプライベート認証局ソフトウェアで社内証明書の発行・更新まで自動化するケースも増えています。

耐量子計算機暗号（PQC）への移行準備

NISTは2024年にML-KEM（旧名Kyber、鍵カプセル化）とML-DSA（旧名Dilithium、電子署名）を含む耐量子計算機暗号の標準（FIPS 203〜205）を確定しました。TLS 1.3の鍵交換においては、既存のECDHEと耐量子アルゴリズムを組み合わせた「ハイブリッド鍵交換」の先行導入がブラウザ・CDN事業者で始まっています。証明書の署名アルゴリズム自体を耐量子仕様に切り替える動きは2026年時点でもまだ初期段階ですが、長期間有効なデータの機密性を扱うシステムでは「Harvest Now, Decrypt Later（今は暗号文を収集し将来の量子計算機で復号する）」という脅威モデルを踏まえた計画的な検討が推奨されています。

Certificate Transparencyの厳格化

主要ブラウザは、証明書がCertificate Transparency（CT）ログに登録されていることを事実上の必須要件としています。これにより、不正発行された証明書やドメイン名の見落としを第三者が監視できるようになっており、自社ドメイン宛に発行された証明書をCTログ検索サービスで定期的に確認することが、意図しない証明書発行（ドメイン乗っ取りの兆候など）の早期発見に役立ちます。

トラブル事例と対策

外部リンク・参考資料

• RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and CRL Profile（IETF）
• CA/Browser Forum - Baseline Requirements Documents
• NIST SP 800-57 Part 1 - Recommendation for Key Management
• Let's Encrypt（無料の非営利認証局）
• SSL Labs Server Test（証明書・TLS設定の検証ツール）
• DigiCert（商用認証局）

関連用語

• X.509証明書
• 証明書チェーン
• Let's Encrypt
• HTTPS
• TLS

この用語についてもっと詳しく

TLS証明書に関するご質問やSSL設定のご相談など、お気軽にお問い合わせください。