プログラミング Tips

ITエンジニアの雑記ブログ。
IT関連ニュースの考察や、プログラミングに関するTipsの備忘録として…
育児や日常の雑記帳としても、記事を投稿していきます。

プログラミングと日常生活に関する情報を発信しています。

Debian9 + Apache + SSL認証"Let's Encrypt"で設定評価「A」を目指した!

前回投稿で、Debian9 + Apacheの環境にSSL認証設定を施してみた。その際、無料のSSL証明書Let's Encryptを用いた。

設定の確認&第三者評価の観点から、SSL環境を評価してくれるサービスを利用した結果、【B】判定。微妙…
「可もなく不可もなく」
「基本的な設定はできているが、もう一つ物足りない…」
の判定と判断したので、【A】以上の判定を目指してみた。

【参考】
SSL認証の評価をしてくれるサイト

# https://www.ssllabs.com/ssltest/analyze.html?d=<ドメイン名>
https://www.ssllabs.com/ssltest/analyze.html?d=hogehoge.net


ゴール

SSL認証評価で【A】評価以上の取得!!

環境

クライアントPC

  • MacOSX 10.13.4

サーバー

  • Debian9
  • Apache/2.4.25 (Debian)
  • certbot 0.10.2

サーバーへSSH接続できることを前提とする。

また、今回はroot権限でそのまま作業を行うが、セキュリティ確保の為にはroot認証は無効化することを推奨する。

サーバーの環境構築とSSH設定、root無効化などの詳細に関しては、
ConoHa VPS の Debian9 に Djangoベースのサービスデプロイしてみた!!〜その①〜
とか
SSH conf を簡単に接続する方法まとめた!
を参照



Step1. 判定結果の確認

SSL認証の評価をしてくれるサイトへ適切なドメインを入力して、評価実行!

# https://www.ssllabs.com/ssltest/analyze.html?d=<ドメイン名>
https://www.ssllabs.com/ssltest/analyze.html?d=hogehoge.net

ConoHaVPS_ssl1

サイト評価の結果、「RSA暗号鍵のサイズ"2048bit"がマイナス評価」ってコメントが出ていた。

確かに、certbot コマンドでSSL情報を生成した際、鍵サイズを設定した記憶がない…ということで、初期値「2048bit」出力だったおいうことが判明。

よって、この点を「4096bit」に更新して試してみる



Step2. SSL認証更新(RSA認証鍵サイズを「4096bit」に…)

上記コメントから、鍵サイズの延伸に対策の糸口を見つめて、SSL認証の差し替えを決定。

certbot renewが、鍵の更新をしてくれるコマンド。

このコマンドは、「有効期限:90日」の判定をして、30日未満だった場合、認証情報を更新してくれる優れもの!!他にも、色々かゆいところに手がとどくオプションを備えているコマンドのようなので、今後このコマンドについても調査&まとめておきたい。

今回は、一先ず評価結果「A」実現のために、既存の認証情報を更新するために使う

certbot renew --force-renew --rsa-key-size 4096

<オプション>
--force-renew : 証明書の有効期限の残りを無視して、過去に発行したすべての証明書を強制的に更新
--rsa-key-size 4096 : 「4096bit」のRSA公開鍵が使用された新しい証明書に更新

この結果、以下の類似メッセージの最後に"success"が出力されれば成功!!

Saving debug log to /var/log/letsencrypt/letsencrypt.log

-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/hogehoge.net.conf
-------------------------------------------------------------------------------
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for hogehoge.net
Waiting for verification...
Cleaning up challenges
Generating key (4096 bits): /etc/letsencrypt/keys/0001_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0001_csr-certbot.pem

-------------------------------------------------------------------------------
new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/hogehoge.net/fullchain.pem
-------------------------------------------------------------------------------

Congratulations, all renewals succeeded. The following certs have been renewed:
  /etc/letsencrypt/live/hogehoge.net/fullchain.pem (success)

今回使用したcertbot renewコマンドは、既存の証明書を自動更新してくれるため、設定ファイルに編集を加える必要がない。よって、次ステップは早速、評価!!



Step3. 第三者評価

前述の通り、certbot renewコマンドは自動更新してくれるので、ここでは確認の作業のみ。

Step1.で用いた評価サイトで再評価!!
ちなみに、キャッシュが残っていると、再評価されない可能性があるので、事前にキャッシュ(履歴)をクリアしておくことをお勧めする。その方法は、各ブラウザごとの方法にしたがってほしい。

# https://www.ssllabs.com/ssltest/analyze.html?d=<ドメイン名>
https://www.ssllabs.com/ssltest/analyze.html?d=hogehoge.net

この結果、無事【A】評価!!

ConoHaVPS_ssl3


設定によっては、更に上の評価【A+】などもあるようだが、とりあえず上位評価が得られたので、今回は目的達成!!

Debian9 + Apache に"Let's Encrypt"をセットアップしてみた!!

WEBページのSSL対応はもはや避けては通れなくなってきていて、GoogleのSEOにもSSL対応是非が影響することが明確にうたわれている。参考

一方、立ち上げたばかりのサービスでに対して、最初から数万円のSSL証明書は買えない!!ということで、無料で発行される"Let's Encrypt"を適応してみたので、その手続きを備忘録としてまとめた。

"Let's Encrypt"について知りたい方は、オフィシャルサイトを参照してほしい。一応、日本語まとめサイトもあるので、合わせて読むと理解が深まると思う。

今回はConoHa VPS の "Debian9" への設定方法をまとめる。CentOS系はそこそこ情報があったのだけれど、Debian系は少なかったので…



環境

クライアントPC

  • MacOSX 10.13.4

サーバー

  • Debian9
  • Apache/2.4.25 (Debian)
  • certbot 0.10.2

サーバーへSSH接続できることを前提とする。

また、今回はroot権限でそのまま作業を行うが、セキュリティ確保の為にはroot認証は無効化することを推奨する。

サーバーの環境構築とSSH設定、root無効化などの詳細に関しては、
ConoHa VPS の Debian9 に Djangoベースのサービスデプロイしてみた!!〜その①〜
とか
SSH conf を簡単に接続する方法まとめた!
を参照

設定方法

作業手順は大きく以下の3ステップとなる

  1. Let's Encryptツールのインストール
  2. apacheのインストール
  3. SSL認証情報の設定
  4. WEBサーバーの設定
  5. WEBサーバーの再起動


Step1. "Let's Encrypt"ツール(certbot)のインストール

まず、この作業はroot権限の元で行うこと

$ apt-get update 
$ apt-get install -y certbot
$ certbot --version
certbot 0.10.2

Step2. apacheのインストール

以下のコマンドでapacheをインストール

apt-get install -y apache2

<チェック>
適当なブラウザにWEBサーバーのIPアドレスを入力し、apache初期画面が表示されることを確認する。この結果、webサーバーが正常にインストール〜起動していることがわかる
apache初期画面

Step3. SSL認証情報の設定

以下のコマンドを実行して、SSL認証ファイルを生成する

# certbot certonly --webroot -w <ドキュメントのルートPATH> -d <ドメイン名>
$ certbot certonly --webroot -w /var/www/html -d hogehoge.net

この結果、以下のような表示になれば成功

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel):hoge@hoge.jp    # ←入力

-------------------------------------------------------------------------------
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v01.api.letsencrypt.org/directory
-------------------------------------------------------------------------------
(A)gree/(C)ancel: A      # ←入力
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for hogehoge.net
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0000_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0000_csr-certbot.pem

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/hogehoge.net/fullchain.pem. Your cert will
   expire on 2018-07-24. To obtain a new or tweaked version of this
   certificate in the future, simply run certbot again. To
   non-interactively renew *all* of your certificates, run "certbot
   renew"
 - If you lose your account credentials, you can recover through
   e-mails sent to hoge@hoge.jp.
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le


このメッセージ中で重要な部分は、IMPORTANT NOTES:以降にある証明書や秘密鍵などに関する情報。ココには、それらの鍵ファイルを出力したパスが載っていて、この例の場合は、/etc/letsencrypt/live/hogehoge.net/ディレクトリ内に各種鍵が格納されていることがわかる。これら鍵ファイルは次ステップでサーバー設定に必要となる。

Step4. WEBサーバーの設定

以下のコマンドでWEBサーバーのSSL設定ファイルを編集

# オリジナルのファイルを別名でコピーしておくと安心
$ cp /etc/apache2/sites-available/default-ssl.conf /etc/apache2/sites-available/default-ssl.conf.org
$ nano /etc/apache2/sites-available/default-ssl.conf

ファイルが開いたら、以下の部分を編集(加筆、修正)する。場合によっては、行の先頭に#が付与されている場合も考えられるが、この場合、#はコメントアウトの意味なので削除!!

ServerName hogehoge.net
DocumentRoot /var/www/html

SSLEngine on
SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:EC$
SSLHonorCipherOrder on
SSLOptions +StrictRequire

SSLCertificateFile /etc/letsencrypt/live/hogehoge.net/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/hogehoge.net/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/hogehoge.net/chain.pem

Step5. WEBサーバーの再起動

順番に以下のコマンドを実行して、設定を反映&再起動!!
毎回、apacheの再起動を促されるが、最後に一回実行すればいい!!

$ a2enmod rewrite
Enabling module rewrite.
To activate the new configuration, you need to run:
  systemctl restart apache2
$ a2enmod ssl
Considering dependency setenvif for ssl:
Module setenvif already enabled
Considering dependency mime for ssl:
Module mime already enabled
Considering dependency socache_shmcb for ssl:
Enabling module socache_shmcb.
Enabling module ssl.
See /usr/share/doc/apache2/README.Debian.gz on how to configure SSL and create self-signed certificates.
To activate the new configuration, you need to run:
  systemctl restart apache2


$ a2ensite default-ssl.conf
Enabling site default-ssl.
To activate the new configuration, you need to run:
  systemctl reload apache2

最後に再起動!!

$ service apache2 restart

まとめ

この結果、ブラウザへ https://hogehoge.net を入力すると、無事SSL通信できていることがわかる!!

ConoHaVPS_ssl2

<補足>
以下のサイトに自分のドメイン名をセットすると、SSL証明のテストを行なって、判定してくれる

# https://www.ssllabs.com/ssltest/analyze.html?d=<ドメイン名>
https://www.ssllabs.com/ssltest/analyze.html?d=hogehoge.net

今回の結果、【B】判定だった。原因はRSA暗号が"2048bit"であることらしい。【A】判定を目指して、4096bitを今後の課題とする

ConoHaVPS_ssl1

以上、今日はここまで!!



参考サイト:
https://www.itzgeek.com/how-tos/linux/how-to-install-lets-encrypt-on-centos-debian-ubuntu-running-apache-web-server.html




リモートリポジトリーの変更をサーバー側へ反映する方法まとめてみた!

勉強を兼ねて、WEBアプリの開発をしているのだが、デプロイする際、gitコマンドで悩んだので、備忘のためにもまとめておく。

普段から、Gitを用いての開発は行なっているのだが、SourceTreeなどのいわゆるGUIベースのツールでサラサラっと流してしまっていたので、いざWEBサービスのデプロイに際して、CUI(コマンドライン)ベースで操作するにちょっと詰まった。

間違えた操作をしてもいいか!?と割り切りも考えたが、WEBサービスの場合は一旦デプロイ済みだと突然サービスが死ぬ、もしくはおかしくなってしまうことが考えられ、結果既存ユーザーのユーザビリティ低下は半端ない…よって、やっぱり慎重にやらなきゃね!?ってことです。

この点、単純なネイティブアプリの開発とは違うところだな〜と、一つ勉強になった。

そもそもいきなり本番サーバーにあげるのではなく、一旦テスト環境にデプロイして、最終検証後のリリースが然るべき手続きではあるが、今は勉強中でもあるので、そこのところは割り切り!!

今後、デプロイの自動化もやってみたい
<イメージ>

  1. ローカル開発
  2. リポジトリへgit push
  3. テスト環境で自動検知 & 更新(git pull)
  4. テスト環境で自動テスト (& エラーがあったら通知)
  5. 本番環境でテスト成功を検知 & 更新(git pull)
    が、とりあえずは先の話。


環境

クライアントPC

  • MacOSX 10.13.4

サーバー

サーバー側の環境には依存しない
但し、サーバーへSSH接続できることを前提とする。

サーバーの環境構築とSSH設定の詳細に関しては、
ConoHa VPS の Debian9 に Djangoベースのサービスデプロイしてみた!!〜その①〜
SSH conf を簡単に接続する方法まとめた!
を参照

あと肝心のgitがインストールされていること

gitのインストール方法

Debian(もしくはUbuntu)へのインストール

$ apt-get install git

Step1. ローカルの変更をリポジトリにpush

本稿のメインではないので詳細は割愛するが、ローカル(手元)でWEBアプリを開発し、一通りのデバックが完了したら、いよいよデプロイできるので、全てのコードをgit pushすして、リモートリポジトリへ!!

ちなみに
gitのインストールに関しては、GUIベースのツールsource treeをインストールすると全て解決する



Step2. サーバー側のコードを更新

ローカルで完成したアプリをgit pushしたら、サーバー側ではリモートリポジトリからそれらを入手して、更新が必要になる。この結果WEBサービスが最新へと更新される。

まずサーバー側に変更がないことを確認

$git status
On branch master
Your branch is up-to-date with 'xxx/master'.
nothing to commit, working tree clean

基本的にサーバー上で直接コードを編集することはないので、nothing to commit, working tree clean(訳:特に変更はないよ)であることを確認

以下のコマンドで、最新のコードを入手

$ git pull

エラーメッセージが出なければ完了!非常に簡単!!

<ポイント>
どこのリモートリポジトリからgit pullしてくるか?に関しては以下のコマンドを実行するとわかる

$ git remote -v
bitbucket https://hogehoge@bitbucket.org/hogehoge/xxx.git (fetch)
bitbucket https://hogehoge@bitbucket.org/hogehoge/xxx.git (push)

補足:pullfetchの違い

gitコマンドを調べていくと、pullfetchが似ていることがわかる。
今回もここで少し悩んだので、ざっと違いをまとめてみる。

git pull

リモートリポジトリからデータを全て取ってきて、手元のデータを更新!!
手元とリモートを同じ状態にするので、「同期」するイメージ。
この場合、mergeしたい変更がある場合には大変なことになるので、注意が必要!!

最悪、事故ってgit pullしちゃった場合も、戻したい先のIDを調べて、
git reset --hard ID--
で元に戻せるから大丈夫!!

<ポイント>
一応事前のgit statusで確認、回避できるから安心

git fetch

リモートリポジトリの変更履歴だけをとってくる。手元のデータは更新しない!!
リモートと手元と同じブランチで作業していて、且つmerge情報がある場合にはこちらがオススメ!!



↑このページのトップヘ