LinuxのUbuntu 16.04 / 16.10でLet's Encryptを設定する(Nginx環境) - WordPress 情報パッケージ
ベストセラー人気 WordPress テーマTop 30 詳細

LinuxのUbuntu 16.04 / 16.10でLet's Encryptを設定する(Nginx環境)

Last Updated:2019年11月24日| 1のコメント
  • Naver ブログを共有する
  • Naver バンドに共有する
  • Facebook 共有する
  • Twitter 共有する
  • 카카오스토리공유하기

無料Let's Encrypt SSL証明書

はじめ

Vultrの仮想サーバーホスティング(VPS)にUbuntuをインストールして WordPressをインストールした後、無料のSSL証明書であるLet's Encryptをインストールして適用してみました。

環境:Ubuntu 16.10、Nginxは、PHP 7

Let's Encryptをインストールする方法を説明した多くの文書があり、どのような方法に従ってか、少し悩みがしました。 少し検索をしてまともな文章を一つ発見した。

基本的な設定で自動更新まで、すべて記載されています。 Ubuntu 16.04環境での設定方法ですが、Ubuntu 16.10でも何の問題もなく動作します。

私はNginx virtual hostsファイル(例えば、 /etc/nginx/sites-available/mydomain.conf)が設定されているので、既存のファイルを上のリンクされた記事の内容に合わせて変更しました。

方法は、リンクの記事にしたがって、されるが、便宜上ここにそのまま移しておきます。 参考してください。

Nginxスニペット

まず、(各仮想ホストの構成では、コードの重複を防止するために)二つのスニペットを作成します。

次の内容が含まれている /etc/nginx/snippets/letsencrypt.conf ファイルを作成します。

location ^~ /.well-known/acme-challenge/ {
default_type "text/plain";
root /var/www/letsencrypt;
}

/etc/nginx/snippets/ssl.conf ファイルを作成し、次の内容を貼り付けます。

ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;

ssl_protocols TLSv1.2;
ssl_ciphers EECDH+AESGCM:EECDH+AES;
ssl_ecdh_curve secp384r1;
ssl_prefer_server_ciphers on;

ssl_stapling on;
ssl_stapling_verify on;

add_header Strict-Transport-Security "max-age=15768000; includeSubdomains; preload";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;

challengesのフォルダを作成します。

sudo mkdir -p /var/www/letsencrypt/.well-known/acme-challenge

Nginx virtual hosts(HTTPのみ)

まだ証明書がないため、ドメインは、HTTPでのみ動作します。

/etc/nginx/sites-available/mydomain.conf ファイルを作成し、次の内容をコピーします。

server {
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
server_name mydomain.com www.mydomain.com;

include /etc/nginx/snippets/letsencrypt.conf;

root /var/www/mydomain;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}

上記のmydomain.comは、実際のドメイン名に一括変更してください。 ルート・パス(/ var / www / mydomain)も、実際のルートパスに変更しなければします。

すでにvirtual hostファイルがある場合は、上記の内容を適切な場所に追加するようにします。

サイトを有効にします。

rm /etc/nginx/sites-enabled/default
ln -s /etc/nginx/sites-available/mydomain.conf /etc/nginx/sites-enabled/mydomain.conf

Nginxを再ロードします。

sudo systemctl reload nginx

Certbot

パッケージをインストールします。

sudo apt-get install software-properties-common
sudo add-apt-repository ppa:certbot/certbot
sudo apt-get update
sudo apt-get install certbot

証明書発給

証明書を要求します。 実際のサイトのアドレスとメールアドレスに変更するようです。

certbot certonly --webroot --agree-tos --no-eff-email --email YOUR@EMAIL.COM -w /var/www/letsencrypt -d www.domain.com -d domain.com

ファイルが /etc/letsencrypt/live/www.mydomain.com/に保存されます。

Nginx virtual hosts(HTTPSのみ)

これで、ドメインの証明書がありますので、 /etc/nginx/sites-available/mydomain.conf ファイルを修正して、httpsに切り替えます。 ファイルの内容を次の内容に置き換えます。

## http://mydomain.com and http://www.mydomain.com redirect to https://www.mydomain.com
server {
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
server_name mydomain.com www.mydomain.com;

include /etc/nginx/snippets/letsencrypt.conf;

location / {
return 301 https://www.mydomain.com$request_uri;
}
}

 

## Serves https://www.mydomain.com
server {
server_name www.mydomain.com;
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server ipv6only=on;

ssl_certificate /etc/letsencrypt/live/www.mydomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/www.mydomain.com/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/www.mydomain.com/fullchain.pem;
include /etc/nginx/snippets/ssl.conf;

root /var/www/mydomain;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}

## https://mydomain.com redirects to https://www.mydomain.com
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name mydomain.com;

ssl_certificate /etc/letsencrypt/live/www.mydomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/www.mydomain.com/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/www.mydomain.com/fullchain.pem;
include /etc/nginx/snippets/ssl.conf;

location / {
return 301 https://www.mydomain.com$request_uri;
}
}

Nginxを再ロードします。

sudo systemctl reload nginx

Cronを使用した自動更新

Certbotは30日以内に有効期限が切れているすべての証明書を更新することができますので、自動更新するcronを作成するようです。 Dry Runを実行して、構成が正しいことをテストすることができます。

certbot renew --dry-run

/root/letsencrypt.sh ファイルを作成します。

#!/bin/bash
systemctl reload nginx

# If you have other services that use the certificates:
# systemctl restart mosquitto

実行可能なように権限を設定します。

chmod +x /root/letsencrypt.sh

Cronを編集します。

sudo crontab -e

次の行を追加します。

20 3 * * * certbot renew --noninteractive --renew-hook /root/letsencrypt.sh

これでLet's Encrypt証明書を発行と適用され、そして自動更新の設定が完了しました。 現在サイトを訪問してみると、自動的にhttpsリンクに変更されていることを確認することができます。

Let's Encryptを適用した後は、サイトのすべてのhttp://のリンクをhttps://リンクに一括変更ヘジュオヤサイトの速度を損なうことなく正常に動作します。 そして、画像などのリンクもすべて変更しなければChromeでアドレス欄に「安全」という文字と一緒に鍵のアイコンが表示されます。

SSL LabsでテストしてみるとA +の評価になりますね。

LinuxのUbuntu 16.04 / 16.10でLet's Encryptを設定する(Nginx環境)3

速度の場合、少し遅くなったようだが有意差はないようです。

LinuxのUbuntu 16.04 / 16.10でLet's Encryptを設定する(Nginx環境)4

最後に、

VPSにLinuxをインストールしてNginx、PHP、MySQL環境を構築して WordPressをインストールする作業とLet's Encrypt証明書を適用する作業が漠然と難しく感じられたが、実際にしてみるとあまり難しいことはありませんでした。 ただし、適切な文書を見つけることが重要なようです。

現在、このブログがホスティングされている Bluehostの場合、すべての WordPress インストールの無料SSLを提供していそうです。 しかし、確認してみる VPSプランは除外されるとね。 低の共有プランも提供してくれるLet's Encrypt証明書をVPSプランに適用してくれないのはソントゥク理解されないが、おそらく「商売の中」からなのです。

この問題のためのホスティングが期限切れになると、無料SSLを簡単に適用することができる Sitegroundに移転したり、 Vultr のようなサービスを利用みようかも考慮しています。 Vultrや デジタルオーシャン 同じメーカーの場合は、サーバー管理のための能力を高めなければ考慮の対象になることがあるようです。 しかし、時間がたくさん残ったから、現在の約定が期限切れになるまで Bluehostの政策が変わる見守るつもりです。 (2017年9月更新:  いつか無料で変わるという漠然とした期待があったが、第期待通り 最近VPSプランでも無料でSSLが提供されるようになりました。)

メモ:



1のコメント

コメント

  1. 自動更新時に次のようにCronを編集しても大丈夫のようです。
    43 6 * * * certbot renew --renew-hook "systemctl reload nginx"

    https://serverfault.com/questions/790772/cron-job-for-lets-encrypt-renewal/825032

    https://stackoverflow.com/questions/42300579/letsencrypt-certbot-multiple-renew-hooks?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa

    https://serverfault.com/questions/790772/cron-job-for-lets-encrypt-renewal?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa

    --pre-hook and --post-hook hooks run before and after every renewal attempt。 If you want your hook to run only after a successful renewal、use --renew-hook in a command like this。

    応答