本文へスキップ
重要 SSL/TLS証明書 47日間ルール正式決定 — ACME自動更新の導入を推奨しております。 Phase 2(100日へ短縮)まで 306日
300,000枚 累計発行
17,206社 利用中
19年 運営
24時間365日 自動発行
Q.

IIS サーバで古い端末から SSL 接続が失敗する問題と回避策(Sectigo R46 ルート)

A. 回答
⚠️ 対象環境について
本ご案内は、Microsoft IIS サーバを利用している場合で、かつ証明書のルートが Sectigo Public Server Authentication Root R46 に基づいている環境にのみ該当します。
IIS 以外(Apache / Nginx 等)の Web サーバをご利用の方、または証明書のルートが R46 / E46 以外の場合は、本内容は適用されません。

特定の組み合わせ(IIS サーバ × Sectigo R46 ルート)の環境で、古い端末から SSL 接続が失敗する事象が確認されています。本ページでは事象の原因と回避策(ルート証明書の無効化)について解説します。

🎯 3行で結論

  • IIS は本来クライアントごとに選ばれるべき証明書経路を、サーバ側で固定してしまう挙動がある
  • 結果、古い端末がクロスルート経由のチェーンを取得できず接続エラー
  • 回避策:IIS サーバ側で 新しい R46 ルートを「信頼されていない証明書」ストアへ移動させる

🔍 事象の概要

最新環境では正常に動作する SSL/TLS 接続が、古い端末や更新が行き届いていないクライアントからのみ失敗する事象が確認されています。

典型的な症状

  • 新しい Windows / macOS / iOS / Android からは問題なく接続できる
  • 古い Android 端末(4.x 系など)や、Windows 7 SP1 以前からの接続でエラー
  • サーバログには通常の接続として記録され、サーバ側からは異常に見えにくい

🛠 原因:IIS のクロスルート選択挙動

クロスルート証明書とは

SSL 証明書の運用では、新旧両方の環境で動作させるため、クロスルート証明書が用意されています。新しい端末は最新のルートを、古い端末は従来のルートを利用することで、環境ごとに適切な証明書チェーンを形成できる仕組みです。

# 通常想定される動作(Apache / Nginx 等)
新しい端末 → 新ルート(R46)経由でチェーン構築 ✅
古い端末   → 旧ルート(クロスルート)経由でチェーン構築 ✅

IIS で起きる問題

しかし IIS サーバには挙動上の問題があり、本来クライアントごとに選択されるべき証明書経路を、サーバ側で自動的に決定してしまう仕様があります。

# IIS での実際の動作
新しい端末 → 新ルート(R46)経由 ✅
古い端末   → 新ルート(R46)を強制 ❌ ← 古い端末は R46 を知らないため失敗

その結果、古い端末が必要とするクロスルート経由のチェーンが提供されず、接続エラーが発生します。

✅ 回避策:R46 ルートを「信頼されていない証明書」ストアへ移動

IIS サーバ上で 新しい R46 ルート証明書を無効化し、強制的にクロスルート経由のチェーンを使わせる方法が有効です。

⚠️ 作業前の確認

  • 本作業は IIS サーバ上で実施し、他のサーバや端末には影響しません
  • サーバ自身が R46 を信頼する用途で使用していないか事前確認してください
  • 作業前に証明書ストアのバックアップを推奨します

設定手順(Sectigo R46 ルート対象)

  1. 管理者権限で MMC を起動

    Windows の検索バーから mmc と入力し、「管理者として実行」で起動します。

  2. 証明書スナップインを追加

    MMC のメニューから以下を実行:

    • [ファイル] → [スナップインの追加と削除]
    • 「証明書」を選択して [追加]
    • 「コンピューターアカウント」→ [次へ]
    • 「ローカルコンピューター」→ [完了]
  3. 対象ルート証明書を無効化

    左ペインで以下のパスを開きます:

    証明書(ローカル コンピューター)
      └ 信頼されたルート証明機関
          └ 証明書

    右ペインから Sectigo Public Server Authentication Root R46 を選択し、右クリック → [切り取り]

    続いて以下のストアへ 貼り付け ます:

    証明書(ローカル コンピューター)
      └ 信頼されていない証明書
          └ 証明書
  4. IIS をリロード(任意・推奨)

    変更を即座に反映させるため、IIS のサイトをリロードまたは再起動します。

    # PowerShell で IIS を再起動(管理者権限)
    iisreset

📊 対応後の動作

この対応により、IIS は古い端末・新しい端末のどちらに対してもクロスルート経由の証明書チェーンを提供するようになり、古い端末でも正しい信頼チェーンが構築されます。

# 対応後の動作
新しい端末 → クロスルート経由のチェーン → 新ルート(端末側で信頼)✅
古い端末   → クロスルート経由のチェーン → 旧ルート(端末側で信頼)✅

🆘 確認方法

対応後の動作確認には、以下のツールが有用です。

ツール 用途
SSL Labs SSL Test 提供される証明書チェーンの確認・古い端末互換性チェック
証明書解析ツール サーバから取得した証明書チェーンの内容確認
openssl s_client コマンドラインで証明書チェーンを取得・確認

openssl での確認例

# サーバから証明書チェーンを取得
openssl s_client -connect www.example.com:443 -showcerts < /dev/null

# 取得されたチェーンの「Issuer」を確認
# 新ルート(R46)ではなく、クロスルートを経由していれば成功

💡 補足:根本的な解決について

本回避策は暫定対応です。古い端末のサポート期限切れ・利用率低下に伴い、将来的にはクロスルート対応自体が不要となります。

恒久的な解決の方向性

  • 古い端末(Android 4.x / Windows 7 SP1 以前)のサポートを終了する
  • IIS から Nginx などの別の Web サーバへ移行する
  • ACME 自動更新で証明書を新ルート(R46)に統一する

ご相談・サポートが必要な場合は お問い合わせフォームまでお気軽にどうぞ。

📚 関連ページ

最終更新: 2026年5月13日

このページで解決しない場合は

SSL証明書のお申込み、認証手続き、技術的なご相談まで、専門スタッフが丁寧にご対応します。

お電話でのご相談: 03-6712-6011(平日 10:30〜17:30)