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

前書き

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

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

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

[。注意]##

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

サーバーにドメイン名が関連付けられていない場合や、暗号化されたWebインターフェースがユーザー向けではない場合には、自己署名証明書が適切な場合があります。 doにドメイン名がある場合、多くの場合、CA署名付き証明書を使用することをお勧めします。 無料の信頼できる証明書を設定する方法については、setting up Nginx with a Let’s Encrypt certificate on CentOS 7
に関するガイドに従ってください。

前提条件

まず、root以外のユーザーにsudo権限を設定する必要があります。 initial server setup for CentOS 7をフォローすることで、このようなユーザーアカウントを設定する方法を学ぶことができます。

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

手順1:Nginxをインストールしてファイアウォールを調整する

開始する前に、Nginx Webサーバーがマシンにインストールされていることを確認する必要があります。

NginxはCentOSのデフォルトのリポジトリでは利用できませんが、isはEPEL(Enterprise Linux用の追加パッケージ)リポジトリにあります。 次のように入力して、EPELリポジトリを有効にして、サーバーにNginxパッケージへのアクセスを許可できます。

sudo yum install epel-release

次に、次のように入力してNginxをインストールできます。

sudo yum install nginx

次のように入力して、Nginxサービスを開始します。

sudo systemctl start nginx

次のように入力して、サービスが稼働していることを確認します。

systemctl status nginx
Output● nginx.service - The nginx HTTP and reverse proxy server
   Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled; vendor preset: disabled)
   Active: active (running) since Fri 2017-01-06 17:27:50 UTC; 28s ago

. . .

Jan 06 17:27:50 centos-512mb-nyc3-01 systemd[1]: Started The nginx HTTP and reverse proxy server.

また、Nginxを有効にして、サーバーの起動時に起動するようにすることもできます。

sudo systemctl enable nginx
OutputCreated symlink from /etc/systemd/system/multi-user.target.wants/nginx.service to /usr/lib/systemd/system/nginx.service.

次に、ファイアウォールでポート80および443へのアクセスをブロックしていないことを確認する必要があります。 ファイアウォールを使用していない場合は、次のセクションに進んでください。

firewalldファイアウォールを実行している場合は、次のように入力してこれらのポートを開くことができます。

sudo firewall-cmd --add-service=http
sudo firewall-cmd --add-service=https
sudo firewall-cmd --runtime-to-permanent

iptablesファイアウォールを実行している場合、実行する必要のあるコマンドは、現在のルールセットに大きく依存します。 基本的なルールセットの場合、次のように入力してHTTPおよびHTTPSアクセスを追加できます。

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

これで、Webブラウザを介してデフォルトのNginxページにアクセスできるようになります。

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

TLS/SSL works by using a combination of a public certificate and a private key. SSLキーはサーバー上で秘密にされます。 クライアントに送信されるコンテンツを暗号化するために使用されます。 SSL証明書は、コンテンツを要求するすべてのユーザーと公開共有されます。 関連するSSLキーで署名されたコンテンツを復号化するために使用できます。

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

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

これで、次のように入力して、単一のコマンドで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は、サーバーの起動時にユーザーの介入なしにファイルを読み取ることができる必要があります。 パスフレーズは、再起動のたびにパスフレーズを入力する必要があるため、これを防ぐことができます。

  • -days 365:このオプションは、証明書が有効であると見なされる時間の長さを設定します。 ここで1年間設定しました。

  • -newkey rsa:2048:これは、新しい証明書と新しいキーを同時に生成することを指定します。 前の手順で証明書に署名するために必要なキーを作成しなかったため、証明書と共に作成する必要があります。 rsa:2048部分は、2048ビット長のRSAキーを作成するように指示します。

  • -keyout:この行は、作成している生成された秘密鍵ファイルを配置する場所をOpenSSLに指示します。

  • -out:これは、作成する証明書を配置する場所をOpenSSLに指示します。

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

プロンプトに適切に記入します。 The most important line is the one that requests the Common Name (e.g. server FQDN or YOUR name). You need to enter the domain name associated with your server or your server’s public IP address.

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

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 []:[email protected]_domain.com

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

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

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

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

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

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

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

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

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

/etc/nginx/conf.dディレクトリにssl.confというファイルを作成して開きます。

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

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

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

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

    server_name server_IP_address;

    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オプションを追加します。 使用するオプションは、Cipherli.stサイトのRemy van Elstからの推奨事項です。 このサイトは、一般的なソフトウェアの使いやすい暗号化設定を提供するように設計されています。 Strong SSL Security on nginxを読むことで、Nginxの選択に関する彼の決定について詳しく知ることができます。

[。注意]##

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

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

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

最後に、HTTP Strict Transport Security, or HSTSについて、特に“preload” functionalityについて読んでください。 HSTSをプリロードするとセキュリティが向上しますが、誤って有効にしたり誤って有効にしたりすると、広範囲に及ぶ結果を招く可能性があります。 このガイドでは、設定をプリロードしませんが、その意味を理解していることが確実な場合は設定を変更できます。

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

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

    server_name server_IP_address;

    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://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 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 Strict-Transport-Security "max-age=63072000; includeSubdomains";
    add_header X-Frame-Options DENY;
    add_header X-Content-Type-Options nosniff;

    ##################################
    # END https://cipherli.st/ BLOCK #
    ##################################
}

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

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

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

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

    server_name server_IP_address;

    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://cipherli.st/                                            #
    # and https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html #
    ########################################################################

    . . .

    ##################################
    # END https://cipherli.st/ 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構成ファイルを使用すると、/etc/nginx/default.dディレクトリにファイルを追加することで、デフォルトのポート80サーバーブロックにディレクティブを簡単に追加できます。 ssl-redirect.confという名前の新しいファイルを作成し、次のコマンドで編集できるように開きます。

sudo vi /etc/nginx/default.d/ssl-redirect.conf

次に、この行に貼り付けます。

/etc/nginx/default.d/ssl-redirect.conf

return 301 https://$host$request_uri/;

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

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

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

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

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

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

https://server_domain_or_IP

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

Nginx self-signed cert warning

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

Nginx self-signed override

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

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

http://server_domain_or_IP

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

結論

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

Related