インストール - Nginx(RHEL)

提供：MochiuWiki : SUSE, EC, PCB
2024年12月26日 (木) 09:02時点におけるWiki (トーク | 投稿記録)による版 (→‎Xdebugの設定)
(差分) ← 古い版 | 最新版 (差分) | 新しい版 → (差分)
ナビゲーションに移動 検索に移動

概要

NginXとは、Apacheと並ぶWebサーバソフトウェアの1つであり、処理速度や機能面で注目を集めている。

NginXのメリットを、以下に示す。

  • 高速である。
  • 大量処理が得意である。
  • Webサイトの利用を向上させる機能が豊富である。
  • 設定が容易である。


Webサーバに同時に複数のアクセスがあった場合、下表に示すように動作の違いがある。

動作方法の違いによる処理速度の向上
Apache 2 NginX
同時・複数アクセスへの対処方法 1アクセスに対して、1つの対応 複数のアクセスに対して、1つの対応にまとまる
アクセス急増時のサーバへの負荷 一気に負荷が増す アクセスに比例して負荷は急激に増えない
その結果のWebサーバの挙動 動作が遅くなり、ダウンしやすくなる 処理速度を維持して、ダウンしにくい


例えば、Webサーバの負担を軽くして処理速度を上げる手段として、リバースプロキシやロードバランサー等があり、これらを実現する場合、Nginxが向いている。

NginXのデメリットを、以下に示す。

  • 大量の動的コンテンツの処理に不向き
    一般的には、大量の動的コンテンツの公開(動画を中心としたWebサイト等)には向かないことがNginXのデメリットとして挙げられる。
    ただし、比較的小規模のWebサイトを運営する場合は、それほど神経質にならなくてもよい。

  • 機能追加のしやすさ
    専用のモジュールを追加することにより、Nginxも機能を拡張することができる。
    ただし、Apacheの方が、実装方法について比較的充実し、情報が豊富でわかりやすい。

    Apache モジュール一覧
    https://httpd.apache.org/docs/trunk/ja/mod/
    NGINX 3rd Party Modules
    https://www.nginx.com/resources/wiki/modules/

  • 初心者向けの設定情報の少なさ
    設定等の情報が少ない。


参考書
A1nwYPPNb8L._SL1500_.jpg
nginx実践ガイド
IT技術者のための現場ノウハウ
61LbDMjddRL._SL1000_.jpg
nginx実践入門
高速/安定稼働を実現する構築と運用のテクニック
61ZE51+HyfL._SL1000_.jpg
Nginx ポケットリファレンス
81V8A5I4p4L._SL1500_.jpg
Nginx HTTP Server
Nginxを利用して、高速なページ配信を実現する



NginXのインストール

パッケージ管理システムからインストール

まず、システムの更新を行う。

sudo dnf update


次に、NginXをインストールする。
NginXは、RHELの公式リポジトリからインストールできる。
ただし、常に最新バージョンが提供されるとは限らない。

sudo dnf install nginx


NginXサービスを自動起動する。

sudo systemctl enable nginx


NginXを開始する。

sudo systemctl start nginx


NginXのステータスを確認する場合は、次のコマンドを実行する。

sudo sytemctl status nginx


ソースコードからインストール

NginXのビルドに必要なライブラリをインストールする。

sudo dnf install libxslt-devel pcre2-devel gd-devel
                 GeoIP-devel                         # GeoIPを使用する場合
                 libcurl-devel                       # Passengerを使用する場合
                 kernel-headers kernel-devel         # AIOを使用する場合


必要ならば、OpenSSLの公式Webサイトにアクセスして、OpenSSL(1.X.Y)のソースコードをダウンロードする。
ダウンロードしたファイルを解凍する。

tar xf openssl-<バージョン>


  • Digest認証モジュールを使用する場合
    NginXのソースコードと一緒に配布されていないため、別途インストールする必要がある。
    Digest認証モジュールのGithubにアクセスして、ソースコードをダウンロードする。
    ダウンロードしたファイルを解凍する。
    tar xf nginx-http-auth-digest-<バージョン>.tar.gz

    または、git cloneコマンドを実行して、ソースコードをダウンロードする。
    git clone https://github.com/atomx/nginx-http-auth-digest.git

  • Passengerモジュールを使用する場合 (Rails連携)
    NginXのソースコードと一緒に配布されていないため、別途インストールする必要がある。
    Passengerモジュールの公式webサイトにアクセスして、ソースコードをダウンロードする。
    ダウンロードしたファイルを解凍する。
    tar xf passenger-<バージョン>.tar.gz
    cd passenger-<バージョン>


NginX 1.9.11以降から、configureスクリプト実行時において、
--add-module=<PATH>オプションの代わりに--add-dynamic-module=<PATH>オプションを使用して、モジュールを動的モジュールとしてコンパイルすることができる。
そして、load_moduleディレクティブを使用して、nginx.confファイルで明示的にモジュールをロードすることができる。

load_module /path/to/modules/<モジュール名>.so;


NginXの公式Webサイトにアクセスして、NginXのソースコードをダウンロードする。
ダウンロードしたファイルを解凍する。

tar xf nginx-<バージョン>.tar.xz
cd nginx-<バージョン>


NginXをビルドおよびインストールする。

Digest認証モジュールも併せてビルドおよびインストールする場合、
configureスクリプトにおいて、--add-module=<Digest認証モジュールのソースコードがあるディレクトリ>オプションを付加する。

NginXのビルドにおいて、ビルドディレクトリを作成すると失敗することに注意する。

export NGINX_DIR=<NginXのインストールディレクトリ>

./configure \
--prefix=$NGINX_DIR \
--sbin-path=$NGINX_DIR/sbin/nginx \
--conf-path=$NGINX_DIR/etc/nginx.conf \
--pid-path=$NGINX_DIR/nginx.pid \
--modules-path=$NGINX_DIR/modules/ \
--error-log-path=$NGINX_DIR/log/error.log \
--http-log-path=$NGINX_DIR/log/access.log \
--lock-path=$NGINX_DIR/nginx.lock \
--http-client-body-temp-path=$NGINX_DIR/tmp/ \
--http-proxy-temp-path=$NGINX_DIR/proxy/ \
--http-fastcgi-temp-path=$NGINX_DIR/fastcgi/ \
--http-uwsgi-temp-path=$NGINX_DIR/uwsgi/ \
--http-scgi-temp-path=$NGINX_DIR/scgi/ \
--with-perl_modules_path=$NGINX_DIR/Perl \
--with-threads --with-file-aio --with-pcre --with-pcre-jit \
--with-http_v2_module --with-http_ssl_module --with-http_addition_module --with-http_realip_module --with-http_flv_module \
--with-http_random_index_module --with-http_degradation_module --with-http_slice_module  --with-http_dav_module --with-http_mp4_module \
--with-http_xslt_module --with-http_xslt_module=dynamic \
--with-http_image_filter_module --with-http_image_filter_module=dynamic \
--with-http_geoip_module=dynamic --with-http_gunzip_module --with-http_gzip_static_module \
--with-http_auth_request_module --with-http_secure_link_module --with-http_stub_status_module --with-http_sub_module \
--with-http_perl_module --with-http_perl_module=dynamic \
--with-mail --with-mail=dynamic --with-mail_ssl_module \
--with-stream=dynamic --with-stream_ssl_module --with-stream_realip_module --with-stream_ssl_preread_module \
--with-compat \
--user=<任意のユーザ名  例. nginx> \
--group=<任意のグループ名  例. nginx>

# 不要の可能性あり
--without-poll_module --without-select_module --with-ipv6

# Digest認証を使用する場合
--add-module=<Digest認証モジュールのソースコードがあるディレクトリ>

# Passengerを使用する場合
--add-module=/<Passengerモジュールのディレクトリ>/src/nginx-module

# GCCコンパイラを指定する場合
--with-cc=/<gcc実行ファイルがあるディレクトリ>/gcc \
--with-cpp=/<g++実行ファイルがあるディレクトリ>/g++

# OpenSSLを手動で設定する場合に記述する
--with-openssl=<上記でダウンロードおよび解凍したOpenSSLのソースコードのトップディレクトリ>

# 以下の設定はAIOを使用する場合に記述する
--with-cc-opt='-fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchron ous-unwind-tables -fstack-clash-protection -g -fPIC -D_GNU_SOURCE' \
--with-ld-opt='-Wl,-z,relro,-z,now -pie'

make -j $(nproc)
make install


configureスクリプト実行時において、--user=<ユーザ名>および--group=<グループ名>を付加した場合、それぞれユーザとグループを作成する必要がある。

sudo useradd --system --no-create-home --user-group --shell /sbin/nologin nginx


Systemdサービスユニットを作成しない場合、NginXを開始するには、以下のコマンドを実行する。

cd <NginXのインストールディレクトリ>/sbin
sudo ./nginx


Systemdサービスユニットを作成しない場合、NginXを停止するには、以下のコマンドを実行する。

  • 方法 1
    cd <NginXのインストールディレクトリ>/sbin
    sudo ./nginx -s stop
    または
    sudo ./nginx -s quit

  • 方法 2
    まず、NginXのプロセスIDを確認する。
    ps aux | grep -i nginx
    NginXを停止する。
    sudo kill <プロセスID 1> <プロセスID 2>


Systemdサービスユニットを作成しない場合、NginXを再起動するには、以下のコマンドを実行する。

cd <NginXのインストールディレクトリ>/sbin
sudo ./nginx -s reload
# または
sudo ./nginx -s reopen


Systemdサービスユニットを作成する場合、/etc/systemd/systemディレクトリに、以下に示すような内容で作成する。

sudo vi /etc/systemd/system/nginx.service



# /etc/systemd/system/nginx.serviceファイル

[Unit]
Description=The nginx HTTP and reverse proxy server
After=network-online.target remote-fs.target nss-lookup.target
Wants=network-online.target

[Service]
PIDFile=/<NginXのインストールディレクトリ>/nginx.pid
ExecStartPre=/<NginXのインストールディレクトリ>/sbin/nginx -t
ExecStart=/<NginXのインストールディレクトリ>/sbin/nginx -g "daemon off;"
ExecReload=/bin/kill -s HUP $MAINPID
KillSignal=SIGQUIT
TimeoutStopSec=5
KillMode=mixed
PrivateTmp=true

# added automatically, for details please see
ProtectSystem=full
#ProtectHome=read-only
PrivateDevices=true
ProtectHostname=true
ProtectClock=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectKernelLogs=true
ProtectControlGroups=true
RestrictRealtime=true
# end of automatic additions 

[Install]
WantedBy=multi-user.target


NginXを開始する。

sudo systemctl start nginx


NginXを停止する。

sudo systemctl stop nginx


NginXを再起動する。

sudo systemctl restart nginx


NginXを自動起動する。

sudo systemctl enable nginx


NginXの設定ファイルの内容を変更した時、変更を反映させるためにNginXを再読み込みする。

sudo systemctl reload nginx



動的モジュール

NginXは多数のモジュールから構成されており、NginXのビルド時にモジュールがNginXバイナリにスタティックに組み込まれる。
追加したいモジュールがある場合も同様、NginXのビルド時にそのモジュールを指定することにより、NginXバイナリにそのモジュールがスタティックに組み込まれる。

過去のNginXにおいては、モジュールを追加・変更するたびに、NginX本体をビルドし直す必要があり、運用が煩雑であった。

しかし、NginX 1.9.11以降では、動的モジュールがサポートされて、動的モジュールを使用時（NginXの起動およびリロード）に組み込むことができるようになった。

例えば、NginXの設定ファイル(nginx.confファイル)において、load_moduleディレクティブの値として、動的モジュールの共有オブジェクトファイルのパスを指定して、
NginXを起動あるいはリロードすることにより、動的モジュールを使用できるようになる。

 load_module "modules/foo_module.so";


load_moduleディレクティブの記述場所はmainコンテキストである。
また、各ブロック（events、http、stream、mail）よりも前に記述する必要があることに注意する。

 user  nginx;
 worker_processes  1;
 
 load_module "modules/ngx_stream_module.so";
 load_module "modules/ngx_http_geoip_module.so";
 
 events {
    worker_connections  1024;
 }
 
 http {
    # ...略
 }


もし、各ブロック（events、http、stream、mail）よりも前に記述した場合は、以下に示すようなエラーが出力される。

# 出力例

nginx: [emerg] "load_module" directive is specified too late in /usr/local/nginx/conf/nginx.conf:16


NginXの標準モジュール全てが動的モジュールとして使用できるわけではない。
現行のバージョンでは、以下に示すモジュールが動的モジュールとして使用することができる。

  • XSLT (ngx_http_xslt_module)
  • Image Filter (ngx_http_image_filter_module)
  • GeoIP (ngx_http_geoip_module)
  • Mail (ngx_mail_module)
  • Stream (ngx_stream_module)


また、サードパーティ製モジュールも動的モジュールとして使用できるが、configureスクリプトの修正が必要となるため、動的モジュールへの対応をサポートしているモジュール以外は、そのままでは使用できない。

現行バージョンでは、動的モジュール単体のみをビルドすることはできないため、動的モジュールをビルドするためには、NginX本体をビルドする手順とほぼ同じ手順を行う必要がある。
なお、将来的には、モジュール単体をビルドできるようにする計画がある。


NginXのディレクトリ構造

NginXのファイル、ディレクトリ、およびコマンドは、NginXを使用するために知っておくべき重要なものである。

  • /etc/nginxディレクトリ
    /etc/nginx/ディレクトリは、NginXのデフォルトの設定ルートである。
    このディレクトリ内には、NginXの動作を設定するファイルがある。

  • /etc/nginx/nginx.confファイル
    /etc/nginx/nginx.confファイルは、NginXで使用されるデフォルトの設定エントリポイントである。
    この構成ファイルは、ワーカープロセス、チューニング、ロギング、動的モジュールのロード、および他のNginX構成ファイルへの参照等の全体に及ぶ設定を行う。
    デフォルトの設定では、/etc/nginx/nginx.confファイルはトップレベルのhttpブロック、またはコンテキストを含み、次に説明するディレクトリの全ての設定ファイルを含む。

  • /etc/nginx/conf.dディレクトリ
    /etc/nginx/conf.dディレクトリは、デフォルトのHTTPサーバの設定ファイルを保存するディレクトリである。
    このディレクトリ内の.confで終わるファイルは、/etc/nginx/nginx.confファイル内のトップレベルのhttpブロックにおいて、include文を使用して設定が管理されている。
    環境によっては、このディレクトリをsites-enabledという名前にして、設定ファイルをsite-availableというディレクトリからリンクしている場合もある。（非推奨）

  • /var/log/nginxディレクトリ
    /var/log/nginxディレクトリは、NginXのデフォルトのログの場所である。
    このディレクトリには、access.logファイルとerror.logファイルがある。
    access.logファイルには、NginXが提供する各リクエストのエントリが含まれる。
    error.logファイルには、エラーイベントとデバッグモジュールが有効になっている場合のデバッグ情報が含まれる。



NginXのコマンド

  • nginx -h
    NginXのヘルプメニューを表示する。

  • nginx -v
    NginXのバージョンを表示する。

  • nginx -V
    NginXのバージョン、ビルド情報、設定引数を表示する。
    また、ビルドされたモジュールを表示する。

  • nginx -t
    NginXの設定をテストする。

  • nginx -T
    NginXの設定をテストして、検証された設定を画面に表示する。
    このコマンドは、サポートを求める場合に便利である。

  • nginx -s <シグナル名>
    -sオプションは、NginXのマスタープロセスにシグナルを送信する。
    stop、quit、reload、reopen等のシグナルを送信することができる。

    stopシグナルは、NginXプロセスを直ちに中止する。
    quitシグナルは、NginXプロセスが実行要求されている処理を終了した後に停止する。
    reloadシグナルは、設定を再読み込みする。
    reopenシグナルは、ログファイルを再開するようNginXに指示する。



ファイアウォールの設定

次に、ファイアウォール設定にいくつかの変更を加えて、httpサービスを許可する。

sudo firewall-cmd --permanent --add-port=80/tcp
sudo firewall-cmd --reload



Nginxのテスト

Nginxが正しく実行されていることを確認する。
これを行うには、htmlファイルを作成し、それをNginxのルートディレクトリに配置する必要がある。
テキストエディタで以下のファイルを作成する。

 sudo nano /srv/www/htdocs/index.html
 
 <html>
 <body>
 <h1>Welcome to osradar</h1>
 </body>
 </html>


最後に、Webブラウザを開き、http://localhost/ にアクセスして、これが表示されるか確認する。


NginX上でPHP-FPM(PHP 7 / 8)の有効化

NginXにはPHPモジュールが無いため、CGIによりプログラムを動作させている。
PHPをNginX上で動作させるためには、PHP-FPM(PHP-FastCGI Process Manager)に対して、設定を行う必要がある。

必要な場合、PHP-FPMのソケットファイルを配置するディレクトリを作成する。

mkdir /<PHPのインストールディレクトリ>/var/run/php-fpm


PHP-FPMの構成ディレクトリ(/etc/php7/fpm)にあるphp-fpm.confファイルのerror_logキーを以下のように編集する。

# PHP 7
sudo cp /etc/php7/fpm/php-fpm.conf.default /etc/php7/fpm/php-fpm.conf

# PHP 8
sudo cp /etc/php8/fpm/php-fpm.conf.default /etc/php8/fpm/php-fpm.conf



# PHP 7
sudo vi /etc/php7/fpm/php-fpm.conf

# PHP 8
sudo vi /etc/php8/fpm/php-fpm.conf



# /etc/php7/fpm/php-fpm.confファイル または /etc/php8/fpm/php-fpm.confファイル

error_log = /var/log/php-fpm.log


次に、www.conf構成ファイルで構成済みプールの正しい設定を定義する。 

# PHP 7
sudo cp /etc/php7/fpm/php-fpm.d/www.conf.default /etc/php7/fpm/php-fpm.d/www.conf

# PHP 8
sudo cp /etc/php8/fpm/php-fpm.d/www.conf.default /etc/php8/fpm/php-fpm.d/www.conf



# PHP 7
sudo vi /etc/php7/fpm/php-fpm.d/www.conf

# PHP 8
sudo vi /etc/php8/fpm/php-fpm.d/www.conf



# /etc/php7/fpm/php-fpm.d/www.confファイル または /etc/php8/fpm/php-fpm.d/www.confファイル

user = <Nginxの実行ユーザ名 (例. nginx)>
group = <Nginxの実行グループ名 (例. nginx)>
listen = <nginx.confファイルで設定したfastcgi_passの値 (例. /var/run/php-fpm/php-fpm.sock)>
listen.owner = <PHP-FPMの実行ユーザ名 (例. nginx)>
listen.group = <PHP-FPMの実行グループ名 (例. nginx)>


次に、/etc/php7/cli/php.iniファイル、または、/etc/php8/cli/php.iniファイルを作成・編集する。

# PHP 7
sudo vi /etc/php7/cli/php.ini

# PHP 8
sudo vi /etc/php8/cli/php.ini



# /etc/php7/cli/php.iniファイル または /etc/php8/cli/php.iniファイル
cgi.fix_pathinfo=0


----- 以下に示す箇所は不要の可能性あり -----
次に、/etc/php7/fpm/php.iniファイルを作成・編集する。
php.iniファイルをコピーして、php.iniファイルのcgi.fixキーを編集する。

sudo cp /etc/php7/cli/php.ini /etc/php7/fpm/



sudo vi /etc/php7/fpm/php.ini

# /etc/php7/fpm/php.iniファイル
cgi.fix_pathinfo=0


そして、/etc/php7/fpm/php.iniファイルをPHP構成ディレクトリにコピーする。

sudo cp /etc/php7/fpm/php.ini /etc/php7/conf.d/

----- ここまで -----


NginXの設定

NginXを構成するため、NginXの設定ファイルを、以下に示すような内容で作成または編集する。

# パッケージ管理システムからインストールしている場合
sudo vi /etc/nginx/conf.d/default.conf
または
sudo vi /etc/nginx/conf.d/<任意のファイル名>.conf  # サーバ設定ファイルを新規作成する場合

# ソースコードからインストールしている場合
sudo vi /<Nginxのインストールディレクトリ>/etc/nginx.conf



 # default.confファイル
 
 # NginXのPIDファイルの場所
 #pid        /tmp/nginx.pid;
 
 # 使用するCPUのプロセス数
 # CPUのコア数より多く設定してもパフォーマンスは上がらない
 worker_processes  1;
 
 # エラーログの指定
 # ログレベルは低い順にdebug, info, notice, warn, error, crit, alert, emerg
 error_log  log/error.log  info;
 
 events {
    worker_connections  1024;
 }
 
 http {
    # ...略
 
    # 設定ファイルの読み込み
    #include /etc/nginx/conf.d/ssl.conf
    #include /etc/nginx/vhost.d/*.conf
 
    server {
        listen       80;
        server_name  localhost;
 
        #charset koi8-r;
 
        access_log  <アクセスログファイルのフルパス>;
                    # 例1. log/localhost.log;
                    # 例2. /srv/www/htdoc/log/localhost.log;
 
        # IPフィルタリング
        # 上にあるルールが優先
        #allow all;
        #deny  all;
 
        # インデックスファイルが存在しない場合、ファイル一覧を有効化 / 無効化
        autoindex on;
 
        location / {
            root   <ドキュメントルートのパス(絶対パスまたは相対パス)>;
                   # 例1. html;
                   # 例2. /srv/www/htdoc;
            index  index.php index.html index.htm;
        }
 
        error_page  404  /404.html;
        location = /404.html {
            root   <ドキュメントルートのパス(絶対パスまたは相対パス)>;
                   # 例1. html;
                   # 例2. /srv/www/htdoc;
        }
 
        # redirect server error pages to the static page /50x.html
        #
        error_page  500 502 503 504  /50x.html;
        location = /50x.html {
            root   <ドキュメントルートのパス(絶対パスまたは相対パス)>;
                   # 例1. html;
                   # 例2. /srv/www/htdoc;
        }
 
        # proxy the PHP scripts to Apache listening on 127.0.0.1:80
        #
        #location ~ \.php$ {
        #    proxy_pass   http://127.0.0.1;
        #}
 
        # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
        #
        #location ~ \.php$ {
        #    root           <ドキュメントルートのパス(絶対パスまたは相対パス)>;
        #                   # 例1. html;
        #                   # 例2. /srv/www/htdoc;
        #    fastcgi_pass   127.0.0.1:9000;
        #    fastcgi_index  index.php;
        #    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
        #    include        fastcgi_params;
        #}
 
        # このセクションは、NginXからPHP-FPMの通信は
        # Unixドメインソケット通信でlistenしているFastCGIサーバにPHPスクリプトを渡すために使用される
        location ~ \.php$
        {
            root           <ドキュメントルートのパス(絶対パスまたは相対パス)>;
                           # 例1. html;
                           # 例2. /srv/www/htdoc;
           fastcgi_pass   <PHP-FPMのソケットファイルのフルパス>;
                          # 例1. unix:/<PHPのインストールディレクトリ>/var/run/php-fpm.sock;
                          # 例2. unix:/var/run/php-fpm/php-fpm.sock;
           fastcgi_index  index.php;
           fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
           include        fastcgi_params;
        }
 
        # ApacheのドキュメントルートがNginXのドキュメントルートと一致する場合、.htaccessファイルへのアクセスを拒否する
        #location ~ /\.ht {
        #    deny  all;
        #}
    }
 
    # ...略
 
 }


NginXおよびPHP-FPMを起動する。

sudo systemctl restart nginx php-fpm


Webブラウザを起動した後、http://localhost/index.php にアクセスして、正常に表示されるか確認する。


仮想ホストの構築

パッケージ管理システムからNginXをインストールした場合、/etc/nginx/vhosts.dディレクトリ内に、Webサイトの設定ファイルを複数作成することができる。
一般的には、1つのWebサイトごとに1ファイル、<ドメイン名>.confのような名前を付ける。

  • NginXの設定ファイルにまとめて記述する場合
# パッケージ管理システムからインストールしている場合
sudo vi /etc/nginx/default.conf

# ソースコードからインストールしている場合
sudo vi /<Nginxのインストールディレクトリ>/etc/nginx.conf



 # /etc/nginx/default.confファイル または /<Nginxのインストールディレクトリ>/etc/nginx.confファイル
 
 http {
    # ...略
 
    server {
       listen       <ポート番号 例. 80>;
       server_name  <ドメイン名 例. virtualhost01>  alias  <ドメイン名 例. virtualhost01>.alias;
 
       access_log  <ログファイルのフルパス>
                   # 例. log/vhost.access.log;
 
       error_page  404  /404.html;
       location = /404.html {
          root   <仮想ホストのドキュメントルート>;
       }
 
       # redirect server error pages to the static page /50x.html
       #
       error_page   500 502 503 504  /50x.html;
       location = /50x.html {
          root   <仮想ホストのドキュメントルート>;
       }
 
       location / {
          root   <仮想ホストのドキュメントルート>;
          index  index.php index.html index.htm;
       }
 
       # このセクションは、NginxからPHP-FPMの通信はUnixドメインソケット通信でlistenしているFastCGIサーバにPHPスクリプトを渡すために使用される
       location ~ \.php$
       {
          root           <仮想ホストのドキュメントルート>;
          fastcgi_pass   unix:<PHP-FPMのソケットのパス>;
                         # 例1. unix:/var/run/php-fpm/php-fpm.sock;
                         # 例2. unix:/home/user/PHP/var/run/php-fpm/php-fpm.sock;
          fastcgi_index  index.php;
          include        fastcgi_params;
          fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
          # proxy_pass   http://127.0.0.1;
       }
    }
 
    # ...略
 }


  • 仮想ホストごとに分割して設定する場合
    一般的に、仮想ホストの設定ファイルは、/etc/nginx/vhost.dディレクトリ、または、/<NginXのインストールディレクトリ>/etc/vhosts.dディレクトリに配置する。
# パッケージ管理システムからインストールしている場合
sudo vi /etc/nginx/vhost.d/vhost1.conf

# ソースコードからインストールしている場合
sudo vi /<Nginxのインストールディレクトリ>/etc/vhost.d/vhost1.conf



 # /etc/nginx/vhost.d/vhost1.confファイル または /<Nginxのインストールディレクトリ>/etc/vhost.d/vhost1.confファイル
 
 server {
    listen       <ポート番号 例. 80>;
    server_name  <ドメイン名 例. virtualhost01>  alias  <ドメイン名 例. virtualhost01>.alias;
 
    access_log  <ログファイルのフルパス>
                # 例. log/vhost.access.log;
 
    error_page  404  /404.html;
    location = /404.html {
       root   <仮想ホストのドキュメントルート>;
    }
 
    # redirect server error pages to the static page /50x.html
    #
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
       root   <仮想ホストのドキュメントルート>;
    }
 
    location / {
       root   <仮想ホストのドキュメントルート>;
       index  index.php index.html index.htm;
    }
 
    # このセクションは、NginxからPHP-FPMの通信はUnixドメインソケット通信でlistenしているFastCGIサーバにPHPスクリプトを渡すために使用される
    location ~ \.php$
    {
       root           <仮想ホストのドキュメントルート>;
       fastcgi_pass   unix:<PHP-FPMのソケットのパス>;
                      # 例1. unix:/var/run/php-fpm/php-fpm.sock;
                      # 例2. unix:/home/user/PHP/var/run/php-fpm/php-fpm.sock;
       fastcgi_index  index.php;
       include        fastcgi_params;
       fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
       # proxy_pass   http://127.0.0.1;
    }
 }


上記で作成した仮想ホストの設定ファイルを読み込むため、NginXの設定ファイルを編集する。

# パッケージ管理システムからインストールしている場合
sudo vi /etc/nginx/default.conf

# ソースコードからインストールしている場合
sudo vi /<Nginxのインストールディレクトリ>/etc/nginx.conf



 # /etc/nginx/default.confファイル または /<Nginxのインストールディレクトリ>/etc/nginx.confファイル
 
 http {
 
    # ...略
 
    include /<NginXのvhost.dディレクトリのフルパス>/*.conf
            # 例1. /etc/nginx/vhosts.d/*.conf;
            # 例2. /<NginXのインストールディレクトリ>/etc/vhosts.d/*.conf;
 
    server {
 
       # ...略
 
    }
 
    # ...略
 }


仮想ホストにアクセスできるようにするため、/etc/hostsファイルに仮想ホスト名と対応するIPアドレスを追記する。

sudo vi /etc/hosts



# /etc/hostsファイル

<仮想ホストで使用するIPアドレス>   <仮想ホスト名>


NginXとPHP-FPMを起動する。

sudo systemctl start php-fpm
sudo systemctl start nginx



ログフォーマット

Apache2とNginXのログフォーマット
Apache2 NginX 説明
%a $remote_addr リモートIPアドレス
%A $server_addr ローカルIPアドレス
%b $body_bytes_sent レスポンスのバイト数(HTTPヘッダは除く)
CLF書式において、0の時は-(ハイフン)になる。
%B $body_bytes_sent レスポンスのバイト数(HTTPヘッダは除く)
%D - リクエストを処理するのに掛かった時間(マイクロ秒単位)
%f $request_filename リクエストされたファイル名
%h - リモートホスト名
%H $server_protocol リクエストプロトコル名
%K - keepaliveのコネクション数
%l - リモートログ名
%m $request_method リクエストメソッド(GET)
%p $server_port リクエストを受けたポート番号
%P $pid 子プロセスID
%q $query_string クエリ文字列
例. http://example.com/test.php?id=12345 -> ?id=12345
%r $request リクエストの最初の行
基本的には、%m %U$q %Hとした設定と同様
%s $status ステータスコード
%t $time_local リクエストを受け付けた日時
[11/Aug/2017:12:34:56 +0900]
%{format}t - formatで与えられた書式による時刻
%T $request_time リクエストを受けてから応答するまでの処理時間(秒)
%Dの秒数バージョン
%u $remote_user リモートユーザ名
%U $request_uri リクエストされたパス
%v $server_name サーバのServerNameの値
%V $server_name UseCanonicalNameで指定されたサーバ名
%X $request_completion 応答が完了したときの接続ステータス
書式 : aborted + = kept alive - = closed
%I $request_length リクエストとヘッダを含む受け取ったバイト数
%O $bytes_sent ヘッダを含むサーバから送信されたバイト数
%{Referer}i $http_referer リファラー
%{User-Agent}i $http_user_agent ユーザエージェント名


NginXのみのログフォーマット
ログフォーマット 説明
$args リクエスト行の引数
$binary_remote_addr $remote_addrのバイナリ出力
$connection コネクションのシリアル番号
$connection_requests コネクションを経由した現在のリクエスト数
$content_length Content-Lengthのリクエストヘッダフィールド

Content-Lengthとは、HTTPヘッダの項目であり、渡すデータのサイズが入っている。
$content_type Content-Typeのリクエストヘッダフィールド

Content-Typeとは、ヘッダで最も一般的に用いられる項目の1つであり、
ボディ部に積載したデータの種類や形式（メディアタイプ）を指定する。
主に、サーバがクライアントに送信するHTTPレスポンスの中で送信データの形式を伝えるために用いるが、
クライアントがフォームなどから送信するPOSTデータの形式を知らせるのにも用いられる。
$document_root 現在のリクエストに対するルートディレクティブおよびエイリアスディレクティブの値
$document_uri $uriと同じ
$host サーバホスト名
$hostname ホスト名
$https 接続がSSLモードで動作している場合は"on"、それ以外の場合は空文字列となる。
$limit_rate この変数を設定することにより、応答速度制限を行うことができる。
$msec 現在の時刻をミリ秒単位で表示する。
$nginx_version NginXのバージョン
$pipe リクエストがパイプライン化されている場合は"p"、それ以外の場合は"."
$proxy_protocol_addr Proxyプロトコルヘッダからのクライアントアドレスを表示する。
それ以外は空文字列となる。
$realpath_root $document_rootの実パス名
$remote_port クライアントのポート番号を表示する、
$request_body リクエストボディを表示する。
$request_body_file リクエストボディを格納した一時ファイル名を表示する。
$scheme http
$sent_http_name 任意のレスポンスヘッダフィールドを表示する。
$time_iso8601 ローカルタイム（ISO 8601標準)を表示する。



NginXのその他の設定

charset

値 : キャラクタ名 / off
初期値 : off
使用環境 : http, server, server.location, locationディレクティブのif文

指定された文字セットを"Content-Type"応答ヘッダフィールドに追加する。
charsetがsource_charsetディレクティブで指定されたcharsetと異なる場合は、変換が実行される。

offに設定する場合、"Content-Type"応答ヘッダフィールドへのcharsetの追加を取り消す。

設定できる値は、charset_map、charset、source_charsetディレクティブの形で、少なくとも1度は設定に存在する必要がある。
utf-8、windows-1251、koi8-r文字セットについては、conf/koi-win、 conf/koi-utf、conf/win-utfを設定に含めれば十分である。
その他の文字セットについては、例えば、単に架空の変換テーブルを作成することでも動作する。

また、"X-Accel-Charset"応答ヘッダフィールドに文字セットを設定することができる。
この機能は、proxy_ignore_headers、fastcgi_ignore_headers、uwsgi_ignore_headers、scgi_ignore_headers、grpc_ignore_headersディレクティブで無効化することができる。

tcp_nodelay

値 : on / off
初期値 : on
使用環境 : http, server.location

小さなパケットを大きなパケットに合成して、帯域幅の利用率を向上させる。(nagleアルゴリズム)
TCPプロトコルでは、アプリケーション層のデータが非常に少なく（1バイト程度）、かつ、トランスポート層のオーバーヘッドが40バイト（IPヘッダ20バイト + TCPヘッダ20バイト）にもなる現象がある。
この場合、送信データの多くは制御パケットであるため、帯域消費量が増加して、帯域利用率が悪くなる。(ネットワークに輻輳が発生しやすくなる)

この問題を解決するため、新規に生成されたパケットは送信データが確認されるまで、あるいは、相手側からの確認応答があるまで、
1MSSに切り上げる、または、確認応答があるまで待った後にタイムアウトまで送信する。
ネットワークの輻輳を避けるため、TCPスタックは0.2秒(Unixの実装の値)までデータを待つメカニズムを実装しており、小さすぎるパケットを送信することはない。

例えば、あるソフトウェアが小さなデータの送信を要求してきたとする。
すぐに送信する、または、データが生成されるのを待って再度送信するかを選択することができるとする。
もし、データをすぐに送ることができれば、インタラクティブでクライアントサーバタイプのソフトウェアは大きなメリットを得ることができる。
また、リクエストを即座に送信すれば、レスポンスも速くなる。


ただし、ネットワーク上でデータをストリーミングする必要がある場合、逆効果になる可能性がある。
ファイル転送を行う場合、転送するごとにクライアント側で0.2秒の遅延を発生させるからである。

tcp_nopush

値 : on / off
初期値 : off
使用環境 : http, server.location

TCP/IPにおける転送の標準であるtcp_corkの設定である。(tcp_nodelayとは逆の働きをする)
遅延を最適化する代わりに、1度に送信するデータ量を最適化する。

tcp_nopushを有効にする場合、tcp_corkメソッドが呼ばれるようになるため、パケットはすぐに送信されず、パケットが最大になった時に一気に送信される。(ネットワークの輻輳や混雑を解決する)
(一般的な意味は、TCP通信において、ソフトウェアがパケットを受信した時、すぐに転送することである)

sendfile

値 : on / off
初期値 : off
使用環境 : http, server.location, server.locationのif文

sendfileが有効になっている場合、NginXはデータ転送を行う時にsendfile関数(システムコール)を呼び出す。
sendfile関数は、Linuxカーネル 2.0以降で導入されたシステムコールである。

通常のネットワークでのデータ転送に比べて、スイッチの数が少なく、転送するデータのコピー数も少ない。

sendfile関数は、2つのファイルディスクリプタ間で直接データを渡すため（カーネル内での動作）、カーネルバッファとユーザバッファ間のデータのコピーを回避して、
ゼロコピーと呼ばれるほど効率的な処理を行うことが可能である。


Basic認証

Basic認証のパスワードファイルを作成する。

htpasswdコマンドを実行して、Basic認証を設定する。
以下の例では、.htpasswdファイルとしているが、ファイル名は任意の名前でよい。

htpasswd -c /<任意のパスワードファイルのディレクトリ>/<Basic認証ファイル名> <Basic認証時のユーザ名>

例. htpasswd -c /etc/nginx/conf.d/.htpasswd sample_user


Basic認証を有効にするため、nginx.confファイル等に以下に示す設定を追加する。

 # トップページ(http://www.example.com/)にBasic認証を掛ける場合、/のlocationディレクティブに設定を追加する
 location / {
    root   <ドキュメントルートのディレクトリ>;
    index  index.html index.htm;
 
    auth_basic "<認証名>";
               # 例. "Basic Authentication";
    auth_basic_user_file <Basic認証ファイルの絶対パス>;
                         # 例. auth_basic_user_file /etc/nginx/conf.d/.htpasswd;
 }
 
 # トップページ以外(http://www.example.com/hoge/)にBasic認証を掛ける場合、/hoge/のlocationディレクティブを作成および設定を追加する
 location /hoge/ {
    auth_basic "<認証名>";
               # 例. "Basic Authentication";
    auth_basic_user_file <Basic認証ファイルの絶対パス>;
                         # 例. /etc/nginx/conf.d/.htpasswd;
 }


設定を反映する。

sudo systemctl restart nginx
sudo systemctl reload  nginx



Digest認証

Digest認証とは

Webブラウザ等のクライアントからサーバへユーザ名やパスワード等を送信して、サーバから結果を応答する手順のことである。

認証情報は平文で送信せずに、ハッシュ関数と呼ばれる一定の計算手順で逆変換できない状態に加工してから送信する。
サーバ側では、クライアント側からユーザ名やパスワード等のそのものを受信することはできないが、
登録済みの情報から同じようにハッシュ値を算出して、クライアントから受信したハッシュ値に一致すれば認証成功となる。

より安全性を高めるため、サーバとクライアントの双方がその場限りのランダムなデータ（nonceと呼ばれる）を生成して、送信するデータに付け加えてからハッシュ値を算出する。
これにより、認証情報そのものは同じでも、実際に送信するデータは毎回変化するため、秘密の情報を割り出さなくても実行できる反射攻撃などを防ぐことができる。

ハッシュ関数の種類においては、ヘッダ領域の中で指定することができ、双方が対応しているアルゴリズムが採用される。
当初の規格（RFC 2617）ではMD5方式が使用されていたが、現在では十分な安全性が確保できないことが知られており、改訂版（RFC 7616）ではSHA-256の使用が推奨されている。

Digest認証は、認証情報を平文のまま送受信するBASIC認証（基本認証）と比較して、クライアントとサーバ間の伝送路の安全が確保されていない状況で認証情報を保護することができるが、
現代では、SSL/TLSを用いてHTTPによるデータ伝送全体を暗号化するHTTPS通信が広く普及しており、かつてより重要性は低下している。

NnginXにおけるDigest認証モジュールの注意点

Digest認証モジュールは、NginXのソースコードと一緒に配布されていないため、別途インストールする必要がある。

Digest認証モジュールは、RFCに基づいて機能が完成しているが、実際の運用で使用するのに十分な安全性を確保するために、より広範な検証が必要な状態である。
現在の注意点については、bugs.txtファイルとgithub issue trackerを参照すること。

Digest認証の設定

Digest認証のパスワードファイルを作成する。

htdigestコマンドを実行して、Digest認証を設定する。
以下の例では、.htdigestファイルとしているが、ファイル名は任意の名前でよい。

# 初めてDigest認証ファイルを作成する場合
htdigest -c <作成するDigest認証ファイルのフルパス> "<realm名>" <Digest認証時のユーザ名>

# Digest認証ファイルに設定を追記する場合
htdigest <追記するDigest認証ファイルのフルパス> "<realm名>" <Digest認証時のユーザ名>

例. htdigest -c /etc/nginx/conf.d/.htdigest "test" sample_user


Digest認証を有効にするため、nginx.confファイル等に以下に示す設定を追加する。

 # トップページ(http://www.example.com/)にDigest認証を掛ける場合、/のlocationディレクティブに設定を追加する
 location / {
    root   <ドキュメントルートのディレクトリ>;
    index  index.html index.htm;
 
    auth_digest "<realm名>";
               # 例. "test";
    auth_digest_user_file <Digest認証ファイルの絶対パス>;
                         # 例. /etc/nginx/conf.d/.htdigest;
 }
 
 # トップページ以外(http://www.example.com/hoge/)にDigest認証を掛ける場合、/hoge/のlocationディレクティブを作成および設定を追加する
 location /hoge/ {
    auth_digest "<realm名>";
                # 例. "test";
    auth_digest_user_file <Digest認証ファイルの絶対パス>;
                          # 例. /etc/nginx/conf.d/.htdigest;
 }


設定を反映する。

sudo systemctl restart nginx
sudo systemctl reload  nginx



HTTPS（SSL）の設定 (Let's Encrypt)

Let's Encryptとは

Let's Encrypt(Linux Foundationの協業プロジェクト)は、Web全体の安全性を改善することを掲げており、
発行料無料のSSL/TLSサーバ証明書を取得することができる。

Let's Encryptでは、 一般的なドメイン認証(DV)の証明書を無料で発行しており、
その中間証明書は、大手認証局(CA)のルート証明書によってクロス署名されているため、多くの主要ブラウザ等々で信頼済みとして扱われる。

なお、1回の認証で得られる証明書の有効期限は90日である。
したがって、90日以内に証明書の更新を、再度実施する必要がある。

Certbotクライアントのインストール

証明書を取得するため、Certbotクライアントをインストールする。

sudo dnf install certbot


証明書の取得

Apache2やNginX等のWebサーバが稼働していることが前提となることに注意する。
また、インターネット側から、証明書を使用するWebサーバ(証明書を取得するFQDNのサーバ)のTCP80番ポートを開放することも前提となる。

  • --webroot -wオプション
    稼働中のWebサーバのドキュメントルート配下を認証用の一時領域に使用する。
    例. --webroot -w <ドキュメントルート> -d <証明書を取得するFQDN>

    証明書を取得するFQDNが複数ある場合は、-d <証明書を取得するFQDN>を複数指定できる。
    例. hoge.comとpiyo.comの2つについて取得する場合
    -d hoge.com -d piyo.com

  • FQDN (Fully Qualified Domain Name)
    <ホスト名>.<ドメイン名>を省略せずに記述する。


ドキュメントルートは、仮想ホストで複数のホスト定義がある場合、該当するホスト定義のものを指定する。
ドキュメントルート指定の動作としては、指定したドキュメントルート配下に.well-knownディレクトリが作成されて、認証用のファイルが自動的かつ一時的に設置される。

証明書を取得する。

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


初回のみメールアドレスの登録と利用条件への同意が必要となる。

# 受信可能なメールアドレスを指定する
(Enter 'c' to cancel): <メールアドレス>

# 利用条件に同意する
(A)gree/(C)ancel: A

# 非営利団体 Electronic Frontier Foundation にもメールアドレスを登録するか否か
(Y)es/(N)o: Y


最後に、"Congratulations"と表示されると成功である。

上記のメッセージに表示される通り、/etc/letsencrypt/live/<FQDN>ディレクトリ内に、4つの証明書が保存される。

  • cert.pem
    SSLサーバー証明書(公開鍵含む)
  • chain.pem
    中間証明書
  • fullchain.pem
    cert.pemファイルとchain.pemファイルが結合されたファイル
  • privkey.pem
    公開鍵に対する秘密鍵


証明書を使用するWebサーバが未稼働の場合でも、Certbotの簡易Webサーバ機能を使用して(--standaloneオプションを付加する)、証明書を取得することができる。
この場合も、インターネット側から証明書を使用するWebサーバのTCP80番ポートを開放する必要がある。

certbot certonly --standalone -d <FQDN>
# または
sudo certbot certonly --standalone -d <FQDN>

例.
sudo certbot certonly --standalone -d www.hoge.com


取得済みの証明書の更新

有効期限が30日未満の証明書を全て更新する。
もし、有効期限の残り日数に関わらずに更新する場合は、--force-renewオプションも付加する。

certbot renew
# または
sudo certbot renew



エラー関連

test failed

Webサイトにアクセスする時、"test failed"というエラーメッセージが表示される場合がある。
これは、NginXの初期設定ではIPv4とIPv6をリッスンするが、使用しているWebサーバがIPv6をサポートしていない場合に起きる。

nginx.confファイルにおいて、IPv6を使用しないように設定する。

vi nginx.conf



# nginx.confファイル

# 編集前
listen [::]:80 default_server;

# 編集後
# listen [::]:80 default_server;


NginXを再読み込みする。

sudo systemctl reload nginx



HTTPS（SSL）の設定

CSRについて

CSR(Certificate Signing Request)とは、証明書発行要求といい、認証局に対して行う、認証局の秘密鍵で署名してもらうためのリクエストのことである。

CSRの中身を確認するためには、reqコマンドに-textオプションを付加することで確認できる。

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
               （省略）


上記の出力例において、[Signature Algorithm]項目は、sha256WithRSAEncryptionである。
SHA-1は解読されるリスクが高まっているため、今後作成するものはSHA-2とするべきである。

SHA-2には、SHA-224、SHA-256、SHA-384、SHA-512の4種類がある。
SHA-512が最も安全性が高いが、クライアント端末側がSHA-512に対応している必要がある。

自己署名証明書の発行(サーバ側)

秘密鍵を作成する
openssl genrsa -out <秘密鍵のファイル名>.key 2048


秘密鍵のファイルのアクセス権限を変更する。

chmod 400 <秘密鍵のファイル名>.key


CSR(証明書署名要求)の作成

作成した秘密鍵を使用して、クライアント側のCSRを作成する。

openssl req -sha256 -new -subj "/C=JP/ST=Tokyo/L=Tokyo City/O=Company Name/OU=Department/CN=*.<ドメイン名>" -key <秘密鍵のファイル名>.key -out <CSRのファイル名>.csr


SAN (Subject Alternative Name)の作成

サーバ証明書に自己署名証明書を使用する場合、クライアントPCに自己署名証明書をインストールしても、Webブラウザ(Chrome等)は警告を表示する。
これは、Chrome等のWebブラウザは、コモンネーム(CN)ではなく、SAN(Subject Alternative Name)を確認しているからである。
そのため、SANを加えて自己署名証明書を作成する必要がある。

※注意
DNS項目ではワイルドカードが使用できるが、IP項目では使用できないことに注意する。

vi san.txt  # ファイル名は任意



# san.txtファイル

subjectAltName = DNS:localhost,*.localhost,*.example.com IP:127.0.0.1,172.20.0.1


サーバ証明書の作成

作成したCSRに署名を行って、サーバ証明書を発行する。
<サーバ証明書のファイル名>.csrファイルは、サーバ証明書を発行するためのファイルのため、後で削除してもよい。

openssl x509 -sha256 -req -days <証明書の有効日数 例. 3650> -in <CSRのファイル名>.csr -signkey <秘密鍵のファイル名>.key \
        -extfile san.txt \
        -out <サーバ証明書のファイル名>.crt


Webサーバの設定

Webサーバに設置するものは、秘密鍵（.key拡張子）とサーバ証明書（.crt拡張子）の2つである。

SSLを有効にするため、NginXの設定ファイルを編集する。

# パッケージ管理システムからインストールしている場合
sudo vi /etc/nginx/nginx.conf

# ソースコードからインストールしている場合
sudo vi /<Nginxのインストールディレクトリ>/etc/nginx.conf



 # 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;
    }
 }


ロードバランサにSSL証明書を設置して、SSL接続を終端することもできる。
その場合、サーバ証明書は1つ用意して、ロードバランサからWebサーバまでの通信はhttpとなる。（httpsでも可能であるが、httpの方が負荷が軽いため）

httpを使用するメリットとして、Webサーバで受けるアクセスがhttpとなるので負荷が減るためである。(暗号化された通信を複合するために、SSLの接続を受けるのは負荷が掛かる)

自己証明書の発行(クライアント側)

秘密鍵を作成する
openssl genrsa -out <秘密鍵のファイル名>.key 2048


秘密鍵のファイルのアクセス権限を変更する。

chmod 400 <秘密鍵のファイル名>.key


CSR(証明書署名要求)

作成した秘密鍵を使用して、クライアント側のCSRを作成する。

openssl req -sha256 -new -subj "/C=JP/ST=Tokyo/L=Tokyo City/O=Company Name/OU=Department/CN=*.<ドメイン名>" \
                         -key <秘密鍵のファイル名>.key -out <CSRのファイル名>.csr


SAN (Subject Alternative Name)の作成

サーバ証明書に自己署名証明書を使用する場合、クライアントPCに自己署名証明書をインストールしても、Webブラウザ(Chrome等)は警告を表示する。
これは、Chrome等のWebブラウザは、コモンネーム(CN)ではなく、SAN(Subject Alternative Name)を確認しているからである。
そのため、SANを加えて自己署名証明書を作成する必要がある。

※注意
DNS項目ではワイルドカードが使用できるが、IP項目ではワイルドカードが使用できないことに注意する。

vi san.txt  # ファイル名は任意



# san.txtファイル

subjectAltName = DNS:localhost,*.localhost,*.example.com IP:127.0.0.1,172.20.0.1


サーバ証明書の作成

作成したCSRに署名を行って、サーバ証明書を発行する。
<サーバ証明書のファイル名>.csrファイルは、サーバ証明書を発行するためのファイルのため、後で削除してもよい。

openssl x509 -sha256 -req -days <証明書の有効日数 例. 3650> -in <CSRのファイル名>.csr -signkey <秘密鍵のファイル名>.key \
        -extfile san.txt \
        -out <サーバ証明書のファイル名>.crt


クライアントPCがWindowsの場合、Windows PCにインポートするには、サーバ証明書のファイル(.crt拡張子)をpkcs12形式に変換する必要がある。

openssl pkcs12 -export -inkey <秘密鍵のファイル名>.key -in <サーバ証明書のファイル名>.crt \
                       -out <クライアント側にインポートするサーバ証明書のファイル名>.p12 -name <任意の識別子名>


Webサーバの設定

サーバに設置するものは、サーバ証明書のファイル（.crt拡張子）と秘密鍵（.key拡張子）の2つである。
Windows PC(クライアントPC)へ配布するものは、pkcs12形式に変換したクライアント側のサーバ証明書のファイル(.p12拡張子)である。

Windows PCへクライアント側のサーバ証明書のファイル(.p12拡張子)をインポートする場合、ファイルを実行することによりインポート画面が起動するため、
インポート画面に沿って、サーバ証明書のファイル(.p12拡張子)をインポートする。


Xdebugの設定

PHP-FPMの初期設定では、9000番ポートを使用している。
もし、古いバージョンのXdebug(バージョン2.x)を使用している場合、デフォルトのデバッグポートは9000番ポートを使用しているため、競合が発生する。
そのため、古いバージョンのXdebug(バージョン2.x)を使用する場合は、Xdebugのデバッグポートを変更する必要がある。

# PHP 7の場合
sudo vi /etc/php7/conf.d/xdebug.ini

# PHP 8の場合
sudo vi /etc/php8/conf.d/xdebug.ini

# ソースコードからPHPをインストールしている場合
vi /<PHPのインストールディレクトリ>/etc/php.ini



# xdebug.iniファイル  または  php.iniファイル

xdebug.remote_port=<9000以外の値  例. 9003>


NginXとPHP-FPMを再起動する。

sudo systemctl restart nginx php-fpm



「http://mochiuwiki.e2.valueserver.jp/index.php?title=インストール_-_Nginx(RHEL)&oldid=12848」から取得