Debian9でNginxの自己署名SSL証明書を作成する方法

投稿日: 2019-11-08 2022-04-20
タグ: Debian 9, nginx, Security

このチュートリアルの以前のバージョンは、 JustinEllingwoodによって作成されました。

序章

TLS 、つまりトランスポート層セキュリティ、およびその前身である SSL は、セキュアソケットレイヤーの略で、通常のトラフィックを保護された暗号化ラッパーでラップするために使用されるWebプロトコルです。

このテクノロジーを使用すると、サーバーは、メッセージが外部の関係者によって傍受される可能性なしに、サーバーとクライアントの間でトラフィックを安全に送信できます。証明書システムは、ユーザーが接続しているサイトのIDを確認するのにも役立ちます。

このガイドでは、Debian9サーバー上のNginxWebサーバーで使用するための自己署名SSL証明書を設定する方法を示します。

注：自己署名証明書は、サーバーとクライアント間の通信を暗号化します。ただし、Webブラウザに含まれている信頼できる認証局によって署名されていないため、ユーザーは証明書を使用してサーバーのIDを自動的に検証することはできません。

サーバーにドメイン名が関連付けられていない場合や、暗号化されたWebインターフェイスがユーザー向けでない場合は、自己署名証明書が適切な場合があります。 do にドメイン名がある場合、多くの場合、CA署名付き証明書を使用することをお勧めします。 Let’s Encryptプロジェクトで無料の信頼できる証明書を設定する方法については、 Debian9でLet’sEncryptを使用してNginxを保護する方法を参照してください。

前提条件

始める前に、root以外のユーザーにsudo権限を設定しておく必要があります。このようなユーザーアカウントを設定する方法については、Debian9の初期サーバー設定に従ってください。

また、NginxWebサーバーをインストールする必要があります。 LEMPスタック全体（Linux、Nginx、MySQL、PHP）をサーバーにインストールする場合は、 Debian9でのLEMPのセットアップに関するガイドに従ってください。

Nginx Webサーバーが必要な場合は、代わりに Debian9へのNginxのインストールに関するガイドに従うことができます。

前提条件を完了したら、以下に進みます。

ステップ1—SSL証明書を作成する

TLS / SSLは、公開証明書と秘密鍵の組み合わせを使用して機能します。 SSLキーはサーバー上で秘密にされます。クライアントに送信されるコンテンツを暗号化するために使用されます。 SSL証明書は、コンテンツを要求するすべての人と公に共有されます。これは、関連付けられたSSLキーによって署名されたコンテンツを復号化するために使用できます。

1つのコマンドで、OpenSSLを使用して自己署名キーと証明書のペアを作成できます。

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/nginx-selfsigned.key -out /etc/ssl/certs/nginx-selfsigned.crt

一連の質問があります。それを説明する前に、発行しているコマンドで何が起こっているかを見てみましょう。

openssl ：これは、OpenSSL証明書、キー、およびその他のファイルを作成および管理するための基本的なコマンドラインツールです。
req ：このサブコマンドは、X.509証明書署名要求（CSR）管理を使用することを指定します。「X.509」は、SSLおよびTLSが鍵および証明書の管理のために準拠している公開鍵インフラストラクチャ標準です。新しいX.509証明書を作成したいので、このサブコマンドを使用しています。
-x509 ：これは、通常行われるように証明書署名要求を生成するのではなく、自己署名証明書を作成することをユーティリティに通知することにより、前のサブコマンドをさらに変更します。
-nodes ：これは、パスフレーズで証明書を保護するオプションをスキップするようにOpenSSLに指示します。サーバーの起動時に、ユーザーの介入なしにNginxがファイルを読み取れるようにする必要があります。パスフレーズは、再起動するたびに入力する必要があるため、これが発生するのを防ぎます。
-365日：このオプションは、証明書が有効であると見なされる期間を設定します。ここで1年間設定しました。
-newkey rsa：2048 ：これは、新しい証明書と新しいキーを同時に生成することを指定します。前の手順で証明書に署名するために必要なキーを作成しなかったため、証明書と一緒に作成する必要があります。 rsa:2048部分は、2048ビット長のRSAキーを作成するように指示します。
-keyout ：この行は、作成している生成された秘密鍵ファイルを配置する場所をOpenSSLに指示します。
-out ：これはOpenSSLに作成する証明書を配置する場所を指示します。

上で述べたように、これらのオプションはキーファイルと証明書の両方を作成します。情報を証明書に正しく埋め込むために、サーバーについていくつか質問があります。

プロンプトに適切に記入します。最も重要な行は、共通名を要求する行です（例：サーバーFQDNまたはあなたの名前）。サーバーに関連付けられているドメイン名、またはサーバーのパブリックIPアドレスを入力する必要があります。

プロンプト全体は次のようになります。

Output
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:New York
Locality Name (eg, city) []:New York City
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Bouncy Castles, Inc.
Organizational Unit Name (eg, section) []:Ministry of Water Slides
Common Name (e.g. server FQDN or YOUR name) []:server_IP_address
Email Address []:admin@your_domain.com

作成した両方のファイルは、/etc/sslディレクトリの適切なサブディレクトリに配置されます。

OpenSSLを使用している間、クライアントとの Perfect ForwardSecrecyのネゴシエーションに使用される強力なDiffie-Hellmanグループも作成する必要があります。

これを行うには、次のように入力します。

sudo openssl dhparam -out /etc/nginx/dhparam.pem 4096

これにはしばらく時間がかかりますが、完了すると、/etc/nginx/dhparam.pemに強力なDHグループが作成され、構成で使用できるようになります。

ステップ2—SSLを使用するようにNginxを構成する

/etc/sslディレクトリの下にキーファイルと証明書ファイルを作成しました。これらを利用するには、Nginx構成を変更する必要があります。

構成にいくつかの調整を加えます。

SSLキーと証明書ファイルの場所を含む構成スニペットを作成します。
将来的に任意の証明書で使用できる強力なSSL設定を含む構成スニペットを作成します。
Nginxサーバーブロックを調整してSSLリクエストを処理し、上記の2つのスニペットを使用します。

Nginxを構成するこの方法により、サーバーブロックをクリーンに保ち、共通の構成セグメントを再利用可能なモジュールに配置できます。

SSLキーと証明書を指す構成スニペットの作成

まず、/etc/nginx/snippetsディレクトリに新しいNginx構成スニペットを作成しましょう。

このファイルの目的を正しく区別するために、self-signed.confと呼びましょう。

sudo nano /etc/nginx/snippets/self-signed.conf

このファイル内で、ssl_certificateディレクティブを証明書ファイルに設定し、ssl_certificate_keyを関連するキーに設定する必要があります。私たちの場合、これは次のようになります。

/etc/nginx/snippets/self-signed.conf

ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;

これらの行を追加したら、ファイルを保存して閉じます。

強力な暗号化設定を使用した構成スニペットの作成

次に、いくつかのSSL設定を定義する別のスニペットを作成します。これにより、Nginxに強力なSSL暗号スイートが設定され、サーバーの安全性を維持するのに役立ついくつかの高度な機能が有効になります。

設定するパラメーターは、将来のNginx構成で再利用できるため、ファイルに一般的な名前を付けます。

sudo nano /etc/nginx/snippets/ssl-params.conf

Nginx SSLを安全にセットアップするために、Cipherli.stサイトのRemyvanElstによる推奨事項を使用します。このサイトは、人気のあるソフトウェアの使いやすい暗号化設定を提供するように設計されています。

上記にリンクされているサイトで推奨される設定は、強力なセキュリティを提供します。場合によっては、これにはクライアントの互換性が向上するという犠牲が伴います。古いクライアントをサポートする必要がある場合は、「はい、レガシー/古いソフトウェアで動作する暗号スイートを教えてください」というラベルの付いたページのリンクをクリックしてアクセスできる代替リストがあります。そのリストは、以下にコピーされたアイテムの代わりに使用できます。

使用する構成の選択は、サポートする必要があるものに大きく依存します。どちらも優れたセキュリティを提供します。

私たちの目的のために、提供された設定全体をコピーすることができます。いくつかの小さな変更を加える必要があります。

まず、アップストリームリクエスト用に優先DNSリゾルバーを追加します。このガイドではGoogleを使用します。

次に、厳密なトランスポートセキュリティヘッダーを設定する行をコメントアウトします。この行のコメントを解除する前に、 HTTP Strict Transport Security（HSTS 、特にの「プリロード」機能についてお読みください。 HSTSをプリロードするとセキュリティが向上しますが、誤って有効にした場合や誤って有効にした場合は、広範囲に及ぶ結果が生じる可能性があります。

以下をssl-params.confスニペットファイルにコピーします。

/etc/nginx/snippets/ssl-params.conf

ssl_protocols TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/nginx/dhparam.pem;
ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;
ssl_ecdh_curve secp384r1; # Requires nginx >= 1.1.0
ssl_session_timeout  10m;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off; # Requires nginx >= 1.5.9
ssl_stapling on; # Requires nginx >= 1.3.7
ssl_stapling_verify on; # Requires nginx => 1.3.7
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
# Disable strict transport security for now. You can uncomment the following
# line if you understand the implications.
# add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";

自己署名証明書を使用しているため、SSLステープルは使用されません。 Nginxは警告を出力しますが、正常に動作し続けます。

終了したら、ファイルを保存して閉じます。

SSLを使用するようにNginx構成を調整する

スニペットができたので、Nginx構成を調整してSSLを有効にすることができます。

このガイドでは、/etc/nginx/sites-availableディレクトリにあるカスタムサーバーブロック構成ファイルを使用していることを前提としています。この例では、/etc/nginx/sites-available/example.comを使用します。必要に応じて、構成ファイル名に置き換えてください。

先に進む前に、現在の構成ファイルをバックアップしましょう。

sudo cp /etc/nginx/sites-available/example.com /etc/nginx/sites-available/example.com.bak

次に、構成ファイルを開いて調整を行います。

sudo nano /etc/nginx/sites-available/example.com

内部では、サーバーブロックはおそらく次のように始まります。

/etc/nginx/sites-available/example.com

server {
    listen 80;
    listen [::]:80;

    server_name example.com www.example.com;

    root /var/www/example.com/html;
    index index.html index.htm index.nginx-debian.html;

    . . .
}

ファイルの順序が異なる場合があり、rootおよびindexディレクティブの代わりに、location、proxy_pass、またはその他のカスタム構成ステートメントがある場合があります。。 listenディレクティブを更新し、SSLスニペットを含めるだけでよいので、これは問題ありません。この既存のサーバーブロックを変更して、ポート443でSSLトラフィックを処理し、新しいサーバーブロックを作成して、ポート80で応答し、トラフィックをポート443に自動的にリダイレクトします。

注：すべてが正しく機能していることを確認するまで、302リダイレクトを使用します。その後、これを永続的な301リダイレクトに変更できます。

既存の構成ファイルで、2つのlistenステートメントを更新してポート443とSSLを使用し、前の手順で作成した2つのスニペットファイルを含めます。

/etc/nginx/sites-available/example.com

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    include snippets/self-signed.conf;
    include snippets/ssl-params.conf;

    server_name example.com www.example.com;

    root /var/www/example.com/html;
    index index.html index.htm index.nginx-debian.html;

    . . .
}

次に、最初のブロックの閉じ括弧（}）の後に、2番目のサーバーブロックを構成ファイルに貼り付けます。

/etc/nginx/sites-available/example.com

. . .
server {
    listen 80;
    listen [::]:80;

    server_name example.com www.example.com;

    return 302 https://$server_name$request_uri;
}
```

This is a bare-bones configuration that listens on port 80 and performs the redirect to HTTPS. Save and close the file when you are finished editing it.

## Step 3 — Adjusting the Firewall

If you have the `ufw` firewall enabled, as recommended by the prerequisite guides, you'll need to adjust the settings to allow for SSL traffic. Luckily, Nginx registers a few profiles with `ufw` upon installation.

We can see the available profiles by typing:

```command
sudo ufw app list

次のようなリストが表示されます。

OutputAvailable applications:
. . .
  Nginx Full
  Nginx HTTP
  Nginx HTTPS
. . .

次のように入力すると、現在の設定を確認できます。

sudo ufw status

おそらく次のようになります。つまり、WebサーバーへのHTTPトラフィックのみが許可されます。

OutputStatus: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
Nginx HTTP                 ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)
Nginx HTTP (v6)            ALLOW       Anywhere (v6)

さらにHTTPSトラフィックを取り込むために、「Nginx Full」プロファイルを許可してから、冗長な「NginxHTTP」プロファイルの許可を削除できます。

sudo ufw allow 'Nginx Full'
sudo ufw delete allow 'Nginx HTTP'

ステータスは次のようになります。

sudo ufw status

OutputStatus: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
Nginx Full                 ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)
Nginx Full (v6)            ALLOW       Anywhere (v6)

ステップ4—Nginxでの変更を有効にする

変更を加えてファイアウォールを調整したので、Nginxを再起動して新しい変更を実装できます。

まず、ファイルに構文エラーがないことを確認する必要があります。これを行うには、次のように入力します。

sudo nginx -t

すべてが成功すると、次のような結果が得られます。

Outputnginx: [warn] "ssl_stapling" ignored, issuer certificate not found
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

最初の警告に注意してください。前述のように、自己署名証明書はSSLステープルを使用できないため、この特定の設定は警告をスローします。これは予想されることであり、サーバーは接続を正しく暗号化できます。

出力が上記と一致する場合、構成ファイルに構文エラーはありません。 Nginxを安全に再起動して、変更を実装できます。

sudo systemctl restart nginx

ステップ5—暗号化のテスト

これで、SSLサーバーをテストする準備が整いました。

Webブラウザーを開き、https://に続けて、サーバーのドメイン名またはIPをアドレスバーに入力します。

https://server_domain_or_IP

作成した証明書は、ブラウザの信頼できる認証局の1つによって署名されていないため、次のような恐ろしい警告が表示される可能性があります（Google Chromeを使用している場合は次のように表示されます）。

Nginx self-signed cert warning

これは予想された正常なことです。証明書の暗号化の側面にのみ関心があり、ホストの信頼性のサードパーティによる検証には関心がありません。「詳細」をクリックしてから、提供されたリンクをクリックして、とにかくホストに進みます。

Nginx self-signed override

あなたはあなたのサイトに連れて行かれるべきです。ブラウザのアドレスバーを見ると、「x」が付いたロックが表示されます。この場合、これは単に証明書を検証できないことを意味します。それはまだあなたの接続を暗号化しています。

2つのサーバーブロックでNginxを構成し、HTTPコンテンツをHTTPSに自動的にリダイレクトする場合は、リダイレクトが正しく機能するかどうかを確認することもできます。

http://server_domain_or_IP

これで同じアイコンが表示される場合は、リダイレクトが正しく機能したことを意味します。

ステップ6—永続的なリダイレクトへの変更

リダイレクトが正しく機能し、暗号化されたトラフィックのみを許可する場合は、Nginx構成を変更してリダイレクトを永続的にする必要があります。

サーバーブロック構成ファイルを再度開きます。

sudo nano /etc/nginx/sites-available/example.com

return 302を見つけて、return 301に変更します。

/etc/nginx/sites-available/example.com

	return 301 https://$server_name$request_uri;

ファイルを保存して閉じます。

構文エラーがないか構成を確認してください。

sudo nginx -t

準備ができたら、Nginxを再起動して、リダイレクトを永続的にします。

sudo systemctl restart nginx

結論

クライアント接続に強力な暗号化を使用するようにNginxサーバーを構成しました。これにより、リクエストを安全に処理できるようになり、外部の関係者がトラフィックを読み取るのを防ぐことができます。

getdocs

13036