独立站HTTPS設定：SSL証明書、HSTS、混合コンテンツの修正
1. 証明書の選定と自動更新：OV証明書は買わない、手動更新もしない
多くの独立站は初年度に有料SSL証明書を買い、翌年更新を忘れてブラウザに赤い警告を出されます。直感に反する結論ですが、ほとんどのB2B独立站にはLet’s Encryptの無料DV証明書で十分です。OCSP staplingもA+評価も取得でき、有料OV証明書で追加される企業名表示はコンバージョン率に測定可能な影響を与えません。
証明書の選定で押さえるべきは2点だけです。1つ目は鍵アルゴリズムで、RSA 2048ではなくECDSA P-256を選ぶとハンドシェイクのサイズが40%小さくなり、モバイルの初回読み込みが約80ミリ秒速くなります。2つ目は更新方法で、certbotかacme.shによる自動更新が必須です。crontabで毎日1回チェックし、手動更新は絶対にしません。証明書切れの事故は90%が担当者の退職か失念が原因です。
| 証明書の種類 | 年間コスト | ブラウザ表示 | 適した用途 | おすすめ |
|---|---|---|---|---|
| Let’s Encrypt DV ECDSA | 0円 | 鍵アイコン、企業名なし | ほとんどのB2B独立站 | 既定の選択、自動更新 |
| Let’s Encrypt DV RSA | 0円 | 鍵アイコン、企業名なし | 旧端末の互換性が必要な場合 | IE11のトラフィックがある場合のみ |
| 有料OV証明書 | 2000〜8000元/年 | 緑色の企業名 | 金融、決済、高単価 | 不要なら買わない |
| 有料EV証明書 | 5000〜20000元/年 | EV表示（ほとんどのブラウザで廃止） | ほぼ出番なし | 推奨しない |
導入例：杭州のSaaS海外展開サイトでacme.shを使いLet’s Encrypt証明書を取得。crontabに0 3 * * 1 /root/.acme.sh/acme.sh –renew -d example.comを設定し、毎週月曜の午前3時に自動で更新をチェックします。同時に監視に「証明書の残り有効期間が15日未満なら企業WeChatでアラート」というルールを追加。この設定を一度書けば、その後2年は触る必要がありません。
複数ドメインとワイルドカードの扱いは、CDNグローバル高速化のノード証明書戦略と合わせて設計します。CDN事業者は通常エッジ証明書を提供しているため、オリジン証明書とエッジ証明書は別々に管理し、エッジ証明書の更新をオリジンに依存させないようにします。
2. HSTS：段階的に引き上げ、一気に設定しない
HSTS（HTTP Strict Transport Security）は、ブラウザにHTTPSを強制させるレスポンスヘッダーです。直感に反するのは、max-ageを長くするほど安全になる一方で、危険も大きくなる点です。最初からmax-age=31536000を設定すると、テスト環境やstagingサブドメイン、社内管理画面が1年間HTTPでアクセスできなくなり、証明書に問題が起きればサイト全体が停止します。
正しい移行ステップは3段階です。1週目はmax-age=300（5分）にして、ユーザーからの報告や業務上の異常がないか様子を見ます。2〜4週目はmax-age=86400（1日）にして異常がないことを確認します。1か月後にmax-age=31536000（1年）へ引き上げ、includeSubDomainsを追加します。preloadリストへの申請はさらに後回しにし、安定稼働3か月を過ぎてからchromium preloadへ申請するのがおすすめです。
| フェーズ | HSTSヘッダーの書き方 | 観察期間 | リスクポイント |
|---|---|---|---|
| 第1段階 | Strict-Transport-Security: max-age=300 | 1週間 | リスクはほぼなく、いつでも戻せる |
| 第2層 | max-age=86400 | 1か月 | 一部の古いブラウザでは非対応の可能性 |
| 第3層 | max-age=31536000; includeSubDomains | 3か月 | サブドメインのHTTPSがすべて整っていること |
| 最終段階 | preloadディレクティブを追加し、hstspreload.orgへ申請 | 長期 | 申請後の解除は非常に困難 |
事例：産業機器の海外展開サイトで、メインサイトのexample.comはHTTPSに対応済みですが、legacy.example.comはまだHTTPのままだとします。いきなりincludeSubDomainsを設定すると、legacyサブドメインのユーザーが締め出されます。正しい手順は、まずすべてのサブドメインをHTTPS化し、その後メインサイトのHSTSを段階的に1年へ引き上げることです。サブドメインの一覧はSSL Labsのテストレポートで確認できます。
HSTSと海外展開サイトのコンプライアンス基盤の転送セキュリティ要件は一致しています。GDPRが求める個人データ転送の暗号化に対して、HSTSは最も直接的な技術的実装です。
三、混合コンテンツ：自動アップグレードと手動クレンジングの2工程
混合コンテンツとは、HTTPSページ内でhttp://プロトコルのリソースを読み込むことを指し、2種類に分かれます。受動的混合コンテンツ（画像、動画、フォント）はブラウザが自動的にブロックしますがエラーは出ません。能動的混合コンテンツ（<script>、<iframe>、fetch、XHR）はページが赤く表示され、ブラウザが読み込みを拒否して機能が完全に停止します。
修正は2段階です。まずレスポンスヘッダーContent-Security-Policy: upgrade-insecure-requests;を追加すると、ブラウザがページ内のすべてのhttp://リソース要求を自動的にhttps://へ変更します。これで問題の80%は解決します。次にChrome DevToolsのConsoleパネルで確認し、残ったハードコードされたhttp://をコードとデータベースから削除します。特にWordPressのwp_optionsテーブルのsiteurlとhome、過去記事の<img src=”http://…”>のような古いデータに注意してください。
| 混合コンテンツの種類 | ブラウザの動作 | 修正の優先度 | 修正方法 |
|---|---|---|---|
| http://<script>または<iframe> | 即座にブロックされ、ページにエラー | P0、すぐに修正 | 参照元をhttpsに変更、またはCDNを切り替え |
| http:// XHR/fetch リクエスト | コンソールにエラー、機能が停止 | P0、すぐに修正 | コード内で相対プロトコルまたはhttpsに変更 |
| http://<img>画像 | 一部のブラウザは自動アップグレード | P1、1週間以内に修正 | upgrade-insecure-requestsで保険をかける |
| http://のフォントやCSS背景画像 | サイレント失敗でスタイルが崩れる | P1、1週間以内に修正 | CDNでhttpsリンクに差し替え |
| http://の<a href>リンク | HTTPに遷移しエラーは出ないが漏えいする | P2、毎月クリーンアップ | サイトマップ内で一括置換 |
WordPressサイトで最も多い落とし穴は、過去記事の画像リンクがhttp://でハードコードされていることです。データベースでSQLによる一括置換を直接行わないでください。まずバックアップを取り、Search Replace DBツールでシリアライズ安全な置換を行います。そうしないとPHPのシリアライズデータが壊れます。バックアップの方法はこちらサイトのバックアップと復元演習。
混合コンテンツのクリーンアップとCore Web Vitalsの最適化は連動しています。ブロックされたスクリプトはLCPを遅らせ、読み込みを拒否された画像はCLSを引き起こします。混合コンテンツをクリーンアップすると、この2つの指標は通常自動的に改善します。
四、受け入れチェックリストと毎月の点検
HTTPS設定は一度公開したら終わりではありません。証明書は期限切れになり、サブドメインは新たに追加され、過去のコンテンツでhttpリンクが再び混入します。毎月の点検表を作成し、月に一度実行すれば5〜10分で完了します。
| チェック項目 | ツール/方法 | 合格ライン | 不合格時の対応 |
|---|---|---|---|
| SSL Labsの評価 | ssllabs.com/ssltest | AまたはA+ | TLS設定を調整し、古いプロトコルを無効化 |
| 証明書の残り有効期間 | openssl s_client | 15日以上 | 直ちに更新を実行 |
| HTTPからHTTPSへのリダイレクト | curl -I http://example.com | 301でhttpsへ | rewriteルールを追加 |
| HSTSヘッダーの有無 | curl -Iでレスポンスヘッダーを確認 | max-ageが86400以上 | レスポンスヘッダー設定を追加 |
| 混合コンテンツの件数 | Chrome DevToolsのコンソール | 0件 | httpのハードコードを特定して置換 |
| TLSバージョン | SSL Labsのレポート | TLS 1.2/1.3のみ | TLS 1.0/1.1を無効化 |
点検の自動化方法はこちらサイト監視とアラートの証明書期限切れと可用性監視の章をご覧ください。ハッキング後はHTTPS設定が壊れていることが多いです。クリーンアップ手順はこちらサイトがハッキングされた後のクリーンアップと再インデックス。
直感に反する注意点：HSTS preloadは簡単に申請しないでください。一度あなたのドメインがブラウザ内蔵のpreloadリストに入ると、将来削除するには専用の削除手順を踏む必要があり、数か月間は古いユーザーのブラウザでHTTPSが強制され続けます。サブドメインやテスト環境を頻繁に調整している場合は、preloadはメインサイトが安定稼働して半年以上経ってから検討してください。
FAQ よくある質問
無料のLet’s Encrypt証明書で十分ですか、有料のOVを買うべきですか？
HSTSを最初からmax-age=31536000に設定しても大丈夫ですか？
混在コンテンツはどうやって一括修正する？ワンクリックツールはある？
証明書の自動更新はどう設定する？一番怖い落とし穴は？
HTTPSはSEOに影響する？全サイトHTTPSは必須？
TLSバージョンはどう設定する？TLS 1.0と1.1は無効にすべき？
最後に
HTTPS設定は「証明書を入れれば終わり」と考えられがちですが、実は独立系サイトの安全とSEOの土台です。証明書の期限切れ、HSTSの欠如、混合コンテンツの残存。この3つはどれもブラウザに赤い警告を出させ、購入者が警告を見てページを閉じてしまえば、SEOの評価も下がります。一度きちんと設定し、毎月点検すればコストはわずかで、効果はサイト全体に表れます。
実践は3ステップ。まずLet’s Encryptの自動更新で証明書をクリアし、SSL LabsでA以上を取ります。次にHSTSを5分から1年へと3段階で引き上げます。最後にupgrade-insecure-requestsと手作業での整理で混合コンテンツをゼロにします。ここまで終えて、HTTPSはようやく完成します。日々の保守チェックリストは公式サイト保守で毎月やる6つのことにまとめ、HTTPS点検を組み込みましょう。
覚えておきたい一言。HTTPSは証明書を入れれば終わりではなく、証明書の自動更新、HSTSの段階的な引き上げ、混合コンテンツのゼロ化。この3層すべてを通過して初めて本物のHTTPSです。どれか1層でも欠ければ、ブラウザの赤い警告が購入者を追い払います。