Google Cloud Platformで無料の範囲でDrupal8をセットアップした 3

hagi2020/06/11(木) - 10:22 に投稿
フロントページ

今回は、Let's Encryptを利用して、https用の電子証明書の設定を行う。途中、数点ひっかかった。

まず、

sudo apt install certbot python-certbot-nginx

でcertbotを導入する。このやり方は、https://certbot.eff.org/lets-encrypt/debianbuster-nginxで調べられる。

https://certbot.eff.org/lets-encrypt/debianbuster-nginx

私の場合は、元々別サーバーで、certbotは導入済みで、既存のアカウントと既存証明書がある。それらについては、元サーバーの/etc/letsencryptの下にあるので、これのバックアップ(tar cf)を取って、新サーバーでリストア(tar xf)する。これで既存のDrupalサイトとDBを持ってきて、DNSを書き換えて再設定すれば、取得済みの電子証明書も引き継ぐことができるようになる。今回は、新しいgcp.hagihara.tokyoという名前を使っているので、アカウントは既存のものを使うが、既存証明書は使わない。

やりたいのはcertbot --nginxなのだが、まずここでつまずく。最初に出てくるメッセージは

The nginx plugin is not working; there may be problems with your existing configuration.
The error was: NoInstallationError(“Could not find a usable ‘nginx’ binary. Ensure nginx exists, the binary is executable, and your PATH is set correctly.”,)

だ。調べるとnginxが入っている場所が/usr/sbinなのだが、これが実行パスに入っていないことが原因であることが判明した。これを解決するには、certbot --nginx --nginx-ctl /usr/sbin/nginxと入れてやることで解決する。nginxは立ち上がっているので、--webroot -w /var/www/html/drupal -d gcp.hagihara.tokyoを追加してやれば良いことになる。webrootは第一回で設定した場所で、一点注意しなければいけないのは、そのディレクトリでmkdir .well-knownをして、chown www-data.www-data .well-knownなければいけないことだ(いずれもsudo)。この操作を行うことで、必要な証明書をnginx経由で取得できるようになる。

この--nginxスイッチをつけて実行すると、/etc/nginx/sites-enabledにある構成ファイルを見るので、事前にserver_nameを定義しておく。今回は、サイトは一つだけ上げる形で/etc/nginx/sites-available/defaultにそのまま手を入れているが、本来はDNS名毎にファイルを作ったほうが良いだろう。

# Default server configuration
#
server {
            server_name gcp.hagihara.tokyo;

という感じで足しておく。首尾よく、電子証明書がゲットできると最後に

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 

と聞かれるので、今回はredirect、httpで来たやつはhttpsに飛ばすという設定の2を選択した。

これで冒頭のキャプチャーのように、ブラウザ上で鍵マークがつく。一応、これでOKである。ただし、
https://www.ssllabs.com/ssltest/analyze.html?d=gcp.hagihara.tokyo
で確認すると、評価がBランクとなっている。最近確認していなかったが、私が立てている既存サイトも立てた時はAランクだったのだが、今ではBランクに落ちている。

SSLLABS処置前

よく読むと、古いTLS 1.0や1.1を受け入れるとB以上にはならないよと書いてある。また、私の環境では、デフォルトでは、TLS 1.3は有効になっていない。いろいろググってみると、TLSの設定は、/etc/nginx/nginx.confにあると書かれているので、それを修正した。

hagi1960@instance-2:/etc/nginx\$ diff nginx.conf nginx.conf.orig
34c34
<       ssl_protocols TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
---
>       ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
hagi1960@instance-2:/etc/nginx\$ 

差分は上記のとおりで、しめしめこれでOKと思ってsystemctl restart nginxを行うと、予想に反して、やはりBのままで、TLS 1.0が依然として受け付けられている。さらに調べてみると、何と、letsencryptのデフォルトの問題であることが分かった。

certbotで修正された/etc/nginx/sites-available/defaultの中にinlude /etc/letsencrypt/options-ssl-nginx.confが含まれていて、何とその中でssl_protocolsが再定義されてしまっていたのである。この部分は余計なお世話なので、コメントアウトした。

hagi1960@instance-2:/etc/letsencrypt\$ diff options-ssl-nginx.conf options-ssl-nginx.conf.orig
10c10
< # ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
---
> ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
hagi1960@instance-2:/etc/letsencrypt\$ sudo systemctl reload nginx
hagi1960@instance-2:/etc/letsencrypt\$

上記の差分のとおりに修正して、nginxに読み込ませて、再度チェックすると無事にAランクに昇格した。

SSLLABS処置後

これで、細かい注意事項はあるものの設定完了。TLS 1.3への対応も無事成功している。

タグ

コメント

Twitterシェア