ホスト名、依存関係、所有権を棚卸する
訪問者や統合が使う全てのホスト名を列挙してください：apex（ルートドメイン）、www、サブドメイン、API、資産ホスト、ポータル、リージョン名など。各ホストについて、TLS がどこで終端するか、誰が変更できるか、証明書のカバレッジと有効期限、更新方法、URL を生成する依存先を記録します。要求されるホスト名は、証明書の Subject Alternative Name リストに含まれている必要があります。CMS、CDN、タグマネージャ、オブジェクトストレージ、決済プロバイダ、メールテンプレート、サードパーティ埋め込みを必ず含めてください。これらは最初の HTTPS リリース後に HTTP URL を導入しがちです。
代表となる www か apex の一つを選び、代替はすべて HTTPS で直接その代表にリダイレクトします。
証明書を導入し、許容する TLS バージョンを決める
公開要求に応答するウェブサーバ、リバースプロキシ、CDN、またはロードバランサを設定します。証明書と必要なチェーンをインストールし、意図したホスト名にバインドして、ホスティングネットワークの外部から検証してください。ブラウザはチェーン、ホスト名、有効期間を確認します；公開の警告はリリースの阻害要因です。既定では TLS 1.3 を優先し、互換性が必要な場合のみ TLS 1.2 を残してください。SSL と TLS 1.0／1.1 は無効にします。レガシーな暗号スイートの丸コピーではなく、保守されたプラットフォームの指針を使い、サーバと TLS ライブラリは常にパッチ適用してください。
秘密鍵へのアクセスを制限し、同じ鍵を共有しているすべてのシステムを記録しておくことで、鍵を交換したときに全てに反映できるようにします。
HTTP を一回だけリダイレクトし、HTTPS を正規化する
各 HTTP URL から等価の HTTPS URL へサーバーサイドの恒久的リダイレクト（通常は 301 または 308）を返してください。チェーンは避けてください。遅延と障害点が増えます。内部リンク、canonical タグ、サイトマップ、構造化データ、ソーシャルタグ、メール、およびアプリ生成の絶対リンクには、HTTPS の正規 URL を使用します。ホームページ、深いページ、クエリ付き URL、エラールート、ホスト名のバリアントをテストしてください。TLS がプロキシで終端する場合は、アプリケーションが HTTP と HTTPS の間でループしないよう、信頼できるプロキシからの転送プロトコルヘッダー（例: X-Forwarded-Proto）を適切に処理するよう設定してください。
HTTP はリダイレクトまたは証明書チャレンジを完了するためにのみ残し、別の公開サイトを提供するために使ってはいけません。
混在コンテンツを発生源から見つけて修正する
混在コンテンツとは、HTTPS ページが HTTP または別の安全でないプロトコルでリソースを要求することです。ブラウザはいくつかのメディアをアップグレードする場合がありますが、スクリプト、スタイルシート、フレーム、fetch 呼び出し、フォントなど多くの危険な要求をブロックします。すべての参照をテスト済みの HTTPS URL、自己コンテンツには相対 URL、または承認済みの代替に置き換えてください。代表的なテンプレートをクロールし、主要な操作経路を実行しながら開発者ツールで検査してください。CSS、JavaScript、CMS ブロック、資産マニフェスト、タグマネージャのエントリ、ダウンロード、ベンダー埋め込みを確認します。安全なページは HTTP のダウンロードを提供してはいけません。
ブラウザの自動アップグレードは利用不可や非対応のサードパーティ依存を残す可能性があるため、保存されている URL を正してください。
更新を自動化し、証明書復旧をリハーサルする
更新は、カレンダーのリマインダーではなく、自動化されたデプロイとして扱ってください。証明書を更新し、すべての配信層に展開して、安全にサービスを再読み込みできる必要があります。本番環境で有効期限が切れる前に、同じ検証経路をテストしてください。たとえば Let’s Encrypt は有効期間が90日の証明書を60日ごとに更新することを推奨しています。発行者とプラットフォームのライフサイクルに従ってください。証明書名、発行者アカウント、チャレンジ方法、自動化、鍵の保管場所、展開先、緊急連絡先をインベントリに記録してください。展開後は公開エンドポイントから有効期限を検証してください。
更新に失敗した場合は、DNS、チャレンジルーティング、権限、発行者アクセス、レートリミット、CDN からオリジンへの展開を確認してください。
HTTPS 構成が整ったら HSTS を段階的に導入する
HTTP Strict Transport Security（HSTS）は、ブラウザにそのホストへの将来の訪問を HTTPS にするよう指示する HTTPS レスポンスヘッダです。ブラウザはその後、証明書のエラーに対するバイパスを訪問者に提示しなくなります。HSTS ヘッダーは HTTPS 経由でのみ送信し、HSTS は HTTPS のレスポンスを受けた後に学習されるため、HTTP リダイレクトは残してください（プリロードリストが適用されない限り）。まずは短い max-age で開始し、更新の仕組みと必要なルートが正しく機能することを確認した後に延長してください。すべての現在および将来のサブドメインが有効な HTTPS を提供できるようになるまで includeSubDomains を追加しないでください。プリロードは HSTS 仕様の一部ではなく、別途長期的なコミットメントの検討が必要です。
max-age=0 はブラウザが有効な HTTPS レスポンスに到達した後でしか機能しません。到達不能になった HTTPS ホストを復旧させることはできません。
トランスポートを弱めずにリリース、テスト、ロールバックする
変更前に、既知の安全な証明書、エッジ、リダイレクト構成を記録してください。誰がロールバックを承認するかを定義し、可能ならステージング環境で検証し、設定カテゴリは一度に一つだけ変更します。公開エンドポイントをすぐに複数のネットワークからチェックし、リダイレクトを追跡して証明書を検査し、重要な訪問者操作を完了してください。対象ユーザーのブラウザとクライアントグループでテストします。決済や規制対象のフローについては、決済プロバイダと資格を有するセキュリティ専門家に要件を確認してください。変更で HTTPS が壊れた場合は、検証済みの安全な構成を復元し、顧客ページを HTTP に戻すことで回避しないでください。
次回の更新や移行で診断が容易になるよう、ホスト名、時刻、クライアント、エラー、変更、結果をキャプチャしてください。