Let'sEncryptSSL証明書でNginxを保護する方法

Let’s Encryptは、Internet Security Research Group（ISRG）によって開拓された無料のオープンソースの自動認証局（CA）であり、SSL/TLS証明書を提供して2者が関与する通信を暗号化します。

ウェブサイトのSSL証明書は、暗号化によってウェブサイトのセキュリティを強化するだけでなく、Googleがより良いSEOランキングのためにSSL証明書を含めることを義務付けているため、サイトのSEOランキングも向上させます。

この記事では、Ubuntu 18.04でLet’sEncryptSSL証明書を使用してNGINXサーバーを保護する方法について説明します。

前提条件

rootユーザーを使用するか、sudo対応ユーザーを使用して、Ubuntu18.04サーバーでSSHセッションを開く権限があります。
ここからのチュートリアルに従って、すでにNGINXをインストールしています。
登録済みのドメイン名。
DNS使用するドメイン名に基づいてサーバーのIPアドレスを指すレコード。

このチュートリアルでは、ドメイン名を使用する必要があります。 SUBDOMAIN、DOMAIN、またはTLD変数のいずれかが表示されたら、それらを独自の値に置き換えます。

Let'sEncryptクライアントライブラリをインストールする

実行する必要のある最初のステップは、Let’s Encryptクライアントライブラリをインストールすることです。このライブラリは、LE機関に証明書を要求するために使用されます。これを行う1つの方法は、サーバーの公式リポジトリからLet’sEncryptクライアントライブラリのクローンを作成することです。

Ubuntuの公式リポジトリから同じものをインストールすることも可能です。 Ubuntuのリポジトリでは、クライアントライブラリは certbotと呼ばれています Let’sEncryptの開発者によって提供されます。ただし、前者のインストール方法を選択します。つまり、Let’sEncryptのGithubリポジトリのクローンを作成します。

これを行うには、選択したインストールフォルダーに移動し、リポジトリのクローンを作成します。インストールフォルダを/usr/localとして選択しました、環境に応じて他のフォルダを選択できます。


# apt-get install git
# cd /usr/local
# git clone https://github.com/letsencrypt/letsencrypt

Letsencryptフォルダーに移動すると、証明書を取得するためにLet’sencryptに必要なcertbotを含むすべてのクローンフォルダーとファイルが見つかります。

List Lets Encrypt Folder

Let'sEncryptを設定してドメインを確認する

証明書を取得するプロセスで、Let’sEncryptクライアントは.well-known/acme-challengeに一時ファイルを作成しますフォルダ。このファイルには、証明書を取得しようとしているドメインを実際に所有しているという事実を検証するためのトークンが含まれています。上記のフォルダはドメインのウェブルートに該当することを忘れないでください。

したがって、Let’sEncryptが一時ファイルにアクセスしてドメインを確認できることが不可欠です。アクセスを許可するには、NGINXがドメインのWebルートの所有者であるため、NGINXを構成する必要があります。フォルダ/.well-known/acme-challenge専用のロケーションブロックを追加しますこれにより、Let’sEncryptがドメイン検証用のトークンを配置できるようになります。これを行うには、仮想ホストのNGINX構成ファイルを編集します。環境に応じてルートフォルダを調整することを忘れないでください。



    server {
            listen 80;
            server_name SUBDOMAIN.DOMAIN.TLD;
            root /var/www/html/wordpress;
            ...
            ...
            ...
            location /.well-known/acme-challenge {
               allow all; 
               default_type "text/plain";
            }
           ...
           ...
    }

構成ファイルが構文的に正しいことを確認し、NGINXを再起動します：


# nginx -t 
# systemctl restart nginx

UFWファイアウォールの構成

Ubuntu 18.04にはデフォルトのファイアウォールマネージャーUFWが付属しており、すでに有効にしてサーバーで実行している場合、HTTPまたはHTTPS接続はNGINXサーバーに到達できません。

以前に構成されたサーバーに証明書をインストールしようとしていて、ファイアウォールルールがすでに存在している可能性もあります。もちろん、ufw statusを使用してファイアウォールルールを一覧表示できます。 Ubuntu 18.04サーバーでHTTPおよびHTTPS接続を有効にする前に、サーバーでコマンドを実行します。

ターミナルで次の一連のコマンドを実行して、サーバーでHTTPおよびHTTPS接続を許可します。


# ufw status
# ufw allow http
# ufw allow https
# ufw reload

SSL証明書を暗号化しようとリクエスト

以前に複製したLet’s Encryptクライアントを使用して、選択したドメインのSSL証明書を要求しましょう。証明書を要求するときにLet’s Encryptスクリプトで使用できる構成オプションは多数ありますが、以下のオプションのみを使用します。

証明書のみ ：このオプションは、letsencryptスクリプトにSSL証明書のみを取得するように指示します。 NGINXの構成は後で手動で行います。
webroot ：このオプションは、ドメイン名の検証プロセスで使用されるwebrootプラグインを指定します。
webroot-path ：このオプションはドメインのルートを設定し、NGINX構成で構成したWebサイトの場所を指す必要があります。
同意する ：手段は、Let’sEncryptの利用規約に同意します。
メール ：このメールは、Let’s Encryptから有効期限の通知を受け取るために使用されますが、紛失したキーを復元するためにも使用できます。
d ：このオプションは、証明書が要求されるドメイン名を指定します。

上記のオプションとletsencryptクライアントスクリプトを組み合わせて、次のコマンドを使用して証明書を要求します。


# cd /usr/local/letsencrypt
# ./letsencrypt-auto certonly --agree-tos --email [email protected] --webroot --webroot-path /var/www/html/wordpress -d SUBDOMAIN.DOMAIN.TLD

FetchedLetsは証明書を正常に暗号化できます

Let’s Encryptスクリプトは、SSL証明書が正常にフェッチされ、証明書が/etc/letsencrypt/liveに保存されると、小さなメモを表示します。フォルダ。

Let'sEncryptのSSL証明書用にNGINXを構成する

この段階で、Let’sEncryptの証明書チェーンはサーバーに正常に保存されています。次に、セキュリティで保護されたSSL対応のNGINXWebサーバーの仮想ホストファイルの構成に進みます。

Diffie-Hellmanキーを生成

Let’s Encrypt証明書をNGINXで構成する場合、Diffie-Hellmanキーの使用はオプションですが、これは主に、Let’sEncrypt証明書で使用するために暗号化キーを安全に交換する方法として使用されます。


# mkdir -p /etc/nginx/ssl
# cd /etc/nginx/ssl
# openssl dhparam -out /etc/nginx/ssl/dhparam.pem 4096

DHパラメータファイルを/etc/nginx/sslに配置しました単に便宜上のディレクトリ。ファイルを他の場所に置くことができます。

SSLパラメーターの構成

次に、サーバーがサポートする必要のあるプロトコルバージョン、暗号スイート、セッション、ヘッダーなどのSSL接続のパラメーターを別のファイルに追加します。

これにより、可能な場合はいつでもForwardSecrecyを有効にする強力な暗号スイートがセットアップされます。さらに、HSTSとHPKPがSSL接続用のNGINXサーバーを強化できるようにします。これにより、強力で将来性のあるSSL構成で、 QualysLabsSSLテストでA+グレードを取得できるようになります。。


# vi /etc/nginx/conf.d/ssl.conf
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:ECDHE-RSA-AES128-GCM-SHA256:AES256+EECDH:DHE-RSA-AES128-GCM-SHA256:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
ssl_dhparam /etc/nginx/ssl/dhparam.pem;
server_tokens off;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
#Online Certificate Status Protocol Stapling
ssl_stapling on;
ssl_stapling_verify on;
ssl_session_tickets off;
#HTTP Strict Transport Security
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
ssl_trusted_certificate /etc/letsencrypt/live/SUBDOMAIN.DOMAIN.TLD/chain.pem;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
add_header X-Frame-Options DENY;
add_header X-XSS-Protection "1; mode=block";
add_header X-Content-Type-Options nosniff;
add_header X-Robots-Tag none;

NGINX仮想ホストを編集

最後に、選択したドメインのNGINXサーバーブロックを編集します。 NGINXサーバーブロックのデフォルトの場所である/etc/nginx/sites-availableに移動します NGINX仮想ホストファイルを編集します。


# vi /etc/nginx/sites-available/your_nginx_file.conf

server {
         listen 80;
         listen [::]:80;
         server_name SUBDOMAIN.DOMAIN.TLD;
         return 301 https://$host$request_uri;
}
...
...

上記のサーバーブロックは、ドメインSUBDOMAIN.DOMAIN.TLDのポート80で着信要求をリッスンするようにNGINXに指示します。同じものをhttpsセクションにリダイレクトします。その構成は以下のとおりです。


...
...
server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;

        root   /var/www/html/wordpress;
        index index.html index.php index.htm;

        server_name  SUBDOMAIN.DOMAIN.TLD;
        error_log /var/log/nginx/SUBDOMAIN.DOMAIN.TLD-error.log debug;
        access_log /var/log/nginx/SUBDOMAIN.DOMAIN.TLD-access.log;

        ssl_certificate /etc/letsencrypt/live/SUBDOMAIN.DOMAIN.TLD/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/SUBDOMAIN.DOMAIN.TLD/privkey.pem;

        include /etc/nginx/conf.d/ssl.conf;

        location /.well-known/acme-challenge {
               allow all;
               default_type "text/plain";
        }

        location / {
            try_files $uri $uri/ =404;
        }

        location = /favicon.ico {
                log_not_found off;
                access_log off;
        }

        location = /robots.txt {
                allow all;
                log_not_found off;
                access_log off;
        }

        location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
                expires max;
                log_not_found off;
        }
}

構文エラーがないか構成ファイルを確認してください：


# nginx -t

サーバーブロックをアクティブ化するには、/etc/nginx/sites-enabled内に上記の仮想ホスト構成ファイルのシンボリックリンクを作成しますフォルダ。


# cd /etc/nginx/sites-enabled
# ln -s ../sites-available/your_nginx_file.conf .

NGINXをリロードして、新しい設定を適用します：


# systemctl reload nginx

上記のSSL設定の構成を分析するには、ブラウザでSSL Labs Testを指定し、ドメイン名を入力して[送信]をクリックします。テストの概要を表示するには、1分待ちます。 A +レーティングとは、NGINXサーバーを保護するプロセスにほとんどのSSLオプションを含めたことを意味します。

Let'sEncrypt証明書の自動更新

Let’sEncryptの証明書は90日間有効です。この理由は、主要な侵害による被害を制限し、自動化を促進することです。

証明書の更新プロセスを自動化するには、crontabを使用してcronジョブを作成し、毎週1回実行されるスクリプト行を追加して、証明書の有効期限が近づいたときに証明書を更新します。


# crontab -e
45 4 * * 6 cd /usr/local/letsencrypt/ && ./certbot-auto renew && systemctl restart nginx

上記の1行のスクリプトは毎週土曜日に実行され、証明書が更新されるかどうかを確認します。更新される場合は、証明書を更新してからNGINXサーバーを再起動します。

証明書が更新されなくてもNGINXサーバーが再起動されるため、完全には最適化されていないことに注意してください。最善のオプションは、SSL証明書を更新するカスタムスクリプトを作成し、証明書が実際に更新された場合はNGINXサーバーを再起動することです。

結論

この記事では、Let’s Encryptクライアントライブラリをインストールする方法、ドメインの証明書をリクエストする方法、およびNGINXを使用してLet’sEncryptSSL証明書を構成する方法を学習しました。さらに、cronjobの例には、証明書の更新プロセスを定期的に処理する方法も示されています。