SSLとは？TLS・HTTPSとの違い、証明書の仕組みと設定方法を徹底解説

2026年07月13日

ウェブサイトへアクセスしたとき、ブラウザーのアドレス欄に「https://」と表示されることがあります。この通信では、入力したパスワード、問い合わせ内容、氏名、住所、決済情報などが、第三者から簡単に読み取られないように保護されています。その仕組みを説明するとき、現在も一般的に使われている言葉がSSLです。

ただし、現在のウェブサイトで実際に利用されている通信方式は、厳密にはSSLではなく、その後継であるTLSです。SSL 3.0は安全性が不十分であるとして使用しないことが求められ、TLS 1.0とTLS 1.1も正式に非推奨となっています。現在のシステムでは、原則としてTLS 1.2またはTLS 1.3を使用します。

本記事では、SSLという言葉の意味から、暗号化、電子証明書、HTTPS、TLSとの違い、導入方法、設定例、更新管理、エラー対策まで詳しく解説します。専門的な技術を導入する担当者だけでなく、ウェブサイト運営者が外部の制作会社やサーバー会社と相談するときにも使える内容です。

1. SSLとは

SSLとは、ウェブブラウザーとウェブサーバーなど、ネットワーク上で通信する機器の間に暗号化された通信経路を作るために開発された通信方式です。正式名称はSecure Sockets Layerで、日本語では安全な通信層などと説明されます。

1.1 SSLが保護する通信

SSLは、利用者の端末から送信された情報を、そのまま読める平文ではなく、暗号化されたデータとして送るために使われていました。通信途中のネットワークを第三者が監視していたとしても、適切な暗号化が機能していれば、内容を簡単に理解することはできません。

ウェブサイトでは、ログイン情報、検索内容、問い合わせフォーム、個人情報、注文情報などが通信されます。SSLとその後継であるTLSは、この通信に対して機密性、完全性、通信相手の確認という複数の保護を提供します。TLS 1.3の仕様も、盗聴、改ざん、メッセージ偽造の防止を目的として定められています。

1.2 SSLという名称が残っている理由

現在のウェブ通信でSSLそのものは使われていませんが、「SSL証明書」「SSL化」「常時SSL」といった表現は広く残っています。サーバー会社や証明書発行会社も、一般利用者に分かりやすい名称としてSSLという言葉を継続して使用することがあります。

そのため、ウェブ制作の現場で「SSLを導入する」と言われた場合、通常は古いSSL方式を有効にすることではありません。TLSを利用してHTTPS通信を有効にし、電子証明書を設定する作業を意味します。

1.3 SSLで実現される暗号化

暗号化とは、一定の規則と鍵を使い、元の情報をそのままでは理解できない形式へ変換する処理です。通信を受信する正規の相手は、共有された通信鍵を使って暗号化されたデータを元へ戻します。

SSLやTLSでは、接続を開始するときに公開鍵暗号などを用いて安全に通信条件を決め、その後のデータ通信では処理速度の速い共通鍵暗号を利用します。複数の暗号技術を組み合わせることで、安全性と処理性能の両立を図っています。

1.4 SSLで確認できる通信相手

SSLやTLSでは、ウェブサーバーが提示する電子証明書を利用して、接続先が対象ドメインの正当な管理者であるかを確認します。ブラウザーは、証明書を発行した認証局、対象ドメイン、有効期限、電子署名などを検証します。

ただし、電子証明書が有効であることは、ウェブサイトの事業内容や商品が必ず安全であることを保証するものではありません。通信先ドメインとの接続が暗号化され、その証明書が技術的に信頼できることを示す仕組みです。

1.5 現在のSSLの正しい理解

現在「SSL」と呼ばれている仕組みの実体は、ほとんどの場合TLSです。SSL 2.0とSSL 3.0は利用すべきではなく、ウェブサーバーの設定でも無効にする必要があります。SSL 3.0については、RFC 7568により使用しないことが明確に要求されています。

したがって、現代のウェブサイト運営では「SSLを導入しているか」だけでなく、「安全なTLSの版を利用しているか」「証明書が正しく管理されているか」「暗号化されていない通信が残っていないか」を確認することが重要です。

2. SSLからTLSへ移行した歴史

SSLはインターネット初期の安全な通信に大きく貢献しましたが、複数の弱点が発見され、後継のTLSへ置き換えられました。現在の安全な通信設定を理解するには、名称だけでなく各版の位置付けを知る必要があります。

2.1 SSL 2.0の登場と問題

SSL 2.0は、ウェブ通信を暗号化する初期の仕組みとして公開されました。しかし、暗号方式の変更を検知する仕組みやメッセージの完全性確認などに問題があり、安全な通信方式として長期間利用できる設計ではありませんでした。

現在のウェブサーバーやブラウザーでSSL 2.0を有効にする必要はありません。古い機器との互換性を理由に残すと、攻撃者に弱い方式を選択させられる危険があるため、明示的に無効化します。

2.2 SSL 3.0の改良と廃止

SSL 3.0では、SSL 2.0に存在した複数の問題が改善され、その後のTLSの基礎となる設計が採用されました。しかし、暗号化処理の弱点を悪用する攻撃などが明らかになり、現代の安全基準を満たせなくなりました。

RFC 7568では、SSL 3.0は十分に安全ではないとして使用禁止が求められています。SSL 3.0にしか対応していない古い端末や業務システムがある場合は、設定で延命するのではなく、更新や置き換えを計画する必要があります。

2.3 TLS 1.0とTLS 1.1

TLS 1.0はSSL 3.0を基礎として標準化され、その後TLS 1.1が公開されました。これらは長年利用されましたが、古い暗号方式への依存、最新攻撃への耐性、現在の暗号設計との整合性などに問題があります。

TLS 1.0とTLS 1.1は、RFC 8996によって正式に非推奨となりました。古い方式を許可すると、利用者とサーバーがより弱い通信条件で接続する原因になるため、現在の公開ウェブサイトでは無効化することが原則です。

2.4 TLS 1.2の位置付け

TLS 1.2は、多くのウェブサーバー、ブラウザー、業務システムで広く利用されている通信方式です。適切な暗号方式を選択し、古い方式を無効化すれば、現在も安全な通信に利用できます。

ただし、TLS 1.2という版を有効にしただけで安全になるわけではありません。弱い暗号方式、古い署名方式、不適切な鍵交換方式などを残さず、現在の安全な利用推奨に基づいて設定する必要があります。

2.5 TLS 1.3の特徴

TLS 1.3は、通信開始時のやり取りを整理し、古く安全性に問題のある暗号方式を取り除いた新しい仕様です。TLS 1.2以前と比較して、接続開始に必要なやり取りを減らし、安全性と通信速度の改善を図っています。

TLS 1.3はRFC 8446で定義され、TLSを利用するクライアントとサーバー間の通信について、盗聴、改ざん、偽造を防ぐことを目的としています。対応環境ではTLS 1.3を優先し、互換性が必要な場合にTLS 1.2も許可する構成が一般的です。

通信方式現在の位置付けウェブサーバーでの対応
SSL 2.0使用不可無効化する
SSL 3.0使用禁止無効化する
TLS 1.0非推奨無効化する
TLS 1.1非推奨無効化する
TLS 1.2利用可能安全な暗号方式に限定する
TLS 1.3推奨される現行方式対応環境で有効化する

3. SSLが必要とされる理由

SSLまたはTLSによる暗号化は、会員サイトや通販サイトだけに必要なものではありません。情報を入力しない企業サイトでも、通信内容の改ざん、偽サイトへの誘導、管理画面の保護などを考えると、HTTPS化が必要です。

3.1 通信内容の盗聴を防ぐ

暗号化されていないHTTP通信では、利用者とウェブサーバーの間を流れる内容を、途中のネットワーク管理者や攻撃者に読み取られる可能性があります。公共の無線通信、共有ネットワーク、不正な中継機器などが危険の例です。

TLSを利用すると、通信内容は接続ごとに生成された鍵で暗号化されます。第三者が通信データを取得しても、適切な鍵を持たなければ、入力された内容を簡単に復元することはできません。

3.2 ウェブページの改ざんを検知する

暗号化されていない通信では、利用者へ届く途中でページ内容やプログラムが変更される可能性があります。広告の挿入、不正なプログラムの追加、ダウンロード先の変更などが行われても、利用者が気付けない場合があります。

TLSには、通信内容が途中で変更されていないことを確認する機能があります。受信側が完全性を確認できないデータは正規の通信として扱われないため、通信途中の不正な書き換えを防ぎやすくなります。

3.3 偽の接続先を見分ける

利用者が正しいURLを入力したつもりでも、名前解決やネットワーク経路が不正に変更され、偽のサーバーへ接続させられる可能性があります。電子証明書は、接続先のサーバーが対象ドメインに対応しているかを確認する材料になります。

ブラウザーは、証明書の対象名、発行元、電子署名、有効期限などを検証します。確認に失敗した場合は警告を表示し、利用者が安全でない接続を継続しないようにします。

3.4 ログイン情報を保護する

利用者名とパスワードを入力するページだけHTTPSにしても、その前後のページがHTTPであれば、セッション情報やページ遷移が保護されない場合があります。ログイン後の識別情報が盗まれると、攻撃者に利用者として操作される危険があります。

そのため、ログイン画面だけを部分的に暗号化するのではなく、サイト全体をHTTPSへ統一する常時SSLが必要です。画像、プログラム、スタイルシート、外部通信を含め、ページ内のすべての接続を確認します。

3.5 利用者からの信頼を維持する

HTTPSに対応していないウェブサイトでは、ブラウザーが安全でない通信であることを表示する場合があります。問い合わせや購入を検討している利用者が警告を見れば、入力を中止したり、企業の安全管理に不安を感じたりする可能性があります。

ただし、アドレス欄に鍵の表示があるだけで、ウェブサイト自体の事業内容が保証されるわけではありません。運営者はHTTPSと合わせて、正確な企業情報、プライバシー方針、問い合わせ先、適切な情報管理を整備する必要があります。

4. SSL通信を支える3つの役割

SSLやTLSは、単にデータを読めなくするだけの仕組みではありません。安全な通信を成立させるため、機密性、完全性、認証という3つの役割を組み合わせています。

4.1 機密性による盗聴対策

機密性とは、通信内容を許可された相手だけが読める状態にすることです。TLSでは、接続時に決定された通信鍵を利用し、ウェブページ、入力情報、応答内容などを暗号化します。

通信鍵は接続ごとに作られ、別の通信へそのまま流用されないように設計されます。そのため、一つの通信に関する情報が漏れた場合でも、すべての過去通信が直ちに読める状態にならない構成が重要です。

4.2 完全性による改ざん対策

完全性とは、送信された情報が途中で不正に変更されていないことを確認できる性質です。TLSでは、暗号学的な検証情報を通信データへ加え、受信側で内容の一致を確認します。

攻撃者が通信内容の一部を書き換えた場合、検証結果が一致しなくなります。受信側はその通信を正しいデータとして処理せず、接続を終了するなどの対応を取ります。

4.3 認証による接続先確認

認証とは、通信相手が想定した相手であることを確認する仕組みです。一般的なHTTPSでは、ウェブサーバーが電子証明書を提示し、ブラウザーが証明書の信頼性とドメイン名を検証します。

通常のウェブサイトではサーバー側を確認しますが、企業間通信や管理システムでは、利用者側にも証明書を持たせる相互認証を使用することがあります。相互認証では、サーバーとクライアントの双方が証明書を提示します。

4.4 暗号方式の合意

ブラウザーとサーバーは、接続を始める際に、対応しているTLSの版や暗号方式などの情報を交換します。その中から双方が利用でき、サーバー方針に適合する組み合わせを選択します。

サーバー側が古い方式を許可していると、古い端末との接続は維持できますが、安全性が低下する場合があります。対応利用者の状況を確認しながら、安全性を優先した通信方式に限定する必要があります。

4.5 セッション鍵によるデータ通信

公開鍵暗号は、通信相手の確認や鍵交換に適していますが、大量データの暗号化には計算負荷が高くなる場合があります。そのため、TLSでは通信開始時に安全な方法で共通のセッション鍵を作ります。

実際のウェブページや入力情報は、そのセッション鍵を使った共通鍵暗号で処理されます。これにより、安全な鍵交換と高速なデータ通信の両方を実現します。

5. SSL証明書とは

一般にSSL証明書と呼ばれるものは、ウェブサーバーの身元確認と公開鍵の配布に利用される電子証明書です。現在はTLSで利用されるため、TLS証明書またはサーバー証明書と呼ぶ方が技術的には正確です。

5.1 SSL証明書に含まれる情報

電子証明書には、証明書の対象となるドメイン名、公開鍵、発行した認証局、有効期間、電子署名、証明書番号などが含まれます。ブラウザーはこれらの情報を使って接続先を検証します。

証明書に秘密鍵そのものは含まれません。秘密鍵はウェブサーバー側で厳重に管理し、第三者へ渡らないようにします。秘密鍵が漏えいした場合は、証明書の失効と再発行が必要です。

5.2 公開鍵と秘密鍵

公開鍵は、電子証明書を通じて利用者へ提示できる鍵です。一方の秘密鍵は、サーバー運営者だけが保持します。二つの鍵には数学的な関係がありますが、公開鍵から秘密鍵を現実的な時間で求めることが困難になるよう設計されています。

秘密鍵は、サーバーが正当な証明書所有者であることを示す処理に使われます。証明書ファイルだけを他のサーバーへコピーしても、対応する秘密鍵がなければ正しいTLS通信を成立させることはできません。

5.3 認証局の役割

認証局は、申請者が対象ドメインを管理していることなどを確認し、電子署名を付けた証明書を発行します。主要なブラウザーや基本ソフトには、信頼する認証局の情報があらかじめ登録されています。

ブラウザーは、サーバー証明書から中間認証局、最上位認証局までの信頼経路を確認します。経路が正しく構成されていない場合、証明書自体が有効でも警告が表示されることがあります。

5.4 有効期限が必要な理由

電子証明書には有効期限があります。有効期限を設けることで、古い暗号鍵や、管理状況が確認されていない証明書が長期間利用され続ける危険を抑えます。

証明書の期限が切れると、ブラウザーは安全な接続として検証できず、利用者へ警告を表示します。証明書管理では、取得作業よりも、期限前の自動更新と更新失敗の監視が重要です。NISTも、証明書と対応する秘密鍵を組織的に管理する必要性を示しています。

5.5 証明書の信頼経路

サーバー証明書は、通常、中間認証局の証明書を通じて最上位認証局へつながります。ウェブサーバーは、利用者の端末が正しく経路を確認できるよう、必要な中間証明書も提示します。

中間証明書の設定が不足していると、一部のブラウザーでは表示できても、別の端末やアプリケーションでは検証に失敗する場合があります。導入後は複数の端末や検査手段で証明書経路を確認します。

6. SSL証明書の種類

SSL証明書は、保護するドメインの範囲や確認方法によって分類できます。価格だけで選ぶのではなく、サイト構成、利用目的、運営主体の表示方法に適した証明書を選択します。

6.1 単一ドメイン証明書

単一ドメイン証明書は、一つの指定されたドメインを保護するための証明書です。例えば「www.example.jp」を対象に発行した場合、設定内容によっては「example.jp」や他の副ドメインが対象に含まれないことがあります。

申請前に、利用者がアクセスするすべてのホスト名を確認します。「www」の有無を両方利用する場合は、両方を証明書へ含めるか、一方へ転送する設計にします。

6.2 ワイルドカード証明書

ワイルドカード証明書は、「*.example.jp」のように、一階層下の複数の副ドメインを保護できます。サービスごとに副ドメインを追加する環境では、証明書管理をまとめられる利点があります。

一方で、同じ秘密鍵を多数のサーバーへ配布すると、一台の侵害が広範囲へ影響する可能性があります。利用範囲、秘密鍵の保管、更新方法を確認し、利便性だけで選択しないことが重要です。

6.3 複数ドメイン証明書

複数ドメイン証明書は、一枚の証明書に複数の異なるドメイン名を登録できます。企業サイト、会員サイト、関連サービスなど、複数のホスト名をまとめて管理したい場合に利用されます。

証明書を表示すると、登録されている他のドメイン名も確認できる場合があります。公開したくない内部的な名称や、互いに関係を知られたくないサービスを一枚へまとめないよう注意します。

6.4 無料証明書

無料の認証局を利用すると、費用を支払わずにドメイン確認型の証明書を取得できます。自動取得と自動更新の仕組みを構築しやすく、小規模サイトから大規模サービスまで利用できます。

無料であることは、暗号化の強度が低いことを意味しません。ただし、導入支援、損害補償、組織確認、問い合わせ対応などは提供事業者によって異なるため、必要な運用支援を確認します。

6.5 有料証明書

有料証明書では、組織確認を伴う商品、導入支援、管理画面、企業向け契約、再発行支援などが提供される場合があります。複数部門で大量の証明書を管理する企業では、管理機能が選定理由になることがあります。

有料証明書を導入しただけで、無料証明書より必ず安全になるわけではありません。安全性は、秘密鍵の管理、TLS設定、更新監視、サーバーの脆弱性対策を含めて判断します。

証明書の種類対象範囲適している利用例
単一ドメイン証明書一つのドメイン企業サイト、商品サイト
ワイルドカード証明書一階層下の複数副ドメイン多数の副ドメインを持つサービス
複数ドメイン証明書複数の異なるドメイン複数サイトの一括管理
無料証明書商品条件による一般サイト、自動更新環境
有料証明書商品条件による組織確認や運用支援が必要な企業

7. SSLとTLSの違い

SSLとTLSは、安全な通信を実現するという目的が似ているため、同じ意味として使われることがあります。しかし、技術上は異なる世代の通信方式であり、現在利用すべきなのはTLSです。

7.1 名称の違い

SSLはSecure Sockets Layerの略称で、初期の暗号化通信方式を指します。TLSはTransport Layer Securityの略称で、SSLの設計を引き継ぎながら標準化と改良が行われた後継方式です。

現在でも「SSL証明書」という商品名が使われていますが、証明書がSSL専用という意味ではありません。実際には、TLS通信に利用する電子証明書として設定されます。

7.2 安全性の違い

SSL 2.0とSSL 3.0には、現在の攻撃手法に対して十分な安全性がありません。特にSSL 3.0は、公式な技術文書において利用しないことが求められています。

TLSもすべての版が安全というわけではなく、TLS 1.0とTLS 1.1は非推奨です。通信方式の名称だけでなく、利用している版と暗号方式を確認する必要があります。

7.3 通信処理の違い

TLSは、SSLの設計を基礎としながら、鍵の生成、完全性確認、暗号方式の選択などを改善しています。特にTLS 1.3では、古い暗号方式や不要になった処理が削除されました。

TLS 1.3では、接続開始時の通信回数も削減されています。これにより、安全性だけでなく、利用者がページへアクセスしてから通信を開始するまでの待ち時間も改善できます。

7.4 現場での呼び方

ウェブ制作会社やレンタルサーバー会社が「SSL対応」と表現している場合でも、通常はTLSによるHTTPS対応を意味します。この呼び方は一般利用者へ定着しているため、直ちに誤りとして扱う必要はありません。

技術仕様書や安全設定では、SSLとTLSを区別して記載することが重要です。「SSLを許可する」という曖昧な表現ではなく、「TLS 1.2とTLS 1.3を許可し、それ以前を無効化する」と具体的に記載します。

7.5 導入時に確認すべき違い

証明書発行サービスを比較するときは、「SSL対応」という表示だけで判断せず、利用できるTLSの版、対応暗号方式、自動更新、秘密鍵の保管方法を確認します。

サーバーや負荷分散装置、配信サービスを組み合わせている場合は、それぞれの区間で設定が異なることがあります。利用者から配信サービスまでTLS 1.3でも、配信サービスから元サーバーまで古い方式という構成を残さないよう確認します。

比較項目SSLTLS
世代初期の通信方式SSLの後継方式
現在の利用使用しないTLS 1.2または1.3を利用
安全性現在の基準を満たさない適切な版と設定で安全性を確保
一般的な呼称証明書や暗号化の通称として残る現在の正式な通信方式
サーバー設定無効化する安全な版だけを有効化する

8. SSLとHTTPSの違い

SSLとHTTPSも同じ意味として使われることがありますが、役割が異なります。SSLやTLSは通信を保護する仕組みであり、HTTPSはHTTPをTLSで保護して利用する通信方法です。

8.1 HTTPの役割

HTTPは、ブラウザーがウェブサーバーへページや画像などを要求し、サーバーが応答するための通信規則です。ウェブ上の文書、画像、プログラム、外部接続などを取得する基礎になります。

HTTP自体には、通信内容を暗号化する仕組みがありません。そのため、通常のHTTP通信だけでは、途中の第三者による盗聴や改ざんから内容を十分に保護できません。

8.2 HTTPSの役割

HTTPSは、HTTP通信をTLSによって保護したものです。ブラウザーは最初にTLSによる安全な接続を確立し、その暗号化された経路の中でHTTPの要求と応答を送受信します。

現在のHTTPSではTLSが利用されますが、歴史的な呼び方として「SSL通信」と説明されることがあります。MDNもHTTPSを、TLSを利用してクライアントとサーバー間の通信を暗号化するHTTPとして説明しています。

8.3 URL表示の違い

HTTPサイトのURLは「http://」から始まり、HTTPSサイトは「https://」から始まります。HTTPSの末尾に追加される「s」は、安全に保護された通信であることを表しています。

ただし、URLを書き換えるだけではHTTPSになりません。ウェブサーバーに証明書と秘密鍵を設定し、TLS通信を受け付ける設定を行う必要があります。

8.4 通信番号の違い

一般的にHTTPは80番、HTTPSは443番の通信番号を利用します。利用者が通信番号を明示しない場合、ブラウザーは通信方式に応じた既定値を使用します。

実際のクラウドや社内システムでは、負荷分散装置や中継サーバーでTLS通信を終了し、内部では別の通信番号を使うことがあります。外部だけでなく、内部区間の暗号化要件も確認します。

8.5 HTTPS化の意味

HTTPS化とは、電子証明書を設定し、サイトへの接続をHTTPからHTTPSへ移行することです。現在は一部ページだけでなく、サイト全体をHTTPS化する常時SSLが一般的です。

移行時には、画像やプログラムのURL、外部連携先、転送設定、検索エンジン向けの正規URL、サイトマップなども更新します。証明書を設定しただけでは移行は完了しません。

比較項目HTTPHTTPS
通信の暗号化なしTLSで暗号化
通信相手の確認なし電子証明書で確認
改ざん検知十分な仕組みなしTLSで確認
一般的な通信番号80443
利用すべき場面HTTPSへの転送用など原則としてウェブサイト全体

9. TLSハンドシェイクの仕組み

ブラウザーとウェブサーバーが暗号化通信を開始する前には、利用する通信方式、暗号方式、証明書、通信鍵などを決める処理が行われます。この一連の処理をTLSハンドシェイクと呼びます。

9.1 接続要求の送信

ブラウザーは、対応しているTLSの版、暗号方式、拡張機能、無作為な値などを含む接続要求をサーバーへ送ります。サーバーはその情報を確認し、利用可能な通信条件を選択します。

サーバーがTLS 1.2とTLS 1.3に対応し、ブラウザーもTLS 1.3を利用できる場合は、通常TLS 1.3が選ばれます。互換性がない場合は、双方が対応する安全な方式へ調整されます。

9.2 サーバーからの応答

サーバーは、選択したTLSの版、暗号方式、接続に必要な情報などをブラウザーへ返します。また、サーバーの身元を示す電子証明書も提示します。

TLS 1.3では、以前の版より接続開始時のやり取りが整理されています。不要な通信を減らすことで、暗号化通信を開始するまでの遅延を小さくしています。

9.3 証明書の検証

ブラウザーは、証明書に記載されたドメイン名がアクセス先と一致するか、有効期限内か、信頼できる認証局が署名しているかを確認します。必要な中間証明書がそろっているかも確認対象です。

検証に失敗した場合、ブラウザーは証明書エラーを表示します。利用者が警告を無視して接続すると、偽のサーバーや不正な中継者へ情報を送る危険があります。

9.4 通信鍵の生成

証明書の確認後、ブラウザーとサーバーは、その接続で使用する通信鍵を安全に作ります。TLS 1.3では、将来サーバーの秘密鍵が漏えいした場合でも、過去通信の復号を困難にする鍵交換方式が中心となっています。

作られた鍵は、実際のページデータや入力情報を暗号化するために利用されます。通信が終了すれば、その接続用の鍵は継続利用されません。

9.5 暗号化通信の開始

双方が同じ通信鍵を持ち、接続条件の確認が完了すると、HTTPSによるデータ通信が始まります。ブラウザーはページを要求し、サーバーは暗号化された応答を返します。

接続中は、データの暗号化だけでなく、改ざんされていないことも確認されます。通信の検証に失敗した場合は、安全性を維持するため接続が終了します。

10. SSL証明書を導入する手順

SSL証明書の導入は、証明書を購入してサーバーへ置くだけの作業ではありません。対象ドメインの確認、秘密鍵の生成、サーバー設定、転送、更新監視までを一つの運用として設計します。

10.1 対象ドメインを整理する

最初に、HTTPS化するドメインと副ドメインを一覧化します。「www」の有無、会員サイト、問い合わせサイト、管理画面、外部公開用の接続先などを確認します。

古いドメインや一時的な検証環境を含めると、更新対象が増えます。一方で必要なドメインを漏らすと、一部ページで証明書エラーが発生するため、アクセス経路を確認して整理します。

10.2 秘密鍵と証明書署名要求を作る

有料証明書などを申請する場合は、サーバー側で秘密鍵と証明書署名要求を作成します。証明書署名要求には、公開鍵や申請対象名などが含まれ、認証局へ提出します。

秘密鍵は認証局へ送信しません。秘密鍵を電子メールや一般的な共有場所で受け渡さず、アクセス権を制限した安全な場所へ保存します。

OpenSSLによる作成例

openssl req \  -new \  -newkey rsa:2048 \  -nodes \  -keyout example.jp.key \  -out example.jp.csr

この例では秘密鍵を暗号化せずに保存するため、ファイル権限や保管場所を厳格に管理する必要があります。環境の安全要件に応じて、鍵管理サービスや専用機器の利用も検討します。

10.3 ドメインの管理権限を確認する

認証局は、申請者が対象ドメインを管理していることを確認します。確認方法には、指定された内容を名前解決情報へ追加する方法、ウェブサーバーへ確認用ファイルを置く方法などがあります。

自動更新を利用する場合は、更新のたびに確認処理が自動実行できる構成にします。手動作業に依存すると、担当者の不在や引き継ぎ漏れにより期限切れが発生しやすくなります。

10.4 証明書をサーバーへ設定する

発行されたサーバー証明書、必要な中間証明書、対応する秘密鍵をウェブサーバーへ設定します。証明書と秘密鍵の組み合わせが一致しなければ、サーバーは正常に起動できない場合があります。

設定後は構文確認を行い、問題がなければウェブサーバーを再読み込みします。再起動による停止を避けるため、製品が対応していれば設定の再読み込みを利用します。

10.5 HTTPSへの転送を設定する

HTTPでアクセスした利用者をHTTPSへ自動的に移動させます。転送先では、パス、検索条件、必要な識別情報が失われないように設定します。

転送が複数段階になると、表示速度や検索エンジンの処理へ影響する場合があります。「http://example.jp」から最終URLまで、一回の転送で到達できる構成を目指します。

11. ウェブサーバーのSSL設定例

ウェブサーバーでは、証明書ファイル、秘密鍵、TLSの版、HTTPからHTTPSへの転送などを設定します。以下のコードは一般的な構成例であり、利用する基本ソフトやサーバー構成に合わせた検証が必要です。

11.1 NginxでHTTPSを有効にする

Nginxでは、443番で暗号化通信を待ち受け、証明書と秘密鍵の場所を指定します。TLS 1.2とTLS 1.3だけを許可することで、SSLや古いTLSによる接続を防ぎます。

設定変更後は、構文確認を実施してから再読み込みします。証明書の読み込み権限、秘密鍵のファイル権限、中間証明書の設定も確認します。

Nginxの設定例

server {    listen 443 ssl;    listen [::]:443 ssl;    server_name example.jp www.example.jp;    ssl_certificate     /etc/nginx/tls/fullchain.pem;    ssl_certificate_key /etc/nginx/tls/privkey.pem;    ssl_protocols TLSv1.2 TLSv1.3;    ssl_session_timeout 1d;    ssl_session_cache shared:SSL:10m;    ssl_session_tickets off;    root /var/www/example;    index index.html; }

11.2 NginxでHTTPSへ転送する

80番で受け付けたHTTP通信は、HTTPSの正規URLへ転送します。サイトの正規ドメインを一つに決め、「www」の有無も同時に統一すると、不要な転送を減らせます。

利用者から受け取ったHostヘッダーを無条件に転送先へ使うと、構成によっては不正な転送先を作られる危険があります。固定した正規ドメインを指定する方法が安全です。

転送設定例

server {    listen 80;    listen [::]:80;    server_name example.jp www.example.jp;    return 301 https://example.jp$request_uri; }

11.3 ApacheでHTTPSを有効にする

Apacheでは、暗号化通信機能を有効にし、仮想ホストへ証明書と秘密鍵を設定します。利用している版や配布方法によって設定ファイルの場所が異なります。

中間証明書を含む証明書一式を適切に指定し、古い通信方式を無効化します。設定変更後は、構文確認を行ってから安全に反映します。

Apacheの設定例

<VirtualHost *:443>    ServerName example.jp    ServerAlias www.example.jp    DocumentRoot /var/www/example    SSLEngine on    SSLCertificateFile /etc/apache2/tls/fullchain.pem    SSLCertificateKeyFile /etc/apache2/tls/privkey.pem    SSLProtocol -all +TLSv1.2 +TLSv1.3 </VirtualHost>

11.4 HSTSを設定する

HSTSは、対応ブラウザーへ「今後このサイトにはHTTPSだけで接続する」と通知する仕組みです。HTTPで入力された場合でも、保存された方針に従ってHTTPS接続を優先します。RFC 6797で応答ヘッダーとして定義されています。

ただし、長期間の設定やすべての副ドメインへの適用を行った後でHTTPSを停止すると、利用者がサイトへ接続できなくなる場合があります。最初は短い期間で試験し、問題がないことを確認してから延長します。

HSTSの設定例

add_header Strict-Transport-Security    "max-age=31536000; includeSubDomains"    always;

11.5 設定を反映する前に検査する

Nginxでは「nginx -t」、Apacheでは「apachectl configtest」などを使って、設定ファイルの構文を確認できます。構文エラーがある状態で再起動すると、ウェブサイトが停止する可能性があります。

構文が正しくても、証明書の対象名、信頼経路、秘密鍵との一致までは確認できない場合があります。反映後はブラウザーだけでなく、外部検査やコマンドでも確認します。

構文確認例

sudo nginx -t sudo systemctl reload nginx sudo apachectl configtest sudo systemctl reload apache2

12. アプリケーションのSSL設定例

ウェブサーバーだけでなく、アプリケーションが直接HTTPSを受け付ける構成もあります。また、外部サービスへ接続するアプリケーションでは、相手側の証明書を正しく検証する必要があります。

12.1 Node.jsでHTTPSサーバーを作る

Node.jsでは、秘密鍵と証明書を読み込み、HTTPSサーバーを起動できます。開発環境では自己署名証明書を使うことがありますが、公開サービスでは信頼される認証局の証明書を利用します。

秘密鍵の読み取り権限を必要最小限にし、ソースコード管理へ登録しないようにします。証明書や鍵の場所は、環境変数や安全な設定管理から取得する方法を検討します。

Node.jsの実装例

import fs from "node:fs"; import https from "node:https"; const options = {  key: fs.readFileSync("/etc/tls/privkey.pem"),  cert: fs.readFileSync("/etc/tls/fullchain.pem"),  minVersion: "TLSv1.2", }; const server = https.createServer(options, (request, response) => {  response.writeHead(200, {    "Content-Type": "text/plain; charset=utf-8",  });  response.end("安全なHTTPS接続です。\n"); }); server.listen(443);

12.2 Pythonで証明書を検証する

Pythonから外部のHTTPSサービスへ接続する場合、利用する通信ライブラリは通常、接続先の証明書を検証します。検証を無効化すると、偽のサーバーへ接続しても気付けない危険があります。

開発中に証明書エラーを避ける目的で、検証を無効にした設定を本番へ残さないようにします。社内認証局を利用する場合は、正しい認証局証明書を信頼先として設定します。

Pythonの接続例

import requests response = requests.get(    "https://example.jp/api/status",    timeout=10, ) response.raise_for_status() print(response.json())

12.3 証明書検証を無効化しない

「証明書エラーが出るから」という理由で、検証を無効化するコードを追加すると、TLSの接続先確認機能が失われます。通信が暗号化されて見えても、攻撃者のサーバーと暗号化している可能性があります。

エラーが発生した場合は、中間証明書不足、期限切れ、対象名の不一致、端末時刻、社内中継装置などの原因を調査します。検証無効化は解決策ではありません。

避けるべき設定例

import requests # 本番環境では使用しない response = requests.get(    "https://example.jp",    verify=False, )

12.4 接続時間を制限する

HTTPS接続でも、相手が応答しない場合に無期限で待機すると、アプリケーション資源が消費されます。接続開始と応答待ちに適切な制限時間を設定します。

証明書検証や名前解決を含め、外部サービスとの接続は失敗する前提で設計します。再試行回数、待機時間、障害時の代替処理を決め、過剰な再接続で相手側へ負荷をかけないようにします。

接続時間を分ける例

import requests response = requests.get(    "https://example.jp/api/status",    timeout=(3.05, 10), ) response.raise_for_status()

12.5 相互TLS認証を利用する

相互TLS認証では、サーバーだけでなくクライアントも電子証明書を提示します。企業間の接続、管理用接続、機器認証など、接続元を強く限定したい環境で利用されます。

クライアント証明書を配布した後は、更新、失効、端末紛失、担当者退職への対応が必要です。パスワードの代わりに証明書を使えば管理が不要になるわけではありません。

curlによる相互認証例

curl \  --cert client-cert.pem \  --key client-key.pem \  --cacert company-ca.pem \  https://api.example.jp/status

13. 安全なSSL設定のポイント

HTTPSを有効にしても、古い通信方式や弱い設定が残っていれば十分な安全性は得られません。通信方式、秘密鍵、証明書、応答ヘッダー、外部資源まで含めて確認します。

13.1 古い通信方式を無効化する

SSL 2.0、SSL 3.0、TLS 1.0、TLS 1.1を無効にし、原則としてTLS 1.2とTLS 1.3だけを許可します。古い利用者への互換性を維持する場合も、安全性への影響を評価する必要があります。

特に古い業務端末がある場合は、公開サイト全体の設定を弱めるのではなく、接続元を限定した専用環境への分離や端末更新を検討します。SSL 3.0と古いTLSは公式に廃止または非推奨とされています。

13.2 弱い暗号方式を許可しない

TLS 1.2では、複数の暗号方式から利用するものを設定できます。古い暗号、短い鍵、既知の攻撃に弱い方式などを許可すると、安全な版を使っていても通信が弱くなる場合があります。

独自に暗号方式一覧を作るより、利用するウェブサーバーや信頼できる安全指針の推奨設定を参考にします。定期的に推奨内容を確認し、古くなった設定を更新します。RFC 9325はTLSを安全に利用するための現行推奨をまとめています。

13.3 秘密鍵を保護する

秘密鍵を読み取れる利用者や処理を必要最小限に制限します。一般利用者がアクセスできる公開フォルダー、ソースコード管理、共有ストレージなどへ保存してはいけません。

秘密鍵のバックアップも暗号化し、利用記録を残します。鍵の漏えいが疑われる場合は、新しい鍵と証明書を発行し、古い証明書を失効させます。

13.4 混在コンテンツを解消する

HTTPSページの中でHTTPの画像、プログラム、スタイルシートなどを読み込む状態を混在コンテンツと呼びます。ページ本体がHTTPSでも、HTTPで読み込む資源が改ざんされる危険があります。

ブラウザーは一部のHTTP資源をHTTPSへ自動的に変更し、危険な資源を遮断する場合があります。しかしブラウザーの処理に依存せず、サイト内のURLをすべてHTTPSへ修正する必要があります。

13.5 HSTSを段階的に導入する

HSTSを設定すると、対応ブラウザーは対象期間中、そのドメインへHTTPSだけで接続します。利用者が誤ってHTTPのURLを入力した場合や、HTTPリンクを開いた場合の通信低下を防ぎます。

一方で、証明書更新やHTTPS設定に失敗すると、利用者がHTTPへ戻ってアクセスすることもできません。短い有効期間から始め、すべての副ドメインを含める前に対象環境を確認します。

14. SSLエラーの原因と対処法

SSLエラーは、証明書の期限切れだけで発生するものではありません。ドメイン名、中間証明書、端末時刻、秘密鍵、通信方式、名前解決など、複数の原因を順番に確認します。

14.1 証明書の期限切れ

証明書の有効期限が切れると、ブラウザーは接続先の正当性を現在の情報として確認できません。自動更新を設定していても、確認用通信の失敗や設定変更により更新されない場合があります。

期限切れを防ぐため、証明書自体の期限だけでなく、自動更新処理の成功を監視します。更新後にウェブサーバーが新しい証明書を読み込んだかも確認します。

14.2 ドメイン名の不一致

アクセスしたドメイン名が証明書の対象に含まれていない場合、名称不一致のエラーが発生します。「www」の有無、別の副ドメイン、内部名、古いドメインなどが原因になります。

転送前のドメインにもHTTPSでアクセスされる場合、そのドメインに対応する証明書が必要です。証明書エラーが発生してから別ドメインへ転送しても、利用者は転送先へ到達できない場合があります。

14.3 中間証明書の不足

サーバー証明書だけを設定し、中間認証局の証明書を提示していない場合、信頼経路を構築できない端末でエラーが発生します。管理者のブラウザーでは表示できても、別環境では失敗することがあります。

認証局から提供された証明書一式を確認し、完全な証明書連鎖をウェブサーバーへ設定します。導入後は、複数のブラウザーや外部検査で経路を確認します。

14.4 端末時刻のずれ

証明書の有効期間は日時で判定されるため、利用者端末やサーバーの時計が大きくずれていると、まだ有効でない証明書や期限切れ証明書として扱われる場合があります。

一台の端末だけでエラーが発生する場合は、端末時刻と時間帯設定を確認します。サーバー側でも信頼できる時刻同期を利用し、監視ログの時刻を正確に保ちます。

14.5 対応方式の不一致

サーバーがTLS 1.3だけを許可し、利用者端末がTLS 1.2までしか対応していない場合など、双方で利用可能な方式が一致しなければ接続できません。暗号方式の組み合わせが一致しない場合も同様です。

安全性を下げて古い方式を無制限に許可する前に、影響を受ける端末や業務を特定します。端末更新、専用環境、接続経路の分離など、安全性を維持できる方法を検討します。

エラーの状態主な原因主な対処
期限に関する警告証明書期限切れ、端末時刻のずれ更新状況と時刻を確認
名前に関する警告ドメイン名の不一致対象名を含む証明書を発行
発行元に関する警告中間証明書不足、未信頼の認証局証明書連鎖を修正
接続方式エラー対応するTLSや暗号方式がないクライアントとサーバー設定を確認
一部資源が表示されないHTTP資源の混在資源URLをHTTPSへ変更

15. SSLを継続的に運用する方法

SSL対応は、証明書を初回設定した時点で完了する作業ではありません。証明書の更新、秘密鍵の管理、設定の見直し、障害監視、担当者の引き継ぎを継続する必要があります。

15.1 証明書更新を自動化する

短い有効期間の証明書を手動で更新すると、作業忘れによる期限切れが発生しやすくなります。自動更新に対応した証明書と取得ソフトを利用し、定期処理として更新します。

Certbotは証明書の取得とウェブサーバーへの設定を支援するソフトで、ApacheやNginxと連携できます。ただし、導入方法は基本ソフトや配布方法によって異なるため、公式文書に従って設定します。

Certbotの実行例

sudo certbot --nginx \  -d example.jp \  -d www.example.jp

15.2 自動更新を試験する

自動更新の設定が存在していても、実際に成功するとは限りません。通信番号の閉鎖、名前解決の変更、確認用ファイルへのアクセス制限などにより失敗することがあります。

定期的に更新試験を行い、更新後の再読み込みまで確認します。更新処理の終了状態とログを監視し、失敗時に担当者へ通知します。

更新試験例

sudo certbot renew --dry-run

15.3 証明書一覧を管理する

企業内で複数のサイトやシステムを運用している場合、証明書の対象名、発行元、有効期限、設置先、管理者、自動更新方法を一覧化します。

一覧だけを表計算ファイルで管理すると、実際の環境とのずれが生じる場合があります。サーバーやクラウド環境から証明書情報を自動収集し、未登録の証明書を発見できる仕組みが効果的です。

15.4 TLS設定を定期的に見直す

現在安全とされる暗号方式でも、将来新しい攻撃や計算能力の変化によって推奨されなくなる可能性があります。証明書更新だけでなく、TLSの版と暗号方式も定期的に見直します。

ウェブサーバー、負荷分散装置、配信サービス、外部接続先など、TLSを終了するすべての場所を確認します。一つの機器だけ古い設定が残らないようにします。

15.5 障害対応手順を準備する

証明書期限切れ、秘密鍵漏えい、認証局障害、設定誤りなどが発生した場合の連絡先と復旧手順を用意します。緊急時に必要な管理権限や認証局アカウントへアクセスできる担当者も決めます。

秘密鍵の漏えい時には、単に証明書を再設置するだけでは不十分です。新しい秘密鍵を生成し、新しい証明書を取得し、古い証明書を失効させ、漏えい原因を調査します。

おわりに

SSLとは、インターネット上の通信を暗号化し、盗聴や改ざんを防ぐために開発された通信方式です。ただし、SSL 2.0とSSL 3.0は現在使用できず、実際のウェブサイトでは後継のTLSが利用されています。現代の「SSL化」は、TLSを使ってHTTPS通信を有効にすることを意味します。

安全なHTTPSを実現するには、電子証明書を設定するだけでは不十分です。TLS 1.2とTLS 1.3だけを有効にし、古い通信方式を無効化し、秘密鍵を保護し、混在コンテンツを解消し、証明書更新を監視する必要があります。

ウェブサイトの安全性は、一度の設定作業では維持できません。証明書、サーバー、アプリケーション、外部サービスを継続的に確認し、安全な設定へ更新することで、利用者が安心してアクセスできる通信環境を維持できます。

LINE Chat