「SSLとTLSって同じもの？違うもの？」「証明書エラーが出たけど何が原因？」「HTTPSなら絶対安全なの？」——そんな疑問をお持ちではないでしょうか。SSL/TLSはインターネット上の通信を暗号化し、安全なやり取りを実現する技術です。

本記事ではSSL/TLSの基本から仕組み・証明書の種類・証明書エラーの原因・よくある誤解まで初心者向けにわかりやすく解説します。

書籍「セキュリティ対策の基礎知識」
メルマガ登録でプレゼント！

セキュリティ対策で何をして良いかわからない
企業の情シス部門の方必見！

メルマガ登録はこちらから

SSL/TLSとは

SSLとは

SSL（Secure Sockets Layer）は、インターネット上でデータを暗号化して送受信するためのプロトコル（通信規約）です。1990年代半ばにNetscape社によって開発され、WebサイトとWebブラウザ間の通信を暗号化する技術として広く普及しました。

しかしSSLには重大な脆弱性が発見され、現在ではすべてのバージョンが非推奨・廃止となっています。代表的な脆弱性として2011年に発見された「BEAST」や2014年に発見された「POODLE」があり、暗号化を突破される深刻な欠陥が確認されています。

TLSとは

TLS（Transport Layer Security）は、SSLの脆弱性を修正した後継プロトコルです。1999年にTLS 1.0が公開されて以降、TLS 1.1・1.2・1.3とバージョンアップを重ね、現在はTLS 1.3が最も推奨されるバージョンとなっています。

TLSはSSLよりも安全性が高く、ハンドシェイク（通信開始時の手続き）の手順も効率化されているため、より高速かつ安全な通信を実現します。

なぜ「SSL/TLS」とまとめて呼ばれるのか

技術的にはSSLはすでに使われておらず、現在主流なのはTLSです。しかしSSLという名称が広く定着していたため、TLSのことも慣習的に「SSL」または「SSL/TLS」と呼ぶことが一般的になっています。

そのため、Webサイトで「SSL証明書」と表記されているものも、実際の中身はTLSプロトコルに対応した証明書であるケースがほとんどです。本記事でも以降「SSL/TLS」と表記しますが、現在使われている技術は実質的にTLSであると理解しておきましょう。

SSLとTLSの違い

バージョンの変遷

SSLは1.0（未公開）・2.0・3.0と進化しましたが、いずれも脆弱性が発見され現在はすべて非推奨です。TLSはSSL 3.0を引き継ぐ形で1.0・1.1・1.2・1.3と進化し、現在TLS 1.2とTLS 1.3が広く使用されています。2021年にはTLS 1.0と1.1も正式に非推奨となりました。

ハンドシェイクの違い

ハンドシェイクとは、ブラウザとサーバーが通信を始める前に行う「認証」と「暗号鍵の交換」の手続きです。SSLハンドシェイクは明示的な接続で手順が多く、処理に時間がかかっていました。TLSハンドシェイクは暗黙的な接続で、不要な手順を省くことで処理を高速化しています。

暗号化アルゴリズムの違い

SSLはメッセージ認証にMD5という現在では時代遅れとされるアルゴリズムを使用していました。一方TLSはHMAC（Hash-based Message Authentication Code）を採用し、より複雑で安全な暗号化を実現しています。暗号スイート（暗号化に使うアルゴリズムの組み合わせ）についても、TLSではセキュリティ上の懸念があるものがアップグレードされています。

違いの一覧表

TLS 1.0/1.1はなぜ無効化されたのか

TLS 1.0・1.1にもBEASTやPOODLEと同様に暗号化を突破される脆弱性が確認されています。これらはパッチ修正が困難な設計上の欠陥を含んでいたため、2020年頃までに主要ブラウザやプラットフォームからサポートが完全に打ち切られました。

古いバージョンを使い続けると、クレジットカード業界のセキュリティ基準「PCI DSS」など各種コンプライアンス違反につながるほか、最新のChromeやEdgeで「保護されていません」という警告が表示されるリスクもあります。自社サイトが古いプロトコルを使用していないか、定期的な確認が重要です。

書籍「セキュリティ対策の基礎知識」
メルマガ登録でプレゼント！

セキュリティ対策で何をして良いかわからない
企業の情シス部門の方必見！

メルマガ登録はこちらから

SSL/TLSが必要な理由

暗号化されていない通信のリスク

SSL/TLSを使わない通信では、送受信されるデータが「平文」のままインターネット上を流れます。これは多くの人が行き交う駅前でクレジットカード番号を口に出して伝えるようなもので、悪意ある第三者は特別な技術がなくても簡単に内容を盗み見ることができます。

SSL/TLSで防げる3つのリスク（盗聴・なりすまし・改ざん）

盗聴の防止 通信内容を暗号化することで、第三者がデータを傍受しても内容を解読できなくします。

なりすましの防止 SSL証明書によってWebサイトの運営者情報を確認できるため、正規のサイトに似せた偽サイトであるかどうかを判別できます。

改ざんの防止 通信途中でデータが書き換えられていないかを検証する仕組みがあり、改ざんが検出された場合は通信が破棄されます。

SSL/TLSの仕組み

公開鍵暗号方式と共通鍵暗号方式

SSL/TLSの暗号化には「公開鍵暗号方式」と「共通鍵暗号方式」を組み合わせたハイブリッド方式が使われています。

公開鍵暗号方式は暗号化と復号に異なる鍵（公開鍵と秘密鍵）を使う方式で、安全性は高いものの処理速度が遅いという特徴があります。共通鍵暗号方式は暗号化と復号に同じ鍵を使う方式で、処理速度は速いものの鍵の受け渡しに課題があります。

SSL/TLSでは、まず公開鍵暗号方式を使って安全に共通鍵を交換し、その後は処理の速い共通鍵暗号方式で実際の通信を暗号化するという2段階の仕組みを採用しています。

公開鍵・秘密鍵とは？仕組みをイラストと例え話で初心者に分かりやすく解説

2021.6.16

「公開鍵・秘密鍵ってよく聞くけど、結局何のこと？」「共通鍵暗号方式と公開鍵暗号方式って何が違うの？」そんな疑問を持つ方も多いのではないでしょうか。 公開鍵・秘密鍵は、インターネット上の安全な通信を支える暗号技術の核心です。本記事では、

SSL/TLSハンドシェイクの流れ

ブラウザとサーバーが暗号化通信を始める前に、以下のような手続き（ハンドシェイク）が行われます。

1. クライアントがサーバーに接続を要求し、使用可能な暗号方式を伝える
2. サーバーがサーバー証明書（公開鍵を含む）をクライアントに送付する
3. クライアントが証明書の正当性を検証する（有効期限・ドメイン名の一致・信頼できる認証局の署名かなど）
4. クライアントが共通鍵の元になる情報を生成し、サーバーの公開鍵で暗号化して送信する
5. サーバーが秘密鍵でその情報を復号し、共通鍵を生成する
6. 以降は共通鍵を使った暗号化通信が開始される

このハンドシェイクはわずか一瞬で完了するため、ユーザーが意識することはありません。

TLS 1.3がもたらす技術的な進化

最新規格であるTLS 1.3は、セキュリティとパフォーマンスを大幅に向上させています。「0-RTT（Zero Round Trip Time）」という仕組みにより、以前接続したことのあるサイトへの再接続時間を短縮できるほか、脆弱性のある古い暗号スイートを排除し、ハンドシェイクの往復回数を減らすことで通信開始までの時間も短縮されています。

現在Webサイトを運用している場合は、サーバー側の設定がTLS 1.2以上に対応しているか、可能であればTLS 1.3に対応しているかを確認することをおすすめします。

通信の改ざんを検知する仕組み（MAC）

SSL/TLSでは「MAC（メッセージ認証コード）」という仕組みで通信の改ざんを検知します。送信側はデータと共通鍵を使ってMACを計算し、データと一緒に送信します。受信側も同じ計算を行い、送られてきたMACと比較します。

データが1文字でも変更されるとMACの値は大きく変わるため、両者が一致しなければ「改ざんされている」と判断できます。共通鍵を知らない第三者は正しいMACを作成できないため、なりすましてデータを書き換えることもできません。

サーバー証明書とは

サーバー証明書に書かれている情報

サーバー証明書には、証明書が使われるドメイン名・有効期限・発行した認証局の情報・サーバーの公開鍵などが含まれています。証明書の中身は基本的に公開情報であり、誰でもブラウザから内容を確認できます。

認証局（CA）の役割

認証局（CA：Certificate Authority）とは、サーバー証明書を発行する信頼された第三者機関です。認証局は申請者がそのドメインの正当な所有者であるか、または組織が実在しているかを審査したうえで証明書を発行します。

WebブラウザやOSにはあらかじめ「信頼してよい認証局のリスト」が登録されており、そのリストに含まれる認証局が発行・署名した証明書を自動的に信頼する仕組みになっています。

サーバー証明書の種類（DV・OV・EV）

DVは個人サイトやブログなど低コストで導入したい場合に、OVは一般企業のコーポレートサイトに、EVは金融機関やECサイトなど高い信頼性が求められるサイトに適しています。

証明書の有効期間短縮（200日・47日ルール）と運用の自動化

2026年「200日」、2029年「47日」ルールへのロードマップ

サーバー証明書の有効期間は、セキュリティ強化のため今後段階的に短縮されていくことが決定しています。現状の最大398日（1年強）から、2026年には最大200日、2029年には最大47日まで短縮される方針です。

この短縮には、万が一証明書の秘密鍵が盗まれた場合の悪用期間を短くし、インフラ全体のセキュリティ機敏性を高める目的があります。Webサイトを運営する企業のIT担当者は、このスケジュールを踏まえた運用体制の見直しが必要です。

手動更新の限界とACMEプロトコルによる自動化

有効期間が47日になると、年7〜8回の更新作業が発生するため、従来の手動管理は現実的ではなくなります。今後は以下のような自動化対策が重要になります。

• ACMEプロトコル（証明書管理自動化プロトコル）の導入：証明書の発行・更新を自動化する標準プロトコル
• 証明書ライフサイクル管理（LCM）ツールの活用：複数の証明書を一元管理し、更新漏れを防ぐ
• 証明書発行・更新のAPI連携：既存のインフラ管理システムと連携した自動更新の仕組み構築

特に複数のドメインやサブドメインを運用している企業では、早めに自動化の仕組みを整えておくことをおすすめします。

証明書エラーが出る原因と対処法

証明書の有効期限切れ

サーバー証明書には有効期限があり、期限が切れるとブラウザが警告を表示します。証明書管理者は有効期限を把握し、期限前に更新する必要があります。自動更新の設定をしておくことで更新漏れを防げます。

信頼されていない認証局（オレオレ証明書）

「自己署名証明書（オレオレ証明書）」とは、第三者の認証局ではなく自分自身で署名した証明書のことです。信頼された認証局による署名ではないため、ブラウザは「この証明書は信頼できません」という警告を表示します。

主にローカル開発環境でのテスト用に使われますが、本番環境で使用するとユーザーに不信感を与えるため避けるべきです。

ドメイン名の不一致

証明書に記載されているドメイン名と、実際にアクセスしているURLのドメイン名が一致しない場合にエラーが発生します。サブドメインを追加した際に証明書を更新し忘れたケースなどで起こりやすいです。

証明書エラーを無視するとどうなる？

証明書エラーを無視して接続を続けると、通信自体は暗号化されますが「通信相手が本物である」という保証が失われます。この状態では中間者攻撃（攻撃者が通信の間に入り込み、情報を盗み見たり改ざんしたりする攻撃）が成立する可能性があります。

公共Wi-Fiなどのオープンなネットワーク経由でアクセスする際は特に注意が必要で、証明書エラーが表示された場合は安易に「詳細設定」から接続を続けず、サイトの信頼性を慎重に判断しましょう。

HTTPSなら安全とは限らない？よくある誤解

フィッシングサイトでも証明書は取得できる

「URLがhttpsだから安全なサイトのはず」という思い込みは危険です。認証局がDV証明書を発行する際に確認しているのは「そのドメインを操作できるか」という点だけで、サイトの内容が正規のものかどうかは審査されません。

そのため、正規サイトに似せたドメイン（例：login-example.comなど）を取得すれば、そのドメイン用の証明書は問題なく発行されます。結果としてURLがhttpsで鍵マークも表示される「安全そうな」フィッシングサイトが多数存在しています。

漫画でも見たように、SSL/TLSの有無は「通信が暗号化されているか」を示すものであり、サイト自体の信頼性まで保証するものではない点に注意が必要です。

鍵マークだけで安全と判断してはいけない理由

鍵マークが示しているのは「このサイトとの通信が暗号化されている」ことのみです。サイトの運営者が正規の企業であるかどうかまでは保証しません。

より高い信頼性を確認したい場合は、鍵マークをクリックして証明書の詳細情報（発行元・組織名）を確認することをおすすめします。特にOV証明書やEV証明書では組織名が明記されているため、運営元の実在性をより確実に判断できます。

SSL/TLSを導入するメリット・デメリット

メリット（セキュリティ強化・信頼性向上・SEO対策）

セキュリティの強化：通信の暗号化により盗聴・改ざん・なりすましのリスクを低減できます。

サイトの信頼性向上：鍵マークが表示されることでユーザーが安心して情報を入力できるようになり、コンバージョン率の向上にもつながります。

SEO対策としての効果：Googleは2014年にSSL/TLS対応を検索順位の判定要素として導入すると発表しました。未対応のサイトは相対的に不利になる可能性があります。全ページをHTTPS化する「常時SSL化」はSEO上の必須事項となっています。

常時SSL化を行う際に注意したいのが「混合コンテンツ（Mixed Content）」です。これはHTTPSページ内で画像やスクリプトなどのHTTPコンテンツを読み込んでしまう現象で、ブラウザの警告表示やセキュリティ低下の原因になります。解消するには、ブラウザのデベロッパーツールでエラー箇所を確認し、サイト内のリンクを絶対パスから相対パスに修正したうえで、すべてのリソースをHTTPS経由で取得できるよう変更しましょう。

デメリット（コスト・専門知識・通信速度）

導入・維持コスト：証明書の種類によっては年間数千円〜数十万円のコストがかかります。

専門知識が必要：サーバー設定やリダイレクト設定など、導入には一定の技術知識が求められます。

通信速度への影響：暗号化処理が加わる分、わずかに通信速度が低下する場合がありますが、近年の技術進歩によりほとんど気にならないレベルになっています。

SSL/TLSの確認方法

ブラウザで証明書情報を確認する方法

Chromeの場合、アドレスバーのURL左側の部分をクリックし「この接続は保護されています」を選択、続けて「証明書は有効です」をクリックすると証明書の詳細情報が表示されます。

サーバー証明書の発行元を確認する方法

証明書ビューワーには「発行元」として運営組織の情報が表示されます（OV・EV証明書の場合）。これにより、そのサイトが本当に正規の企業によって運営されているかを確認できます。DV証明書の場合は組織名が表示されないため、ドメイン名の正確性をより慎重に確認しましょう。

Qualys SSL Labsを使った自社サイトの設定診断

自社サイトのSSL/TLS設定が適切かどうかを確認したい場合は、無料診断ツール「Qualys SSL Labs」の「SSL Server Test」が便利です。サイトのURLを入力するだけで、対応しているプロトコルのバージョン・暗号スイートの優先順位・証明書チェーンの問題点・既知の脆弱性の有無などを総合的に診断し、A〜Fの評価で結果を表示してくれます。

特に法人サイトを運営している場合は、定期的にこのツールでチェックし、古いプロトコルが有効になっていないか、不正な中間証明書が混入していないかを確認することをおすすめします。

SSL/TLSの導入方法

CSR（証明書署名要求）の作成

CSR（Certificate Signing Request）とは、サーバー上で作成するSSLサーバー証明書発行用の申請書のようなものです。サーバーの公開鍵やドメイン情報などが含まれます。

証明書の申し込み・審査

認証局のWebサイトから希望する証明書を選んで申し込みます。DV証明書は自動審査で数分〜即日発行されますが、OV・EV証明書の場合は登記簿謄本や印鑑証明書などの追加書類が必要で、審査に数日〜数週間かかります。

サーバーへのインストール

発行された証明書をダウンロードし、サーバーにインストールします。多くのレンタルサーバーでは管理画面から簡単に設定できるケースも増えています。

SSL/TLSに関するよくある質問

無料のSSL証明書と有料の違いは？

無料のSSL証明書（Let’s Encryptなど）はDV認証のみで、ドメインの所有権確認だけを行います。一般的な個人サイトやブログには十分なセキュリティレベルです。有料の証明書はOV・EV認証が選べ、組織の実在性を証明できるため、企業サイトや金融機関・ECサイトなど高い信頼性が求められる場合に適しています。

SSL/TLSを導入すれば100％安全になる？

100％安全にはなりません。SSL/TLSは通信の暗号化となりすまし対策には有効ですが、フィッシングサイトでも証明書を取得できる点や、偽のWi-Fiスポット経由での通信傍受など、SSL/TLSだけでは防げないリスクも存在します。総合的なセキュリティ対策の一部として活用することが重要です。

自己署名証明書はなぜ警告が出るの？

自己署名証明書は信頼された第三者（認証局）ではなく、サーバー自身が自分の秘密鍵で署名した証明書だからです。ブラウザやOSが信頼している認証局のリストに含まれていないため、「この証明書の発行元を確認できません」という警告が表示されます。ローカル開発環境などで意図的に使用する場合は問題ありませんが、本番環境では正規の認証局から発行された証明書を使用しましょう。

メールやVPNでもSSL/TLSは必要？

必須です。Webサイトに限らず、メール（SMTP/IMAP通信）やVPN接続においても、盗聴を防ぐためにSSL/TLS（STARTTLSを含む）による暗号化を適用することが推奨されます。社内システムでメールサーバーやVPN機器を運用している場合は、これらの通信にも最新バージョンのプロトコルが使われているか確認しましょう。

証明書の有効期間短縮（200日・47日ルール）にどう備えればいい？

証明書の有効期間は2026年に最大200日、2029年には最大47日まで短縮される予定です。手動での更新作業は更新漏れのリスクが高まるため、ACMEプロトコルに対応した証明書管理ツールの導入や、証明書ライフサイクル管理（LCM）の仕組みを早めに整えることをおすすめします。

特に複数のドメインを運用している企業は、自動化なしでは運用が困難になる可能性があります。

まとめ

SSLは現在すべて廃止され、後継のTLSが実質的に使われていますが、慣習的に「SSL/TLS」と呼ばれています。通信の暗号化・改ざん防止・なりすまし防止という3つの役割を、公開鍵暗号方式と共通鍵暗号方式の組み合わせで実現しています。

ただし「HTTPSなら絶対安全」とは限らず、フィッシングサイトでも証明書を取得できる点には注意が必要です。証明書エラーが出た場合は安易に無視せず、有効期限や発行元を確認しましょう。

書籍「セキュリティ対策の基礎知識」
メルマガ登録でプレゼント！

セキュリティ対策で何をして良いかわからない
企業の情シス部門の方必見！

メルマガ登録はこちらから