「インストール - Nginx(RHEL)」の版間の差分

ナビゲーションに移動 検索に移動
1,011行目: 1,011行目:
  sudo systemctl restart nginx
  sudo systemctl restart nginx
  sudo systemctl reload  nginx
  sudo systemctl reload  nginx
<br><br>
== HTTPS(SSL)の設定 (Let's Encrypt) ==
==== Let's Encryptとは ====
[https://letsencrypt.org/ Let's Encrypt](Linux Foundationの協業プロジェクト)は、Web全体の安全性を改善することを掲げており、<br>
発行料無料のSSL/TLSサーバ証明書を取得することができる。<br>
<br>
Let's Encryptでは、 一般的なドメイン認証(DV)の証明書を無料で発行しており、<br>
その中間証明書は、大手認証局(CA)のルート証明書によってクロス署名されているため、多くの主要ブラウザ等々で信頼済みとして扱われる。<br>
<br>
なお、1回の認証で得られる証明書の有効期限は90日である。<br>
したがって、90日以内に証明書の更新を、再度実施する必要がある。<br>
<br>
==== Certbotクライアントのインストール ====
証明書を取得するため、Certbotクライアントをインストールする。<br>
sudo dnf install certbot
<br>
==== 証明書の取得 ====
<u>Apache2やNginX等のWebサーバが稼働していることが前提となることに注意する。</u><br>
<u>また、インターネット側から、証明書を使用するWebサーバ(証明書を取得するFQDNのサーバ)のTCP80番ポートを開放することも前提となる。</u><br>
<br>
* <code>--webroot -w</code>オプション
*: 稼働中のWebサーバのドキュメントルート配下を認証用の一時領域に使用する。
*: 例. <code>--webroot -w <ドキュメントルート> -d <証明書を取得するFQDN></code>
*: <br>
*: 証明書を取得するFQDNが複数ある場合は、<code>-d <証明書を取得するFQDN></code>を複数指定できる。
*: 例. hoge.comとpiyo.comの2つについて取得する場合
*: <code>-d hoge.com -d piyo.com</code>
*: <br>
* FQDN (Fully Qualified Domain Name)
*: <ホスト名>.<ドメイン名>を省略せずに記述する。
*: <br>
<br>
ドキュメントルートは、仮想ホストで複数のホスト定義がある場合、該当するホスト定義のものを指定する。<br>
ドキュメントルート指定の動作としては、指定したドキュメントルート配下に.well-knownディレクトリが作成されて、認証用のファイルが自動的かつ一時的に設置される。<br>
<br>
証明書を取得する。<br>
certbot certonly --webroot -w <ドキュメントルートのパス> -d <FQDN>
# または
sudo certbot certonly --webroot -w <ドキュメントルートのパス> -d <FQDN>
例.
sudo certbot certonly --webroot -w /srv/www/htdocs -d www.hoge.com
<br>
初回のみメールアドレスの登録と利用条件への同意が必要となる。<br>
# 受信可能なメールアドレスを指定する
(Enter 'c' to cancel): <メールアドレス>
# 利用条件に同意する
(A)gree/(C)ancel: A
# 非営利団体 Electronic Frontier Foundation にもメールアドレスを登録するか否か
(Y)es/(N)o: Y
<br>
最後に、"Congratulations"と表示されると成功である。<br>
<br>
上記のメッセージに表示される通り、/etc/letsencrypt/live/<FQDN>ディレクトリ内に、4つの証明書が保存される。<br>
* cert.pem
*: SSLサーバー証明書(公開鍵含む)
* chain.pem
*: 中間証明書
* fullchain.pem
*: cert.pemファイルとchain.pemファイルが結合されたファイル
* privkey.pem
*: 公開鍵に対する秘密鍵
<br>
証明書を使用するWebサーバが未稼働の場合でも、Certbotの簡易Webサーバ機能を使用して(<code>--standalone</code>オプションを付加する)、証明書を取得することができる。<br>
<u>この場合も、インターネット側から証明書を使用するWebサーバのTCP80番ポートを開放する必要がある。</u><br>
certbot certonly --standalone -d <FQDN>
# または
sudo certbot certonly --standalone -d <FQDN>
例.
sudo certbot certonly --standalone -d www.hoge.com
<br>
==== 取得済みの証明書の更新 ====
有効期限が30日未満の証明書を全て更新する。<br>
もし、有効期限の残り日数に関わらずに更新する場合は、<code>--force-renew</code>オプションも付加する。<br>
certbot renew
# または
sudo certbot renew
<br><br>
== エラー関連 ==
==== test failed ====
Webサイトにアクセスする時、<u>"test failed"</u>というエラーメッセージが表示される場合がある。<br>
これは、NginXの初期設定ではIPv4とIPv6をリッスンするが、使用しているWebサーバがIPv6をサポートしていない場合に起きる。<br>
<br>
nginx.confファイルにおいて、IPv6を使用しないように設定する。<br>
vi nginx.conf
<br>
# nginx.confファイル
# 編集前
listen [::]:80 default_server;
# 編集後
# listen [::]:80 default_server;
<br>
NginXを再読み込みする。<br>
sudo systemctl reload nginx
<br><br>
== HTTPS(SSL)の設定 ==
==== CSRについて ====
CSR(Certificate Signing Request)とは、証明書発行要求といい、認証局に対して行う、認証局の秘密鍵で署名してもらうためのリクエストのことである。<br>
<br>
CSRの中身を確認するためには、<code>req</code>コマンドに<code>-text</code>オプションを付加することで確認できる。<br>
openssl req -text -in <サーバ証明書のファイル名>.csr
# 出力例
Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=JP, ST=TOKYO, L=KAWASAKI, O=Kaisha, OU=Busho, CN=common.name
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                (省略)
    Signature Algorithm: sha256WithRSAEncryption
                (省略)
<br>
上記の出力例において、[Signature Algorithm]項目は、sha256WithRSAEncryptionである。<br>
SHA-1は解読されるリスクが高まっているため、今後作成するものはSHA-2とするべきである。<br>
<br>
SHA-2には、SHA-224、SHA-256、SHA-384、SHA-512の4種類がある。<br>
SHA-512が最も安全性が高いが、クライアント端末側がSHA-512に対応している必要がある。<br>
<br>
==== 自己署名証明書の発行(サーバ側) ====
===== 秘密鍵を作成する =====
openssl genrsa -out <秘密鍵のファイル名>.key 2048
<br>
秘密鍵のファイルのアクセス権限を変更する。<br>
chmod 400 <秘密鍵のファイル名>.key
<br>
===== CSR(証明書署名要求)の作成 =====
作成した秘密鍵を使用して、クライアント側のCSRを作成する。<br>
openssl req -sha256 -new -subj "/C=JP/ST=Tokyo/L=Tokyo City/O=Company Name/OU=Department/CN=*.<ドメイン名>" -key <秘密鍵のファイル名>.key -out <CSRのファイル名>.csr
<br>
===== SAN (Subject Alternative Name)の作成 =====
サーバ証明書に自己署名証明書を使用する場合、クライアントPCに自己署名証明書をインストールしても、Webブラウザ(Chrome等)は警告を表示する。<br>
これは、Chrome等のWebブラウザは、コモンネーム(CN)ではなく、SAN(Subject Alternative Name)を確認しているからである。<br>
そのため、SANを加えて自己署名証明書を作成する必要がある。<br>
<br>
<u>※注意</u><br>
<u>DNS項目ではワイルドカードが使用できるが、IP項目では使用できないことに注意する。</u><br>
vi san.txt  # ファイル名は任意
<br>
# san.txtファイル
subjectAltName = DNS:localhost,*.localhost,*.example.com IP:127.0.0.1,172.20.0.1
<br>
===== サーバ証明書の作成 =====
作成したCSRに署名を行って、サーバ証明書を発行する。<br>
<u><サーバ証明書のファイル名>.csrファイルは、サーバ証明書を発行するためのファイルのため、後で削除してもよい。</u><br>
openssl x509 -sha256 -req -days <証明書の有効日数 例. 3650> -in <CSRのファイル名>.csr -signkey <秘密鍵のファイル名>.key \
        -extfile san.txt \
        -out <サーバ証明書のファイル名>.crt
<br>
===== Webサーバの設定 =====
Webサーバに設置するものは、秘密鍵(.key拡張子)とサーバ証明書(.crt拡張子)の2つである。<br>
<br>
SSLを有効にするため、NginXの設定ファイルを編集する。<br>
# パッケージ管理システムからインストールしている場合
sudo vi /etc/nginx/nginx.conf
# ソースコードからインストールしている場合
sudo vi /<Nginxのインストールディレクトリ>/etc/nginx.conf
<br>
<syntaxhighlight lang="nginx">
# HTTPS server
server {
    listen      443 ssl;  # HTTP/2を有効にする場合は、http2と追記する
    server_name  <ホスト名またはIPアドレスまたはドメイン名>;
    # サーバ証明書および中間証明書のファイルの指定
    ssl_certificate      <サーバ証明書のファイルのフルパス>;
    # 秘密鍵の指定
    ssl_certificate_key  <秘密鍵のファイルのフルパス>;
    ssl_session_cache    shared:SSL:1m;
    ssl_session_timeout  5m;
    ssl_ciphers  HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers  on;
    location / {
        root  <ドキュメントルートのパス(絶対パスまたは相対パス)>;
        index  index.html index.htm;
    }
}
</syntaxhighlight>
<br>
<u>ロードバランサにSSL証明書を設置して、SSL接続を終端することもできる。</u><br>
<u>その場合、サーバ証明書は1つ用意して、ロードバランサからWebサーバまでの通信はhttpとなる。(httpsでも可能であるが、httpの方が負荷が軽いため)</u><br>
<br>
<u>httpを使用するメリットとして、Webサーバで受けるアクセスがhttpとなるので負荷が減るためである。(暗号化された通信を複合するために、SSLの接続を受けるのは負荷が掛かる)</u><br>
<br>
==== 自己証明書の発行(クライアント側) ====
===== 秘密鍵を作成する =====
openssl genrsa -out <秘密鍵のファイル名>.key 2048
<br>
秘密鍵のファイルのアクセス権限を変更する。<br>
chmod 400 <秘密鍵のファイル名>.key
<br>
===== CSR(証明書署名要求) =====
作成した秘密鍵を使用して、クライアント側のCSRを作成する。<br>
openssl req -sha256 -new -subj "/C=JP/ST=Tokyo/L=Tokyo City/O=Company Name/OU=Department/CN=*.<ドメイン名>" \
                          -key <秘密鍵のファイル名>.key -out <CSRのファイル名>.csr
<br>
===== SAN (Subject Alternative Name)の作成 =====
サーバ証明書に自己署名証明書を使用する場合、クライアントPCに自己署名証明書をインストールしても、Webブラウザ(Chrome等)は警告を表示する。<br>
これは、Chrome等のWebブラウザは、コモンネーム(CN)ではなく、SAN(Subject Alternative Name)を確認しているからである。<br>
そのため、SANを加えて自己署名証明書を作成する必要がある。<br>
<br>
<u>※注意</u><br>
<u>DNS項目ではワイルドカードが使用できるが、IP項目ではワイルドカードが使用できないことに注意する。</u><br>
vi san.txt  # ファイル名は任意
<br>
# san.txtファイル
subjectAltName = DNS:localhost,*.localhost,*.example.com IP:127.0.0.1,172.20.0.1
<br>
===== サーバ証明書の作成 =====
作成したCSRに署名を行って、サーバ証明書を発行する。<br>
<u><サーバ証明書のファイル名>.csrファイルは、サーバ証明書を発行するためのファイルのため、後で削除してもよい。</u><br>
openssl x509 -sha256 -req -days <証明書の有効日数 例. 3650> -in <CSRのファイル名>.csr -signkey <秘密鍵のファイル名>.key \
        -extfile san.txt \
        -out <サーバ証明書のファイル名>.crt
<br>
<u>クライアントPCがWindowsの場合、Windows PCにインポートするには、サーバ証明書のファイル(.crt拡張子)をpkcs12形式に変換する必要がある。</u><br>
openssl pkcs12 -export -inkey <秘密鍵のファイル名>.key -in <サーバ証明書のファイル名>.crt \
                        -out <クライアント側にインポートするサーバ証明書のファイル名>.p12 -name <任意の識別子名>
<br>
===== Webサーバの設定 =====
<u>サーバに設置するものは、サーバ証明書のファイル(.crt拡張子)と秘密鍵(.key拡張子)の2つである。</u><br>
<u>Windows PC(クライアントPC)へ配布するものは、pkcs12形式に変換したクライアント側のサーバ証明書のファイル(.p12拡張子)である。</u><br>
<br>
Windows PCへクライアント側のサーバ証明書のファイル(.p12拡張子)をインポートする場合、ファイルを実行することによりインポート画面が起動するため、<br>
インポート画面に沿って、サーバ証明書のファイル(.p12拡張子)をインポートする。<br>
<br><br>
<br><br>


案内メニュー