デジタル署名の検証エラー？ 🤔 原因と解決策を徹底解説！

デジタル証明書には有効期間が定められています。検証しようとしている証明書の有効期間が過ぎている場合、その証明書は無効とみなされ、検証エラーとなります。これは最も一般的なエラー原因の一つです。

• エラーメッセージに「有効期限切れ」「expired」などの文言が含まれていないか確認します。
• 証明書の詳細情報を表示し、「有効期間の開始日 (Not Before)」と「有効期間の終了日 (Not After)」を確認します。検証日時がこの期間内に収まっているかを確認します。

• 署名を受け取った側の場合: 署名者に連絡し、有効な証明書で再署名してもらうよう依頼します。
• 署名を作成する側の場合: 証明書の有効期限を確認し、期限が切れている場合は新しい証明書を取得して署名し直します。多くの認証局では、有効期限が近づくと更新通知が送られてきますので、見逃さないようにしましょう。
• 注意: 過去の特定の時点での有効性を確認したい場合（例：契約締結日時点での有効性）、タイムスタンプが付与されているかどうかが重要になります。タイムスタンプについては後述します。

証明書は、有効期限内であっても、秘密鍵の漏洩、所有者情報の変更、不正利用などの理由で認証局によって失効されることがあります。失効された証明書は無効です。

証明書の失効状態を確認する方法として、主に以下の2つがあります。

• CRL (Certificate Revocation List / 証明書失効リスト): 認証局が定期的に発行する、失効した証明書のシリアル番号リストです。検証ソフトウェアはこれをダウンロードして確認します。
• OCSP (Online Certificate Status Protocol): 証明書のシリアル番号を指定して、認証局のOCSPレスポンダ（サーバー）にリアルタイムで失効状態を問い合わせるプロトコルです。CRLよりも新しい情報を得やすいですが、問い合わせ先のサーバーがダウンしていると確認できない場合があります。

検証ソフトウェアがCRLやOCSPにアクセスできない、あるいは取得した情報で証明書が失効していると判断された場合にエラーとなります。

• エラーメッセージに「失効」「revoked」「CRL」「OCSP」などの文言が含まれていないか確認します。
• 証明書の詳細情報に、CRL配布点 (CRL Distribution Point) やOCSPサーバー (Authority Information Access – OCSP) のURLが記載されているか確認します。
• ネットワーク接続が正常で、これらのURLにアクセスできるか確認します（ファイアウォールなどでブロックされていないか？）。
• 手動でCRLをダウンロードしたり、OCSPリクエストを送信したりして確認することも可能です（後述のツール例を参照）。

• ネットワーク接続を確認・修正します。ファイアウォールやプロキシの設定を見直してください。
• 一時的なCRL/OCSPサーバーの問題である可能性もあるため、時間をおいて再度試します。
• CRLの有効期限が切れている場合、最新のCRLを取得するように検証ソフトウェアを設定するか、手動で更新します。
• 証明書が実際に失効している場合は、有効期限切れの場合と同様に、署名者に有効な証明書での再署名を依頼するか、自身が署名者の場合は新しい証明書を取得します。

デジタル証明書は、通常、階層構造（信頼の連鎖、証明書チェーン）になっています。個別の証明書（エンドユーザー証明書）は中間認証局によって発行され、その中間認証局の証明書はさらに上位の認証局によって発行され、最終的には「ルート認証局 (Root CA)」にたどり着きます。ルート認証局は自己署名証明書（自分自身で発行した証明書）を持ちます。

検証を行うコンピュータ（OSやブラウザ、特定のアプリケーション）は、「信頼されたルート証明書ストア」を持っており、ここに登録されているルート認証局の証明書を起点として信頼の連鎖を辿ります。検証しようとしている証明書の連鎖を辿っていった結果、信頼されたルート証明書ストアに含まれるルート証明書に行き着かない場合、「信頼されていない発行元」としてエラーになります。

よくあるケースとしては、

• 比較的新しい認証局で、OSやソフトウェアの信頼リストにまだ含まれていない。
• 企業内などで独自に構築されたプライベート認証局によって発行された証明書。
• いわゆる「オレオレ証明書」（自己署名証明書）で、正当な認証局から発行されていないもの。

• エラーメッセージに「信頼されていない」「untrusted」「発行元」「issuer」「ルート」「root」などの文言が含まれていないか確認します。
• 証明書の詳細情報を表示し、「証明のパス (Certification Path)」を確認します。最上位の証明書（ルート証明書）が、お使いのシステムの信頼リストに含まれているか確認します。
• 中間証明書が不足している場合もあります。本来であれば、署名時にエンドユーザー証明書と中間証明書をセットで含めるべきですが、含まれていない場合に検証エラーとなることがあります。

• 信頼できる発行元の場合:
  • OSやブラウザ、検証に使用しているソフトウェアを最新版にアップデートします。信頼されたルート証明書リストが更新されることがあります。
  • 必要に応じて、信頼すべきルート証明書や中間証明書を手動でシステムの信頼ストアにインポートします。ただし、信頼できる発行元から入手した証明書のみをインポートしてください。 不明な証明書のインポートはセキュリティリスクとなります。
  • 企業内のプライベート認証局の場合は、システム管理者に問い合わせて、必要なルート証明書や中間証明書を入手・インストールします。
• 信頼できない発行元（オレオレ証明書など）の場合:
  • その署名が本当に信頼できるものなのか、別の手段で確認する必要があります。安易に信頼しないでください。
  • 開発・テスト目的など、自己署名証明書であることを理解した上で使用している場合は、検証ソフトウェアの設定で一時的にエラーを無視するか、その証明書を例外的に信頼する設定を行うこともありますが、セキュリティリスクを伴うため慎重に行ってください。
• 中間証明書が不足している場合: 署名者に連絡し、中間証明書を含めて再署名してもらうか、別途中間証明書を入手して検証環境にインストールします。

デジタル署名の重要な役割の一つは、データが署名された後に変更されていないこと（完全性）を保証することです。検証プロセスでは、受信したデータからハッシュ値を再計算し、署名に含まれる（復号された）ハッシュ値と比較します。もしデータが署名後にわずかでも変更されていれば、再計算されたハッシュ値は元のハッシュ値と一致せず、検証エラーとなります。

改ざんは悪意のあるものだけでなく、ファイル転送中のエラー、文字コードの変換、意図しない編集などによっても発生する可能性があります。

• エラーメッセージに「改ざん」「tampered」「modified」「integrity」「ハッシュ不一致」「hash mismatch」などの文言が含まれていないか確認します。
• 可能であれば、署名された時点の元データ（原本）を入手し、現在手元にあるデータと比較します。差分がないか確認します。

• 署名者や信頼できる配布元から、データを再度ダウンロードまたは取得し直します。
• データの転送方法や保管方法を見直し、意図しない変更が発生しないように注意します（例：バイナリモードでの転送、編集ロックなど）。
• もし意図的にデータを変更した後に検証しようとしている場合は、変更前のオリジナルデータに対して検証を行う必要があります。

デジタル署名やハッシュ計算には、様々なアルゴリズム（例: RSA, ECDSA, SHA-1, SHA-256）が使用されます。検証側のソフトウェアが、署名に使われたアルゴリズムに対応していない場合、検証は失敗します。

また、古いアルゴリズム（特にSHA-1や短い鍵長のRSAなど）は、現在では脆弱（ぜいじゃく）であるとみなされており、セキュリティ上の理由から多くのソフトウェアで意図的にサポートが打ち切られたり、警告が表示されたりするようになっています。たとえ計算上は検証できても、「安全でない」という警告やエラーが表示されることがあります。

• エラーメッセージに「アルゴリズム」「algorithm」「unsupported」「weak」「脆弱」などの文言が含まれていないか確認します。
• 証明書や署名の詳細情報を確認し、使用されている署名アルゴリズム（例: `sha256WithRSAEncryption`）やハッシュアルゴリズム（例: `SHA-256`）、公開鍵アルゴリズム（例: `RSA (2048 bit)`）を確認します。
• 検証に使用しているソフトウェアのマニュアルやリリースノートを確認し、サポートされているアルゴリズムや、非推奨・拒否されるアルゴリズムの情報を調べます。

• 検証に使用しているソフトウェアを最新版にアップデートします。新しいアルゴリズムへの対応や、脆弱なアルゴリズムに対する警告強化が含まれている場合があります。
• 署名に使われているアルゴリズムが古く脆弱な場合、署名者に連絡し、より強力で推奨されるアルゴリズム（例: SHA-256以上、RSA 2048bit以上、ECDSAなど）を使用して再署名してもらうよう依頼します。
• 自身が署名を作成する側の場合、使用するツールやライブラリの設定を確認し、安全な最新のアルゴリズムを使用するようにします。SHA-1の使用は避け、SHA-256以上を選択しましょう。
• 一時的な回避策として、検証ソフトウェアの設定で古いアルゴリズムを許可することも可能な場合がありますが、セキュリティリスクを理解した上で、限定的な状況でのみ使用すべきです。

証明書の有効期限の検証は、通常、検証を行うコンピュータの現在時刻に基づいて行われます。もしコンピュータの時計が大幅にずれていると、まだ有効な証明書が期限切れと判断されたり、逆に期限切れの証明書が有効と誤判断されたりする可能性があります。

また、署名が「いつ」行われたかを証明するためには、「タイムスタンプ (Timestamp)」が重要になります。これは、信頼できる第三者機関である時刻認証局 (TSA: Time-Stamping Authority) によって、特定の時刻にそのデータが存在していたこと（および署名が行われたこと）を証明するものです。タイムスタンプが付与されていれば、署名に使用された証明書の有効期間は、署名が行われた（タイムスタンプが取得された）時点で評価されます。これにより、証明書が後に失効したり有効期限が切れたりしても、署名時点での有効性を証明できます。

タイムスタンプ自体にも有効期限や失効の問題があり、タイムスタンプの検証でエラーが発生することもあります。

• 検証を行うコンピュータの時計が正確であるか確認します。NTPサーバーと同期させるのが一般的です。
• エラーメッセージに「時刻」「time」「timestamp」「TSA」などの文言が含まれていないか確認します。
• 署名にタイムスタンプが付与されているか確認します。付与されている場合、タイムスタンプ証明書の有効性（有効期限、発行元、失効状態）も確認します。

• コンピュータの時計を正確な時刻に合わせます。
• タイムスタンプの検証でエラーが出ている場合、タイムスタンプ証明書の発行元が信頼されているか、有効期限・失効状態に問題がないかを確認します（証明書の検証と同様）。
• 署名を作成する側の場合、長期的な有効性が求められる署名（電子契約など）には、信頼できるTSAからのタイムスタンプを付与することを強く推奨します。

これまでの原因に当てはまらない場合、検証に使用しているソフトウェア（メールクライアント、PDFビューア、ブラウザ、専用の検証ツールなど）自体のバグや設定ミス、あるいはOS環境との相性問題などが原因である可能性も考えられます。

例えば、

• ソフトウェアの特定バージョンに存在するバグ。
• 必要なライブラリやコンポーネントが不足している、または古い。
• セキュリティポリシーの設定（例: 特定のアルゴリズムを禁止している）。
• 他のセキュリティソフトとの干渉。

• 別のコンピュータや、別の検証ソフトウェア（可能であれば）で同じ署名を検証してみます。それで問題なく検証できれば、元の環境に問題がある可能性が高いです。
• 使用しているソフトウェアのバージョンを確認し、最新版にアップデートしてみます。
• ソフトウェアの設定を確認し、デジタル署名検証に関する項目を見直します。
• OSのイベントログや、ソフトウェアのデバッグログなどを確認し、エラーに関する詳細情報がないか探します。
• 一時的にセキュリティソフトを無効にして試してみます（ただし、セキュリティリスクが伴うため注意が必要です）。

• ソフトウェアを最新版にアップデートします。
• ソフトウェアの再インストールを試します。
• 設定を見直します。不明な場合は、デフォルト設定に戻してみるのも一つの手です。
• ソフトウェア開発元のサポート情報やフォーラムなどを確認し、同様の問題が報告されていないか、解決策がないか探します。
• OSのアップデートや、必要なランタイムライブラリ等の更新も試みます。
• 問題が解決しない場合は、別の検証ツールを利用することを検討します。