意外と Let’s Encrypt での証明書発行は 簡単である
まず、サイトの SSL/TLSへの対応を図るには、サイトの証明書が必要になります。
証明書には、色々な種類がありますが、ここで無料で利用できるのは、いわゆるドメイン認証と呼ばれるもので、
サイト（およびオーナー）が正しく存在するか、サイトがＤＮＳサーバーが認識しているサーバーと同じかという必要最小限の証明しかしないものです。
ただ、これでもしっかり暗号化はできるので、ほとんどのウェブブラウザ（スマホのブラウザも含む）で対応しており、普通に暗号化できます。
また、証明書の発行手続きも更新手続きもオンラインで自動化できるので、非常に楽です。
（最初の発行時だけメールアドレスぐらいを入力するくらいです。）
証明書の発行自体は ツールがあるので、そのセットアップを含めても１時間程度の作業だと思います。
当初は、それらのツールがないと思い、それなりにスクリプトでも書かないといけないのかなぁと思っていましたが、
先のツールで、なんなくクリアできて、案外、スムーズかつ簡単に発行までは行えました。
サイト証明書 には、以下の種類があり、それぞれの信頼性が異なる点に注意してください。
（Let’s Encrypt が無料で発行する
ドメイン認証は、最も信頼性が低いものです。）
以下は、シマンテックのページからの引用です。（シマンテックでは、証明書を “SSL証明書”と言います。）
| EV SSL証明書 | 企業認証型
SSLサーバ証明書 | ドメイン認証型
SSLサーバ証明書 |
|---|
| ドメイン使用権の認証 |
〇 |
〇 |
〇 |
ウェブサイト運営団体の
実在性を認証 |
〇 |
〇 |
× |
| 個人による取得 |
× |
× |
〇 |
| アドレスバーに組織名表示 |
〇 |
× |
× |
| フィッシング詐欺対策 |
◎ |
〇 |
× |
| 信頼性 |
★★★ |
★★ |
★ |
[ 出典元 : https://www.symantec.com/ja/jp/page.jsp?id=ssl-compare ]
シマンテックのグループでもある （安いと言われている）ジオトラストでもドメイン認証型SSL証明書は、（上記の出典元ページによると）31,300円/年 費用がかかります。
安いところでも やっぱり 10,000円/年はかかるものでした。
そのため、SSL/TLS への対応は、個人サイトを含め なかなか進まなかったのですが、
Let’s Encrypt の登場（安定してきたこともある）によって、現在では、4割程度のサイトで SSL/TLS への対応されたと言われています。( 2017.3 現在 )
この波は、止まらないでしょうし、SSL/TLS による暗号化は普通になると思います。
SSL/TLSに対応するということは アドレス(URL)が変わるということ
これは、非常に当たり前のことですが、ＵＲＬは、
http://server-setting.info → https://server-setting.info へと変わります。
もちろん、技術的には併用することもできます。（事実、ＳＮＳやブックマークなどでは、別のページと認識することが多いです。）
しかし、一つの同じ内容のページに対して２つのアドレスが存在することは、少なくともＳＥＯ的にはあまり良いとは言えません。
逆に、２つを併用する目的が特別にない限りは、いずれかに統一することが好ましいのはメンテナンスの面からも言うまでもないと思います。
では、https:// に統一した時に、どのような問題が発生するか、以下にまとめてみます。
SNSやブックマークからのリンクカウントが０となる。
(http と https を同じとみなしてくれるものもありますが、多くは違うアドレスとみなします。)
以下は、違うとみなされるものの有名どころの一覧です。
（Pocketは同じと認識しているようです。twitterは、現在では正確なカウントができないので、意識する必要はないかと思います。）
- FaceBookの共有、いいねのカウント
- Google Plus の共有、+1 のカウント
- はてなブックマーク のカウント
このサイトでは、以下のように http アドレス + https アドレスの両方を表記してみました。
（http アドレス で既に登録数が1以上ある場合のみです。）
そもそも、これらのカウント表示がどれだけ有効的なものか？は不明ですが、少なくとも登録用のボタンがあれば、
FaecBookへの投稿も促せますし、ツイッターもされやすいのは確かです。
また、ページにカウント表記がある場合は、そのカウントが多ければ、人気のページなんだなぁというぐらいの認識にはなり得るのもうなづけます。
そういう意味での訪問者へのサイトやページの有効性、有用性情報の一つとして、このサイトでは、一応、表記するようにしています。
ただし、javascriptでのカウント読み出しを行っていて、ページ表示完了までに 時間を要しているのも事実です。
これについては、今後、様子をみて 再検討したいと思っています。
ウェブアプリなどに登録しているサイト情報(URL)を変更あるいは追加する必要がある。
良く利用されていて、一番、面倒なのは、Google Search Consoleなどの管理系ウェブアプリしょうかね。
これらは、http と https を別物とみなすことが多く、設定の変更あるいは追加登録を行う必要があります。
ウェブアプリなどに登録しているURLを変更あるは追加する必要がある。
一番、面倒なのは、Google Search Consoleなどの管理系ですかね。これらは、http と https を別物とみなすことが多く、設定の変更を行う必要があります。
検索順位が変わってしまうのか？ＳＥＯ的に不安である。
Googleでは、SSL/TLSに対応すると検索順位的には上がると言われています。
ただ、このサイトに限って色々と調べてみると 確かに上下している検索気ワードはあるものの、必ずしも SSL/TLSの対応によって影響が出たとは言い切れないです。
また、すぐには https アドレスは、反映されません。概ね、1カ月程度の時間がかかるみたいです。
人気のサイト、ページについては、反映が早いようですが、そうでもないサイト、ページに関しては時間がかかるみたいです。
以下は、Googleでの自サイト内を “windows” というキーワードで検索した結果です。
混在しているがわかりますね。
これによって、検索キーワードによっては、検索結果として表示されるページ自体が SSL/TLSの対応前と変わったり(https アドレスのページが優先されるみたい)していましたが、
それについては、SSL/TLSの対応によるものだと思いました。
これについては、混在が解消されていけば、もとに戻っていくものと思います。
https のURLへ統一する場合、一般的は、 301 のリダイレクトを行います。
つまり、
http://server-setting.info でアクセスされた場合は、
301 を返信し、https://server-setting.info へリダイレクト(ページ移動)させます。
リファラが飛ばないことがある
リファラ(referer )とは、
参照元のことで、どこのサイトから自サイトへ来たかという情報をウェブブラウザが ウェブサーバへ通知することを言います。
その情報をウェブサーバは、アクセスロギングなどに書き込み、サイト、ページの分析に利用したりしています。
リファラは、https のサイトから https へ流れた場合は、普通に読み込めます。
しかし、https のサイトから http へ流れた場合、リファラは読めません。( RFC 2616 勧告による )
（もちろん http → http は読めます。）
なので、これで困るなぁと思われる方は、
SSL/TSLに対応していない アフィリエイト（広告主） から広告収入を得ているサイト運営者でしょう。
Google Adsでも、”サイト収入は減る” と Google自身も言っていた時期があったみたいです。
以前は、まだまだ SSL/TLS への対応がままならない状況もあり、広告主が （若干、割高な）https アドレスページへの広告を嫌った面もあったようです。
（今では、価格差はない？のかなぁ、詳しくは知りません。）
今では、逆に信頼できるサイトのイメージも定着してきており、広告主が https アドレスページへの広告を出しただっているとも言われています。
変なサイトへ広告を出して企業イメージが損なわれるより、若干、高くても https アドレスページへの広告を出した方がより良いことが理解されつつあるのでしょうね。
このサイトでは、Google Ads が表示されていますが、実際に SSL/TLS へ切り替えての広告クリック率などは、ほとんど変わらないことから、
少なくとも Google Ads については、マイナスの影響はなさそうです。
まっとうな (Amazonを含め)アフィリエイトの会社は、SSL/TLS に対応していますし、
サイトやサイト内ページの分析には、なんら影響はないはずですから、普通の方には、ほとんど影響ないと思います。
とりあえず、以下のメタタグを埋めると httpsページ →
http ページ への遷移でも
リファラ―を読めるらしいです。( 確認していません、自己責任でお願いします。
)
<meta name="referrer" content="unsafe-url">
|
ただ、対応してるブラウザが以下のように限定されているようです。
- PC版
- Google Chrome（Windows版）
- Google Chrome（Mac版）
- Firefox 38（開発者版、正式版は未リリース）
- モバイル版
- Chrome for Android（41.0.2272.96で確認）
[ 出典: http://web-tan.forum.impressrd.jp/e/2015/04/14/19750 ]
先にも書きましたが、そもそもリファラ（参照元）情報は、ウェブブラウザが渡してくれるものです。
ウェブブラウザが、どこから来たのかを教えてくれるのです。
では、どういう時に教えてくれない（ノーリファラー（参照元なし））のでしょうか？
以下に、列挙してみます。
- ブラウザのアドレスバーに直接URLを入力した場合
（ブラウザのブックマーク機能から直接着た場合も入力したことと同じ）
- ウェブブラウザ以外（多いのはメールクライアントツールやFlashなどのリンク）のソフトウェア（アプリ）のリンク（ボタン）からページを開いた場合
（メールでもウェブブラウザを使うウェブメールは、読めることが多い。）
- ウェブブラウザ以外（多いのはメールクライアントツールやFlashなどのリンク）のソフトウェア（アプリ）のリンク（ボタン）からページを開いた場合
（セキュリティソフトなどで同様にリファラ（参照元）情報を渡さないようにしている場合も含む）
- メタタグによるリダイレクトされた場合（FirefoxとIEだけらしい）
- httpsページ → http ページ への訪問の場合
このような場合は、リファラ―は読めません。
そのため、分析する際には、これらのノーリファラ―のページビュー数が多ければ多いほど、それらをどう解釈するかという点も重要になってきます。
暗号化するのだから、負荷がかかるんじゃないの？と思いきや大したことはなかった
少なからず 暗号化するのだから、やっぱりサーバに負荷がかかるんじゃないのかなぁ？と思っていましたが、
結果的には、ほとんど大したことはありませんでした。
（現在(2017.08)では、HTTP/2 にも対応していないので単純に SSL/TLS で接続しているだけです。）
このサイトを運営しているサーバは、かなり非力なサーバということもあって、少し、気にしていましたが、
実際に負荷がかかっているか確認してみましたが、それほどのことはありませんでした。
以下は、このサイトが動作している 非力なサーバの各負荷の推移を表したグラフです。
赤いラインが概ね SSL/TLS に対応した日付です。
[CPUの負荷の推移]
[DISK使用量の推移]
[ネットワーク転送量の推移]
[ページビューの推移]
経過日数（プロットの数）が、まだまだ少ないので、はっきりしたことは言えませんが、
少なくとも CPUの負荷は、ほとんど上がっていませんね。
他サーバへ置いていた画像を全てこのサーバへ移したこともあって
ディスクの読み込み負荷が上がっています。（SSL/TLSが直接の原因ではありません。）
ネットワークの転送量についても 同様です。
画像をこのサーバから転送しているので、その分の増分はあります。
まだまだ、データ数が少ないので、様子を見る必要がありますが、
ページビューは、このサイト特性上、土曜、日曜は、極端にアクセス数が減るので、
ちょっとわかりづらいところもありますが、ほぼ変化がないような状態です。
サーバは、負荷らしい負荷はかかっていないようです。
では、ウェブブラウザ側ではどうでしょうか？
これは、CPUの負荷などをみてもよくわかりませんでした。
実感としてもそれほどの差があるようにも思えませんでした。
多少は、違うのかもしれませんが、実際にページビューの表示速度は、それほど変わりません。
少なくとも体感速度は、全く感じませんでした。
ん～っ、HHTP/2 への対応など もっと高速化、セキュア化を進めていくと
また、変わってくるのかもしれませんが、単純な SSL/TLSでの接続だけでは、負荷らしい負荷はかからないようです。
少なくとも、このサイトのアクセス数程度であれば、この非力なサーバでも問題なさそうなのです。
一番面倒なのは 全ページ SSL/TLS対応することだと思った・・・
とりあえず このサイトの SSL/TLS 対応を終えた思ったことは、
各記事の SSL/TLS 対応が、なによりも面倒でした。
そもそも、このサイトの記事は、以下に雑に作られてきたか・・・を思い知らされました。
“サイトをSSL/TLS に対応させる” ということは、サイト内のすべての記事において、非SSL/TLS つまり http でアクセスしているページを
全て SSL/TLS つまり https でアクセスするように修正することです。
例えば、他サイトから直接 ある画像 がページ内で表示されているとします。
その画像へのアクセスの仕方が、http でアクセスしていると そのページは、SSL/TLSに対応していないページということになります。
つまり、そのページを表示するために http で何らかのアクセスをしていると、そのページは非対応となります。
（逆に SSL/TLSに対応しようとしているサイトから 非対応サイト(http アドレス)へのリンクなどは、先のリファラの問題はありますが、SSL/TLSの対応という面では、まったく問題ありません。）
以下は、サーバ自体は、SSL/TLSに対応しているものの ウェブブラウザ(FireFox)での SSL/TLSに対応できていないページを https で表示した時の 例です。
このアドレスバーの鍵に警告のアイコンが表示されています。
隣の情報のアイコンをクリックすると以下のようにメッセージが表示されます。
このように、ウェブブラウザは、安全ではないサイトと認識します。
これを見た方がどう思うか・・・です。
サイト運営者なら、ページに http でアクセスしている情報があるんだなぁと思うかもしれませんが、
それほどの知識がない方は、このサイトが安全ではないのだなと判断されるでしょう。
せっかく、安全なサイトをアピールするための SSL/TLS への対応でもあるのに、本末転倒ですね。
そのため、ここの各ページの対応は、ページ内でどこで他サイトへアクセスしているか調べ上げ、それらを正しく編集しなければなりません。
このサイトでは、負荷分散などを試すのに、画像などを他のサイトに追い出したりしていたのがあだとなりまして、
この修正にやたらと時間を要したということです。
ちなみに、本来、正しく SSL/TLSに対応していれば、以下のようにアドレスバーに鍵アイコンが表示されます。
参考までにChrome では、SSL/TLSに対応していれば、以下のようにアドレスバーに鍵アイコンが表示されます。
また、サーバ自体は、SSL/TLSに対応しているものの SSL/TLSに対応していないページを https でアクセスすると以下のように表示されます。
鍵のアイコンは表示される情報のアイコンのみとなります。
情報のアイコンをクリックすると以下のようにメッセージが表示されます。
また、サーバが全く SSL/TLS に対応しておらず https でのアクセスをリダイレクトもしていないような場合、以下のようなメッセージが画面に表示されます。
このページは、さすがに変なサイトだと思われても仕方がないくらいのインパクトですね。
サーバが全く SSL/TLS に対応しないのであれば、せめてリダイレクトするようにしておけば上記の画面が表示されることはありません。
それくらいの対応はしておきましょうね。
いかがだったでしょうか？
SSL/TLS への対応で思ったことを、備忘録も含めてまとめてみました。
今でも SSL/TLS への対応に迷っておられる方に、少しでも参考になれば幸いです。
)
コメントを投稿 :