証明書

X.509とは? 証明書の仕組み・用途・取得方法を徹底解説します!

インターネット上で安全な通信を確保するために欠かせない「X.509証明書」。

TLS/SSL、電子メールの暗号化、コード署名など、さまざまな場面で活用されていますが、「X.509とは何か?」「どのように取得・管理すればいいのか?」と疑問に感じる方も多いのではないでしょうか。

本記事では、X.509証明書の基本から発行・管理方法、さらには最新のセキュリティ課題までを分かりやすく解説します。

専門知識がなくても理解できるように、図解や具体例を交えながら詳しく説明するので、ぜひ最後までご覧ください!

外資系エンジニア

この記事は以下のような人におすすめ!

  • X.509とは何か知りたい人
  • TLS/SSL証明書とX.509の関係が知りたい
  • どのような場面で、X.509が使われるのか知りたい

X.509の基礎知識

1-1. X.509とは何か

1-1-1. X.509の基本概念

X.509とは、公開鍵基盤(PKI: Public Key Infrastructure)において使用されるデジタル証明書の標準フォーマットです。

主に、以下のような目的で利用されます。

  • インターネット通信の暗号化(HTTPSやVPN)
  • 電子メールのセキュリティ強化(S/MIME)
  • 電子署名による認証(ソフトウェアの署名や文書の電子署名)

X.509証明書は、ある主体(個人、組織、ウェブサイトなど)の公開鍵とその所有者情報を認証局(CA: Certificate Authority)が署名することで、真正性を保証します。

1-1-2. X.509証明書の基本構成

X.509証明書は、特定のフォーマットでデータを格納しています。主な構成要素は以下のとおりです。

項目説明
バージョン情報X.509のどのバージョンのフォーマットを使用しているか
シリアル番号証明書ごとの一意の識別番号
発行者(Issuer)証明書を発行した認証局(CA)の情報
有効期限証明書の有効期間(開始日と終了日)
証明書所有者(Subject)証明書が発行された対象(ウェブサイト、企業、個人など)
公開鍵情報証明書に関連付けられた公開鍵
署名アルゴリズム認証局(CA)が使用した署名の方式
デジタル署名証明書の改ざんを防ぐための認証局の署名

このように、X.509証明書は、暗号技術を用いて通信の安全性を確保する重要な役割を担っています。

1-2. X.509の歴史と背景

1-2-1. X.509の誕生と進化

X.509の規格は、国際電気通信連合(ITU-T)によって1988年に初めて策定されました。

当初は、電子メールなどの通信においてユーザーを認証する目的で開発されましたが、インターネットの発展とともにその用途が広がりました。

その後、X.509は以下のような進化を遂げてきました。

  • X.509 v1(1988年): 最初の規格。基本的な証明書の構造が定義された。
  • X.509 v2(1993年): 証明書の識別情報(Subject Unique Identifier、Issuer Unique Identifier)を追加。
  • X.509 v3(1996年): 拡張機能をサポートし、証明書にカスタム属性を追加できるように。

現在では、X.509 v3が最も広く使用されており、TLS/SSL証明書をはじめ、多くのインターネットセキュリティ技術の基盤となっています。

1-2-2. X.509の標準化と普及

X.509は、インターネットにおける認証技術の基盤として広く普及しています。

特に、TLS/SSLを活用したウェブサイトの暗号化通信において不可欠な存在です。

また、近年ではゼロトラストセキュリティの考え方が広まる中で、デバイス認証やIoTセキュリティの分野でもX.509証明書の利用が増加しています。

X.509証明書の構造

X.509とは、デジタル証明書の標準フォーマットであり、暗号化通信や電子署名の分野で広く使用されています。

X.509証明書の構造を理解することで、その仕組みや役割をより深く理解することができます。

ここでは、X.509証明書の基本構成要素と、バージョンごとの違いについて詳しく解説します。

2-1. X.509証明書の基本構成要素

X.509証明書には、特定の情報が含まれており、それぞれに重要な役割があります。

これらの情報は、証明書が適切に機能し、セキュリティを確保するために必要不可欠です。

2-1-1. X.509証明書の主な要素

X.509証明書の基本的な構成要素は以下のとおりです。

項目説明
バージョン情報X.509のどのバージョン(v1、v2、v3)を使用しているか
シリアル番号証明書ごとの一意の識別番号
署名アルゴリズム認証局(CA)が使用した署名アルゴリズム
発行者(Issuer)証明書を発行した認証局(CA)の情報
有効期間(Validity)証明書の有効開始日と有効期限
証明書所有者(Subject)証明書が発行された主体(個人、企業、ウェブサイトなど)
公開鍵情報証明書に含まれる公開鍵の詳細
拡張フィールド(Extensions)X.509 v3で導入された追加情報(使用用途の制限など)
デジタル署名証明書の改ざんを防ぐための認証局の署名

これらの要素が組み合わさることで、X.509証明書は安全な通信と信頼性の確保を実現します。

2-1-2. X.509証明書の役割

X.509証明書は、以下のような目的で使用されます。

  • ウェブサイトのSSL/TLS認証(HTTPS通信の暗号化)
  • 電子メールの暗号化と署名(S/MIME)
  • ソフトウェアのコード署名(アプリケーションの真正性保証)
  • VPNやWi-Fiの認証(セキュアなネットワークアクセスの確立)

例えば、ウェブサイトがX.509証明書を使用することで、ユーザーはそのサイトが本物であり、暗号化された安全な通信が行われていることを確認できます。

2-2. バージョンごとの違い(v1、v2、v3)

X.509証明書は、1988年に初めて標準化されて以来、いくつかのバージョンアップが行われてきました。

バージョンごとの主な違いを理解することで、現在使用されているX.509 v3の特徴がより明確になります。

2-2-1. X.509 v1(バージョン1)

X.509 v1は、最も基本的なデジタル証明書の形式であり、以下の情報を含んでいました。

  • 証明書の所有者(Subject)
  • 証明書を発行した認証局(Issuer)
  • 公開鍵情報
  • 有効期間
  • 署名アルゴリズム

しかし、X.509 v1には拡張性がなく、用途の広がりに対応することが難しかったため、後のバージョンで改良されました。

2-2-2. X.509 v2(バージョン2)

X.509 v2では、以下の2つの識別情報が追加されました。

  • Issuer Unique Identifier(発行者の一意識別子)
  • Subject Unique Identifier(証明書所有者の一意識別子)

これにより、同じ名前の証明書所有者や発行者が存在する場合でも、それぞれを識別できるようになりました。

ただし、まだ拡張機能には対応していませんでした。

2-2-3. X.509 v3(バージョン3)

現在広く使用されているX.509 v3では、拡張フィールド(Extensions)が導入され、大幅な機能強化が行われました。

主な改良点は以下のとおりです。

  • 証明書の用途制限(特定の用途にのみ証明書を使用可能にする)
  • 代替名(Subject Alternative Name, SAN)(1つの証明書で複数のドメインを保護可能)
  • 鍵の使用制限(Key Usage)(暗号化・署名・認証などの用途を明示)
  • 認証局のポリシー情報(信頼チェーンを明確化)

特にSAN(Subject Alternative Name)の追加により、1つの証明書で複数のドメインやサブドメインをカバーできるようになり、ウェブサイト運営者にとって利便性が向上しました。

SANとは?NASとの違いや導入のポイントをわかりやすく解説SANとは? 企業のストレージ管理を効率化する技術ですが、NASやDASとの違いや導入のメリット・デメリット、最新技術について理解していますか?本記事では、SANの基本概念から最新トレンド、クラウドとの連携、最適な選び方までを徹底解説!SANの導入を検討している方や最適なストレージ戦略を知りたい方向けにまとめています。...

2-2-4. X.509バージョンごとの比較表

バージョン特徴主な用途
v1基本的な証明書構造初期のSSL/TLS
v2一意識別子を追加限定的な認証用途
v3拡張フィールドを追加、柔軟性向上現在のTLS/SSL、VPN、電子署名

X.509の用途と活用事例

X.509とは、公開鍵基盤(PKI)を支える重要な要素であり、インターネット上で安全な通信やデータの真正性を保証するために広く活用されています。

特に、ウェブサイトのTLS/SSL証明書や電子メールの暗号化、ソフトウェアのコード署名などに利用されており、オンラインセキュリティの根幹を成しています。

ここでは、X.509が具体的にどのように使われているのかを詳しく解説します。

3-1. TLS/SSLにおけるX.509の役割

3-1-1. TLS/SSLとX.509の関係

TLS(Transport Layer Security)/SSL(Secure Sockets Layer)は、インターネット上でデータを暗号化し、安全に通信するためのプロトコルです。

X.509証明書は、このTLS/SSL通信の中で重要な役割を果たしています。

TLS/SSLでは、ウェブサイトが本物であることを証明し、通信を暗号化するためにX.509証明書が使用されます。

これにより、ユーザーが訪問するウェブサイトが偽装されたものではないことを確認し、安全に情報を送受信できるようになります。

例えば、HTTPS(Hypertext Transfer Protocol Secure)を使用するウェブサイトでは、X.509証明書を用いたSSL/TLSが導入されており、以下のような情報を提供しています。

  • ウェブサイトの所有者情報
  • 証明書の発行元(認証局)
  • 公開鍵を用いた暗号化通信の設定
  • 証明書の有効期限と署名

この仕組みにより、インターネット上の安全なデータ通信が可能になっています。

3-1-2. TLS/SSL証明書の種類

X.509を使用したTLS/SSL証明書には、いくつかの種類があります。

以下の表は、一般的なTLS/SSL証明書の種類と特徴をまとめたものです。

証明書の種類特徴主な用途
DV証明書(ドメイン認証証明書)ドメインの所有権のみを確認個人サイト、ブログ
OV証明書(企業認証証明書)企業の実在性を確認企業ウェブサイト
EV証明書(拡張認証証明書)企業の詳細な審査を実施銀行、ECサイト
ワイルドカード証明書サブドメインを一括で保護大規模なウェブサイト
マルチドメイン証明書複数の異なるドメインを保護企業の複数サイト運営

TLS/SSL証明書は、インターネットの安全性を高めるために不可欠な存在であり、特にECサイトや金融機関ではEV証明書が広く採用されています。

3-1-3. X.509証明書の検証プロセス

TLS/SSL通信では、クライアント(ブラウザなど)がウェブサイトのX.509証明書を検証するプロセスが含まれます。

この検証プロセスは、以下のようなステップで行われます。

  1. ウェブサイトがX.509証明書を提示
  2. ブラウザが証明書の有効性を確認
  3. 認証局(CA)の署名をチェック
  4. 証明書の有効期限や失効情報を確認
  5. 証明書チェーン(ルート証明書までの信頼関係)を検証
  6. 通信の暗号化が確立され、安全な接続が確保される

このプロセスにより、フィッシングサイトやなりすましを防ぎ、安全なオンライン取引が可能になります。

3-2. S/MIMEやコード署名での利用

3-2-1. S/MIMEとX.509

S/MIME(Secure/Multipurpose Internet Mail Extensions)は、電子メールのセキュリティを強化するための規格であり、X.509証明書を使用した電子署名と暗号化によってメールの改ざんや盗聴を防ぎます。

S/MIMEにおけるX.509証明書の役割は次のとおりです。

  • 電子メールの改ざん防止(署名機能)
  • 盗聴防止(暗号化機能)
  • 送信者の身元確認(認証機能)

例えば、企業間で機密情報をやり取りする場合、S/MIMEを利用することでメールの内容が第三者に漏れるのを防ぎ、正しい送信者からのメールであることを確認できます。

3-2-2. コード署名とX.509

コード署名は、ソフトウェアやアプリケーションが改ざんされていないことを保証するための技術であり、X.509証明書が使用されます。

特に、次のようなケースでコード署名証明書が利用されます。

  • WindowsやmacOS向けのアプリケーション
  • ブラウザ用プラグインや拡張機能
  • モバイルアプリ(iOS/Android)
  • ファームウェアのアップデート

3-2-3. コード署名証明書の仕組み

コード署名証明書を使用すると、ソフトウェアの開発者はプログラムにデジタル署名を付与できます。

これにより、以下のような利点があります。

  • ユーザーが安全なソフトウェアであることを確認できる
  • ソフトウェアの改ざんを防止できる
  • OSやブラウザでの警告を回避できる

例えば、Windowsでは署名のないソフトウェアを実行しようとすると、「不明な発行元」と表示されることがあります。

しかし、X.509証明書を用いたコード署名が行われていれば、信頼された発行元として認識され、警告が表示されるリスクが低減されます。

X.509証明書の取得と管理

X.509とは、インターネットの安全な通信を支える重要な技術であり、その証明書は正しく取得・管理される必要があります。

X.509証明書の運用においては、適切な発行プロセス証明書の失効管理が不可欠です。

本章では、証明書の取得方法と管理手順について詳しく解説します。

4-1. 証明書の発行プロセス

4-1-1. X.509証明書の発行の流れ

X.509証明書は、認証局(CA: Certificate Authority)によって発行されます。

証明書を取得する一般的なプロセスは以下の通りです。

  1. 秘密鍵と公開鍵の生成
    まず、申請者(ウェブサイト運営者や企業)は、秘密鍵と公開鍵のペアを作成します。
    • 秘密鍵(Private Key):証明書の所有者のみが保持
    • 公開鍵(Public Key):証明書に含まれ、第三者が利用
  2. 証明書署名要求(CSR)の作成
    公開鍵と組織情報(ドメイン名、会社名など)を含む証明書署名要求(CSR: Certificate Signing Request)を作成します。
  3. 認証局(CA)へ申請
    CSRを認証局に提出し、証明書の発行を申請します。
  4. 認証局による審査と検証
    認証局は、申請者の身元を確認します。証明書の種類によって、確認方法が異なります。証明書の種類認証レベル主な審査内容DV証明書(ドメイン認証)低ドメイン所有権の確認OV証明書(企業認証)中企業の実在性確認EV証明書(拡張認証)高企業の詳細な実在証明
  5. X.509証明書の発行
    認証が完了すると、X.509証明書が発行され、申請者に提供されます。
  6. 証明書のインストール
    取得したX.509証明書をサーバーに設定し、TLS/SSLの暗号化通信を有効化します。

このように、X.509証明書の発行には、鍵の作成から認証局の審査まで、いくつかの重要な手順が必要です。

4-1-2. X.509証明書の発行にかかる時間

証明書の種類によって、発行にかかる時間が異なります。

証明書の種類発行までの期間
DV証明書(ドメイン認証)数分〜数時間
OV証明書(企業認証)1〜3日
EV証明書(拡張認証)1週間〜2週間

一般的なウェブサイトでは、DV証明書が多く使用されており、申請から数分で発行されることが特徴です。

一方、EV証明書は、厳格な審査があるため発行までに時間がかかります。

4-2. 証明書失効リスト(CRL)とその管理

X.509証明書は一度発行されると有効期間が設定されますが、状況によっては証明書を失効させる必要があります。

例えば、秘密鍵が漏洩した場合や、ドメインの所有者が変更された場合です。

4-2-1. 証明書の失効とその理由

X.509証明書の失効が必要となる主なケースは以下のとおりです。

  • 秘密鍵の漏洩(不正利用のリスクがある)
  • ドメイン名や組織情報の変更
  • 証明書の誤発行
  • 企業の閉鎖やサービス終了
  • セキュリティ侵害(攻撃者による証明書の悪用)

このような事態に備えて、X.509証明書には失効管理の仕組みが組み込まれています。

4-2-2. 証明書失効リスト(CRL)とは

証明書失効リスト(CRL: Certificate Revocation List)は、失効したX.509証明書のリストを管理するための仕組みです。

CRLは定期的に更新され、クライアント(ブラウザなど)が参照することで、無効な証明書を識別できます。

CRLの主な特徴:

  • 認証局(CA)が発行する
  • 失効した証明書のシリアル番号が記録される
  • 定期的に更新される(1日〜数週間ごと)
  • クライアントは証明書を検証する際にCRLを参照する

4-2-3. OCSPによるリアルタイム失効確認

CRLは便利な仕組みですが、リストの更新頻度が限られているため、最新の失効情報をリアルタイムで確認するには、OCSP(Online Certificate Status Protocol)が利用されます。

方式特徴メリット
CRL失効証明書のリストを定期更新オフライン環境でも利用可能
OCSP失効情報をリアルタイムで問い合わせ最新の失効情報を取得可能

OCSPを利用することで、証明書の失効状態を即時に確認でき、より高いセキュリティが確保されます。

4-2-4. 証明書の適切な更新と管理

証明書の管理を適切に行うことで、システムの安全性を維持できます。

以下のポイントに注意することで、X.509証明書の運用をスムーズに進めることができます。

  • 証明書の有効期限を把握し、更新を忘れない
  • 秘密鍵の管理を厳重に行う
  • 失効が必要な場合は速やかにCRLやOCSPを利用する
  • 証明書の発行履歴を記録し、不正な発行を防ぐ

特に、証明書の有効期限切れはセキュリティリスクとなるため、期限前に適切な更新を行うことが重要です。

X.509に関連する技術とプロトコル

X.509とは、インターネット上で安全な通信や認証を実現するためのデジタル証明書の標準規格です。

しかし、X.509証明書が適切に機能するためには、さまざまな関連技術やプロトコルが支えています。

特に公開鍵基盤(PKI)はX.509の認証プロセスを実現するための重要な仕組みであり、また、オンライン証明書状態確認プロトコル(OCSP)は証明書の有効性をリアルタイムで確認するための手法として利用されています。

本章では、X.509証明書と密接に関連するPKIとOCSPについて詳しく解説します。

5-1. 公開鍵基盤(PKI)との関係

5-1-1. PKIとは何か

PKI(Public Key Infrastructure:公開鍵基盤)とは、X.509証明書を利用して安全な通信や認証を実現するための仕組みです。

PKIは、X.509証明書の発行・管理・検証を行い、インターネット上での安全なデータ交換を支えています。

PKIの主な役割は以下のとおりです。

  • 認証:ユーザーやサーバーが本物であることを証明
  • 暗号化:公開鍵を用いて安全な通信を実現
  • データの完全性保証:電子署名を利用して改ざんを防止
  • 証明書の管理:X.509証明書の発行、失効、更新を行う

PKIの仕組みを理解することで、X.509証明書がどのように安全な通信を実現しているのかが明確になります。

5-1-2. PKIの主要な構成要素

PKIは、以下の主要な要素から成り立っています。

要素役割
認証局(CA: Certificate Authority)X.509証明書を発行・管理する機関
登録機関(RA: Registration Authority)証明書発行の申請者情報を審査する機関
証明書リポジトリ証明書の公開情報を保存し、利用者が検証できるようにする
証明書失効リスト(CRL: Certificate Revocation List)無効になった証明書の一覧
オンライン証明書状態確認プロトコル(OCSP)証明書の有効性をリアルタイムで確認

PKIは、これらの要素が相互に連携することで、信頼できる認証システムを提供しています。

5-1-3. PKIとX.509の関係

X.509とは、PKIの中核をなす技術であり、PKIの認証プロセスを支えるデジタル証明書の標準フォーマットです。

PKIでは、認証局(CA)がX.509証明書を発行し、ユーザーやサーバーの真正性を保証します。

具体的な流れは以下の通りです。

  1. ユーザーが認証局(CA)に証明書を申請
  2. 登録機関(RA)が申請者の身元を確認
  3. CAがX.509証明書を発行
  4. ユーザーが証明書を使用して通信の暗号化や認証を実施
  5. 必要に応じてCRLやOCSPを利用し、証明書の有効性を確認

PKIは、X.509証明書の信頼性を維持するための重要な基盤であり、安全なデジタル社会を実現するために不可欠な技術です。

5-2. オンライン証明書状態確認プロトコル(OCSP)

5-2-1. OCSPとは

OCSP(Online Certificate Status Protocol)とは、X.509証明書の有効性をリアルタイムで確認するためのプロトコルです。

従来、証明書の失効を確認する方法として証明書失効リスト(CRL)が用いられてきましたが、CRLにはいくつかの課題がありました。

OCSPは、こうした問題を解決するために設計されており、証明書の有効性を即時に確認できるというメリットがあります。

5-2-2. CRLとOCSPの比較

CRLとOCSPの違いを以下の表にまとめました。

項目CRL(証明書失効リスト)OCSP(オンライン証明書状態確認)
確認方法一括ダウンロードリアルタイムで問い合わせ
更新頻度定期更新(1日〜数週間)即時
レスポンス速度遅い(大きなリストを処理)速い(単一証明書の照会)
帯域負荷高い(大容量データを取得)低い(必要な情報のみ取得)

従って、OCSPを利用することで、最新の証明書状態を効率的に取得できるため、セキュリティと利便性の向上が期待できます。

5-2-3. OCSPの動作プロセス

OCSPの仕組みは以下の手順で動作します。

  1. クライアント(ブラウザなど)がOCSPリクエストを送信
    → X.509証明書の状態を確認するため、OCSPサーバーに問い合わせを行う。
  2. OCSPサーバー(OCSPレスポンダー)が証明書の状態を確認
    → 証明書が有効か失効しているかをチェックする。
  3. OCSPレスポンダーが結果をクライアントに返す
    • “good”(有効):証明書は問題なく利用可能
    • “revoked”(失効済み):証明書が無効(盗難・不正使用など)
    • “unknown”(不明):証明書がデータベースに存在しない

このように、OCSPはCRLよりも迅速かつ効率的に証明書の状態を確認できるため、現在のPKI環境では広く採用されています。

5-2-4. OCSPステープリングとは

OCSPを利用する際、リクエストごとにOCSPサーバーにアクセスすると、通信の遅延が発生する可能性があります。

これを解決するために導入されたのがOCSPステープリングです。

OCSPステープリングの特徴:

  • サーバー側がOCSPの応答をキャッシュしておく
  • クライアントは直接OCSPレスポンダーに問い合わせる必要がない
  • 通信の負荷を軽減し、応答速度を向上させる

特に、大規模なウェブサービスではOCSPステープリングの導入が推奨されており、HTTPSのパフォーマンス向上に貢献しています。

X.509の今後の展望と課題

X.509とは、インターネット上のセキュリティを支える重要な技術であり、ウェブサイトの暗号化(TLS/SSL)、電子メールの暗号化(S/MIME)、コード署名、デバイス認証など、さまざまな分野で活用されています。

しかし、技術の進化とともに、X.509証明書の運用における課題も浮き彫りになっています。

本章では、X.509の今後の展望と、直面するセキュリティ上の課題とその対策について詳しく解説します。

6-1. セキュリティ上の課題と対策

X.509証明書は、安全な認証と暗号化通信を提供する一方で、いくつかのセキュリティ上のリスクを抱えています。

特に、証明書の管理ミス、脆弱な暗号アルゴリズム、認証局(CA)の信頼性の問題が指摘されており、適切な対策が求められています。

6-1-1. 証明書の有効期限管理と自動更新の必要性

X.509証明書には有効期限が設定されており、期限が切れるとウェブサイトやサービスが正常に動作しなくなる可能性があります。

特に、証明書の期限切れが原因で発生するサービス停止は、大きな影響を及ぼします。

課題

  • 証明書の更新を忘れると、ブラウザで警告が表示され、ユーザーの信頼を損なう
  • 手動更新は運用負荷が高く、大規模環境では管理が困難

対策

  • 証明書の有効期限を可視化し、事前に通知を受け取る(証明書管理ツールの導入)
  • ACMEプロトコルを活用し、自動更新を設定する(Let’s Encryptなどの無料CAが対応)

6-1-2. 量子コンピュータ時代の暗号リスク

現在のX.509証明書は、RSAやECC(楕円曲線暗号)などの公開鍵暗号を使用しています。

しかし、量子コンピュータの技術が発展すると、従来の暗号方式が解読されるリスクが高まります。

課題

  • RSAやECCは量子コンピュータによって解読可能になる可能性がある
  • 量子耐性のある新しい暗号アルゴリズムの導入が必要

対策

  • ポスト量子暗号(PQC:Post-Quantum Cryptography)の導入(NISTが標準化を進行中)
  • ハイブリッド証明書の採用(従来の暗号方式と量子耐性アルゴリズムを併用)

6-1-3. 認証局(CA)の信頼性とセキュリティリスク

X.509証明書は、認証局(CA)が発行しますが、CA自体が攻撃を受けると、悪意のある証明書が発行される可能性があります。

実際に、過去にはCAがハッキングされ、不正な証明書が発行される事件が発生しました。

課題

  • CAのセキュリティが破られると、フィッシングサイトやなりすまし攻撃が容易になる
  • 特定のCAに依存する仕組みでは、中央集権的なリスクが存在

対策

  • 証明書の透明性(Certificate Transparency:CT)ログを活用(Googleなどが推奨)
  • 分散型認証基盤(DID:Decentralized Identity)やブロックチェーン技術の活用

6-1-4. 証明書失効の迅速な対応

X.509証明書が盗まれたり、不正に利用された場合、速やかに失効処理を行うことが重要です。

しかし、従来の証明書失効リスト(CRL)には課題があり、リアルタイムでの証明書状態確認が求められます。

課題

  • CRLはリストの更新頻度が低く、リアルタイム性に欠ける
  • OCSP(Online Certificate Status Protocol)は高速だが、OCSPレスポンダーがダウンすると確認不能になる

対策

  • OCSPステープリングの導入(サーバーがOCSP情報をキャッシュし、証明書の確認負荷を軽減)
  • 短期間の証明書発行を標準化(Let’s Encryptなどが採用している90日証明書)