開発者ドキュメント

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

getdocs

序章

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

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

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

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

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

前提条件

このチュートリアルに従うには、次のものが必要です。

前提条件を完了したら、最初のステップに進みます。

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

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

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

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

このコマンドの各部分の機能の内訳は次のとおりです。

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

プロンプトに適切に記入します。 最も重要な行は、共通名を要求する行です（例： サーバー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グループも作成する必要があります。

これを行うには、次を実行します。

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

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

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

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

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

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

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

まず、お好みのテキストエディタを使用して、新しいNginx構成スニペットを作成します。 /etc/nginx/snippets ディレクトリ。 次の例では、 nano:

このファイルの目的を正しく区別するには、名前を付けます self-signed.conf:

  1. 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;

これらの行を追加したら、ファイルを保存してエディターを終了します。 使用した場合 nano、を押すことでこれを行うことができます CTRL + X、 それから Y、 と ENTER.

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

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

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

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

Nginx SSLを安全にセットアップするために、Cipherlist.euの推奨事項を採用します。 Cipherlist.eu は、一般的なソフトウェアで使用されている暗号化設定を理解するための便利でわかりやすいリソースです。

注： Cipherlist.eu から推奨される設定は、強力なセキュリティを提供します。 場合によっては、これにはクライアントの互換性が向上するという犠牲が伴います。 古いクライアントをサポートする必要がある場合は、「はい、レガシー/古いソフトウェアで動作する暗号スイートを教えてください」というラベルの付いたページのリンクをクリックしてアクセスできる代替リストがあります。 必要に応じて、そのリストを次のサンプルコードブロックのコンテンツに置き換えることができます。

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

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

まず、アップストリームリクエスト用に優先DNSリゾルバーを追加します。 Googleの（8.8.8.8 と 8.8.4.4）このガイドの場合。

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

以下をあなたのに追加してください ssl-params.conf スニペットファイル：

/etc/nginx/snippets/ssl-params.conf
ssl_protocols TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/nginx/dhparam.pem; 
ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
ssl_ecdh_curve secp384r1;
ssl_session_timeout  10m;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
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 ディレクトリ。 このガイドは、前提条件のNginxチュートリアルの規則に従い、使用します /etc/nginx/sites-available/your_domain この例では。 必要に応じて、構成ファイル名に置き換えてください。

先に進む前に、現在の構成ファイルをバックアップしてください。

  1. sudo cp /etc/nginx/sites-available/your_domain /etc/nginx/sites-available/your_domain.bak

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

  1. sudo nano /etc/nginx/sites-available/your_domain

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

/etc/nginx/sites-available/your_domain.com
server {
    listen 80;
    listen [::]:80;

    server_name your_domain www.your_domain.com;

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

    . . .
}

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

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

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

/etc/nginx/sites-available/your_domain.com
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    include snippets/self-signed.conf;
    include snippets/ssl-params.conf;

    server_name your_domain.com www.your_domain.com;

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

    . . .
}

次に、閉じ括弧の後に2番目のサーバーブロックを構成ファイルに追加します（}）最初のブロックの：

/etc/nginx/sites-available/your_domain.com
. . .
server {
    listen 80;
    listen [::]:80;

    server_name your_domain.com www.your_domain.com;

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

これは、ポートでリッスンする最低限の構成です 80 HTTPSへのリダイレクトを実行します。 編集が終了したら、ファイルを保存して閉じます。

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

あなたが持っている場合 ufw ファイアウォールが有効になっている場合、前提条件ガイドで推奨されているように、SSLトラフィックを許可するように設定を調整する必要があります。 幸いなことに、Nginxはいくつかのプロファイルを登録しています ufw インストール時に。

次のコマンドを実行して、使用可能なプロファイルを確認できます。

  1. sudo ufw app list

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

Output
Available applications:
  Nginx Full
  Nginx HTTP
  Nginx HTTPS
  OpenSSH

次のように入力して、現在の設定を確認することもできます sudo ufw status:

  1. sudo ufw status

おそらく次の出力が生成されます。つまり、WebサーバーへのHTTPトラフィックのみが許可されます。

Output
Status: active

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

HTTPSトラフィックを許可するには、「NginxFull」プロファイルの権限を更新できます。

  1. sudo ufw allow 'Nginx Full'

次に、冗長な「NginxHTTP」プロファイルの許容値を削除します。

  1. sudo ufw delete allow 'Nginx HTTP'

走った後 sudo ufw status、次の出力が表示されます。

  1. sudo ufw status



Output
Status: active

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

この出力は、ファイアウォールの調整が成功し、Nginxで変更を有効にする準備ができていることを確認します。

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

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

まず、ファイルに構文エラーがないことを確認します。 あなたは実行することによってこれを行うことができます sudo nginx -t:

  1. sudo nginx -t

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

Output
nginx: [warn] "ssl_stapling" ignored, issuer certificate not found for certificate "/etc/ssl/certs/nginx-selfsigned.crt"
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

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

出力がこの例と一致する場合、構成ファイルに構文エラーはないはずです。 この場合、Nginxを安全に再起動して変更を実装できます。

  1. sudo systemctl restart nginx

新しい変更でシステムが再起動されたので、テストに進むことができます。

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

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

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

https://server_domain_or_IP

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

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

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

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

http://server_domain_or_IP

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

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

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

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

  1. sudo nano /etc/nginx/sites-available/your_domain.com

を見つける return 302 に変更します return 301:

/etc/nginx/sites-available/your_domain.com
	return 301 https://$server_name$request_uri;

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

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

  1. sudo nginx -t

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

  1. sudo systemctl restart nginx

再起動後、変更が実装され、リダイレクトが永続的になります。

結論

クライアント接続に強力な暗号化を使用するようにNginxサーバーを構成しました。 これにより、リクエストを安全に処理し、外部の第三者がトラフィックを読み取るのを防ぐことができます。 または、無料のTLS / SSL証明書をインストールし、Webサーバーで暗号化されたHTTPSを有効にする認証局であるLet’sEncryptから取得できる自己署名SSL証明書を使用することもできます。 詳細については、 Ubuntu18.04でLet’sEncryptを使用してNginxを保護する方法に関するチュートリアルをご覧ください。

モバイルバージョンを終了