無料のSSLサーバー証明書で、常時SSLを実現!!



スポンサーリンク





本記事は、PDFに清書してあります。

ご入り用の方は、こちら↓のページを訪れてみてください。

無料のSSLサーバー認証局 Let’s Encrypt




Googleの「常時SSL」の推奨とか、
SSLサーバー証明書を無料で取得できるLet’s Encryptのサービス開始などで、
常時SSL化の波が大きくなっています。

本記事は、
ご自分でWebサーバーを開設されている方に向けて書いたものです。

共用型のレンタルサーバーを利用されている方は、
Google AdSenseなどSSL化対応の広告コード貼り付け
記事が参考になるかと思いますが、
無料や有料の商用ブログサービスでブログを開設されている方は対象外です。

本記事では、以下の2点について整理してあります。

(1) Let’s Encryptでの無料のSSLサーバー証明書の取得と、
Webサーバーへの設定について
CentOS 7/Apache 2.4、他のWebサーバーについてはご容赦を!)

(2) Webページに貼り付ける、下に示すASPの広告コードSSL対応状況について

・Google AdSense
・Amazonアソシエイト
・A8ネット
・その他

ページにSSL非対応のリンクが挿入されていると、
そのページは保護されたページにはなりません。

場合によっては、その箇所が非表示となるため
広告収入を得ようとしている方にとっては大きな関心事です。




実際にSSL化を実施してみると、想像していたものよりはるかに簡単です。
Let’s Encrypt利用すれば、誰でも挫折することなく「常時SSL」が実現できるものと
思います。

今更「常時SSL化」の方法?
と本レポートを出すには遅くなってしまった感は否めません。

でも、これからという方!
本記事を参考に、あなたのサイトを常時SSL化に対応してみてください
(実は、私もレンタルサーバーの方のサイトの対応は未だなんです。
自前構築の自宅サーバーのみ対応)。




1 概要

Googleより、「常時SSL」がSEO対策へ及ぼすことがアナウンスされています。

HTTPSをランキング シグナルに使用します

自分のサイトでビジネスを行っている人なら、
ほっておけない問題なのかもしれません。

常時SSLとは、一口でいうと
Webサイトの全ページをHTTPS化(SSL/TLS暗号化)するセキュリティ手法
のことです。

自分のサイトをHTTPS化にするには、
SSLサーバー証明書」というものが必要となります。
従来、SSLサーバー証明書は購入する価格が安くはなく、
また簡単な手続きで購入できるものではありませんでした。

でも、2016年4月12日に
完全無料で「SSLサーバー証明書」が取得できるLet’s Encrypt
というサービスが開始されて、
少なくとも費用の面からの困難が解消されました。

実際に利用してみると導入手続きやWebサーバーへの設定等、想像以上に簡単で、
SSL導入への敷居を大幅に低くするものです。

本記事は、そのLet’s Encryptの利用の仕方を中心に、
心配なWebページへの広告貼り付けの話を中心に記述します。

参考までに、
一番簡単なドメイン認証型のSSLサーバー証明書を取得する一般的な流れは、
以下に示す通りです。

(1) 秘密鍵を作成
(2) 秘密鍵を元に、CSR(証明書を発行するための署名要求)を生成
(3) 認証局へCSRを送信
(4) 認証局からドメイン所有者へ確認メールが届くので承認する
(5) 認証局から証明書がメールなどで届く



Let’s Encryptの場合は、
Let’s Encryptクライアントソフト(コマンド)をインストールして、
証明書を取得するためのコマンドを打つだけなのです。





2 SSL/TLS

本章では、
常時SSL」の背景であるSSL/TLSについて、ざーっと説明します。
知識がお有りの方は、読みとばされて全く問題はありません。

『「常時SSL」の細かい背景は難しそうだ』と思われる方は、
軽く眺めてください。

本章の内容だけで
常時SSLの技術的背景を深くご理解いただけるのは容易なことなく、
利用するだけならそれほど深く理解する必要もないでしょう。



2.1 常時SSL

Webサイトのすべてのページを暗号化(SSL/TLS化)することを、
常時SSL(Always On SSL)といいます。

常時SSLは、
Webサイト内のログインページやフォームなど特定のページだけでなく、
その他すべてのページをSSL/TLS化することで、
ログイン情報や決済情報だけでなく、Cookieへの不正アクセス(盗聴)も
防止することができます。

SSL/TLS化されたWebサイトは、
URLの頭が「HTTPS」となり通信の暗号化が保証されます。

# 後日、ネットワークスニファーによる
# 非暗号化通信、暗号化通信の実例を本サイトでお見せしたいと思います
# (実際の生の通信内容を見ることは、難しいことではありません。
# HTTPの通信は基本的に文字ベースですから、解読も難しいことではありません)。

これにより、
ユーザーは安心してWebサイトから個人情報や決済情報を提供することができ、
第三者による盗聴を心配する必要がなくなります。

さらに、企業実在認証付きの証明書やEV証明書がサイトに入っている場合には、
アクセスしているWebサイトに証明書が入っていることが確認できるため、
擬似サイトやなりすましサイトへの誘導を防ぐことができるといったメリットがあります。

常時SSL化するメリットに、
検索エンジンから「ユーザーが安心して利用ができる優良なコンテンツである」と評
価されることが挙げられます。

モバイルデバイスの普及により、
「いつでもどこでも」Webサイトを閲覧したり、
Webサービスや検索エンジンを利用する頻度が増えている昨今、
自社のWebサイトやサービスを利用するユーザーが、
フィッシング詐欺や盗聴などの被害に遭わないようにするために、
Webサイト自体の安全性の
向上がより一層求められています。




2.2 SSL/TSLとは?

では、SSLとは、いったいどんなものなのでしょうか?

SSL(Secure Socket Layer)とは、
インターネット上でデータを暗号化して送受信する方法のひとつで、
Netscape Communications社が開発しました。

今でこそWebブラウザといえば
Internet ExplorerGoogle Chromeなどがよく知られていますが、
1995年前後はNetscape Communications社が開発したNetscape Navigatorが
シェア一位でした。

TLSは、SSLと大枠の仕組みで同じものです。

SSLがバージョンアップを重ねて「SSL3.0」となり、
その次のバージョンから「TLS1.0」という名称で呼ばれるようになりました。

SSLの名称はインターネットユーザーの間で広く普及しているため、
TLSを指していても、
SSLまたはSSL/TLSと表記することが多くなっています。

本記事でも暗号化通信の技術自体を指す場合は「SSL/TLS」、
SSL/TLS技術を利用した電子証明書の呼称は
一般のネットユーザに分かりやすいよう
SSLサーバー証明書」と記述することにします。



通常、インターネットでは、データが暗号化されずに送信されています。
そのため、通信途中でデータを傍受されると、
情報が第三者に漏れてしまう可能性があります。

また、相手のなりすましに気づかずに通信すると、
データがなりすましの相手に取得されてしまう可能性があります。

表2.2-1 電子商取引におけるリスク


現在、クレジットカード番号や個人情報を扱う多くのWebサイトでは、
通信途中での傍受やなりすましによる情報漏洩を防ぐ目的で、
SSL/TLSを利用しています。

以前から「https」で始まるWebサイトは存在していましたが、
もっぱら個人情報を入力するフォームであるとか、
ECサイトにおける商品の入力フォームだけがSSL化されていました。

かつては、SSLを導入すると
暗号化オーバーヘッドのためWebサイトが遅くなるというのが常識でした。

しかし、サーバー側、クライアント側ともにCPUの性能が向上したことで、
もはやオーバーヘッドはほとんど感じられなくなってきています。

それだけでなく、
SSL化によりHTTP/2というプロトコルを利用できるようになり、
むしろ速くなるケースもでてきているそうです
(不思議です。 一体どんな技術を使っているのでしょう?)。




2.3 SSLサーバー証明書

SSL/TLS通信を自分のサイトに実装するには、
SSLサーバー証明書」が必要となります。

SSLサーバー証明書とは、
信頼された認証局
情報通信先のサーバーの運営組織が実在していることを証明し、
WebブラウザとWebサーバー間(サーバー同士でも可能)で
SSL/TLS暗号化通信を行うための電子証明書のことです。

SSLサーバー証明書には、次の2つの機能があります。

表2.3-1 SSLサーバー証明書の機能




2.3.1 SSLサーバー証明書の種類(ドメイン認証・企業認証・EV認証)

ひとくちにSSLサーバー証明書といっても、
利用用途や費用にさまざまな違いがあります。



(1)独自SSLと共有SSL
共有SSL」とは、
サーバー会社やプロバイダーが
代行で取得・所有するSSLサーバー証明書を
複数の契約者で共有するサービスです。

多くの場合は無料で暗号化通信を手軽に実現することができますが、
共有SSLの組み込まれたフォームになると
URLがプロバイダーのものに切り替わってしまうなど、
サイトの利用者からは信頼性に欠ける制限があります。

一方、
独自SSL」は世界的な資格を持った認証局が、
対象のドメイン名に対して専用のSSLサーバー証明書を発行して
暗号化通信を実現します。

独自SSLが組み込まれたサイトは、
ドメイン名をオリジナルのもので使用でき、
フォームへ移動してもURLは変わりません。

そのほかサイトシールの利用ができるなど、
サイトの信頼性をより効果的にアピールできます。

ただし、年間数千円~数万円、
よりセキュリティ信頼度の高い独自SSLの場合は
数十万円の費用がかかります。




(2) 独自SSLの種類
共有SSLと比べて信頼度の高い独自SSLですが、
その中にも大きく別けて3つの種類が存在します。

ドメイン認証(Domain Validation: DV)型
ドメインの本当の持ち主であるかどうかを認証します。

個人でも取得可能なので、
アンケートや問合せフォームなどに使用されます。


企業認証(Organization Validation: OV)型
ドメインの持ち主であると同時にサイト運営団体の実在性を認証します。
帝国データバンクに企業情報がある法人のみが利用できます。

ネットショップなど
個人情報や支払・決済に関する情報を取得するサイトで使用されます。


EV(Extended Validation)
ドメインの持ち主であると同時に、
サイト運営団体の実在性を最も厳格に認証します。
帝国データバンクに企業情報があることに加え、
企業の活動実態なども審査の対象になります。

知名度の高いブランド・官公庁・教育機関などのサイトで利用されます。

表2.3-2 独自SSLの種類





2.3.2 SSLサーバー証明書の確認方法

ここでは、
WebサイトのSSLサーバー証明書の確認方法を簡単に示します。
Google ChromeとMicrosoft Edgeについてだけしか示しませんが、
Internet Explorer、Firefoxなどの他のWebブラウザでもSSLサーバー証明書を確認するこ
とができます。
他のブラウザの場合については、検索にてお調べください。

(1) Google Chrome最新バージョン

今まではアドレスバーの鍵マークをクリックすると開くダイアログ中に
「証明書の情報」というメニューがありましたが、
新バージョンからは仕様が変わって
このダイアログの中からメニューが無くなりました。

新バージョンでは、
目的のサイトのSSLサーバー証明書は、httpsから始まるURLのWebサイトにアクセスして
以下のいずれかの方法で確認できます。

以下の3通りの方法のいずれかで、「検証」のウインドウを開きます。

・ 「F12」キーをクリックする
・ 「Ctrl」+「Shift」+「I」の各キーを同時にクリックする
・ ページ内で右クリック(図2.3-1参照)の上、「検証」をクリックする


図2.3-1 Chromeスクリーンの右クリックメニュー



検証」ウインドウが開いたら、「Security」をクリックします。


図2.3-2 検証ウィンドウ

図2.3-2に示すように「Valid certificate」フィールドの左□が緑色になっていれば、
View certificate」をクリックすると
図2.3-3に示すようにSSLサーバー証明書の内容が表示されます。


図2.3-3 証明書ウィンドウ





(2) Windows10の標準ブラウザであるMicrosoft Edge
当たり前のようにSSL通信はできるのですが、
今までのInternet Explorerとは違っています。

2017年10月時点での最新のバージョンでは、
組織名や住所情報はもちろんのこと、
証明書のウィンドウを表示することができないため、
使われているSSLサーバー証明書の詳細を確認することができません。

Edgeは、きっと機能向上途中なのでしょう。
SSLサーバー証明書の表示は、セキュリティの上で重要な機能です。
無くてよいわけがありません。





3 無料で利用できるSSL証明書Let’s Encrypt

通常、HTTPSのWebサイトを運用するには、
商用の認証局にSSLサーバー証明書の発行を申し込み、
必ず費用が発生するものでした。

一部限定した目的では無償で利用できるものが用意されており、
サーバーホスティング事業者と認証局との提携
(サーバー利用費用に同梱される形など)で
証明書費用が実質かからないサービスのほか、
GMOグローバルサインが2013年から行っていた
オープンソースプロジェクト向けのプログラムなどがあるくらいでした。

このような状況も、
無料のLet’s Encryptのサービスが開始されるに伴って変わってきています。




3.1 Let’s Encyptとは?

Let’s Encryptは、
すべてのWebサーバーへの接続を暗号化することを目指したプロジェクトです。

https://letsencrypt.org/

無料だからといって、
信用に足らないといったサービスでは決してありません。


Let’s Encryptの運営母体は、1990年に設立された
電子フロンティア財団(EFF: Electronic Frontier Foundationです。

2009年に制定された長期的なミッションが「ウェブの暗号化(Encrypting the web)」でした。
安全ではない平文のHTTP通信を、すべて暗号化したHTTPSに置き換えようという野心的な
目標が掲げられたのです。

そして、Let’s Encrypt Certificate Authorityが立ち上がります。
深い知識がなくても、誰もがHTTPSを扱えることを目指しています。
2016年4月12日から正式にサービスを開始しました。

非営利団体のISRG(Internet Security Research Group)が運営しており、
シスコ(Cisco Systems)、Akamai、
電子フロンティア財団(Electronic Frontier Foundation)
モジラ財団(Mozilla Foundation)といった著名な大手企業・団体が、
ISRGのスポンサーとしてLet’s Encryptを支援しています。


Let’s Encryptは、
支払い、サーバー設定、メールによる確認、
証明書の更新といった作業を省略することで、
SSL暗号化における設定や保守の複雑さを大幅に削減することを目的にしています。

完全自動化のため、
ドメイン認証(Domain Validation: DV)型証明書のみ発行しており、
企業認証(Organization Validation: OV)型や
EV(Extended Validation)型は提供していません。

日本語ドメインなどの国際化ドメイン名には、対応しているようです。

https://letsencrypt.org/2016/10/21/introducing-idn-support.html




なお、Let’s Encryptは、
多くの方が利用している共用型のレンタルサーバーでは
現在(2017年10月)のところ利用できないのではないかと思っていますが、
どうなのでしょうか?

導入に際して、SSHなどでコマンドをたたく必要があり、
また特定のディレクトリ下のファイルを参照したり、
ApacheなどのWebサーバーの設定ファイルをいじる必要があるからなのですが。

専用型のレンタルサーバーやVPSでは、もちろん利用が可能ですネ。

# この記事を書き終わった時点で知ったのですが、
# 共用型のレンタルサーバーの無料SSLサービスは、
# Let’s Encryptを利用しているようです。




3.2 Let’s Encryptの利用手順

SSLサーバー証明書の取得、そしてWebサーバーのSSL設定は、
非常に煩雑で難しそうに思われている方も多いのではないでしょうか。

Let’s Encryptを利用した場合、
それらはとっても簡単で図3.2-1に示すように全部で3ステップしかありません。

また、各ステップも難しい煩雑な作業では決してありません。

図3.2-1 Let’s Encryptの導入手順




本節では、CentOS 7上で
Let’s EncryptSSLサーバー証明書を発行して
Apache 2.4で利用する手順について説明します。




3.2.1 事前に行っておくべきこと

Let’s Encryptで発行される証明書は、いわゆる「DV証明書」という種類の証明書です。

Let’s Encryptサーバーは、
発行する証明書の対象のドメインの所有者自身が発行要求をしてきたことを確認した上で、
SSLサーバー証明書を発行します。

具体的にどのようなどのような確認が行われるのかというと、
証明書の発行を要求されたLet’s Encryptサーバーは、発行しようとしている証明書のドメイ
ンの80番ポートにアクセスし、特定の内容のファイルが存在していることを確認します。

問題なくファイルが取得できればドメインの所有者が発行要求を出していることを確認できま
すので、これをもって証明書の発行を行うというわけです。






したがって、
Let’s EncryptSSLサーバー証明書を取得するには、
下に示すことがされていなければなりません。
当たり前のことといえば、ごく当たり前の事前条件です。

Apache 2.4がすでにインストールされている。

・ インターネットから
HTTPで、80番ポートで公開しているホームページにアクセスできること。





3.2.2 Certbotクライアントのインストール

CentOS 7用のCertbotクライアントは、
EPELリポジトリからインストールすることができます。

次のようにepelリポジトリをインストールした上で、
certbotpython-certbot-apacheをインストールします。






3.2.3 SSLサーバー証明書の作成

SSLサーバー証明書は、
3.2.2 Certbotクライアントのインストールで示した
certbotクライアントを実行して発行します。

ここでは、Apache httpdのDocumentRootが「/var/www/www.mywebsite.jp」に
設定されていると仮定して話を進めます。
実際のDocumentRootの設定に合わせて読み替えてください。



(1) certbotクライアント
SSLサーバー証明書を取得するためには、
certbotクライアントは、
下に示すように少なくとも次の2つのオプションを指定して実行します。

-dオプション   証明書を発行するサーバーのドメイン
wオプション   DocumentRootのパスを指定




2つのオプション以外にも、
SSLサーバー証明書の取得に際しては、表3.2-1に示すオプションの利用が可能です。

表3.2-1 certboyのSSLサーバー証明書取得に関するオプション





なお、certbotクライアントの利用可能な全オプションについては、
下に示すページをご参照ください。

https://letsencrypt.jp/command/




certbotクライアントを起動すると、
まず下に示すようにメールアドレスを入力するように求められます。

このメールアドレスは、
後に証明書の有効期限が近づいた際にお知らせしてくれたりすることなどに利用されます。

なお、証明書の有効期間は90日間となっています。



次に規約に同意するかを問われます。
同意するためにAと入力します。





次にElectronic Frontier Foundationにメールアドレスを共有するかを問われます。
メールアドレスを共有すると、
EFFや証明書のことなどについてのメールを送ると書かれています。
メーリングリストのようなものです。

メールを受け取りたければYを、受け取りたくなければNと入力します。





これで証明書の作成が開始されます。
正しく証明書の作成が行われた場合は、次のように出力されます。

これで証明書の発行は終了です。




(2) SSLサーバー証明書が保存される場所
Let’s Encryptで取得するSSLサーバー証明書は、
サーバー証明書中間CA証明書の2つの証明からなります。

中間CA証明書とは、
電子証明書(デジタル証明書)を発行する認証局が、
自分自身の認証のために発行する電子証明書の1つです。
中間証明書」とも言います。
CAとは「Certification Authority」の略で、認証局を意味します。

電子証明書はインターネット上で本人証明を行うために使用されており、
この証明書を発行する「信頼できる第三者」のことを認証局と言います。



他にも、暗号化用の秘密鍵も取得します。




サーバー証明書秘密鍵は「/etc/letsencrypt/archive/」以下に保存され、
表3.2-2に示すパスにシンボリックリンクが作成されます。

シンボリックリンクのリンク先は、
SSLサーバー証明書を更新するたびに新しい証明書に変更されます。

表3.2-2 SSLサーバー証明書の保存パス






3.2.4 Apache 2.4への設定

SSLサーバー証明書が作成できたら、Apache 2.4に設定を追加します。

ssl.confの次に示す項目に、それぞれ設定します。

SSLCertificateFile
SSLCertificateKeyFile
SSLCertificateChainFile





これでApache httpdを再起動して完了です。




3.3 SSL証明書の自動更新

Let’s Encryptの証明書の有効期限は90日間と比較的短いため、
定期的に更新する必要があります。

これは自動更新を前提としているためのようです。

自動更新は、「certbot renew」コマンドを実行するだけです。
証明書の有効期限をチェックして、期限が近づいていれば更新してくれます。

また、即時に証明書を更新したい場合は
–force-renewal」オプションを付けて実行します。

ただし、承認数に上限があるようで、
このオプションを付けて毎日コマンドを実行してしまうと、
制限に引っかかってしまうようです。

実行するのは月1回程度に制限すると良いでしょう。

手動でコマンドをたたくことは、忘れてしまうこともあり面倒なことでもあるので、
crontabに登録するようにします。

下に示す例は、毎月1日の午前2時に証明書を自動更新し、
Apacheをリロードするようになっています。

日本国内向けのサイトであれば、
アクセスの少ない午前2時から午前5時の間を選ぶと良いかと思います。






4 AdSense、その他の広告コードのSSL化対応

HTTPS経由でアクセスできるサイトでは、
HTTPとHTTPSのコンテンツが混在しているとみなされます。

したがって、HTTPS対応サイトでは、
広告を含むページ上のすべてのコンテンツがSSLに対応している必要があります。

HTTPの古い広告コードを使用している場合、
広告が非表示となることもありますので、
HTTPSの新しい広告コードに書き換えなければなりません。

本章では、
Google AdSenseをはじめとする主要ASPのHTTPS対応状況を整理します。



4.1 AdSense用広告コード

AdSenseの広告リクエストは、
最新のものであれば、基本的に常にSSLに対応しています。

周辺のサイトがHTTPを使用している場合でも、
必ずHTTPS経由で配信されます。

古いAdSense広告コードを使用している場合は、
AdSenseスクリプトがブロックされてしまいますので、
古いAdSense広告コードを書き換えなければなりません。

https://support.google.com/adsense/answer/10528?hl=ja





AdSense 広告コードのスクリプトが「http://」で始まっている場合、
https://」に変更するだけでSSL化に対応できますが
基本的には下に示すいずれかの手順で対応します。

方法1:  新しい広告コードを作成する
方法2:  既存の広告コードを修正する





(1)方法1: 新しい広告コードを作成する
広告コードを取得し、そのコードをコピーしてから、
広告を掲載するページのHTMLソースコードに貼り付けます。

https://support.google.com/adsense/answer/181960





(2)方法2: 既存の広告コードを修正する
下に示す例のように、スクリプトソースから「http」を削除します。

新しいコードでは、URLは次のように2つのスラッシュで始まります。

同期広告コード:  ”//pagead2.googlesyndication.com/pagead/show_ads.js”
非同期広告コード: ”//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js”




4.2 その他の広告コード

広告コードのSSL化対応、未対応の判断は、
広告コード(広告スクリプト)の中のリンク・トップが、
次のようになっていることでします。

・ 全てのリンクがhttps://で始まる ⇒ SSL化対応
・ ひとつでもhttp://で始まっているリンクがある ⇒ SSL化未対応


当然のことなのですが、
http://」を「https://」に書き換えたからといって、
SSL化対応の広告コードになるわけではありません。

既にページに貼ってある広告コードがSSL化未対応の場合、
最新の広告コードを調べ、SSL化に対応していれば広告コードを貼り替えます。

いくつかのASPについて表4.2-1に、SSL化対応について整理しました。

調べた結果は、ほとんどのASPがSSL化を意識し対応しているようなのですが、
弱小の広告主の場合は対応しきれていないというのが
ざーーっとした印象です。

大手企業の広告に関しては問題が少ないと思いますが、
中小の広告主に関しては自分のWebページに広告を貼る際、
気をつけた方が良いようです。


以上






【参考図書】



スポンサーリンク






コメントを残す

サブコンテンツ

このページの先頭へ

Top