SSLをTLSと言い直すのがめんどくさい、ユゲタです。
GoogleもHTTPSを標準にすることでSEO効果があると、ほのめかしている為、世の中は443ポートに埋もれつつあります。
この間、とある若いエンジニアが、https環境でセキュアだと言って、GETでデータ送信をしていたので、呆れて白目が戻らなくなってしまいました。
本日のIT謎掛け
「HTTPS」と、かけまして・・・
「破滅の英単語(ruin)」と、ときます。
そのココロは・・・
Sがつくと、重要性が増します。
(ruins:遺跡)
Lets'Encryptは神
一昔前までのSSL導入は、安くても年間に数万円のコストがかかる事が当たり前だったのですが、
HTTPS標準化の動きに合わせて、登場してきたLet's Encryptサービスは、無料で443認証の提供をしてくれる、非常にボランティアイズムの高いサービスで、
※じつは裏でしっかりとビジネスはしているようですが・・・
テストサイトなどでも手軽にHTTPSサーバーの構築をすることが可能になりました。
さらに、オレオレSSLも用意することなく、簡易にセットする事ができる無料HTTPSは、まさに神と言ってもいいでしょう。
どなたか、頑張って、類似サービスを出して、この領域も相乗効果による、クオリティアップをしてもらいたいという本音もありますが、とりあえず、いい時代になったという実感はあります。
HTTPSリダイレクトの重要性
Let's Encryptを設定する時に、HTTPでのアクセスをHTTPSに自動的にリダイレクトさせますか？
という質問に対して、うっかり、「No」と返答してしまった人、
本番環境において、HTTPSがちゃんとセットされているにも関わらず、HTTPアクセスを許す意味が無いことを知り、自分でリダイレクト処理をしなければいけない事に気がつくでしょう。
まさに、その本人が僕です・・・
Nginxリダイレクトの落とし穴
リダイレクトは比較的簡単に調べればやり方がでてくるのですが、ググってトップに出てくる３つ（2020年８月現在）が、そのとおりにやってもリダイレクトエラーになるので、その解決方法をお教えします。
まず、リダイレクトのやり方は、以下のような記述が説明されていました。
if ( $http_x_forwarded_proto != 'https' ) {
return 301 https://$host$request_uri;
}
Nginxのプロトコル情報が"$http_x_forwarded_proto"という変数に格納されているとの事で、信用してこのまま設定ファイルに記述してみたところ、
$ nginx -t
で、エラーもなかったので、再起動してみると・・・
$ nginx -s reload
リダイレクトの無限ループになり、サーバー崩壊！！！
確かに、参考にしたページを見ると、６年以上前・・・orz
nginxのバージョンによるトラブルっぽいな・・・
そして、四苦八苦していたら、以下の方法で成功した。
if ( $scheme != 'https' ) {
return 301 https://$host$request_uri;
}
"$scheme"にプロトコル情報が格納されていたんですね。
これで、正常にセットすることができ、一安心。
最後に
こうしたトラブルを無くす為に、nginxの設定ファイルで80ポートと443ポートをそれぞれ分割して記述して、80ポートをそのまま443にリダイレクトすることで、こうした無駄なif文を書かなくてもいいというページを見かけて、
目からウロコ・・・とは、この事。
確かに同じ設定を複数書く面倒くささはあるが、バージョン依存などもしづらい設定内容なので、こちらの記述の方が確実な運用ができるであろうことが認識できた。
サーバー運用は、安定運用をすることを前提にすることがテッパンですよね。
そうそう、SSLの有効期限切れには、十分注意しましょうね。
0 件のコメント:
コメントを投稿