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

前書き

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

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

このガイドでは、Debian 8サーバー上のNginx Webサーバーで使用する自己署名SSL証明書をセットアップする方法を示します。

前提条件

始める前に、 `+ sudo +`権限で設定された非rootユーザーが必要です。 Debian 8の初期サーバー設定に従って、このようなユーザーアカウントを設定する方法を学ぶことができます。

また、Nginx Webサーバーをインストールする必要があります。 サーバーにLEMP(Linux、Nginx、MySQL、PHP)スタック全体をインストールする場合は、https://www.digitalocean.com/community/tutorials/how-to-install-linuxのガイドに従ってください。 -nginx-mysql-php-lemp-stack-on-debian-8 [Debian 8でのLEMPのセットアップ]。

Nginx Webサーバーだけが必要な場合は、代わりにhttps://www.digitalocean.com/community/tutorials/how-to-install-nginx-on-debian-8[Debian 8へのNginxのインストール]のガイドに従ってください。 。

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

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

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

単一のコマンドで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に、作成する証明書を配置する場所を伝えます。

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

プロンプトに適切に記入します。 最も重要な行は、「+ Common Name」を要求する行です(例: サーバーのFQDNまたは自分の名前)+ `。 サーバーに関連付けられているドメイン名、またはサーバーのパブリックIPアドレスを入力する必要があります。

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

OutputCountry Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:

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

OpenSSLを使用している間、クライアントとhttps://en.wikipedia.org/wiki/Forward_secrecy[Perfect Forward Secrecy]の交渉に使用される強力なDiffie-Hellmanグループも作成する必要があります。

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

sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

これには数分かかる場合がありますが、完了すると、「+ / etc / ssl / certs / dhparam.pem +」に強力なDHグループができます。これを設定で使用できます。

手順2:SSLを使用するようにNginxを構成する

`+ / etc / ssl +`ディレクトリの下にキーと証明書ファイルを作成しました。 これらを利用するには、Nginxの設定を変更するだけです。

構成をいくつか調整します。

  1. SSLキーと証明書ファイルの場所を含む構成スニペットを作成します。

  2. 将来的に任意の証明書で使用できる強力なSSL設定を含む構成スニペットを作成します。

  3. 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を安全にセットアップするには、https://cipherli.st [Cipherli.st]サイトでhttps://raymii.org/s/static/About.html[Remy van Elst]の推奨事項を使用します。 このサイトは、一般的なソフトウェアの使いやすい暗号化設定を提供するように設計されています。 Nginxの選択肢に関する彼の決定については、https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html [こちら]をご覧ください。

この目的のために、提供された設定全体をコピーできます。 少し修正するだけです。

まず、アップストリームリクエストに優先DNSリゾルバを追加します。 このガイドではGoogleを使用します。 また、先に生成したDiffie-Hellmanファイルを指すように `+ ssl_dhparam +`設定を設定します。

最後に、https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security [HTTP Strict Transport Security、またはHSTS]、特にhttps://hstspreload.appspot.com/ ["を読んでください。プリロード」機能]。 HSTSをプリロードするとセキュリティが向上しますが、誤って有効にしたり誤って有効にしたりすると、広範囲に及ぶ結果を招く可能性があります。 このガイドでは、設定をプリロードしませんが、その意味を理解していることが確実な場合は変更できます。

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

# from https://cipherli.st/
# and https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
ssl_ecdh_curve secp384r1;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
resolver  valid=300s;
resolver_timeout 5s;


add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";

add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;

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

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

Nginx構成を調整してSSLを使用する

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

このガイドでは、 `+ / etc / nginx / sites-available `ディレクトリにある ` default +`サーバーブロックファイルを使用していると仮定します。 別のサーバーブロックファイルを使用している場合は、以下のコマンドでその名前を置き換えてください。

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

sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/default.bak

次に、サーバーブロックファイルを開いて調整します。

sudo nano /etc/nginx/sites-available/default

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

/ etc / nginx / sites-available / default

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

   # SSL configuration

   # listen 443 ssl default_server;
   # listen [::]:443 ssl default_server;

   . . .

暗号化されていないHTTP要求が暗号化されたHTTPSに自動的にリダイレクトされるように、この構成を変更します。 これにより、サイトに最高のセキュリティが提供されます。 HTTPトラフィックとHTTPSトラフィックの両方を許可する場合は、次の代替構成を使用します。

構成を2つの個別のブロックに分割します。 最初の2つの「+ listen 」ディレクティブの後に、サーバーのドメイン名、またはより可能性の高いIPアドレスを設定する「 server_name +」ディレクティブを追加します。 次に、作成する2番目のサーバーブロックへのリダイレクトを設定します。 その後、この短いブロックを閉じます。

/ etc / nginx / sites-available / default

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




   # SSL configuration

   # listen 443 ssl default_server;
   # listen [::]:443 ssl default_server;

   . . .

次に、すぐ下に新しいサーバーブロックを起動して、残りの構成を含める必要があります。 ポート443を使用する2つの `+ listen +`ディレクティブのコメントを外すことができます。 その後、設定した2つのスニペットファイルを含めるだけです。

/ etc / nginx / sites-available / default

server {
   listen 80 default_server;
   listen [::]:80 default_server;
   server_name ;
   return 302 https://$server_name$request_uri;
}



   # SSL configuration






   . . .

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

(代替構成)HTTPおよびHTTPSトラフィックの両方を許可する

暗号化されたコンテンツと暗号化されていないコンテンツの両方を許可する必要がある場合、またはNginxを少し異なるように構成する必要があります。 これは、回避できる場合は一般的に推奨されませんが、状況によっては必要になる場合があります。 基本的に、2つの個別のサーバーブロックを1つのブロックに圧縮し、リダイレクトを削除します。

/ etc / nginx / sites-available / default

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



   server_name ;



   . . .

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

ステップ3:ファイアウォールを調整する

ファイアウォールを有効にしている場合は、SSLトラフィックを許可するように設定を調整する必要があります。 必要な手順は、使用しているファイアウォールソフトウェアによって異なります。 現在ファイアウォールが設定されていない場合は、お気軽にスキップしてください。

UFW

  • ufw *を使用している場合は、次のように入力して現在の設定を確認できます。

sudo ufw status

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

OutputStatus: active

To                         Action      From
--                         ------      ----
SSH                        ALLOW       Anywhere
WWW                        ALLOW       Anywhere
SSH (v6)                   ALLOW       Anywhere (v6)
WWW (v6)                   ALLOW       Anywhere (v6)

さらにHTTPSトラフィックを許可するには、「WWW Full」プロファイルを許可してから、冗長な「WWW」プロファイル許可を削除します。

sudo ufw allow 'WWW Full'
sudo ufw delete allow 'WWW'

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

sudo ufw status
OutputStatus: active

To                         Action      From
--                         ------      ----
SSH                        ALLOW       Anywhere
WWW Full                   ALLOW       Anywhere
SSH (v6)                   ALLOW       Anywhere (v6)
WWW Full (v6)              ALLOW       Anywhere (v6)

これで、HTTPS要求がサーバーで受け入れられます。

IPTables

`+ iptables +`を使用している場合、次のように入力して現在のルールを確認できます。

sudo iptables -S

有効にしたルールがある場合は、それらが表示されます。 設定例は次のようになります。

Output-P INPUT DROP
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

SSLトラフィックを開くために必要なコマンドは、現在のルールによって異なります。 上記のような基本的なルールセットの場合、次のように入力してSSLアクセスを追加できます。

sudo iptables -I INPUT -p tcp -m tcp --dport 443 -j ACCEPT

ファイアウォールルールをもう一度見ると、新しいルールが表示されます。

sudo iptables -S
Output-P INPUT DROP
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

起動時にプログラムを使用して `+ iptables +`ルールを自動的に適用する場合、新しいルールで設定を更新することを確認する必要があります。

ステップ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

これで、サーバーにHTTPS経由でアクセスできるようになります。

ステップ5:暗号化をテストする

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

ウェブブラウザを開き、アドレスバーに「+ https:// +」と入力してからサーバーのドメイン名またはIPを入力します。

https://

作成した証明書はブラウザの信頼できる認証局のいずれかによって署名されていないため、次のような恐ろしい警告が表示される可能性があります。

image:https://assets.digitalocean.com/articles/nginx_ssl_1604/self_signed_warning.png [Nginx自己署名証明書の警告]

これは予想される正常な動作です。 証明書の暗号化の側面のみに関心があり、ホストの信頼性の第三者検証には関心がありません。 [詳細]をクリックし、表示されるリンクをクリックしてホストに進みます:

image:https://assets.digitalocean.com/articles/nginx_ssl_1604/warning_override.png [Nginx自己署名オーバーライド]

あなたのサイトに連れて行く必要があります。 ブラウザのアドレスバーを見ると、部分的なセキュリティの兆候が表示されます。 これは、その上に「x」が付いたロック、または感嘆符が付いた三角形です。 この場合、これは単に証明書を検証できないことを意味します。 接続を暗号化しています。

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

http://

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

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

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

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

sudo nano /etc/nginx/sites-available/default

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

/ etc / nginx / sites-available / default

server {
   listen 80 default_server;
   listen [::]:80 default_server;
   server_name ;
   return  https://$server_name$request_uri;
}

. . .

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

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

sudo nginx -t

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

sudo systemctl restart nginx

HTTP経由でアクセスすると、サイトは永続的なリダイレクトを発行するようになります。

結論

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

Related