SSL/TLS認証証明書 — そのフィールドと有効期限の意味とは

ある時点で、ブラウザの小さなロックアイコンに注目し、「証明書を表示」をクリックした後、意味がわからない複雑なフィールドに直面する場合があります。「サブジェクト代替名」、「OCSP」、「SHA-256 と RSA 暗号化」など。あなたはダイアログを閉じます。証明書は緑色です。それだけです。

期限までです。金曜日の午前0時。本番環境で。

この記事は、TLS証明書の内部にあるフィールドを一つずつ解説し、次回トラブルシューティングが必要なときに、読むべき内容を知らせます。

証明書は単に署名されたドキュメントです

儀礼を除いて、TLS証明書は、誰がこのドメインを所有しているか、どの公開鍵を使用しているか、そしてこのドキュメントが有効期限を迎えるまでの期間といった事実を含むテキストドキュメントであり、それが証明書機関（CA）によって暗号的に署名されています。CAの署名がブラウザがそれを信頼する原因です。それ以外は注釈です。

基本的なフォーマットはX.509です。1988年に定義され、複数回改訂され、現在は RFC 5280に規定されています。そのため、ブラウザの証明書詳細ダイアログは、1988年を最近の時代と考えるような人々が設計したように見えます。

重要なフィールドの説明

ここに、実際に見られる証明書のフィールドについての注釈付きの分解を示します。以下に示すPEMデータは代表的なもの（現実の証明書ではありません）です。

Certificate:
  Data:
    Version: 3 (0x2)                          # Always v3 for modern certs
    Serial Number:                             # Unique ID issued by the CA
      04:b3:c2:...(truncated)
    Signature Algorithm: sha256WithRSAEncryption  # Hash + key algorithm used to sign
    Issuer:
      C  = US                                 # Country
      O  = Let's Encrypt                      # Organization (the CA)
      CN = R11                                # Common Name of the issuer
    Validity:
      Not Before: Apr  1 00:00:00 2026 GMT    # Cert isn't valid before this date
      Not After : Jun 30 23:59:59 2026 GMT    # Cert is invalid after this date
    Subject:
      CN = iotools.cloud                      # Domain this cert was issued for
    Subject Public Key Info:
      Public Key Algorithm: rsaEncryption
      Public-Key: (2048 bit)                  # RSA key size
    X509v3 extensions:
      Subject Alternative Names:
        DNS:iotools.cloud                     # All domains this cert covers
        DNS:www.iotools.cloud
      Key Usage: Digital Signature, Key Encipherment
      Extended Key Usage: TLS Web Server Authentication
      Basic Constraints: CA:FALSE             # This is NOT a CA cert
      Authority Key Identifier: ...           # Fingerprint of issuer's key
      Subject Key Identifier: ...             # Fingerprint of this cert's key
      Certificate Policies: ...
        CPS: http://cps.letsencrypt.org
      OCSP: http://r11.o.lencr.org           # Where to check revocation status

共通名（CN）

元のフィールドで、証明書がカバーするドメインを指定するものでした。まだ見られるのはそのフィールドが埋められていることですが、 CN = example.com — しかし、ブラウザはほとんどこれに頼らなくなっています。2000年以降、サブジェクト代替名（SAN）拡張がドメインマッチングの公式なフィールドとなっています。CNは現在のところ古びたものであり、SANが存在する場合、ブラウザはSANのみを使用します。

サブジェクト代替名（SAN）

これは、証明書が保護する実際のドメインリストです。1つの証明書は数十の名前をカバーできます——ワイルドカードエントリ（*.example.com）、正確な名前、あるいはIPアドレスを含みます。複数ドメイン証明書（SAN証明書またはUCC証明書）は標準的な実務です。CAはこのリストに対して発行し、ブラウザは訪問中のホスト名とそれを照合します。

ワイルドカードが オブジェクト型のように する一つの点は、サブサブドメインをカバーすることです。 *.example.com 3. 中間プロキシが Accept-Encoding を削除 app.example.com は api.v2.example.com多くの人がこれが難しい方法で気づきます。

有効期限期間

2つのタイムスタンプ: 開始日（Not Before） と 終了日（Not After）。この期間外では証明書は無効です——開始日以前、または終了日以降。どちらもUTCです。

最大証明書寿命は徐々に縮小しています。2015年には最大3年でした。2018年には2年まで縮小し、2020年にAppleが独自に398日（約13ヶ月）を超える証明書を拒否し始めたため、ブラウザベンダーおよびCAもそれに従いました。2026年現在、CA/Browserフォーラムは2027年までに47日まで寿命を縮小するルートを承認しています。

短い有効期限の理由は正当です：プライベートキーが侵害された場合、短い有効期限は影響範囲を縮小します。しかし、現実には短い有効期限はリニューアル自動化の正確性を高める必要をもたらします。Let’s Encryptの90日間の証明書は2015年に同じ理由で議論されましたが、現在はベストプラクティスとされ、自動リニューアルが期待されています。

発行者と信頼連鎖

の 発行者 フィールド名は、証明書を署名したエンティティを示します。ほとんどの公開サイトでは、中間CA（例：Let’s EncryptのR11）であり、根CAではありません。根CAは中間CAの証明書を署名し、中間CAは最終エンティティ証明書（サーバーが提示するもの）を署名します。この連鎖は、根CAのプライベートキーが空気中隔離されたHSM（ハードウェアセキュリティモジュール）に保存されているため、1年間に数百万のドメイン証明書を署名するためには公開できないからです。

ブラウザが証明書を検証する際、連鎖を上に進みます：あなたの証明書 → 中間 → 根。根がブラウザの信頼ストアに含まれている場合、連鎖が検証されます。連鎖内のいずれかの証明書が欠落、有効期限切れ、または無効鍵で署名されている場合、検証は失敗します。

そのため、最も一般的なTLSの誤設定は、中間証明書を葉証明書とともに提供していないことです。ブラウザは中間証明書をキャッシュし、問題が見えない場合がありますが、curl、モバイルアプリ、外部API呼び出しを行うサーバーなどは、根に到達するパスがないため失敗します。

署名アルゴリズム

1つのフィールドにまとめられた2つの要素：証明書データをハッシュ化するハッシュ関数と、そのハッシュを署名する鍵アルゴリズム。 sha256WithRSAEncryption SHA-256ハッシュ、RSA署名。 ecdsa-with-SHA256 SHA-256ハッシュ、ECDSA署名。

SHA-1署名は2017年にブラウザで廃止され、現在はハードファイールを引き起こします。MD5署名は以前に廃止され、実質的に絶滅しました。内部でSHA-1証明書を発行しているシステムがある場合は、ブラウザの更新がそれを自動的に行う前に、CA設定を更新してください。

ECDSA（通常はP-256またはP-384）は、同等のセキュリティでRSAよりも小さい鍵と署名を生成します。256ビットのEC鍵は約3072ビットのRSA鍵と同等です。代償は、RSAは非常に古いクライアントとの互換性が高く、ECDSAは高速で軽量です。現代のデプロイでは、両方を設定し、TLS交渉が選択するようにします。

鍵使用および拡張鍵使用

鍵使用 ビットマスクで、鍵が許可される操作を指定しています：データの署名、データの暗号化、他の証明書の署名（CA専用）。 拡張鍵使用 特定のプロトコルに細部を指定します： TLS Web Server Authentication HTTPSで証明書を使用できるようにします。 TLS Web Client Authentication mTLSクライアント証明書に使用します。 Code Signing ソフトウェア署名証明書に使用します。

目的が宣言された鍵使用に外れている場合、現代のTLS実装はそれを拒否します。ドメインが一致していても、コード署名証明書をWebサーバーに使用することはできません。

基本制約：CA:FALSE

このフィールドは、証明書が他の証明書を署名できるかどうかを指定します。 CA:FALSE それは、署名できない——葉（最終エンティティ）証明書です。 CA:TRUE それはCA証明書であり、他の証明書を署名できるようにされています。

の pathLenConstraint このフィールドが時々併記されているのは、この証明書の下にある中間CAの数を制限するためです。根CAは通常、連鎖の深さを制限するためにこのフィールドを設定します。

OCSPおよび無効化

証明書内のOCSP（オンライン証明書ステータスプロトコル）URLは、証明書が有効期限内に無効化されたかどうかを確認するための場所を示します。無効化は、プライベートキーが侵害されたか、または誤って発行された場合に発生します。

実際には、ブラウザのOCSPチェックは複雑な歴史を持っています。Chromeは数年前からリアルタイムのOCSPチェックを停止し、CRLセット（事前にフェッチされた無効化された高価値証明書のリスト）に切り替えました。FirefoxはまだOCSPを実行していますが、デフォルトはソフト失敗（OCSPサーバーにアクセスできない場合、証明書を有効とみなす）です。結果として、ほとんどの証明書の無効化は理論的なものにすぎません。これは短い有効期限（47日）の証明書の利点の一つです——有効期限が近いため、無効化が重要でなくなるからです。

なぜ証明書が有効期限を迎えるのか

有効期限は、手続き的な摩擦ではありません。それは、侵害された認証情報が有効期間をどれだけ長く維持するかを制限する仕組みです。代替案——永続的な認証情報——は、SHA-1証明書や数十年前に使われていたCA鍵が現在のプロダクション環境に残っているという状況をもたらします。これは2010年に業界の状態でした。

トレードオフは運用上のもの：短い有効期限は信頼できる自動化を必要とします。あなたのリニューアルがシステム管理者のカレンダーのリマインダーに依存している場合、最終的にプロダクション環境で有効期限を迎えます。正しい答えは、ACME（Let’s Encryptプロトコル）またはCAのAPIによる自動リニューアルと、有効期限の数週間前からアラートを通知するモニタリングです。

コマンドラインを使わずに証明書を読む方法

証明書を確認する標準的な方法は openssl x509 -in cert.pem -text -nooutで、RFC 5280を軽く読めるようにフォーマットされた出力を生成します。opensslのフラグを覚える必要がないように、同じ情報を提供する SSL/TLS証明書デコーダー と X.509証明書パーサー のiotools.cloudは、PEM形式の証明書を受取り、すべてのフィールドをラベル付きで整理して表示し、夜中、チェーンの問題をデバッグしているときに、opensslの長いテキストが役に立たない場合に非常に便利です。

あなたも好きかもしれません