SSL alert number 46とは何か?原因と対処法を詳しく解説

目次

はじめに

本記事の目的

本記事は、SSL/TLS通信で表示される「アラート番号46(certificate_unknown)」について、分かりやすく解説することを目的としています。証明書が受け入れられない場面でどんな問題が起きるか、原因や対応策を順を追って説明します。

対象読者

サーバーやネットワークの運用担当者、システム管理者、またはSSL関連のエラーを初めて扱う技術者を想定しています。専門知識が浅くても読み進められるように、具体例や手順を交えて丁寧に説明します。

この記事で学べること

  • アラート番号46が意味することの概略
  • よくある原因とその見つけ方
  • Windows環境での発生例とイベントログの読み方
  • 実際の対処法と注意点
  • 類似エラーとの違い

読み方のヒント

まずは「何が起きているか」を把握するために発生タイミングやログを確認してください。次に、本記事の原因一覧と照らし合わせて優先順位をつけ、具体的な対処法を試してください。この記事を読むことで、問題の切り分けと初期対応がスムーズに行えるようになるはずです。

SSLアラート番号46とは何か

概要

SSL/TLS通信で問題が起きると「アラート」が交わされ、通信を止めます。番号46は「certificate_unknown」と呼ばれ、受け取った証明書を正しく扱えず受け入れられなかったときに送られます。多くの場合、ハンドシェイク(接続開始のやり取り)の途中で発生します。

どういう意味か

送信者は「この証明書は検証できません」と通知して通信を終わらせます。受信側が証明書を確認して致命的な問題と判断した場合に使います。つまり接続はそこで断たれます。

いつ誰が出すか(簡単な流れ)

  1. クライアントが接続を要求(ClientHello)
  2. サーバが証明書を提示(Certificate)
  3. 受け取った側が証明書を検証し、問題があればアラート46を送って切断します

覚えておくポイント

  • 致命的なエラーなので通信は続きません
  • 原因は複数あり、証明書の形式や発行元、チェーンなどに起因します

次章で具体的な原因を分かりやすく解説します。

certificate_unknown(アラート46)の具体的な原因

この章では、SSLアラート46(certificate_unknown)が発生する代表的な原因を、具体例を交えて分かりやすく説明します。原因は一つとは限らず、サーバー側とクライアント側の両方を確認する必要があります。

1) 証明書の不適切なインストール

サーバーが提示する証明書ファイル自体が誤っていたり、設定ミスで参照先が間違っている場合です。例:証明書ファイルを更新したが設定を再読み込みしていない。確認方法:サーバーの設定ファイルと実際に送られる証明書を比較します。

2) 証明書チェーンの不完全さ(中間/ルート不足)

中間証明書やルート証明書が不足すると、クライアントが信頼ルートまで辿れず拒否します。例:Let’s Encryptのチェーンを完全に提供していないケース。確認方法:openssl s_clientでチェーンを確認、ブラウザの証明書表示で中間証明書の有無を確認します。

3) 証明書の破損や内容不正

ファイルが壊れている、改ざんされている、あるいはフォーマットが不正な場合です。例:改行やエンコーディングが壊れているPEMファイル。確認方法:openssl x509で読み込めるか試す。

4) 検証処理のバグや互換性問題

クライアントやサーバー側のライブラリにバグがある、あるいは古い実装で新しい証明書仕様に対応していない場合です。例:古いTLSライブラリが新しい拡張を解釈できない。確認方法:ライブラリのバージョン確認とアップデート、関連の既知不具合を調査します。

5) 未対応の証明書種別や鍵アルゴリズム

利用している鍵アルゴリズムや証明書形式が相手側でサポートされていない場合です。例:ECDSA鍵に未対応の古いクライアント。確認方法:使用中の鍵タイプとクライアントの対応状況を照合します。

6) システム時刻のずれ

端末の時刻が正しくないと、有効期間外と判定されます。例:仮想マシンで時刻同期が外れている。確認方法:サーバー・クライアント双方の時刻を確認します。

ログ解析が最も重要です。サーバーのTLSログ、クライアントのエラー表示、ネットワークキャプチャを組み合わせて原因を特定してください。

Windows環境でのよくある発生例とイベントログ

概要

Windows ServerではSchannelというコンポーネントがTLS/SSLを管理します。証明書の問題が起きると、システムのイベントログに記録されます。代表的な記録はイベントID 36887で、英語のメッセージは「A critical warning was received from the remote endpoint. The TLS protocol defines a critical warning code of 46.」です。これはcertificate_unknownに相当する警告です。

発生しやすい場面(具体例)

  • IISでサイトに証明書をバインドしたがプライベートキーがない/権限が不適切な場合
  • リモートデスクトップ(RDP)で自己署名証明書やチェーン不備の証明書を使った場合
  • SMTPやSQL Serverなどのサービスで中間証明書がインストールされていない場合
    どの場面でも、クライアント側が証明書を信頼できないと同様の警告が出ます。

イベントログの確認方法

  • イベントビューアを開く → Windowsログ → システム
  • ソースで「Schannel」をフィルタリングすると該当イベントが見つかります。

よくあるログ例と読み方

  • イベントID: 36887
  • レベル: エラー
  • メッセージ例: “A critical warning was received from the remote endpoint. The TLS protocol defines a critical warning code of 46.”
    この場合は証明書チェーンや信頼関係に問題があることが多いです。

簡単な確認手順

  1. サーバの証明書ストアで証明書が有効期限内か確認する(certlm.msc)。
  2. 中間証明書が正しくインストールされているか確認する。ブラウザでサイトを開いてチェーンを確認する方法が手早いです。
  3. サイトのバインドにプライベートキーが紐付いているか確認する。権限問題はよくあります。
  4. クライアント側の信頼ストアにルートが入っているか確認する。

これらの手順で原因を絞り込めます。具体的な対処は原因によって異なりますが、まずはイベントログと証明書チェーンの確認をおすすめします。

対処法・解決策

以下は、SSLアラート46(certificate_unknown)を受けたときに順を追って行う対処法です。分かりやすく具体例を交えて説明します。

1) まずの確認(簡単なチェック)

  • ブラウザやクライアントで接続できないか確認します。エラーメッセージを保存してください。
  • サーバーの証明書の有効期限を確認します。期限切れなら再発行が必要です。

2) 証明書チェーンの確認

  • 中間証明書が抜けているとエラーになります。サーバーに中間証明書を含めて正しくインストールしてください。例:ウェブサーバー設定でchainファイルを指定します。

3) 時刻の同期

  • サーバーとクライアント両方の時刻がずれていると検証に失敗します。ntpやOSの時刻同期を確認・修正してください。

4) 発行元の確認

  • 証明書が正規の認証局(CA)で発行されているか確認します。自己署名証明書なら信頼設定が必要です。

5) SSL/TLS設定と暗号スイート

  • サーバーが使うプロトコルや暗号が古すぎると互換性で弾かれます。設定を見直し、一般的なブラウザやクライアントが使える暗号を有効にしてください。

6) 再発行・再インストール

  • 証明書に問題があればCAに再発行を依頼し、サーバーへ正しくインストールします。鍵ファイルやパーミッションも確認します。

7) ログとパケットキャプチャで原因特定

  • 詳細な原因はログやハンドシェイクのパケットを確認します。OpenSSLのs_clientやWiresharkでTLSハンドシェイクを取得すると原因特定に役立ちます。

8) 最後に

  • 必要に応じてOSやサーバーソフトの更新、サポート窓口への問い合わせを行ってください。変更はバックアップを取ってから実施すると安全です。

その他の類似エラーとの違い

概要

SSL/TLSの証明書関連アラートには複数の番号があり、原因が比較的明確なものと曖昧なものがあります。番号46(certificate_unknown)は、特定の理由に当てはまらない場合に返される、より広い意味のエラーです。

主な類似アラートとの違い

  • 42: bad_certificate
  • 証明書の形式や署名が明らかに不正な場合に出ます。例えば、破損したファイルや非対応のフォーマット。
  • 43: unsupported_certificate
  • アルゴリズムや拡張がサーバ/クライアントで対応していない場合に出ます。古い暗号や未知の拡張が原因です。
  • 44: certificate_revoked
  • 証明書が発行元により取り消された(失効)場合に出ます。失効リスト(CRL)やOCSPで確認できます。
  • 45: certificate_expired
  • 有効期限切れの証明書に対して返されます。日付を確認すれば明白です。

46: certificate_unknown の特徴

46は上記のどれにも当てはまらないときに使われます。例としては:
– 中間証明書が欠けていて信頼チェーンが完成しない
– サーバ名(CN/SAN)と接続先が一致しないが明確なマッチングエラーとして分類されない
– 証明書のエンコーディングや拡張の組合せが想定外で判定できない
– 証明書発行元が未知で、明確な「失効」「期限切れ」ではない

見分け方と対応のヒント

  • ログやブラウザの詳細エラーをまず確認します。具体的な理由が書かれていれば42〜45のいずれかに当てはまることが多いです。
  • openssl s_clientやブラウザの証明書チェーン表示で中間証明書の有無やCN/SANを確認します。
  • 46が出た場合は、信頼チェーンの補完や発行元の確認、証明書の再生成を検討します。これらで多くは解決します。

まとめ・ポイント

SSLアラート番号46(certificate_unknown)は、証明書に関する「特定できない問題」で通信が中断されるエラーです。原因は多岐にわたるため、整理して確認することが重要です。

重要なチェックポイント

  • 証明書チェーンの完全性:ルート/中間証明書が欠けていないか確認します。
  • 証明書の有効性:期限切れや失効(CRL/OCSP)を確認します。
  • ホスト名の一致:SNIやCN/SANが接続先と一致しているか確認します。
  • インストールと鍵の一致:サーバ証明書と秘密鍵が一致しているか検証します。
  • システム時刻:時刻ズレは誤判定を招きます。
  • クライアント側の信頼設定:信頼ストアに正しいCAが登録されているか確認します。

対処の順序(実務向け)

  1. ログとハンドシェイクを取得(openssl s_clientやWiresharkを利用)。
  2. 証明書チェーンとSNIを確認。必要なら中間証明書を再配置。
  3. サーバ時刻と証明書の有効期間を確認。
  4. クライアント側の信頼ストアと互換性を確認。

詳細な原因特定には、サーバ・クライアント双方のログとSSLハンドシェイク解析が不可欠です。これらを順に確認すれば、多くの場合は問題を特定し解決できます。

よかったらシェアしてね!
  • URLをコピーしました!

この記事を書いた人

目次