デジタルトラスト 10-01-2026

HTTPSに勝る接続先はない

HTTPSへの安全な接続が不可欠：リダイレクトにもHTTPSが必要な理由

先日ラスベガスを訪れた際、意外にもラスベガスらしくないテーマに出会いました。それは『オズの魔法使い』です。ラスベガスのSphereでは1周年を記念し、黄色いレンガ道を歩く体験を、完全没入型のエンターテインメントとして提供していました。その魅惑的な道のりから思い浮かんだのは、オンラインで日常的に行われている、もっと地味な移動です。あるURLから別のURLへのリダイレクトです。

HTTPSリダイレクトはほんの一瞬で完了することもありますが、ブラウザは転送先に移動する前に、まず転送元のホスト名にアクセスする必要があります。この最初の接続先がHTTPSに対応していない場合、訪問者は目的のサイトに到達する前にセキュリティ警告に遭遇する可能性があります。

つまり、リダイレクト用のドメインにもHTTPSが必要です。ブラウザがHTTPSの保護機能を強化し、TLS証明書の有効期間が短縮されるなか、リダイレクトのセキュリティ確保と管理はますます重要になっています。

すべてのリダイレクト用ドメインにHTTPSが必要な理由

リダイレクトは、ブラウザをあるURLから別のURLへ転送する仕組みです。しかし、ブラウザが転送指示を受け取るには、まず転送元のホスト名に接続する必要があります。そのため、転送元のドメインも接続経路の一部となります。

転送元が有効なTLS証明書を使用したHTTPSに対応していない場合、安全な転送先に到達する前に接続が失敗したり、警告が表示されたりする可能性があります。転送先が安全でも、最初の接続が安全でなければ問題は解消されません。訪問者がほんの一瞬しかアクセスしない場合でも、リダイレクト専用ドメインはHTTPSで保護すべき対象に含まれます。こうした見落とされがちなドメインの重要性を高めているのが、業界における2つの変化です。

HTTPのみのリダイレクトを見過ごせなくなっている理由

Chromeは、HTTPSを標準とするWeb環境への移行を進めています。

Googleは、2026年10月のChrome 154から、公開サイトに対して「常に安全な接続を使用する」機能をデフォルトで有効にする計画を発表しました。ChromeはHTTPSでの接続を試み、HTTPSに対応していない公開サイトへのアクセスを続行する前に、ユーザに警告を表示します。

Googleは、HTTPSの転送先に即座にリダイレクトするHTTP URLについても、ユーザが通常は気付かない可能性のある安全でない接続の一例として明示しています。

同時に、公的に信頼されたTLS証明書の有効期間も短縮されています。

CA/Browser Forumの要件により、公的に信頼されたTLS証明書の最大有効期間は、2026年3月15日に200日へ短縮されました。さらに、2027年3月には100日、2029年3月には47日へ短縮されます。ドメインおよびIPアドレスの認証結果を再利用できる期間も短くなっています。

これらの変化により、証明書管理の対象範囲が広がっています。HTTPSによる保護は、主要なWebサイトやアプリケーションだけでは不十分です。ブラウザが接続経路上でアクセスする可能性のある、すべての公開ホスト名を対象にする必要があります。リダイレクトも例外ではありません。

見落とされやすいリダイレクト用ドメインとは？

本番環境のインフラストラクチャとして管理しているWebサイトやアプリケーションは、すでに保護されているでしょう。難しいのは、その周辺に存在する多数のドメインを漏れなく管理することです。

代表的な例は次のとおりです。

パーキングドメイン
キャンペーン用URL
サブブランドのドメイン
買収によって取得したWeb資産
旧システムのホスト名
移行用ドメイン

これらの多くは、アクセスを別の場所へ転送するだけの用途で使用されているため、証明書のインベントリ作成や更新計画で軽視されがちです。しかし、ブラウザは接続を順番に処理します。まず転送元のホスト名にアクセスして接続を確立し、その後、別の場所へ移動する指示を受け取ります。転送元でHTTPS接続に失敗すると、リダイレクト自体が実行されない可能性があります。

TLS証明書の有効期間の短縮で、リダイレクトの手動管理がさらに困難に

リダイレクト専用ドメインは、その用途に比べて証明書管理の負担が大きくなる場合があります。

ホスト名の用途が訪問者を別のサイトへ転送することだけであっても、TLS証明書の発行、展開、監視、更新が必要になる場合があります。これらの作業が、パーキングドメイン、キャンペーン、買収したWeb資産、代替ドメイン名、移行用インフラストラクチャ全体に及ぶことを考えてみてください。

証明書の有効期間が短縮されると、これらの作業をより頻繁に実施する必要があるため、問題はさらに深刻になります。以前は時折発生する保守作業だったものが、継続的な証明書ライフサイクル管理のプロセスへと変わります。

また、リダイレクト用ドメインは特に見落とされやすい傾向があります。監視を担当するアプリケーションチームが存在しない場合もあります。「Webサイト」として認識されていないこともあるでしょう。アクセス数が比較的少ないドメインもあります。しかし、証明書の更新を一度見逃すだけで、リダイレクトが完了する前に訪問者のアクセスが中断される可能性があります。課題は、単にHTTPSを一度有効にすることではありません。管理するすべてのリダイレクト用ドメインで、HTTPSを確実に維持することです。

HTTPS転送の自動化

自動化によって、こうした運用負荷の多くを軽減できます。

DigiCert UltraDNS Secure Web Forwardingは、HTTPSを使用してトラフィックを安全にリダイレクトするとともに、転送元エンドポイントの証明書管理を自動化できます。

トラフィックの転送元と転送先を指定するだけで利用できます。証明書管理の自動化を有効にすると、UltraDNSとデジサートが証明書の発行、展開、更新、およびドメイン管理権限の確認に必要なDNSレコードの管理を行います。

Web Forwardingは、次のような機能にも対応しています。

複数のリダイレクト方式：必要な動作に応じて、301、302、303、307などのリダイレクトを設定できます。
パスとクエリ文字列の保持：相対転送を設定することで、受信したURLのパスやパラメータを転送先に引き継ぐことができます。
ポータルとAPIによる管理：UltraDNSの管理インターフェースやAPIを通じて、転送レコードを作成・管理できます。
ワイルドカードによるマッチング：リクエストごとに個別のルールを作成することなく、関連するURLやパスをまとめて対象とする転送ルールを設定できます。

訪問者を別のサイトへ転送することを主な目的とするドメインでは、証明書ライフサイクルを自動化することで、安全なHTTPS転送に伴う運用作業の多くを削減できます。

HTTPSリダイレクトを監査する方法

保有するドメインを確認する際は、稼働中の本番Webサイトだけを対象にしてはいけません。

稼働中のドメイン、パーキングドメイン、旧システムのドメイン、キャンペーン用ドメイン、買収によって取得したドメイン、移行関連のドメインを対象に含め、特にトラフィックをリダイレクトするホスト名を確認してください。

リダイレクト用ドメインごとに、次の項目を確認します。

転送元のHTTPS接続をテストする。リダイレクトが実行される前に、転送元のホスト名で安全な接続を確立できることを確認します。
TLS証明書を確認する。必要に応じて、転送元エンドポイントが公的に信頼された有効な証明書を提示していることを確認します。
更新プロセスを確認する。証明書の更新が、担当者の手作業や記憶に依存せず、自動的かつ継続的に実行できる仕組みになっているかを確認します。
リダイレクト全体をテストする。訪問者が意図した転送先に到達できること、パスやクエリ文字列が想定どおりに処理されることを確認します。
リダイレクト用ドメインを証明書インベントリに含める。トラフィックを転送するだけのホスト名であっても、証明書管理の対象であることに変わりはありません。

リダイレクトは一瞬で完了することもありますが、接続経路の一部であることに変わりはありません。

ブラウザがHTTPSの保護機能を強化し、TLS証明書の有効期間が短縮されるなか、転送用ドメインをHTTPS管理の重要な対象として扱うことで、回避可能な警告の発生を防ぎ、証明書の手動管理を減らし、訪問者に一貫した利用体験を提供できます。

何より、黄色いレンガ道を歩くほんの短い旅であっても、安全な接続から始まるべきなのです。