📢 Webサイト閉鎖と移転のお知らせ
このWebサイトは2026年9月に閉鎖いたします。
新しい記事は移転先で追加しております。（旧サイトでは記事を追加しておりません）
| (同じ利用者による、間の34版が非表示) | |||
| 17行目: | 17行目: | ||
! style="background-color:#66CCFF;" | NginX | ! style="background-color:#66CCFF;" | NginX | ||
|- | |- | ||
| style="background-color:# | | style="background-color:#CFCFCF;" | 同時・複数アクセスへの対処方法 | ||
| 1アクセスに対して、1つの対応 || 複数のアクセスに対して、1つの対応にまとまる | | 1アクセスに対して、1つの対応 || 複数のアクセスに対して、1つの対応にまとまる | ||
|- | |- | ||
| style="background-color:# | | style="background-color:#CFCFCF;" | アクセス急増時のサーバへの負荷 | ||
| 一気に負荷が増す || アクセスに比例して負荷は急激に増えない | | 一気に負荷が増す || アクセスに比例して負荷は急激に増えない | ||
|- | |- | ||
| style="background-color:# | | style="background-color:#CFCFCF;" | その結果のWebサーバの挙動 | ||
| 動作が遅くなり、ダウンしやすくなる || 処理速度を維持して、ダウンしにくい | | 動作が遅くなり、ダウンしやすくなる || 処理速度を維持して、ダウンしにくい | ||
|} | |} | ||
| 48行目: | 48行目: | ||
<br> | <br> | ||
<center> | <center> | ||
{| class="wikitable" | {| class="wikitable" | style="background-color:#fefefe;" | ||
! colspan=" | ! colspan="4" style="background-color:#44CC99;" | 参考書 | ||
|- style="text-align: center | |- style="text-align: center;" | ||
| | | style="width: 25%" | <center><html><a href="https://www.amazon.co.jp/nginx%E5%AE%9F%E8%B7%B5%E3%82%AC%E3%82%A4%E3%83%89-impress-top-gear%E3%82%B7%E3%83%AA%E3%83%BC%E3%82%BA-%E6%B8%A1%E8%BE%BA%E9%AB%98%E5%BF%97-ebook/dp/B01N183E3H?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&keywords=nginx%E5%AE%9F%E8%B7%B5%E3%82%AC%E3%82%A4%E3%83%89&qid=1683613390&sr=8-1&linkCode=ll1&tag=presire2-22&linkId=043bfdc7a0aebd00eb1db639408b7d42&language=ja_JP&ref_=as_li_ss_tl" target="_blank"><img style="width: 250px; height: auto;" src="https://m.media-amazon.com/images/I/A1nwYPPNb8L._SL1500_.jpg" ></a></html><br>[https://www.amazon.co.jp/nginx%E5%AE%9F%E8%B7%B5%E3%82%AC%E3%82%A4%E3%83%89-impress-top-gear%E3%82%B7%E3%83%AA%E3%83%BC%E3%82%BA-%E6%B8%A1%E8%BE%BA%E9%AB%98%E5%BF%97-ebook/dp/B01N183E3H?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&keywords=nginx%E5%AE%9F%E8%B7%B5%E3%82%AC%E3%82%A4%E3%83%89&qid=1683613390&sr=8-1&linkCode=ll1&tag=presire2-22&linkId=043bfdc7a0aebd00eb1db639408b7d42&language=ja_JP&ref_=as_li_ss_tl nginx実践ガイド<br>IT技術者のための現場ノウハウ]</center> | ||
| style="width: 25%" | <center><html><a href="https://www.amazon.co.jp/nginx%E5%AE%9F%E8%B7%B5%E5%85%A5%E9%96%80-WEB-DB-PRESS-plus/dp/4774178667?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&keywords=nginx%E5%AE%9F%E8%B7%B5%E3%82%AC%E3%82%A4%E3%83%89&qid=1683613529&sr=8-4&linkCode=ll1&tag=presire2-22&linkId=27b398323efeb2a8b3c7dbc64e799fa1&language=ja_JP&ref_=as_li_ss_tl" target="_blank"><img style="width: 250px; height: auto;" src="https://m.media-amazon.com/images/I/61LbDMjddRL._SL1000_.jpg" ></a></html><br>[https://www.amazon.co.jp/nginx%E5%AE%9F%E8%B7%B5%E5%85%A5%E9%96%80-WEB-DB-PRESS-plus/dp/4774178667?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&keywords=nginx%E5%AE%9F%E8%B7%B5%E3%82%AC%E3%82%A4%E3%83%89&qid=1683613529&sr=8-4&linkCode=ll1&tag=presire2-22&linkId=27b398323efeb2a8b3c7dbc64e799fa1&language=ja_JP&ref_=as_li_ss_tl nginx実践入門<br>高速/安定稼働を実現する構築と運用のテクニック]</center> | |||
| style="width: 25%" | <center><html><a href="https://www.amazon.co.jp/Nginx-%E3%83%9D%E3%82%B1%E3%83%83%E3%83%88%E3%83%AA%E3%83%95%E3%82%A1%E3%83%AC%E3%83%B3%E3%82%B9-%E9%B6%B4%E9%95%B7-%E9%8E%AE%E4%B8%80/dp/4774176338?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&keywords=nginx%E5%AE%9F%E8%B7%B5%E3%82%AC%E3%82%A4%E3%83%89&qid=1683613634&sr=8-3&linkCode=ll1&tag=presire2-22&linkId=fba35fad8e2270d7371a77b5c5a9f44e&language=ja_JP&ref_=as_li_ss_tl" target="_blank"><img style="width: 250px; height: auto;" src="https://m.media-amazon.com/images/I/61ZE51+HyfL._SL1000_.jpg" ></a></html><br>[https://www.amazon.co.jp/Nginx-%E3%83%9D%E3%82%B1%E3%83%83%E3%83%88%E3%83%AA%E3%83%95%E3%82%A1%E3%83%AC%E3%83%B3%E3%82%B9-%E9%B6%B4%E9%95%B7-%E9%8E%AE%E4%B8%80/dp/4774176338?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&keywords=nginx%E5%AE%9F%E8%B7%B5%E3%82%AC%E3%82%A4%E3%83%89&qid=1683613634&sr=8-3&linkCode=ll1&tag=presire2-22&linkId=fba35fad8e2270d7371a77b5c5a9f44e&language=ja_JP&ref_=as_li_ss_tl Nginx ポケットリファレンス]</center> | |||
| style="width: 25%" | <center><html><a href="https://www.amazon.co.jp/Nginx-HTTP-Server-Harness-infrastructure-ebook/dp/B078JP4HZN?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&crid=3B65BLLSDAMIQ&keywords=Nginx+HTTP+Server&qid=1667805465&qu=eyJxc2MiOiIxLjQ3IiwicXNhIjoiMC4wMCIsInFzcCI6IjAuMDAifQ%3D%3D&sprefix=nginx+http+server%2Caps%2C340&sr=8-1&linkCode=ll1&tag=presire2-22&linkId=27ce6fa58f80207d2bb6d06359b505c7&language=ja_JP&ref_=as_li_ss_tl" target="_blank"><img style="width: 250px; height: auto;" src="https://m.media-amazon.com/images/I/81V8A5I4p4L._SL1500_.jpg" ></a></html><br>[https://www.amazon.co.jp/Nginx-HTTP-Server-Harness-infrastructure-ebook/dp/B078JP4HZN?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&crid=3B65BLLSDAMIQ&keywords=Nginx+HTTP+Server&qid=1667805465&qu=eyJxc2MiOiIxLjQ3IiwicXNhIjoiMC4wMCIsInFzcCI6IjAuMDAifQ%3D%3D&sprefix=nginx+http+server%2Caps%2C340&sr=8-1&linkCode=ll1&tag=presire2-22&linkId=27ce6fa58f80207d2bb6d06359b505c7&language=ja_JP&ref_=as_li_ss_tl Nginx HTTP Server<br>Nginxを利用して、高速なページ配信を実現する]</center> | |||
|} | |} | ||
</center> | </center> | ||
<br><br> | |||
== Mainline版 / Stable版 == | |||
Nginxには、Mainline版とStable版の2つの主要なバージョンがある。<br> | |||
<br> | |||
<u>Mainline版を使用する場合は十分なテストと検証を行い、プロダクション環境ではStable版を使用することを推奨する。</u><br> | |||
<br> | |||
==== Stable版 ==== | |||
Stable版は、テスト済みで安定したバージョンである。<br> | |||
<br> | |||
バグが修正され、機能が確立されており、プロダクション環境で使用することを目的としている。<br> | |||
新しい機能は追加されないが、バグ修正とセキュリティアップデートは行われる。<br> | |||
<br> | |||
==== Mainline版 ==== | |||
Mainline版は、最新の開発バージョンである。<br> | |||
新しい機能が追加されており、Stable版よりも頻繁に更新される。<br> | |||
<br> | |||
Mainline版は、開発者やテスタが新しい機能をテストして、フィードバックを提供するために使用される。<br> | |||
<br> | |||
ただし、Mainline版は、テストが十分に行われていない可能性があるため、プロダクション環境で使用するには適していない場合がある。<br> | |||
<br> | |||
Mainline版のメリットを以下に示す。<br> | |||
* 最新の機能やバグ修正を早く利用できる。 | |||
* 開発チームが新しい機能をテストし、フィードバックを提供するのに役立つ。 | |||
<br> | |||
Mainline版のデメリットを以下に示す。<br> | |||
* バグや不具合が発生する可能性がある。 | |||
* 新しい機能が予期せず動作しない可能性がある。 | |||
* 設定ファイルや構成が変更される可能性がある。 | |||
<br><br> | <br><br> | ||
| 77行目: | 109行目: | ||
==== ソースコードからインストール ==== | ==== ソースコードからインストール ==== | ||
NginXのビルドに必要なライブラリをインストールする。<br> | NginXのビルドに必要なライブラリをインストールする。<br> | ||
sudo zypper install libxslt-devel pcre2-devel gd-devel | sudo zypper install libxslt-devel pcre2-devel gd-devel zlib-devel \ | ||
libopenssl-devel libopenssl-1_1-devel # OpenSSL 1 を使用する場合 | |||
libopenssl-3-devel # OpenSSL 3 を使用する場合 | |||
libGeoIP-devel # GeoIPを使用する場合 | |||
libcurl-devel ruby-devel # Passengerを使用する場合 | |||
kernel-source kernel-devel # AIOを使用する場合 | |||
<br> | <br> | ||
必要ならば、[https://www.openssl.org/source/ OpenSSLの公式Webサイト]にアクセスして、OpenSSL(1.X.Y)のソースコードをダウンロードする。<br> | 必要ならば、[https://www.openssl.org/source/ OpenSSLの公式Webサイト]にアクセスして、OpenSSL(1.X.Y)のソースコードをダウンロードする。<br> | ||
| 84行目: | 120行目: | ||
tar xf openssl-<バージョン> | tar xf openssl-<バージョン> | ||
<br> | <br> | ||
* Digest認証モジュールを使用する場合 | |||
[https://github.com/atomx/nginx-http-auth-digest Digest認証モジュールのGithub]にアクセスして、ソースコードをダウンロードする。<br> | *: NginXのソースコードと一緒に配布されていないため、別途インストールする必要がある。<br> | ||
ダウンロードしたファイルを解凍する。<br> | *: [https://github.com/atomx/nginx-http-auth-digest Digest認証モジュールのGithub]にアクセスして、ソースコードをダウンロードする。<br> | ||
*: ダウンロードしたファイルを解凍する。<br> | |||
*: <code>tar xf nginx-http-auth-digest-<バージョン>.tar.gz</code> | |||
*: <br> | |||
*: または、<code>git clone</code>コマンドを実行して、ソースコードをダウンロードする。<br> | |||
*: <code>git clone https://github.com/atomx/nginx-http-auth-digest.git</code> | |||
*: <br> | |||
* Passengerモジュールを使用する場合 (Rails連携) | |||
*: NginXのソースコードと一緒に配布されていないため、別途インストールする必要がある。<br> | |||
*: [https://www.phusionpassenger.com/docs/advanced_guides/install_and_upgrade/standalone/install/oss/tarball.html Passengerモジュールの公式webサイト]にアクセスして、ソースコードをダウンロードする。<br> | |||
*: または、[https://github.com/phusion/passenger PassengerのGithub]にアクセスして、ソースコードをダウンロードする。 | |||
*: ダウンロードしたファイルを解凍する。<br> | |||
*: <code>tar xf passenger-<バージョン>.tar.gz</code> | |||
*: <code>cd passenger-<バージョン></code> | |||
*: <br> | |||
<br> | <br> | ||
NginX 1.9.11以降から、<code>configure</code>スクリプト実行時において、<br> | |||
--add-module=<PATH>オプションの代わりに<code>--add-dynamic-module=<PATH></code>オプションを使用して、モジュールを動的モジュールとしてコンパイルすることができる。<br> | |||
そして、<code>load_module</code>ディレクティブを使用して、nginx.confファイルで明示的にモジュールをロードすることができる。<br> | |||
load_module /path/to/modules/<モジュール名>.so; | |||
<br> | <br> | ||
[https://nginx.org/en/download.html NginXの公式Webサイト]にアクセスして、NginXのソースコードをダウンロードする。<br> | [https://nginx.org/en/download.html NginXの公式Webサイト]にアクセスして、NginXのソースコードをダウンロードする。<br> | ||
| 127行目: | 176行目: | ||
--with-http_xslt_module --with-http_xslt_module=dynamic \ | --with-http_xslt_module --with-http_xslt_module=dynamic \ | ||
--with-http_image_filter_module --with-http_image_filter_module=dynamic \ | --with-http_image_filter_module --with-http_image_filter_module=dynamic \ | ||
--with-http_gunzip_module --with-http_gzip_static_module \ | --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_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-http_perl_module --with-http_perl_module=dynamic \ | ||
| 133行目: | 182行目: | ||
--with-stream=dynamic --with-stream_ssl_module --with-stream_realip_module --with-stream_ssl_preread_module \ | --with-stream=dynamic --with-stream_ssl_module --with-stream_realip_module --with-stream_ssl_preread_module \ | ||
--with-compat \ | --with-compat \ | ||
--with-ipv6 \ # ただし、1.24以降は無効 | |||
--user=<任意のユーザ名 例. nginx> \ | --user=<任意のユーザ名 例. nginx> \ | ||
--group=<任意のグループ名 例. nginx> | --group=<任意のグループ名 例. nginx> | ||
# 不要の可能性あり | # 不要の可能性あり | ||
--without-poll_module --without-select_module | --without-poll_module --without-select_module | ||
# Digest認証を使用する場合 | # Digest認証を使用する場合 | ||
--add-module=<Digest認証モジュールのソースコードがあるディレクトリ> | --add-dynamic-module=<Digest認証モジュールのソースコードがあるディレクトリ> | ||
# Passengerを使用する場合 | |||
--add-dynamic-module=/<Passengerモジュールのディレクトリ>/src/nginx-module | |||
# GCCコンパイラを指定する場合 | # GCCコンパイラを指定する場合 | ||
| 234行目: | 287行目: | ||
NginXの設定ファイルの内容を変更した時、変更を反映させるためにNginXを再読み込みする。<br> | NginXの設定ファイルの内容を変更した時、変更を反映させるためにNginXを再読み込みする。<br> | ||
sudo systemctl reload nginx | sudo systemctl reload nginx | ||
<br><br> | |||
== 動的モジュール == | |||
NginXは多数のモジュールから構成されており、NginXのビルド時にモジュールがNginXバイナリにスタティックに組み込まれる。<br> | |||
追加したいモジュールがある場合も同様、NginXのビルド時にそのモジュールを指定することにより、NginXバイナリにそのモジュールがスタティックに組み込まれる。<br> | |||
<br> | |||
過去のNginXにおいては、モジュールを追加・変更するたびに、NginX本体をビルドし直す必要があり、運用が煩雑であった。<br> | |||
<br> | |||
しかし、NginX 1.9.11以降では、動的モジュールがサポートされて、動的モジュールを使用時（NginXの起動およびリロード）に組み込むことができるようになった。<br> | |||
<br> | |||
例えば、NginXの設定ファイル(nginx.confファイル)において、<code>load_module</code>ディレクティブの値として、動的モジュールの共有オブジェクトファイルのパスを指定して、<br> | |||
NginXを起動あるいはリロードすることにより、動的モジュールを使用できるようになる。<br> | |||
<syntaxhighlight lang="nginx"> | |||
load_module "modules/foo_module.so"; | |||
</syntaxhighlight> | |||
<br> | |||
<code>load_module</code>ディレクティブの記述場所はmainコンテキストである。<br> | |||
また、各ブロック（events、http、stream、mail）よりも前に記述する必要があることに注意する。<br> | |||
<syntaxhighlight lang="nginx"> | |||
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 { | |||
# ...略 | |||
} | |||
</syntaxhighlight> | |||
<br> | |||
もし、各ブロック（events、http、stream、mail）よりも前に記述した場合は、以下に示すようなエラーが出力される。<br> | |||
# 出力例 | |||
nginx: [emerg] "load_module" directive is specified too late in /usr/local/nginx/conf/nginx.conf:16 | |||
<br> | |||
NginXの標準モジュール全てが動的モジュールとして使用できるわけではない。<br> | |||
現行のバージョンでは、以下に示すモジュールが動的モジュールとして使用することができる。<br> | |||
* 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) | |||
<br> | |||
また、サードパーティ製モジュールも動的モジュールとして使用できるが、<code>configure</code>スクリプトの修正が必要となるため、動的モジュールへの対応をサポートしているモジュール以外は、そのままでは使用できない。<br> | |||
<br> | |||
現行バージョンでは、動的モジュール単体のみをビルドすることはできないため、動的モジュールをビルドするためには、NginX本体をビルドする手順とほぼ同じ手順を行う必要がある。<br> | |||
なお、将来的には、モジュール単体をビルドできるようにする計画がある。<br> | |||
<br><br> | <br><br> | ||
| 391行目: | 495行目: | ||
<syntaxhighlight lang="nginx"> | <syntaxhighlight lang="nginx"> | ||
# nginx.confファイル | # nginx.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 { | http { | ||
# ...略 | # ...略 | ||
# 設定ファイルの読み込み | |||
#include /etc/nginx/conf.d/ssl.conf | |||
#include /etc/nginx/vhost.d/*.conf | |||
server { | server { | ||
| 404行目: | 527行目: | ||
# 例1. log/localhost.log; | # 例1. log/localhost.log; | ||
# 例2. /srv/www/htdoc/log/localhost.log; | # 例2. /srv/www/htdoc/log/localhost.log; | ||
# IPフィルタリング | |||
# 上にあるルールが優先 | |||
#allow all; | |||
#deny all; | |||
# インデックスファイルが存在しない場合、ファイル一覧を有効化 / 無効化 | |||
autoindex on; | |||
location / { | location / { | ||
| 461行目: | 592行目: | ||
} | } | ||
# | # ApacheのドキュメントルートがNginXのドキュメントルートと一致する場合、.htaccessファイルへのアクセスを拒否する | ||
#location ~ /\.ht { | #location ~ /\.ht { | ||
# deny all; | # deny all; | ||
| 481行目: | 610行目: | ||
== 仮想ホストの構築 == | == 仮想ホストの構築 == | ||
パッケージ管理システムからNginXをインストールした場合、/etc/nginx/vhosts.dディレクトリ内に、Webサイトの設定ファイルを複数作成することができる。<br> | |||
一般的には、1つのWebサイトごとに1ファイル、<ドメイン名>.confのような名前を付ける。<br> | |||
<br> | |||
NginXの設定ファイルを編集する。<br> | NginXの設定ファイルを編集する。<br> | ||
# パッケージ管理システムからインストールしている場合 | # パッケージ管理システムからインストールしている場合 | ||
| 536行目: | 668行目: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
<br> | <br> | ||
一般的に、仮想ホストの設定ファイルは、/etc/nginx/vhost.dディレクトリ、または、/<NginXのインストールディレクトリ>/etc/vhosts.dディレクトリに配置する。<br> | |||
# パッケージ管理システムからインストールしている場合 | # パッケージ管理システムからインストールしている場合 | ||
sudo vi /etc/nginx/vhost.d/vhost1.conf | sudo vi /etc/nginx/vhost.d/vhost1.conf | ||
| 849行目: | 981行目: | ||
== Digest認証 == | == Digest認証 == | ||
==== | ==== Digest認証とは ==== | ||
Webブラウザ等のクライアントからサーバへユーザ名やパスワード等を送信して、サーバから結果を応答する手順のことである。<br> | |||
<br> | |||
認証情報は平文で送信せずに、ハッシュ関数と呼ばれる一定の計算手順で逆変換できない状態に加工してから送信する。<br> | |||
サーバ側では、クライアント側からユーザ名やパスワード等のそのものを受信することはできないが、<br> | |||
登録済みの情報から同じようにハッシュ値を算出して、クライアントから受信したハッシュ値に一致すれば認証成功となる。<br> | |||
<br> | |||
より安全性を高めるため、サーバとクライアントの双方がその場限りのランダムなデータ（nonceと呼ばれる）を生成して、送信するデータに付け加えてからハッシュ値を算出する。<br> | |||
これにより、認証情報そのものは同じでも、実際に送信するデータは毎回変化するため、秘密の情報を割り出さなくても実行できる反射攻撃などを防ぐことができる。<br> | |||
<br> | <br> | ||
ハッシュ関数の種類においては、ヘッダ領域の中で指定することができ、双方が対応しているアルゴリズムが採用される。<br> | |||
<u>当初の規格（RFC 2617）ではMD5方式が使用されていたが、現在では十分な安全性が確保できないことが知られており、改訂版（RFC 7616）ではSHA-256の使用が推奨されている。</u><br> | |||
<br> | <br> | ||
Digest認証は、認証情報を平文のまま送受信するBASIC認証（基本認証）と比較して、クライアントとサーバ間の伝送路の安全が確保されていない状況で認証情報を保護することができるが、<br> | |||
現代では、SSL/TLSを用いてHTTPによるデータ伝送全体を暗号化するHTTPS通信が広く普及しており、かつてより重要性は低下している。<br> | |||
<br> | <br> | ||
==== realmとは ==== | |||
realmは、サーバが要求する認証領域や識別領域を示すものである。<br> | |||
通常、この領域 (realm名) は保護されたリソースやWebサイトのドメイン名等で識別される。<br> | |||
<br> | <br> | ||
クライアントがリクエストを送信する際に、realmはクライアントに対してどの認証情報が必要かを示し、ユーザに対して正しい認証情報を提供するよう促す。<br> | |||
<br> | <br> | ||
例えば、HTTPヘッダにおいて、以下に示すようにrealmが指定される場合がある。<br> | |||
以下の例では、realmは<u>example.com</u>という文字列で、クライアントはこの識別領域での認証を行う必要がある。<br> | |||
<code>nonce</code>や<code>opaque</code>等の他のパラメータも設定されて、セキュリティの向上や攻撃からの保護を担っている。<br> | |||
WWW-Authenticate: Digest realm="example.com", qop="auth", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41" | |||
<br> | <br> | ||
==== NginXにおけるDigest認証モジュールの注意点 ==== | |||
Digest認証モジュールは、NginXのソースコードと一緒に配布されていないため、別途インストールする必要がある。<br> | |||
<br> | <br> | ||
Digest認証モジュールは、RFCに基づいて機能が完成しているが、実際の運用で使用するのに十分な安全性を確保するために、より広範な検証が必要な状態である。<br> | |||
現在の注意点については、[https://github.com/atomx/nginx-http-auth-digest/blob/master/bugs.txt bugs.txt]ファイルと[https://github.com/atomx/nginx-http-auth-digest/issues github issue tracker]を参照すること。<br> | |||
<br> | <br> | ||
==== Digest認証の設定 ==== | ==== Digest認証の設定 ==== | ||
Digest認証のパスワードファイルを作成する。<br> | Digest認証のパスワードファイルを作成する。<br> | ||
| 960行目: | 1,053行目: | ||
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 zypper 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> | <br><br> | ||
| 1,007行目: | 1,181行目: | ||
SHA-512が最も安全性が高いが、クライアント端末側がSHA-512に対応している必要がある。<br> | SHA-512が最も安全性が高いが、クライアント端末側がSHA-512に対応している必要がある。<br> | ||
<br> | <br> | ||
==== | ==== 自己署名証明書の発行(サーバ側) ==== | ||
===== 秘密鍵を作成する ===== | |||
openssl genrsa -out <秘密鍵のファイル名>.key 2048 | openssl genrsa -out <秘密鍵のファイル名>.key 2048 | ||
<br> | <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 | openssl req -sha256 -new -subj "/C=JP/ST=Tokyo/L=Tokyo City/O=Company Name/OU=Department/CN=*.<ドメイン名>" -key <秘密鍵のファイル名>.key -out <CSRのファイル名>.csr | ||
<br> | <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> | 作成したCSRに署名を行って、サーバ証明書を発行する。<br> | ||
<u><サーバ証明書のファイル名>. | <u><サーバ証明書のファイル名>.csrファイルは、サーバ証明書を発行するためのファイルのため、後で削除してもよい。</u><br> | ||
openssl x509 -sha256 -req -days <証明書の有効日数 例. 3650> -in <CSRのファイル名>.csr -signkey <秘密鍵のファイル名>.key -out <サーバ証明書のファイル名>.crt | openssl x509 -sha256 -req -days <証明書の有効日数 例. 3650> -in <CSRのファイル名>.csr -signkey <秘密鍵のファイル名>.key \ | ||
-extfile san.txt \ | |||
-out <サーバ証明書のファイル名>.crt | |||
<br> | <br> | ||
===== Webサーバの設定 ===== | |||
Webサーバに設置するものは、秘密鍵（.key拡張子）とサーバ証明書（.crt拡張子）の2つである。<br> | Webサーバに設置するものは、秘密鍵（.key拡張子）とサーバ証明書（.crt拡張子）の2つである。<br> | ||
<br> | <br> | ||
| 1,060行目: | 1,254行目: | ||
<br> | <br> | ||
==== 自己証明書の発行(クライアント側) ==== | ==== 自己証明書の発行(クライアント側) ==== | ||
===== 秘密鍵を作成する ===== | |||
openssl genrsa -out <秘密鍵のファイル名>.key 2048 | openssl genrsa -out <秘密鍵のファイル名>.key 2048 | ||
<br> | <br> | ||
秘密鍵のファイルのアクセス権限を変更する。<br> | |||
chmod 400 <秘密鍵のファイル名>.key | |||
<br> | |||
===== CSR(証明書署名要求) ===== | |||
作成した秘密鍵を使用して、クライアント側のCSRを作成する。<br> | 作成した秘密鍵を使用して、クライアント側のCSRを作成する。<br> | ||
openssl req -sha256 -new -subj "/C=JP/ST=Tokyo/L=Tokyo City/O=Company Name/OU=Department/CN=*.<ドメイン名>" \ | openssl req -sha256 -new -subj "/C=JP/ST=Tokyo/L=Tokyo City/O=Company Name/OU=Department/CN=*.<ドメイン名>" \ | ||
-key <秘密鍵のファイル名>.key -out <CSRのファイル名>.csr | -key <秘密鍵のファイル名>.key -out <CSRのファイル名>.csr | ||
<br> | <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> | 作成したCSRに署名を行って、サーバ証明書を発行する。<br> | ||
<u><サーバ証明書のファイル名>. | <u><サーバ証明書のファイル名>.csrファイルは、サーバ証明書を発行するためのファイルのため、後で削除してもよい。</u><br> | ||
openssl x509 -sha256 -req -days <証明書の有効日数 例. 3650> -in <CSRのファイル名>.csr -signkey <秘密鍵のファイル名>.key -out <サーバ証明書のファイル名>.crt | openssl x509 -sha256 -req -days <証明書の有効日数 例. 3650> -in <CSRのファイル名>.csr -signkey <秘密鍵のファイル名>.key \ | ||
-extfile san.txt \ | |||
-out <サーバ証明書のファイル名>.crt | |||
<br> | <br> | ||
<u>クライアントPCがWindowsの場合、Windows PCにインポートするには、サーバ証明書のファイル(.crt拡張子)をpkcs12形式に変換する必要がある。</u><br> | <u>クライアントPCがWindowsの場合、Windows PCにインポートするには、サーバ証明書のファイル(.crt拡張子)をpkcs12形式に変換する必要がある。</u><br> | ||
| 1,075行目: | 1,290行目: | ||
-out <クライアント側にインポートするサーバ証明書のファイル名>.p12 -name <任意の識別子名> | -out <クライアント側にインポートするサーバ証明書のファイル名>.p12 -name <任意の識別子名> | ||
<br> | <br> | ||
===== Webサーバの設定 ===== | |||
<u>サーバに設置するものは、サーバ証明書のファイル（.crt拡張子）と秘密鍵（.key拡張子）の2つである。</u><br> | <u>サーバに設置するものは、サーバ証明書のファイル（.crt拡張子）と秘密鍵（.key拡張子）の2つである。</u><br> | ||
<u>Windows | <u>Windows PC(クライアントPC)へ配布するものは、pkcs12形式に変換したクライアント側のサーバ証明書のファイル(.p12拡張子)である。</u><br> | ||
<br> | <br> | ||
Windows PCへクライアント側のサーバ証明書のファイル(.p12拡張子)をインポートする場合、ファイルを実行することによりインポート画面が起動するため、<br> | Windows PCへクライアント側のサーバ証明書のファイル(.p12拡張子)をインポートする場合、ファイルを実行することによりインポート画面が起動するため、<br> | ||
| 1,107行目: | 1,319行目: | ||
sudo systemctl restart nginx php-fpm | sudo systemctl restart nginx php-fpm | ||
<br><br> | <br><br> | ||
__FORCETOC__ | __FORCETOC__ | ||
[[カテゴリ:SUSE]] | [[カテゴリ:SUSE]][[カテゴリ:Web]] | ||