Ubuntu18.04でNginxの自己署名SSL証明書を作成する方法
序章
TLS 、つまりトランスポート層セキュリティ、およびその前身である SSL は、セキュアソケットレイヤーの略で、通常のトラフィックを保護された暗号化ラッパーでラップするために使用されるWebプロトコルです。
このテクノロジーを使用すると、サーバーは、メッセージが外部の関係者によって傍受される可能性なしに、サーバーとクライアントの間でトラフィックを安全に送信できます。 証明書システムは、ユーザーが接続しているサイトのIDを確認するのにも役立ちます。
このガイドでは、Ubuntu18.04サーバー上のNginxWebサーバーで使用するための自己署名SSL証明書を設定する方法を示します。
注:自己署名証明書は、サーバーとクライアント間の通信を暗号化します。 ただし、Webブラウザに含まれている信頼できる認証局(CA)のいずれによっても署名されていないため、ユーザーは証明書を使用してサーバーのIDを自動的に検証することはできません。
サーバーにドメイン名が関連付けられていない場合や、暗号化されたWebインターフェイスがユーザー向けでない場合は、自己署名証明書が適切な場合があります。 do にドメイン名がある場合、多くの場合、CA署名付き証明書を使用することをお勧めします。 Let’sEncryptプロジェクトここで無料の信頼できる証明書を設定する方法を見つけることができます。
前提条件
このチュートリアルに従うには、次のものが必要です。
- root以外のユーザーで構成された1つのUbuntu18.04サーバー
sudo
特権とファイアウォール。 Ubuntu 18.04 の初期サーバー設定に従うことで、このようなユーザーアカウントを設定する方法を学ぶことができます。 - また、NginxWebサーバーをインストールする必要があります。 LEMP(Linux、Nginx、MySQL、PHP)スタック全体をサーバーにインストールする場合は、 Ubuntu18.04でのLEMPのセットアップに関するガイドに従ってください。
- Nginx Webサーバーのみが必要な場合は、代わりに Ubuntu18.04への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
このコマンドの各部分の機能の内訳は次のとおりです。
sudo
:sudo
コマンドは、のメンバーを許可しますsudo
グループを使用して、特権を別のユーザー(スーパーユーザー、またはデフォルトでは root ユーザー)の特権に一時的に昇格させます。 この場合、証明書とキーのペアを作成しているので、これが必要です。/etc/
ディレクトリ。rootユーザーまたは他の特権アカウントのみがアクセスできます。openssl
:これは、OpenSSL証明書、キー、およびその他のファイルを作成および管理するための基本的なコマンドラインツールです。req
:このサブコマンドは、X.509証明書署名要求(CSR)管理を使用することを指定します。 X.509 は、SSLおよびTLSが鍵と証明書の管理のために準拠している公開鍵インフラストラクチャ標準です。 新しいX.509証明書を作成したいので、このサブコマンドを使用しています。-x509
:これは、通常行われるように証明書署名要求を生成するのではなく、自己署名証明書を作成することをユーティリティに通知することにより、前のサブコマンドをさらに変更します。-nodes
:これは、パスフレーズで証明書を保護するオプションをスキップするようにOpenSSLに指示します。 サーバーの起動時に、ユーザーの介入なしにNginxがファイルを読み取れるようにする必要があります。 パスフレーズは、再起動するたびに入力する必要があるため、これが発生するのを防ぎます。-days 365
:このオプションは、証明書が有効であると見なされる時間の長さを設定します。 ここで1年間設定しました。-newkey rsa:2048
:これは、新しい証明書と新しいキーを同時に生成することを指定します。 前の手順で証明書に署名するために必要なキーを作成しなかったため、証明書と一緒に作成する必要があります。 Thersa:2048
部分は、2048ビット長のRSAキーを作成するように指示します。-keyout
:この行は、作成している生成された秘密鍵ファイルを配置する場所をOpenSSLに指示します。-out
:これは、作成する証明書を配置する場所をOpenSSLに指示します。
前に述べたように、これらのオプションはキーファイルと証明書の両方を作成します。 このコマンドを実行すると、情報を証明書に正しく埋め込むために、サーバーに関するいくつかの質問が表示されます。
プロンプトに適切に記入します。
プロンプト全体は次のようになります。
OutputCountry 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
これにはしばらく時間がかかりますが、完了すると、強力な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
:
- sudo nano /etc/nginx/snippets/self-signed.conf
このファイル内で、 ssl_certificate
証明書ファイルへのディレクティブと ssl_certificate_key
関連するキーに。 これは次のようになります。
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構成で再利用できるため、ファイルに一般的な名前を付けることができます。
- 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
スニペットファイル:
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
この例では。 必要に応じて、構成ファイル名に置き換えてください。
先に進む前に、現在の構成ファイルをバックアップしてください。
- sudo cp /etc/nginx/sites-available/your_domain /etc/nginx/sites-available/your_domain.bak
次に、構成ファイルを開いて調整を行います。
- sudo nano /etc/nginx/sites-available/your_domain
内部では、サーバーブロックはおそらく次のように始まります。
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つのスニペットファイルを含めます。
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番目のサーバーブロックを構成ファイルに追加します(}
)最初のブロックの:
. . .
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
インストール時に。
次のコマンドを実行して、使用可能なプロファイルを確認できます。
- sudo ufw app list
次のようなリストが出力に表示されます。
OutputAvailable applications:
Nginx Full
Nginx HTTP
Nginx HTTPS
OpenSSH
次のように入力して、現在の設定を確認することもできます sudo ufw status
:
- 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トラフィックを許可するには、「NginxFull」プロファイルの権限を更新できます。
- sudo ufw allow 'Nginx Full'
次に、冗長な「NginxHTTP」プロファイルの許容値を削除します。
- sudo ufw delete allow 'Nginx HTTP'
走った後 sudo ufw status
、次の出力が表示されます。
- 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)
この出力は、ファイアウォールの調整が成功し、Nginxで変更を有効にする準備ができていることを確認します。
ステップ4—Nginxでの変更を有効にする
ファイアウォールの変更と調整が完了したら、Nginxを再起動して新しい変更を実装できます。
まず、ファイルに構文エラーがないことを確認します。 あなたは実行することによってこれを行うことができます sudo nginx -t
:
- sudo nginx -t
すべてが成功すると、次のような結果が得られます。
Outputnginx: [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を安全に再起動して変更を実装できます。
- 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構成を変更してリダイレクトを永続的にする必要があります。
サーバーブロック構成ファイルを再度開きます。
- sudo nano /etc/nginx/sites-available/your_domain.com
を見つける return 302
に変更します return 301
:
return 301 https://$server_name$request_uri;
ファイルを保存して閉じます。
構文エラーがないか構成を確認してください。
- sudo nginx -t
準備ができたら、Nginxを再起動して、リダイレクトを永続的にします。
- sudo systemctl restart nginx
再起動後、変更が実装され、リダイレクトが永続的になります。
結論
クライアント接続に強力な暗号化を使用するようにNginxサーバーを構成しました。 これにより、リクエストを安全に処理し、外部の第三者がトラフィックを読み取るのを防ぐことができます。 または、無料のTLS / SSL証明書をインストールし、Webサーバーで暗号化されたHTTPSを有効にする認証局であるLet’sEncryptから取得できる自己署名SSL証明書を使用することもできます。 詳細については、 Ubuntu18.04でLet’sEncryptを使用してNginxを保護する方法に関するチュートリアルをご覧ください。