一部の古い端末でSSL接続が失敗するのはなぜですか?(IISサーバー特有の問題について)
2025年08月22日
原因
この問題は、Microsoft IISサーバーに特有の不具合が原因です。
SSL/TLS証明書の更新では、新しいルート証明書に切り替えつつ古い端末の互換性も維持するため、クロスルート証明書が提供されます。
複数のルート証明書を相互に署名することで、最新端末は新しいルートを、古い端末は従来のルートを選び、それぞれが正しい信頼チェーンを構築できる仕組みです。
ところが IIS サーバーは TLS ハンドシェイクの際に、本来はクライアント端末が選択すべきルート証明書の経路を、サーバー内部で先に確定してしまうという誤った処理を行います。
この挙動により、古い端末が必要とするクロスルート経由の証明書チェーンが利用されず、接続エラーを引き起こすことがあります。
つまり、IISサーバーは「接続する端末ごとに最適な証明書チェーンを選ばせる」というSSL/TLSの基本設計に反した動きをしてしまっているのです。
回避策
古いクライアントでも接続できるようにするには、IISサーバー上で最新ルート証明書を一時的に無効化し、クロスルート証明書を強制的に利用させる方法が有効です。
手順(R46ルート証明書を無効化する場合)
-
管理者権限でMMCを起動
-
Windowsの検索から「mmc」と入力し実行します。
-
-
スナップインを追加
-
[ファイル] → [スナップインの追加と削除] を選択
-
「証明書」を追加し、「コンピュータアカウント」→「ローカルコンピュータ」を指定して完了
-
-
対象ルート証明書を移動
-
「信頼されたルート証明機関」→「証明書」を開きます。
-
Sectigo Public Server Authentication Root R46
を探し、これを「信頼されていない証明書」ストアへ移動します。
-
効果
この設定により、古い端末からの接続時にはクロスルート証明書を経由して信頼チェーンが構築され、エラーが発生せずに通信できるようになります。
まとめ
-
古い端末での接続エラーは IISサーバーの不具合(誤ったチェーン確定処理) が原因
-
対策は R46ルート証明書を無効化し、クロスルート証明書を利用させること
-
これにより、更新が行き届いていない古いクライアントでも正常にSSL接続が可能になる
よく読まれている質問
- 2026年3月15日からSSL/TLS証明書の有効期間が200日に短縮されます
- FujiSSLではどのACMEクライアントが使えますか?
- 量子コンピュータ時代に備える!FujiSSLなら耐量子暗号への移行も安心
- SSLサーバ証明書からクライアント認証EKU削除に関する重要なお知らせ
- FujisslのACMEはどの認証方式に対応していますか?
- クライアント証明書発行までの流れ
- ドメイン所有者確認方法をメール、DNS、ファイルのいずれかに変更したい
- FujiSSLは世界的CA「Sectigo」の中間認証局です
- ACMEを利用するメリットは何ですか?
- www付きのコモンネームで発行した証明書がwww無しのドメインで利用できません。...