SSL とサブドメインのよくある罠 — 鍵マークの先にある、本当の安全

Lesson 1-3 でドメインとサーバの基礎を押さえました。 続くこの Lesson では、Web 上の「安全」を支える SSL の話を中心に、現場でよく見るトラブルを整理していきます。 SSL の話だけで終わらせず、その隣にあるセキュリティ話題まで地続きで扱うのは、現場では SSL だけで完結しないからです。

1. 2026 年、SSL が無いサイトは「議論の対象外」

1-1. ブラウザの「保護されていません」表示

SSL が無い、つまり「http://」のままのサイトを開くと、Chrome や Safari は 「保護されていません」 と警告を表示します。 多くの訪問者は、この警告を見た瞬間に離脱します。 信頼ゼロ、入力フォームに何も書き込まれない、検索順位も上がりにくい、という三重苦に陥ります。

1-2. SEO 順位への影響

Google は https を順位シグナルとして扱う と公式に表明しています。 細かい寄与度の話はさておき、SSL が無いことが明確なマイナスになる、というのは間違いありません。 競合が SSL を当然装備している中、自社だけ未対応では、初期段階で土俵に上がれません。

1-3. 「鍵マークがある=最低ライン」という現状

鍵マークがあることは、サイトの「差別化要素」ではありません。 あって当然のもの、無いと議論にすら参加できないもの、という前提で考えておくと安心です。 2010 年代までは「SSL を入れるかどうか」が選択肢でしたが、2026 年現在、それは選択肢ではなく前提条件です。

2. SSL / TLS / https の関係をやさしく

2-1. 3 つの言葉の関係

用語が 3 つあって混乱しがちですが、関係はシンプルです。 SSL は通信を暗号化する仕組み。 TLS は SSL の後継規格(現在の主流)。 https は、SSL/TLS で守られた http 通信 のこと。 技術的には「TLS」が正確ですが、現場用語としては「SSL」で通じます。

2-2. 例え話

通信の暗号化を、郵便の例で考えるとわかりやすいです。 暗号化のない http は 普通のハガキ。 途中で誰でも中身を読めてしまいます。 一方、暗号化された https は 封筒に入った手紙。 受取人だけが封を開けて読めます。

2-3. 現場用語としては「SSL」で OK

厳密には、現在広く使われているのは TLS(SSL の後継)です。 でも業者も自社のスタッフも「SSL 入れますか?」「SSL 切れてます」のように、SSL の名前で会話します。 担当者も普段は SSL で話して問題ありません。 厳密な議論が必要な場面では「TLS」と置き換える、くらいで十分です。

3. どの SSL を選べばいい?

3-1. 証明書は 3 種類。でも暗号の強さは同じ

まず、ここを最初に押さえておくと安心です。 DV / OV / EV の 3 種類は、暗号通信の強度はすべて同じ です。 SSL/TLS の暗号化アルゴリズムや鍵長は共通仕様なので、種類が違っても通信そのものの安全性は変わりません。 違うのは「証明書発行時に、何を、どれだけ深く認証するか」の部分です。

• DV(Domain Validation / ドメイン認証)：ドメインの所有者であることだけを認証します(メール認証や DNS 認証で確認)。無料 SSL(Let's Encrypt など)はここに該当します。
• OV(Organization Validation / 組織認証)：組織(企業)の実在を認証します。法人登記や第三者データベースで確認するため、発行までに数日かかります。
• EV(Extended Validation / 拡張認証)：組織の厳格な実在認証を行います。法的存在、物理的所在地、運営実態まで認証局が詳細審査します。

「DV だと通信が弱い」「EV だと暗号が強い」というのは よくある誤解 です。 違いは「サイトに対する社会的信頼の表示・利用者の安心感」であって、暗号化の安全性そのものではありません。 ここは事実として押さえておくと、業者との話がスムーズになります。

3-2. 選ぶときに見る 5 つの軸

どの種類を選ぶかは、次の 5 軸で判断します。 繰り返しますが、これらは「社会的信頼の表示が必要な度合い」を測る軸です。 暗号通信の安全性は、どの種類でも同等です。

• 軸 1:サイトの種類(コーポレート / EC / 金融 / 会員制)
• 軸 2:個人情報の取り扱い(あり/なし、量)
• 軸 3:決済・取引額の大きさ
• 軸 4:信頼性アピールの必要性(BtoB 大型案件・公的機関)
• 軸 5:予算とサーバ標準対応の有無

重要なのは、個人情報や決済を扱う場合のサイト全体の安全性は、SSL の種類だけでは決まらない という点です。 権限管理・バックアップ・脆弱性対策・委託先管理・インシデント対応 — これらをセットで設計する必要があります(「7. SSL 周辺のセキュリティ」 で扱います)。

3-3. 判断チャート

軸を組み合わせると、次のような大まかなフローになります。

• 個人情報・決済を扱わず、サーバが無料 SSL に対応 → 無料 SSL(Let's Encrypt 等) で十分
• サーバが無料 SSL に対応していない、または運用上自動更新を任せたい → DV 有料 を検討
• BtoB 大型案件・上場企業など組織実在の社会的表示が必要 → OV を検討
• 金融・医療など業界慣行で求められる → OV or EV を専門家と相談して決定

3-4. 「うちはどれ?」の代表 5 ケース

• コーポレート(問い合わせフォームあり)：無料 SSL で十分。通信暗号化は同じ。
• EC(自社決済)：DV 有料 or OV。信頼性表示の必要性 + 業界慣行から。
• 上場企業・大規模 BtoB：OV を検討。組織実在の社会的表示として。
• 金融・医療：OV or EV を検討。ただし EV の視覚的効果は近年限定的なので、専門家と相談。
• 会員制サービス：DV 有料 + ワイルドカード SSL。機能要件として複数サブドメイン対応が必要。

繰り返しになりますが「EV だから安全」ではありません。 サイト全体の安全性は別の領域で担保します(「7. SSL 周辺のセキュリティ」)。 これらの選択は 判断レイヤー 2〜3(Lesson 1-1「4. Web担当者の関わり方」)に該当し、個人情報・決済が絡む案件は専門家と擦り合わせて決めるのが原則です(Lesson 1-3「5. サーバの選定基準」 と同型)。

4. 一番見落とされる罠 — サブドメインの SSL は別物

4-1. 本体ドメインの SSL は、サブドメインには自動適用されない

ここが本 Lesson の核心の一つです。 「example.com」で SSL を設定しても、その SSL は サブドメイン(「blog.example.com」など)には自動では適用されません。 サブドメインは、技術的には別のドメインとして扱われるためです。 一見「同じドメインだから守られているはず」と感じますが、実際にはサブドメインごとに SSL を設定する必要があります。

4-2. 後から追加した瞬間に問題化する典型パターン

現場で繰り返し見るパターンが、これです。

• 「example.com」で SSL あり → 半年後に「blog.example.com」を作って公開 → 鍵マーク無し で世に出る
• 有料 SSL は契約範囲外のサブドメインを保護してくれない
• リダイレクト設定だけでは解決しない(リダイレクト先の URL が鍵マーク無しでは意味がない)

「ブログを別ドメインで作りましょう」「採用サイトを別で立てましょう」と決まった瞬間、この罠が待っています。 特に外部の制作会社に依頼するとき、SSL のことが議題から抜け落ちがちです。

4-3. 解決策 3 つ

• 個別に SSL 取得：サブドメインごとに別途 SSL を取得します。無料 SSL に対応しているサーバなら、追加コストなしで設定できることが多いです。
• ワイルドカード SSL を最初から契約：「*.example.com」を一括で保護する証明書。複数のサブドメインを将来増やす予定があるなら、これが楽です。
• サーバ標準で対応している場合は管理画面から有効化：多くのレンタルサーバは、サブドメインを作るときに SSL も自動設定する機能を持っています。「自動設定の有無」を確認しておきましょう。

4-4. 計画段階でやっておくべきこと

新規サイト構築・リニューアル時には、必ず業者にこう質問してください。 「将来、サブドメインで別サイトを追加する可能性はありますか?」「その場合、SSL はどのプランで対応しますか?」。 この 2 つを最初に詰めておくと、後から「ブログだけ鍵マーク無し」という事故を未然に防げます。

5. 期限切れの罠 — 監視責任は誰?

5-1. 自動更新の落とし穴

SSL には有効期限があります。 無料 SSL は 90 日ごとに自動更新、有料 SSL は 1 年ごとが一般的です。 どちらも「自動更新」になっていることが多いですが、油断は禁物です。 クレジットカードの期限切れ、契約変更、サーバ移転 — このいずれかで、自動更新が止まることがあります。

5-2. 「監視責任」を文書化する

SSL の有効期限を 誰が監視するか を、契約書または運用マニュアルに明記してください。 担当者が監視するのか、業者が監視するのか、サーバ会社が代行するのか。 「全員が見ている気がして、実は誰も見ていない」状態が、最悪のパターンです。

5-3. 期限切れ=サイト全停止級

SSL が切れると、全ブラウザで「保護されていない」どころか 「危険」 という警告が出ます。 訪問者はほぼ全員引き返します。 さらに、メール送信も止まることがあります(SPF/DKIM が SSL/TLS と連動しているため)。 1 日止まるだけで、月の問い合わせ数が大幅に下がります。

5-4. おすすめの自衛策

• 有効期限をカレンダーに登録(担当者・上長・業者の 3 名)
• 無料 SSL は、自動更新の動作確認を月 1 回実施
• 移転・サーバ変更時には、SSL 移行の手順を事前に文書化

6. 混在コンテンツ(Mixed Content)の罠

6-1. 何が起きるか

https のサイトの中に、http の画像・CSS・JavaScript が混ざっていると、ブラウザは「混在コンテンツ」警告を出します。 鍵マークが「未保護の鍵」に変わり、訪問者からの信頼を一気に失います。 Chrome では一部の混在コンテンツは自動で読み込みをブロックする仕様にもなっています。

6-2. 発生する典型タイミング

• サイトリニューアル後、過去の画像が「http://」のままで残っている
• 画像差し替え後、新画像のパスが http で入力されていた
• 外部サービスの埋め込み(YouTube・SNS・地図など)が http だった

公開前のチェックで防げるところなので、リスト化しておくと安心です。 公開前のチェックリストに「混在コンテンツの確認」を入れておくのが基本です(Lesson 8-1)。

6-3. 見つけ方

Chrome の DevTools(F12)を開き、Console タブを見ると「Mixed Content」の警告が表示されます。 技術寄りの作業に見えますが、担当者でも開いて警告を確認することは可能です。 自分で開けるようになっておくと、業者に依頼する前に問題の有無がわかります。 もし苦手意識があるなら、公開前のチェック工程として業者に「混在コンテンツの確認結果を提示してください」と依頼するだけで十分です。

7. 「鍵マーク=安全」ではない — SSL の隣にある 3 つのセキュリティの話題

SSL の話の締めくくりに、避けて通れない話題があります。 鍵マークがあるからといって、サイトが安全になったわけではない ということ。 鍵マークは「通信が暗号化されている」ことしか示しません。 サイトの中身、運用、人の動き方 — これらに別のリスクが残ります。 担当者として最低限知っておくべきは、次の 3 つです。

7-1. WordPress 脆弱性

WordPress を使っているサイトの多くで、最大のリスクが 脆弱性放置 です。 WordPress 本体、テーマ、プラグインそれぞれにセキュリティ更新が定期的に出ます。 これを放置すると、既知の脆弱性を突かれて改ざんされる事故が起きます。 担当者の責任は、コード修正そのものではなく、「いつ・誰が更新するか」を決めておく ことです。 更新作業を業者に委託するなら、契約書に頻度・対応範囲を明記してください(Lesson 3-5)。

7-2. フォームスパム

問い合わせフォームを公開した瞬間、世界中のボットから大量のスパム送信が始まります。 対策なしのフォームは、1 日で数百件のスパムが届くことも珍しくありません。 CRM が汚染され、本物の問い合わせを見落とすリスクが上がります。 対策は reCAPTCHA(Google の不正対策)、honeypot(ボット用の見えないフィールド)などです。 制作会社にフォームを依頼するときは、スパム対策をデフォルトで入れてもらうよう指定してください。

7-3. パスワード漏れ・不正ログイン

CMS の管理画面 URL が「/wp-admin/」のような推測可能なパスのまま、管理者のパスワードを使い回し、2 要素認証も未設定 — このセットがそろうと、不正ログインまで一直線です。 対策は単純で、管理画面 URL の変更、パスワードの十分な強度、2 要素認証の有効化、この 3 つです。 担当者本人のアカウント運用に直結する話なので、自分から手をつけられます。

7-4. 本 Lesson の射程と、運用設計としてのセキュリティ全体像

ここまでで触れたのは、SSL・混在コンテンツ・WordPress 脆弱性・フォームスパム・パスワード漏れの 5 領域です。 これは「担当者が現場で意識する最低限」の射程に絞ったものです。 実際の 運用設計としてのセキュリティはもっと広い領域 をカバーします。 全体像を持っておきましょう。

• 個人情報の取り扱い(取得・保管・委託・削除)— Lesson 2-1、Lesson 3-5 で前提条件として扱う
• 権限管理(レジストラ・サーバ・CMS・解析ツール・配信ツール各々のアクセス権)— Lesson 1-3「7. ドメイン・サーバの権限管理」 の 5 権限
• バックアップ(取得頻度・保管場所・復元手順・テスト)— Lesson 3-5 の SLA に組み込む
• ログ監視(アクセスログ・改ざん検知・不正アクセス検知)— 業者の運用契約に含める
• 委託先管理(業者・SaaS・クラウドの監督)— Lesson 3-5、個人情報保護法に基づく委託先監督義務
• インシデント対応(障害・乗っ取り・漏洩時のフロー)— Lesson 1-3「7. ドメイン・サーバの権限管理」、Lesson 8-1 公開後の運用
• 業種規制への対応(医療・金融・教育等の業種別セキュリティ規制)— Lesson 2-1「7. 企画段階の前提条件」

これらは 判断レイヤー 2〜3 領域(Lesson 1-1「4. Web担当者の関わり方」)で、担当者単独では完結しません。 個人情報や決済が絡む案件のセキュリティは、企画段階(Lesson 2-1)で前提条件として固め、契約段階(Lesson 3-5)で業者と合意し、運用段階(Lesson 8 章)で継続点検する — という流れで本書全体を通じて段階的に学びます。

8. 担当者が押さえる「セキュリティ最低限チェックリスト」

最後に、担当者が月次・四半期ごとに自分で点検できるチェックリストを整理しておきます。

• 本体ドメインの SSL が有効か、有効期限はいつか
• サブドメイン(blog / recruit / shop など)それぞれの SSL も有効か
• WordPress 本体・テーマ・プラグインの更新責任者は誰か、更新頻度はどうか
• 問い合わせフォームのスパム対策(reCAPTCHA / honeypot 等)は機能しているか
• CMS 管理画面の URL は推測しにくくなっているか、2 要素認証は有効か
• バックアップは取得されているか、復元テストは過去半年で実施したか
• 個人情報を扱うフォームの取扱責任者・委託先は明確になっているか

SSL まわりは項目が多く見えますが、一度仕組みが分かれば点検は数分で回せます。 完璧を一人で抱え込まず、業者と分担しながら少しずつ整えていけば大丈夫です。 まずはチェックリストを上から眺めて、いま手元で確認できるものから一つずつ進めてみましょう。