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

投稿日: 2019-11-08 2022-10-23
タグ: CentOS, nginx, Security

序章

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

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

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

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

この制限のため、自己署名証明書は、一般にサービスを提供する実稼働環境には適していません。これらは通常、テスト、または代替通信チャネルを介して証明書の有効性の信頼を確立できる単一のユーザーまたは少数のユーザーグループが使用する重要ではないサービスを保護するために使用されます。

より本番環境に対応した証明書ソリューションについては、無料の認証局である Let’sEncryptを確認してください。 Let’s Encrypt証明書をダウンロードして構成する方法については、 CentOS7チュートリアルでLet’sEncrypt証明書を使用してNginxを設定する方法をご覧ください。

前提条件

このチュートリアルを完了するには、次のものが必要です。

非rootユーザーがで構成されたCentOSサーバー sudo CentOS7チュートリアルの初期サーバーセットアップで説明されている特権。
CentOS7にNginxをインストールする方法で説明されているようにサーバーにインストールされたNginx。

開始する準備ができたら、サーバーにログインします。 sudo ユーザー。

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

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

The /etc/ssl/certs 公開証明書を保持するために使用できるディレクトリは、サーバー上にすでに存在している必要があります。を作成する必要があります /etc/ssl/private ディレクトリも、秘密鍵ファイルを保持します。このキーの機密性はセキュリティにとって不可欠であるため、不正アクセスを防ぐためにアクセス許可をロックダウンすることが重要です。

sudo mkdir /etc/ssl/private
sudo chmod 700 /etc/ssl/private

これで、次のように入力することで、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

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

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

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

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

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

Output
Country Name (2 letter code) [XX]:US
State or Province Name (full name) []:Example
Locality Name (eg, city) [Default City]:Example 
Organization Name (eg, company) [Default Company Ltd]:Example Inc
Organizational Unit Name (eg, section) []:Example Dept
Common Name (eg, your name or your server's hostname) []:your_domain_or_ip
Email Address []:[email protected]

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

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

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

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

これには数分かかる場合がありますが、完了すると、強力なDHグループが作成されます。 /etc/ssl/certs/dhparam.pem 構成で使用できます。

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

CentOSのデフォルトのNginx構成はかなり構造化されておらず、デフォルトのHTTPサーバーブロックはメイン構成ファイル内にあります。 Nginxはで終わるファイルをチェックします .conf の中に /etc/nginx/conf.d 追加構成用のディレクトリ。

このディレクトリに新しいファイルを作成して、生成した証明書ファイルを使用してコンテンツを提供するサーバーブロックを構成します。次に、オプションで、HTTP要求をHTTPSにリダイレクトするようにデフォルトのサーバーブロックを構成できます。

TLS/SSLサーバーブロックを作成する

と呼ばれるファイルを作成して開きます ssl.conf の中に /etc/nginx/conf.d ディレクトリ：

sudo vi /etc/nginx/conf.d/ssl.conf

内部では、開くことから始めます server ブロック。デフォルトでは、TLS / SSL接続はポート443を使用するため、これが listen ポート。 The server_name 証明書の生成時に共通名として使用したサーバーのドメイン名またはIPアドレスに設定する必要があります。次に、 ssl_certificate, ssl_certificate_key、と ssl_dhparam 生成したSSLファイルの場所を設定するためのディレクティブ：

/etc/nginx/conf.d/ssl.conf

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

    server_name your_server_ip;

    ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
    ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;
    ssl_dhparam /etc/ssl/certs/dhparam.pem;
}

次に、サイトのセキュリティを強化するSSLオプションをいくつか追加します。使用するオプションは、Cipherlist.euからの推奨事項です。このサイトは、人気のあるソフトウェアの使いやすい暗号化設定を提供するように設計されています。

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

上記の構成の2つのコメントブロック間のデフォルトの提案の代わりに、互換性リストを使用できます。使用する構成の選択は、サポートする必要があるものに大きく依存します。

変更したい構成がいくつかあります。まず、アップストリームリクエスト用の優先DNSリゾルバーをに追加できます resolver 指令。このガイドではGoogleを使用しましたが、他の設定がある場合はこれを変更できます。

最後に、 HTTP Strict Transport Security（HSTS ）、特にの「プリロード」機能についてお読みください。 HSTSをプリロードするとセキュリティが向上しますが、誤って有効にした場合や誤って有効にした場合は、広範囲に及ぶ結果が生じる可能性があります。このガイドでは、設定をプリロードしませんが、影響を確実に理解している場合は、設定を変更できます。

/etc/nginx/conf.d/ssl.conf

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

    server_name your_server_ip;

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

    ########################################################################
    # from https://cipherlist.eu/                                            #
    ########################################################################
    
    ssl_protocols TLSv1.3;# Requires nginx >= 1.13.0 else use TLSv1.2
    ssl_prefer_server_ciphers on;
    ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
    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 preloading HSTS for now.  You can use the commented out header line that includes
    # the "preload" directive 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";
    ##################################
    # END https://cipherlist.eu/ BLOCK #
    ##################################
}

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

最後に、サイトの残りのNginx構成を追加します。これは、ニーズによって異なります。例のデフォルトのロケーションブロックで使用されているディレクティブの一部をコピーするだけで、ドキュメントルートといくつかのエラーページが設定されます。

/etc/nginx/conf.d/ssl.conf

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

    server_name your_server_ip;

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

    ########################################################################
    # from https://cipherlist.eu/                                            #
    ########################################################################
    
    . . .
    
    ##################################
    # END https://cipherlist.eu/ BLOCK #
    ##################################

    root /usr/share/nginx/html;

    location / {
    }

    error_page 404 /404.html;
    location = /404.html {
    }

    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
    }
}

終了したら、保存して終了します。これにより、生成されたSSL証明書を使用してトラフィックを暗号化するようにNginxが構成されます。指定されたSSLオプションにより、最も安全なプロトコルと暗号のみが使用されるようになります。この設定例は単にデフォルトのNginxページを提供するだけなので、ニーズに合わせて変更することをお勧めします。

HTTPからHTTPSへのリダイレクトを作成する（オプション）

現在の構成では、Nginxはポート443でのリクエストに対して暗号化されたコンテンツで応答しますが、ポート80でのリクエストに対しては暗号化されていないコンテンツで応答します。これは、サイトが暗号化を提供しているが、その使用を強制していないことを意味します。これは一部のユースケースでは問題ない場合がありますが、通常は暗号化を要求する方が適切です。これは、パスワードなどの機密データがブラウザとサーバー間で転送される可能性がある場合に特に重要です。

ありがたいことに、デフォルトのNginx構成ファイルを使用すると、デフォルトのポート80サーバーブロックにディレクティブを簡単に追加できます。これを行うには、の先頭にこれを挿入します ssl.conf:

/etc/nginx/conf.d/ssl.conf

server {
    listen 80;
    listen [::]:80;
    server_name your_server_ip;
    return 301 https://$host$request_uri;
}

. . .

終了したら、ファイルを保存して閉じます。これにより、ポート80（デフォルト）サーバーブロックでHTTPが構成され、構成したHTTPSサーバーブロックに着信要求がリダイレクトされます。

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

Nginxプロセスが再起動され、構成したSSL設定が実装されます。

ステップ4—暗号化をテストする

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

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

https://server_domain_or_IP

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

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

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

HTTPリクエストをHTTPSにリダイレクトするようにNginxを構成した場合は、リダイレクトが正しく機能するかどうかを確認することもできます。

http://server_domain_or_IP

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

結論

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

getdocs

13036