本記事は広告が含まれる場合がありますホームページの作り方

【SSLとは】SSLの意味と必要性および仕組みや種類を解説

2022年3月10日

Webサイトを立ち上げる際、または運用していく中で、「SSL」という言葉を聞いたことある方も多いかと思います。

SSLとは、インターネット上のデータを暗号化して送受信する仕組みで、現在Webサイトを運営している場合は、SSL化しておくことが推奨されています。

この記事では、SSLと何か意味や必要性などの概要を前半で説明して、後半ではより技術的なSSL通信の仕組みや「サーバー証明書」「SSLの認証方式」などについて深掘りして解説していきます。

この記事でわかること

SSLとは何か、SSLの必要性
SSLの通信の仕組み
SSL実装のためにサーバーで行う必要がある作業
サーバー証明書の種類・認証方式の違い

SSLとは。SSLの概要と必要性

SSLとは通信データを暗号化して安全に通信する仕組み

「SSL（Secure Sockets Layer）」とは、インターネット上でやり取りする通信データを暗号化して送受信する仕組みを指します。

http通信をSSL化(HTTPS)をすることで、通信データを保護し、クレジットカードのような他人に知られると悪用される重要な情報を守ります。

項目	SSL化されていないURL	SSL化されているURL
プロトコル	http://example.com/	https:://example.com/
セキュリティ	低	高
アドレスバーの表示	保護されていない通信	鍵マーク

SSL化している場合

SSL化していないプロトコル「http://...」通信に対して、SSL化するとURLも「https://..」に変わります。

Webブラウザ上でも、WebサイトをSSL化すると、端末間の通信が暗号化されてHTTPS通信になりアドレスバーに鍵マークが表示されて安心感があります。

SSL化されてない場合

SSL化していない場合はインターネット通信は「http」通信で行われますが、通信データは平文（暗号化なしのテキストそのままの状態）で送信されています。悪意ある第三者が情報を盗聴したり書き換えたりすることができる危険な状態です。

SSL化されていない通信の場合は、アドレスの前に以下のマークと「保護されていない通信」と表示されます。

クリックすると下記のように警告表示され、利用者に不安を与えてしまう恐れもあります。

基本的にどのサイトでもSSL化は推奨

個人のブログなど、訪問者が重要な情報を入力するような場面がないWebサイトはSSL化の必要がないように思われるかもしれません。

それでもSSL化はほぼスタンダードの技術になってきており、GoogleもSSLを推奨しています。ホームページ・ブログを始めたばかりの方も、最初からSSL化しておくことをお勧めします。

また、SSL化はGoogleの検索順位のランキング要因にも関わる指標の一つとされているので、SEOの観点からもSSL化はしておきたいところです。

サイトのコンテンツを問わず、ユーザーによるウェブサイトへの接続を保護するために、HTTPS を導入することをおすすめします。 HTTPSでサイトを保護する | Google SearchConsoleヘルプ

Google は過去数か月にわたり、暗号化された安全な接続をサイトで使用していることを検索のランキングアルゴリズムのシグナルとして考慮するテストを実施してきました。このテストで十分な結果が得られたため、Google はランキングシグナルとして HTTPS を使用することにしました。
ランキングシグナルとしての HTTPS | Google 検索セントラルブログ | Google Developers

私のWebサイトはブログでほぼ閲覧専用になると思うのでクレジットカード情報など入れることなないのですが、それでもSSL化した方が良いのでしょうか？

はい。その場合でもSSL化することをおすすめします。今では、SSL化が一般的になり、無料に設定もできますしGoogleもSSL化を推奨しているからです。

SSLが持つ３つの主な機能

前述の通り、SSL(https)とは、一言で言うと通信を暗号化して第三者にみられないように安全に通信する仕組みでした。

より厳密に言うと、SSLは、「通信の暗号化(盗聴防止)」だけでなく、「通信データの改ざん防止」や「(2者間での)なりすまし防止」という3つの機能を備えています。

暗号化(盗み見を防止する)
データの改ざん防止
(2者間での)なりすまし防止

具体的には、暗号化で通信をする前に、第三者機関である認証局が署名したサーバー証明書を利用することでなりすまし防止を行っています。また、暗号化通信の際に改ざん検知用のデータも同時に送ることで改ざんを検知しています。

ここからは具体的なSSLの仕組みについて説明していきます。

SSL通信の具体的な仕組みと流れ

ここからは少し技術的な話を解説していきます。SSLの具体的な仕組みについて知りたい方向けの内容です。

説

SSLを理解するために事前に知っておきたい用語

初めに、解説で利用する用語について下記にまとめておきます。難しい用語もありますが、解説ででてくるのでざっくり目を通しておくと解説がわかりやすくなります。

用語	意味
公開鍵暗号化方式	データの暗号化に使う鍵とデータの復号化に使う鍵がそれぞれ別々になっている暗号化方式。暗号化に使う鍵を公開鍵、データの復号化に使う鍵を秘密鍵と言います。
RSA暗号	公開鍵暗号方式で有名な暗号化アルゴリズムの一つで、桁数が大きい合成数の素因数分解問題が困難であることを安全性の根拠とした公開鍵暗号方式。発明者であるロナルド・リベスト、アディ・シャミア、レオナルド・エーデルマンの原語表記の頭文字をつなげてこのように呼ばれています(※wikipedia)。
公開鍵	通信を暗号化するときに使う鍵。不特定多数に漏れても問題がない公開されている鍵で、通常サーバー証明書の中に含まれています。
秘密鍵	公開鍵で暗号化されたデータを復号化するための鍵。https通信の場合、通常Webサーバーだけの中にあり、第三者に漏れてはいけない秘密の鍵です。
共通鍵暗号化方式	通信の暗号化と復号化を同一の鍵で行う暗号化方式。共通鍵暗号方式で利用する鍵を共通鍵と言います。
サーバー証明書(SSLサーバー証明書)	第三者機関の認証局(CA)によって発行されるデジタルな証明書。サーバー証明書は、クライアントの通信対象のWebサーバーが確かに本人であること証明するもの(なりすましされていない)です。証明書には、ドメイン認証/企業認証/EV認証などいくつかのレベルがあります。
認証局(CA)	Webサーバーの申請者から申請を受けてサーバー証明書を発行する信頼できる第三者機関。
CSR(Certificate Signing Request)	認証局へのサーバー証明書発行要求。対象のURL(ドメイン)や、申請者情報、Webサーバーの公開鍵が含まれた暗号化されたテキストファイルです。Webサーバーの所有者が、サーバー上でCSRを生成して認証局にサーバー証明書発行の申請依頼に利用します。認証局がCSRに署名をしてサーバ証明書を発行します。
ハッシュ化	特定の計算規則にそって元データを不可逆にランダムな文字列に変換・符号化すること。暗号化との違いは、暗号化は復号できるのに対して(可逆性がある)、ハッシュ化は不可逆な変換で理論上元データに戻すことはできません（生卵→ゆで卵は可能だが、逆はゆで卵→生卵は不可なイメージです）。

クライアントPCとWebサーバー間のSSL通信の流れ

クライアントPCとWebサーバー間のSSL化の流れは下記の通りです。

前述の章では、SSL(HTTPS)により通信の中身を暗号化して安全に通信する仕組みと説明しましたが、より具体的に説明すると、下記のような流れでSSL通信を実現しています。

SSL通信の流れ

■クライアントPCとWebサーバー間のSSL通信の流れ

クライアントがWebサーバー(Webサイト)に「https://.....」でアクセスする際に、WebサーバーにSSL接続を要求します。
サーバーはクライアントに対して、自身を証明するためのサーバー証明書(SSLサーバー証明書)を送付します。
クライアントは、サーバーから受け取ったサーバー証明書を検証して、自身がアクセスしたWebサーバー本人の証明書か(なりすまされていないか)を確かめます。
サーバー証明書がWebサーバー本人のものであることを確認とれたのち、クライアントはSSL通信用の共通鍵を作成して、送られてきたサーバー証明書に含まれるWebサーバーの公開鍵で共通鍵を暗号化します。
クライアントは、暗号化した共通鍵をサーバーに送付します。
サーバーは、クライアントに送付したサーバー証明書に含まれる公開鍵の対となる自身だけが持つ秘密鍵で、クライアントから送付された共通鍵を復号化します。
===この時点でクライアントとサーバーは両者共通の共通鍵を持つことになります。===
以降、サーバーとクライアントはデータのやり取りをお互い共通鍵で暗号化・復号化しながらデータ通信します。

なぜ最初から公開鍵・共通鍵だけで通信しないのか

なんで最初から公開鍵と秘密鍵だけで通信しないんですか？わざわざ複雑にしている意味ってあるんでしょうか？？

初めてSSLの暗号化の仕組みを勉強した際に、なぜ最初から公開鍵暗号化方式だけ、または共通鍵暗号化方式だけの一方で暗号化を実現しないのか疑問に思った方もいるのではないでしょうか。

前述のようにわざわざ２つの方式を組み合わせているのは、両者にはそれぞれデメリットがありそれを補うためです。

公開鍵暗号化方式のデメリット

公開鍵・秘密鍵での暗号化復号化は、共通鍵での暗号化復号化よりも処理が重く時間がかかるため、データ通信のたびに公開鍵・秘密鍵で暗号化復号化していると時間がかかるというデメリットがあります。

共通鍵暗号化方式のデメリット

一方、共通鍵だけで通信しようと思うと、通信の相手の数だけそれぞれの相手用の共通鍵をサーバーに保管しておく必要があります。共通鍵暗号方式だけでSSLを実現しようとすると、膨大な数の共通鍵をサーバー側は持たないといけなくなるっというデメリットがあります。

上記から、公開鍵暗号化方式と共通鍵暗号化方式を組み合わせることで、公開鍵暗号化方式のデメリットである暗号化復号化の処理の遅さっと共通鍵暗号化方式のデメリットである膨大な数の鍵が必要になる問題の両方を克服しています。

これを考えた人すごいですね！

公開鍵と秘密鍵の具体的にはどのようなものなのか

現実世界の鍵と違って、デジタル上の鍵というとイメージがつきにくいと思います。

デジタル上の鍵は、実際には下記のような英数字の文字列からなるファイルです。

SSLで利用している公開鍵暗号化方式の一つであるRSA暗号化方式は、桁数が大きい合成数の素因数分解問題が困難であることを安全性の根拠とした仕組みになっています。

暗号化プロトコルSSLとTLSについて

補足になりますが、現在は「SSL」だけではなく、「TLS」や「SSL/TLS」と表記されている情報が多々あります。

元々1994年ネットスケープ社がSSL(バージョン1.0)というプロトコルを開発したのですが、その後、SSLに脆弱性が発見されて、IETFという団体がTLSというよりセキュリティの高いTLS（Transport Layer Security）というプロトコルを開発しました。

ただし、現在のHTTPS通信で利用されているプロトコルは厳密にはSSLではなくTLSですが、元々SSLからスタートしたことから、慣習的に、現在も「SSL」もしくは「SSL/TLS」という表記をしている情報が多いということです。

バージョン	年
SSL1.0	設計レビュー中に大きな脆弱性が見つかり破棄
SSL2.0	1994年リリース
SSL3.0	1995年リリース
TLS1.0	1999年リリース
TLS1.1	2006年リリース
TLS1.2	2008年リリース
TLS1.3	2018年リリース　※2022年現在主に利用されているバージョン

Transport Layer Security - Wikipedia

SSL実装のためにサーバーで行う必要がある作業

ここからは、SSL通信を実現するために必要となるサーバー証明書発行の流れや中身、および証明書の検証プロセスについて詳しくご紹介します。

なお、実際には最近の多くのレンタルサーバーの場合だと、サーバー側でほどんど実施してくれるので、下記のような手順を全て自分でやる必要は基本的にありません。

おすすめのレンタルサーバーを「【レンタルサーバー比較】WordPressおすすめサーバー５選＋」の記事で詳しく説明していますので、独自ドメイン取得・レンタルサーバーをご検討されている方は合わせてご参照ください。

CSR発行からサーバー証明書の発行の流れ

CSR発行からサーバー証明書の発行の流れは下記の通りです。申請者がCSRを作成して、認証局に署名を依頼してサーバー証明書を発行して、サーバーにインストールします。

SSL化実装のためにすること

■SSL化の実装のためにすること

サーバー側で公開鍵・秘密鍵を生成して、CSRを作成する(CSRには、組織情報や対象サイト情報(URL)や公開鍵が含まれている)
CA(認証局)にCSRを送付して、サーバー証明書の作成を依頼する。
CAによってサーバー証明書が発行される。サーバー証明書には、組織情報や対象サイト情報(URL)、公開鍵、証明書の有効期限が含まれている
サーバー証明書をサーバーにインストールする(所定の場所に格納する)
====ここまででサーバー管理者側での基本作業は完了====
必要に応じて.htaacessで常時SSLの設定や、WordPressを利用の場合などはアプリ側の調整設定を行う。

なんだかすごく難しいそうですね。。

安心してください。最近のレンタルサーバーでしたら、初心者の人でもSSL化できるように、SSL化の設定にチェックを入れてポチッとボタンを押すだけで、あとはレンタルサーバー側でほどんどやってくれます。

多くのレンタルサーバーで、ホームページやブログを開設してSSL化する際に、サーバー契約者が上記のような細かい作業をすることは基本的にありません。

最近のレンタルサーバーの場合、無料SSLだとサーバー管理画面からSSL化の設定にチェックを入れてポチッとボタンを押すだけでできるものもあります。

あるいは、有料のSSLを申し込んだ場合でも、サーバー側でサーバー証明書発行申請(CSR情報記入など)するだけで、あとはレンタルサーバーサイドで証明書発行からインストールまでしてくれるところも多いです(証明書インストールは自身で行うケースもあります)。

ここからは具体的な中身についてもう少し説明をしていきますね。

CSR(Certificate Signing Request)

CSRは、認証局へのサーバー証明書発行要求のことです。

Webサーバーの所有者が、CSRを生成して認証局にサーバー証明書発行の申請依頼に利用します。認証局がCSRに署名をしてサーバ証明書を発行します。

サーバー証明書(SSLサーバー証明書)

SSL（サーバー）証明書とは、ドメインや組織の実在を証明する役割をもつ電子証明書のことで、SSLサーバー証明書を発行することでサイト閲覧者がそのサイトの信憑性を確認できるようになります。

下記は、証明書の中身です。証明書には、証明書の有効期限、対象のURL(ホスト名含むドメイン名・コモンネームと言います)や署名してくれた認証局の情報、およびWebサーバーの公開鍵情報が含まれています。

サーバー証明書が発行されたら、Webサーバーにインストールする必要があります。インストールはサーバー側でやってくれる場合もあれば自分でインストールする場合もあります。

ルート証明書と中間CA証明書およびサーバー証明書

通常、クライアント側でWebサーバーの署名が信頼できるか確認するために、証明書は階層構造になってそれぞれ下位の証明書の身元を保証するようになっています。

最も上位の機関が発行した証明書をルート証明書といい、ルート証明書は通常Webブラウザの中に最初からインストールされています。

ルート証明書は、下位の認証局（ここではサーバー証明書に署名してくれた認証局。中間CA証明書）の身元を保証しています。

そして中間CA証明書は、Webサーバーの証明書の身元を保証しています。なお、通常、中間CA証明書もWebサーバーに保存されています。

日本の認証局（CA）の例

GMOグローバルサイン
さくらのSSL
セコムのSSLサーバー証明書
Sectigo（旧コモドジャパン）

少し強引ですが会社組織に例えると、社長(ルートCA)が決裁承認権を部長に渡し、部長(中間CA)が課長に決済承認権を渡し、課長(Webサーバー)は自身で決済承認するといった感じですね。

(参考)認証局(CA)の署名のプロセスとクライアント側での検証プロセス

以下は参考です。認証局(CA)の署名のプロセスとクライアント側での検証プロセスについての補足です。

認証局の署名のプロセス

クライアント側での証明書検証のプロセス

署名・検証の際の特殊な使わ方

この署名と検証のプロセスで特殊なのが、「CAが秘密鍵で暗号化に相当する処理」を行い、クライアントPC側が「CAの公開鍵で署名データを復号化する処理」をしていると言う点です。

本来は、「公開鍵で暗号化して」「秘密鍵で復号化する」のが公開鍵暗号化方式の仕組みで、筆者も初めて勉強した際はこの署名のプロセスにおいては逆の使われ方に違和感を感じていました。

調べてみると、RSAという暗号アルゴリズムでの署名プロセスにおいては、平文データを秘密鍵で復号化して、公開鍵で複合化されたデータを暗号化して元に戻すという処理がとられているようです。

(参考)「電子署名=『秘密鍵で暗号化』」という良くある誤解の話

サーバー証明書の種類・認証方式の違い

通常、サーバー証明書を発行する際は申請者が認証局（CA）に発行申請をし、問題がなければ申請者に対してサーバー証明書の認証・発行を行います。この際の認証方式に「ドメイン認証(DV認証)」「企業認証(OV認証)」「EV認証」の3つの方式があります。

認証の種類「ドメイン認証」「企業認証」「EV認証」

一般ユーザーがブログやホームページを立ち上げる際、最近では無料のSSLを利用することが多くなってきましたが、SSLの種類には、ドメインや組織の実在証明（信頼できる組織か否かの正確な証明書）をするようなより厳格なSSLもあります。

サーバー証明書には、SSLサーバー申請者の本人確認として、「ドメイン認証(DV認証)」「企業認証(OV認証)」「EV認証」の3つの方式を提供しています。

認証方式	説明	ドメイン認証	実在認証	認証レベル	費用
ドメイン認証SSL (DV認証)	申請者が対象ドメインの所有者かどうかの本人確認をとった方式	◯	×	★	★
企業認証SSL (OV認証)	DV認証に加え、実在する企業なのか書類や電話で確認を取る方式	◯	◯	★★	★★
EV認証	OV認証と同様(より厳格な審査)。	◯	◯	★★★	★★★

なお、通常ホームページやブログでSSL化する際に利用する認証方式はドメイン認証SSLです。

ドメイン認証SSL(DV認証)

DV認証とは、ドメイン所有者とサーバー証明書の申請者が同一か否かを判断し証明するものになります。

3つの認証方式の中では1番簡単に申請・発行することができ、料金も低価格で導入できるのが特徴で、個人や小さいサイトを運営している方におすすめの認証方式の一つです。

サーバー証明書はサイトの閲覧者であれば誰でも確認することができます。

無料のSSLは、いわゆる「ドメイン認証型のSSL」です。ドメイン認証型とは、SSLの申請者がドメインの所有者であることが証明できればOKというものです。

しかし、問題点として、ドメインの所有者自身が架空業者などの悪意ある人であれば、いくらSSLで暗号化・なりすまし防止・改ざん防止を備えていても、情報が正当に扱われません。

そこで、より厳格な審査方式として、その企業が存在するか、DV認証の内容に加えて組織の所在地や会社名を確認するプロセスを必要とする方式として「企業認証SSL」や「EV SSL」というものが存在します。

認証局 Let's Encrypt について

認証局のLet's Encryptとは、非営利団体のInternet Security Research Groupによって運営されている証明書認証局で、TLSの証明書を無料で発行している組織です。

多くの方は「あれ？自分のサイトは認証局に証明書申請した覚えがない...」と思う方も多いのではないでしょうか。

ほとんどの方は、WordPressを利用する時はレンタルサーバーを利用すると思いますが、そのレンタルサーバーを利用したときに無料で発行されるサーバー証明書（利用するレンタルサーバー会社によって異なります）が、この「Let's Encrypt」の場合もあるという事です。

企業認証(OV認証)と EV認証

OV認証とEV認証は、上記のDV認証の内容に加えて組織の所在地や会社名を確認することができ、更にEV認証はOV認証よりも世界的なガイドラインに基づき、より厳しい審査を得て発行されます。

企業認証SSLやEV認証を使ってより厳密な証明書を発行することで、そのサイト運営者が確かに実在する会社・組織なのかを確認することができます。

レンタルサーバーの「ConoHa」やドメイン取得サービスの「お名前.com」など、数々の有名サービスをリリースしている「GMOインターネット株式会社」コーポレートサイトのサーバー証明書を確認してみましょう。

DV認証と違い、ドメインを所有している組織の所在地や会社名など詳しい内容が記載されていますね。

「GMOインターネット株式会社」はEV認証みたいですねなります！

ドメイン認証では、サーバー証明書からそのWebサイト運営者本人であることは確認できますが、Webサイト運営者自身が悪意ある人間・組織かどうかまで判断できません。

そんな時にOV認証やEV認証を利用することで、ちゃんと自社の組織が運営するサイトだと利用者にわかってもらえるようになります。

まとめ

まとめです。この記事では、インターネット上のデータを暗号化して送受信する仕組みであるSSLや、SSLサーバー証明書、SSL（の種類）認証方式について紹介しました。