TLS・SSLとは？仕組み・HTTPS化・証明書の種類をわかりやすく解説

Network Security
2026.04.18

「自社サイトもHTTPS化しないとマズいと聞いたけど、TLSとSSLって結局何が違うの？」「証明書にもDV・OV・EVと種類があるらしいが、どれを選べばいいのか判断できない」——情シス1人体制で運用を任されていると、こうした疑問が後回しになりがちです。

この記事では、TLS/SSLの仕組みとHTTPS化の実務について、現場で使えるレベルで解説します。プロトコルの基本から証明書の選び方、Webサーバーでの設定、HSTS等のセキュリティヘッダーまで、中小企業の情シスが「明日から手を動かせる」形で整理しました。

TLS・SSLとは？仕組み・HTTPS化・証明書の種類をわかりやすく解説

TLS/SSLとは？（概要・なぜ重要か）

TLS（Transport Layer Security）は、インターネット上の通信を暗号化し、改ざん・盗聴・なりすましから守るためのプロトコルです。SSL（Secure Sockets Layer）は、その前身にあたる古い規格で、名前の通りネットワーク層の上に「安全な層」を被せる役割を持っていました。

現在のWebサービスで実際に使われているのはTLSですが、「SSL証明書」「SSL化」といった呼び方が広く定着しているため、両者を並べて「TLS/SSL」と表記されるのが一般的です。

SSLとTLSの違い

SSLはNetscape社が1990年代に開発した規格で、SSL 2.0・SSL 3.0と進化したあと、標準化団体IETFに引き継がれる際にTLSへと名称が変わりました。現在では以下の整理で理解しておけば十分です。

・SSL 2.0 / 3.0: 脆弱性が多数発見されており、完全に非推奨（POODLE攻撃等）
・TLS 1.0 / 1.1: 2020年以降、主要ブラウザでサポート終了
・TLS 1.2: 現在の実質的な下限バージョン。広く使われている
・TLS 1.3: 2018年に策定された最新版。ハンドシェイクの簡略化と安全性向上が図られている

新しくサーバーを構築するなら、TLS 1.2とTLS 1.3のみを有効化し、それ以前のバージョンは無効化するのが基本方針です。

なぜHTTPS化が必須なのか

HTTPS（HTTP over TLS）化は、もはや「やったほうがいい」ではなく「やらないと不利益が大きい」段階に入っています。

・検索順位への影響: Googleは2014年からHTTPSをランキングシグナルの一つとして明言している
・ブラウザ警告: Chrome等はHTTP接続で「保護されていない通信」と警告を表示する
・フォーム入力の信頼性: 問い合わせフォームや会員登録フォームをHTTPで運用すると、情報漏洩リスクに加えて企業の信頼低下に直結する
・各種API・サービス連携: 決済・地図・SNS連携等、HTTPS必須のサービスが年々増加している

TLS/SSLの仕組み（ハンドシェイクの基本）

TLSは「公開鍵暗号」と「共通鍵暗号」を組み合わせて、効率と安全性を両立させる仕組みを採用しています。暗号化の基礎は姉妹サイトLinuxMaster.JPでも解説していますが、ここではHTTPS通信の流れに沿って整理します。

ハンドシェイクの大まかな流れ

TLS 1.2のハンドシェイクは、クライアント（ブラウザ）とサーバーの間で以下のようなやり取りを行います。

・ClientHello: 対応する暗号スイート一覧・TLSバージョン等をサーバーへ通知
・ServerHello: 使用する暗号スイートを選択し、サーバー証明書を送信
・証明書検証: クライアントが証明書のチェーン・有効期限・ドメイン一致を検証
・鍵交換: 共通鍵を安全に生成・共有するための情報を交換
・Finished: 以降の通信は共通鍵で暗号化される

TLS 1.3ではこのやり取りが1往復に短縮され、ハンドシェイクの高速化と同時に、脆弱な暗号スイートが仕様レベルで排除されました。

証明書チェーンの役割

サーバー証明書は単独で信頼されるわけではなく、「中間CA証明書」と「ルートCA証明書」をつなぐチェーンで検証されます。ルート証明書はOSやブラウザにあらかじめ組み込まれており、ここまで遡れる証明書だけが「正規のもの」と判定されます。

サーバー側でよくあるトラブルは、中間CA証明書の設定漏れです。自端末のブラウザでは問題なく見えても、古いスマートフォンでエラーになるケースの多くはこれが原因です。オンラインのSSLチェッカー（SSL Labs等）で外部からの見え方を確認する習慣をつけておくと安全です。


# コマンドラインから証明書チェーンを確認する例
openssl s_client -connect example.com:443 -servername example.com -showcerts

サーバー証明書の種類と選び方

証明書は「認証レベル」と「対応ドメイン範囲」の2軸で分類されます。ここを押さえれば、ベンダーの営業資料を読むときに迷わなくなります。

認証レベルによる分類

種類 認証範囲 想定用途 コスト感
DV（ドメイン認証） ドメインの所有権のみ コーポレートサイト・ブログ・社内ツール 無料〜年数千円
OV（組織認証） ドメイン所有権+組織の実在性 会員制サイト・問い合わせフォーム中心のサイト 年数万円〜
EV（実在認証） 厳格な審査+組織の法的実在性 金融機関・大規模ECサイト 年十数万円〜

かつてEV証明書はブラウザのアドレスバーに組織名が緑色で表示され、信頼性アピールの切り札でしたが、現在の主要ブラウザではこの表示は廃止されています。そのため、中小企業のコーポレートサイトや情報発信サイトであれば、DVまたはOVで十分というのが現場感覚です。

対応ドメイン範囲による分類

・シングルドメイン証明書: example.com 1本のみに対応
・ワイルドカード証明書: *.example.com のサブドメインすべてに対応
・マルチドメイン（SAN）証明書: 複数の独立したドメインを1枚の証明書で保護

サブドメインを多く運用する場合はワイルドカード、ドメインが複数ある場合はSANが選択肢になります。Let’s Encryptでもワイルドカードに対応しているため、無料で十分に運用できます。

HTTPS化の具体的な手順

ここからは、Linux上のNginx/Apacheで実際にHTTPS化を進める際の手順を整理します。

1. 証明書の取得（Let’s Encrypt）

無料で自動更新に対応した証明書発行サービスがLet’s Encryptです。certbotというツールを使えば、取得から更新までを自動化できます。


# certbotインストール（Ubuntu/Debian）
sudo apt install certbot python3-certbot-nginx

# Nginx向けに証明書を取得
sudo certbot --nginx -d example.com -d www.example.com

# 自動更新のcron確認（certbotは通常自動で登録される）
sudo systemctl list-timers | grep certbot

証明書の有効期間は90日と短めですが、cron/systemd timerで自動更新される設計のため、運用負荷はほぼゼロです。

2. Webサーバーの設定（Nginx例）

証明書を取得したら、Webサーバー側で以下の観点を設定します。

・TLSバージョン: TLS 1.2と1.3のみを有効化
・暗号スイート: 最新の推奨構成を採用（Mozillaの設定ジェネレータを活用）
・HTTPからHTTPSへのリダイレクト: 301で恒久リダイレクト


# /etc/nginx/conf.d/example.com.conf の抜粋
server {
    listen 80;
    server_name example.com www.example.com;
    # HTTPアクセスはすべてHTTPSへリダイレクト
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # TLS 1.0 / 1.1 は無効化
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;
}

3. HSTS・セキュリティヘッダーの追加

HTTPS化しただけでは、最初のHTTPアクセスの瞬間に中間者攻撃（MITM）の余地が残ります。これを塞ぐのがHSTS（HTTP Strict Transport Security）です。


# Nginxのserverブロック内に追加（HTTPS側のみ）
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

HSTSを一度有効化すると、ブラウザは指定期間中そのドメインにHTTP接続を試みなくなります。最初は短いmax-ageで検証し、問題がなければ1年（31536000秒）に延ばすのが実務的な導入手順です。

中小企業でも今日からできること

情シス1人・予算少なめの体制でも、以下のステップなら今日から着手できます。

・外部公開サイトの棚卸し: HTTPで運用しているサービス・サブドメインを一覧化する
・Let’s Encrypt化: コストゼロで証明書を取得し、certbotで自動更新を組む
・SSL Labsでスコア確認: 外部公開サーバーを無料のSSLチェッカーで評価し、A判定を目指す
・古いTLSバージョンの無効化: TLS 1.0/1.1を無効にし、TLS 1.2/1.3のみに揃える
・HSTSの段階的導入: max-ageを短く設定して検証してから本番適用する

これらは特別な予算承認がなくても、工数だけで完結する範囲です。

よくある誤解と注意点

HTTPS化すれば安全、ではない

TLSが保証するのは「通信経路の暗号化」と「接続先サーバーの同一性」だけです。Webアプリケーション自体の脆弱性（SQLインジェクション・XSS等）はTLSでは防げません。HTTPS化はあくまで出発点であり、WAFの導入やアプリケーション側の対策と組み合わせて初めて実効性が出ます。

無料証明書は信頼性が低い、は古い情報

「Let’s Encryptは無料だから信頼されない」という誤解がいまだに残っていますが、技術的には有料のDV証明書と同じ暗号強度です。ブラウザ側の鍵マーク表示も同じで、コーポレートサイトやブログで差別化にならないケースがほとんどです。

証明書の有効期限管理を甘く見ない

証明書切れは「その日」から全ユーザーにエラーが表示される致命的な事故です。自動更新の仕組みが動いていることを前提にせず、定期的に監視ツールや手動チェックで「あと何日で切れるか」を把握しておく運用が不可欠です。

なお、法律面（電子署名法等）での証明書の取り扱いは、詳細は法律の専門家にご確認ください。

本記事のまとめ

TLS/SSLは「暗号化」「改ざん防止」「なりすまし防止」の3役を担うプロトコルであり、現在のWebではHTTPSが事実上の標準です。証明書は認証レベル（DV/OV/EV）と対応範囲（シングル/ワイルドカード/SAN）の組み合わせで選び、中小企業のサイトであればLet’s EncryptのDV+ワイルドカードで多くの要件が満たせます。

HTTPS化は「証明書を入れて終わり」ではなく、古いTLSバージョンの無効化・HSTS・セキュリティヘッダーまで含めて一つの施策です。設定後はSSL Labs等の外部チェッカーでスコアを確認し、A以上を目指しながら継続的にメンテナンスしていきましょう。

HTTPS化の次に学ぶべきセキュリティ対策は？

TLS/SSLは守りの出発点にすぎません。WAF・認証強化・ログ監視まで含めた実践ノウハウを、現場目線で体系的に学んでいきましょう。
正しいセキュリティ知識を体系的に身につけたい方へ、メルマガで実践的なセキュリティ対策ノウハウをお届けしています。


無料メルマガに登録する（10秒で完了）
＞＞ セキュリティマスター通信を受け取る

関連記事

コメント

タイトルとURLをコピーしました