HTTPS化で何が守られるのか：SSL/TLSと証明書を実務で理解する
HTTPS化でまず押さえるべきことは、URLの先頭を http:// から https:// に変えるだけではない、という点です。HTTPSでは、ブラウザとサーバーの通信をTLSで保護し、途中で読まれにくくし、改ざんに気づけるようにし、接続先のサーバーがそのドメインの相手だと確認します。
Web制作、WordPress運用、サーバー移行、フォーム設置、API連携では、この違いがそのままトラブルの原因になります。証明書の期限切れ、HTTP画像の混在、リダイレクト設定の不足があると、サイトは表示されてもブラウザ警告や送信エラーにつながります。
この記事では、2026年7月7日時点の公開ドキュメントを前提に、SSL/TLS、HTTPS、証明書の関係を実務で確認できる形に整理します。
- HTTPSは、HTTP通信をTLSで保護したもの
- TLSが守るのは、主に暗号化・改ざん検知・サーバー認証
- 証明書は「この公開鍵はこのドメインのもの」と示すために使う
- HTTPS化後も、画像・CSS・JavaScriptがHTTPのままだと混在コンテンツになる
- 実務では、証明書の期限、対象ドメイン、リダイレクト、混在コンテンツを確認する
SSL/TLSとHTTPSの関係
SSL/TLSを理解する近道は、現在使うべき名前を分けることです。実務では「SSL証明書」という呼び方が残っていますが、現在のWeb通信で使われる中心はTLSです。
MDNのTLS解説では、TLSは信頼できないネットワーク上でクライアントとサーバーが安全に通信するためのプロトコルで、WebではHTTPS接続を保護するために使われると説明されています。
名前の整理
HTTP: WebページやAPIの通信方式TLS: 通信を保護する仕組みHTTPS: HTTPをTLSで保護した通信SSL: TLS以前の古い名称として、会話やサービス名に残っていることが多いSSL/TLS証明書: 実務上の呼び名。現在はTLS証明書として理解するとよい
ここがポイント: 「SSLを入れる」は、実務ではほとんどの場合「TLS証明書を用意して、HTTPSで配信できるようにする」という意味です。
TLSは、接続の最初にハンドシェイクと呼ばれるやり取りを行います。そこでブラウザとサーバーは、使うTLSバージョン、暗号方式、サーバー証明書、通信に使う秘密の鍵を決めます。
MDNは、現在のTLSバージョンとしてTLS 1.3を挙げ、TLS 1.2も一部サイトで使われている一方、TLS 1.0と1.1は使うべきではないと説明しています。自分でサーバー設定を管理する場合は、古いTLSを残していないかが確認ポイントになります。
HTTPS化で守られる3つのこと
HTTPS化の価値は、単にブラウザに鍵マークを出すことではありません。フォーム、ログイン、管理画面、API通信の中身を守るためにあります。
1. 通信内容を読まれにくくする
TLSでは、ブラウザとサーバーの間を流れるデータが暗号化されます。
たとえば、問い合わせフォームで次のような内容を送る場面を考えます。
name=山田太郎
email=taro@example.com
message=見積もりをお願いします
HTTPのままだと、通信経路上の第三者が内容を読み取れるリスクがあります。HTTPSでは、通信の中身が暗号化されるため、同じネットワーク上にいる人がそのまま読める形では流れません。
これはWordPressのログイン画面でも重要です。ユーザー名、パスワード、Cookieが関係する画面をHTTPで扱うのは避けるべきです。
2. 通信途中の改ざんに気づける
TLSは、通信中のデータが途中で書き換えられていないかを確認する役割も持ちます。
たとえば、サイトが次のJavaScriptを読み込んでいるとします。
<script src="https://example.com/app.js"></script>
HTTPSで保護されていれば、このファイルが通信途中でこっそり別の内容に差し替えられるリスクを下げられます。MDNも、TLSは暗号化だけでなく、通信の完全性を守ると説明しています。
3. 接続先のサーバーを確認する
証明書は、ブラウザが「このサーバーは本当にこのドメインの相手か」を確認するために使います。
たとえば、ユーザーが https://example.com にアクセスしたとき、サーバーは証明書を提示します。ブラウザは、その証明書が信頼された認証局によって発行され、対象ドメインと一致し、期限内であるかを確認します。
ここで問題があると、ブラウザは警告を出します。よくある原因は次の通りです。
- 証明書の期限が切れている
www.example.com用の証明書でexample.comにアクセスしている- 中間証明書の設定が不足している
- 自己署名証明書を公開サイトで使っている
- サーバー移行後に古い証明書が残っている
証明書の基本：DV、OV、EVは何が違うか
初心者がまず理解すべき証明書は、ドメイン所有を確認するDV証明書です。多くのWebサイト、個人サイト、WordPressサイトではDV証明書でHTTPS化できます。
証明書の種類は、何を確認して発行されるかで分かれます。
| 種類 | 確認する主な内容 | 向いている場面 |
|---|---|---|
| DV | ドメインを管理していること | ブログ、会社サイト、WordPress、一般的なWebサイト |
| OV | ドメインに加えて組織情報 | 組織名の確認を重視する企業サイト |
| EV | より厳格な組織確認 | 金融系など、厳格な審査を重視する場面 |
Let’s EncryptはDV証明書を提供する認証局で、公式FAQではOV証明書やEV証明書は発行していないと説明しています。また、通常の証明書は90日有効で、90日証明書は60日ごとの更新が推奨されています。
重要なのは、無料か有料かよりも、次の条件を満たすことです。
- サイトのドメイン名と証明書の対象名が一致している
- 証明書が期限内である
- 秘密鍵が漏れていない
- 更新が自動化され、失効前に反映される
- サーバーやCDNの設定に証明書チェーンが正しく入っている
Let’s EncryptのFAQでは、秘密鍵はLet’s Encrypt側ではなく利用者のサーバー側で生成・管理されるとも説明されています。秘密鍵は証明書と違い、公開してよいファイルではありません。
実務でHTTPS化するときの確認手順
HTTPS化では、証明書を発行しただけで終わりにしないことが大切です。ブラウザ、コマンド、管理画面の3方向から確認すると、見落としが減ります。
1. ブラウザで見る
まずは対象URLを開きます。
https://example.com/
https://www.example.com/
確認するのは次の点です。
- 鍵マークや保護表示が出るか
- 証明書の対象ドメインがアクセスURLと合っているか
- 有効期限が切れていないか
http://で開いたときにhttps://へ移動するか- 画像、CSS、JavaScriptが崩れていないか
WordPressでは、トップページだけでなく、ログイン画面、投稿ページ、固定ページ、問い合わせフォーム、画像が多い記事も確認します。トップページだけHTTPS化できていても、古い記事内にHTTP画像が残っていることがあります。
2. curlでヘッダーとリダイレクトを見る
CLIで確認するなら、curlの -I オプションが手軽です。curl公式マニュアルでは、-I / --head はヘッダーだけを取得するオプションとして説明されています。
curl -I http://example.com/
期待したい出力例は次のような形です。
HTTP/1.1 301 Moved Permanently
Location: https://example.com/
これは、HTTPで来たアクセスをHTTPSへ恒久リダイレクトしている状態です。MDNも、HTTPでアクセスされた場合は301でHTTPS版へリダイレクトする方法を説明しています。
HTTPS側も確認します。
curl -I https://example.com/
出力例です。
HTTP/2 200
content-type: text/html; charset=UTF-8
strict-transport-security: max-age=31536000
strict-transport-security はHSTSのヘッダーです。HSTSはブラウザに「次回以降はHTTPSで接続してほしい」と伝える仕組みです。ただし、設定を間違えるとHTTPに戻しにくくなるため、サブドメインや開発環境まで含めた影響を確認してから使います。
3. OpenSSLで証明書の中身を見る
証明書の期限やチェーンを詳しく見るなら、OpenSSLの s_client が使えます。OpenSSL公式ドキュメントでは、openssl s_client はSSL/TLSサーバー診断に使えるクライアントプログラムとして説明されています。
openssl s_client -connect example.com:443 -servername example.com </dev/null
出力の中では、まず次を見ます。
Verify return code: 0 (ok)
Verify return code: 0 (ok) なら、証明書検証が通っています。エラーが出る場合は、ドメイン不一致、期限切れ、中間証明書不足、古いクライアント環境などを疑います。
証明書の期限を見たい場合は、環境によって次のように組み合わせます。
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates
出力例です。
notBefore=Jun 1 00:00:00 2026 GMT
notAfter=Aug 30 23:59:59 2026 GMT
この notAfter が期限です。自動更新を入れている場合でも、更新後にWebサーバーへ反映されていなければ古い証明書が出続けることがあります。
よくある失敗と直し方
HTTPS化の失敗は、証明書そのものより「周辺設定」に出ることが多いです。特にWordPressやレンタルサーバーでは、管理画面、テーマ、プラグイン、CDNが絡みます。
混在コンテンツで警告が出る
混在コンテンツは、HTTPSページの中でHTTPの画像、CSS、JavaScript、フォントなどを読み込む状態です。MDNは、HTTPSで配信されたページでもサブリソースがHTTPだと混在コンテンツになり、リソース種別によってブラウザがアップグレードまたはブロックすると説明しています。
NG例です。
<img src="http://example.com/wp-content/uploads/logo.png" alt="ロゴ">
<script src="http://example.com/js/app.js"></script>
改善例です。
<img src="https://example.com/wp-content/uploads/logo.png" alt="ロゴ">
<script src="https://example.com/js/app.js"></script>
同じドメイン内の画像なら、相対パスにする方法もあります。
<img src="/wp-content/uploads/logo.png" alt="ロゴ">
WordPressでは、次の場所に古いHTTP URLが残りやすいです。
- 投稿本文内の画像URL
- テーマファイルに直書きされたURL
- ウィジェットやカスタムHTML
- CSS内の
background-image - プラグイン設定の外部スクリプトURL
- CDNや画像最適化サービスの設定
証明書は有効なのに警告が出る
証明書が期限内でも、対象ドメインが違うと警告が出ます。
たとえば、証明書が example.com のみを対象にしていて、ユーザーが https://www.example.com にアクセスすると警告になる場合があります。逆も同じです。
確認する組み合わせは最低限これです。
https://example.com/
https://www.example.com/
http://example.com/
http://www.example.com/
www ありなしのどちらを正規URLにするかを決め、もう一方は301で正規URLへ寄せます。検索エンジン対策というより、ユーザーと運用者が同じURLを見られるようにするためです。
更新したのに古い証明書が出る
証明書更新後に古い証明書が出る場合は、発行作業ではなく反映経路を見ます。
- Webサーバーを reload / restart していない
- ロードバランサーやCDN側の証明書が古い
- サーバーが複数台あり、一部だけ更新されていない
example.comとwww.example.comで別設定になっている- 管理画面上は更新済みでも、公開側の配信設定が別にある
この切り分けでは、ブラウザだけでなく openssl s_client や外部のTLS診断ツールを使うと、実際に公開されている証明書を確認できます。
WordPress運用で最低限見るポイント
WordPressでは、HTTPS化の設定箇所が複数に分かれます。サーバーでHTTPSが有効でも、WordPress側のURL設定がHTTPのままだと、リダイレクトループや混在コンテンツが起きます。
サイトURLを確認する
管理画面の一般設定では、次のURLを確認します。
WordPress アドレス (URL): https://example.com
サイトアドレス (URL): https://example.com
環境によっては wp-config.php でURLを固定している場合もあります。
define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');
この値を変える前に、バックアップとログイン経路を確認してください。設定を間違えると管理画面に入れなくなることがあります。
管理画面とフォームを優先して確認する
全ページを一度に見るのが難しい場合は、優先順位を付けます。
/wp-login.php/wp-admin/- 問い合わせフォーム
- 会員登録、購入、予約などの入力画面
- REST APIや外部連携で使うURL
- 画像や広告タグが多い記事
入力フォームがHTTPリソースを含んでいると、ユーザーの不安につながります。技術的にはページが表示できても、ブラウザ警告が出るサイトでは送信前に離脱されやすくなります。
開発環境では自己署名証明書の扱いを分ける
ローカル開発では自己署名証明書を使うことがあります。ただし、公開サイトで自己署名証明書を使うと、通常のブラウザでは信頼されません。
開発環境と本番環境は分けて考えます。
- ローカル検証: 自己署名証明書やローカルCAを使う場合がある
- ステージング: 本番に近いドメイン構成でDV証明書を使うと確認しやすい
- 本番: 信頼された認証局の証明書を使い、自動更新を監視する
HTTPS化後のチェックリスト
HTTPS化は、公開後の確認まで含めて完了です。特にサーバー移行やドメイン変更と同時に行う場合は、DNS、Webサーバー、WordPress、CDNを分けて見ます。
http://でアクセスするとhttps://に301リダイレクトされるwwwありなしの正規URLが決まっている- 証明書の対象名に必要なドメインが含まれている
- 証明書の期限が十分に残っている
- 自動更新後にWebサーバーへ反映される
- トップページ以外の投稿、固定ページ、管理画面もHTTPSで表示できる
- 混在コンテンツが残っていない
- CDNやロードバランサー側の証明書も更新されている
- curlやOpenSSLのログを共有するときは、認証情報やCookieを含めない
curl公式マニュアルは、verboseやtraceの出力にはユーザー名、認証情報、秘密データが含まれる可能性があると注意しています。トラブル調査でログを送る場合は、URL、Cookie、Authorizationヘッダー、フォーム内容を必ず確認してください。
関連ツールと使い分け
HTTPSの確認は、1つのツールだけで完結させない方が安定します。見る対象がそれぞれ違うからです。
| ツール | 向いている確認 | 注意点 |
|---|---|---|
| ブラウザ | 警告表示、混在コンテンツ、実際の画面崩れ | キャッシュや拡張機能の影響を受けることがある |
| curl | HTTPステータス、リダイレクト、レスポンスヘッダー | 証明書の詳細確認はOpenSSLの方が見やすい場面がある |
| OpenSSL | 証明書チェーン、期限、検証結果、SNI | 出力が長いので見る箇所を決める |
| TLS診断サービス | 設定全体の評価、古いTLSや暗号スイートの確認 | 公開サイト向け。社内サイトや未公開環境には向かない場合がある |
| ホスティング管理画面 | 証明書発行、自動更新、ドメイン追加 | 実際に公開されている証明書とは別に確認が必要 |
最初はブラウザとcurlで十分です。期限切れやドメイン不一致が疑わしいときにOpenSSLへ進み、サーバー設定を自分で管理している場合はTLS診断サービスで古い設定が残っていないかを見る、という順番が扱いやすいです。
実務での結論
HTTPS化は、サイト公開時のチェック項目ではなく、運用中も続く保守項目です。証明書は期限があり、ページ内のリンクは増え、CDNやフォーム連携の設定も変わります。
特に見るべき分岐点は次の3つです。
- 証明書更新が自動で成功し、公開サーバーに反映されているか
- HTTPで残った画像、スクリプト、外部タグがないか
example.comとwww.example.com、本番とステージング、CDNとオリジンサーバーの設定がずれていないか
この3つを定期的に見れば、HTTPS化の多くのトラブルは早めに見つけられます。証明書を発行する作業よりも、公開後にどのURLで、どの証明書が、どのリソースを配信しているかを確認することが実務では重要です。