Reverse Proxy SSL証明書の集中管理

server {
    listen 80;
    server_name arakan60.com;
    rewrite ^(.*)$ https://$host$1 permanent;
}

server {
    listen 443 ssl;
    server_name arakan60.com;

    ssl_certificate /etc/letsencrypt/live/arakan60.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/arakan60.com/privkey.pem; 

    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;

    proxy_max_temp_file_size 0;

    location / {
        proxy_pass https://192.168.11.106;

    --- 以下省略 ---

server {
        listen 80;
	server_name arakan60.com;
        return 301 https://arakan60.com$request_uri;
}

server {
	listen 443 ssl;
	server_name arakan60.com;
	root /home/yaopi/www/wordpress;
	index index.htm index.php;
	
	# ssl on;
	ssl_certificate /etc/letsencrypt/live/arakan60.com/fullchain.pem;
	ssl_certificate_key /etc/letsencrypt/live/arakan60.com/privkey.pem; 

	# クライアントのIPアドレス取得
        set_real_ip_from    192.168.11.104; 
        real_ip_header      X-Forwarded-For;

    --- 以下省略 ---

server {
    listen 80;
    server_name arakan60.com;

    location ^~ /.well-known {
        root /home/yaopi/www/wordpress;　←　①
    }

    rewrite ^(.*)$ https://$host$1 permanent;
}

server {
    listen 443 ssl ssl http2;
    server_name arakan60.com;

    location ^~ /.well-known {
        root /home/yaopi/www/wordpress;　←　①’
    }

    ssl_certificate /etc/letsencrypt/live/arakan60.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/arakan60.com/privkey.pem; 

    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;

    proxy_max_temp_file_size 0;

    location / {
        proxy_pass http://192.168.11.106;　←　②

    --- 以下省略 ---

server {
        listen 80;
	server_name arakan60.com;
	root /home/yaopi/www/wordpress;
	index index.htm index.php;
	
	# クライアントのIPアドレス取得
        set_real_ip_from    192.168.11.104; 
        real_ip_header      X-Forwarded-For;

    --- 以下省略 ---

 * @package WordPress

 */

define('FORCE_SSL_ADMIN', true);
$_SERVER['HTTPS'] = 'on';

<script src="https://..." ></script>

　管理画面へのアクセスを簡単にかつ強制的に SSL 接続にするには

　リバースプロキシの使用 #

SSL を提供するリバースプロキシにより WordPress がホストされ、自身は SSL なしでホストされる場合、このオプションを設定すると当初すべてのリクエストが無限リダイレクトループに陥ります。これを避けるには HTTP_X_FORWARDED_PROTO ヘッダーを認識するように WordPress を構成してください。ここでリバースプロキシは適切に構成されており、ヘッダーを設定するものとします。

define('FORCE_SSL_ADMIN', true);
if ( ! empty( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https' ) {
       $_SERVER['HTTPS']='on';
}

「リバースプロキシ」のSSL脆弱性診断結果。

「Webサーバー」のSSL脆弱性診断結果。

	#
	# SSL に関する設定 ここから
	#

	#SSLセッションをキャッシュさせる
        ssl_session_cache shared:SSL:50m;

	#SSLセッションのタイムアウト
        ssl_session_timeout 1d;	

	#SSLセッションチケットは使わない
	ssl_session_tickets off;
	
	#利用するプロトコルを指定する
	ssl_protocols TLSv1.2 TLSv1.3;

	#サーバ指定のcipherにする
        ssl_prefer_server_ciphers on;

	#利用するcipherを指定
	ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
	
	#鍵長を 2048ビットにする
	ssl_dhparam /etc/ssl/dhparam.pem;

	#Strict Transport Security を長期（１年）に指定
	add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload';	
	
	#
	# SSL ここまで
	#

　SNI（Server Name Indication）とは
　一つのサーバーで複数のドメイン名を使用する場合に、 複数のSSL証明書を運用できるようにするSSL/TLSの拡張仕様です。

　1つのサーバーに複数のドメインが設定されている際の問題点
　SSL証明書は基本的に、１つのサーバー（１つのグローバルIPアドレス）に対して１ドメイン分しか利用できません。
　HTTPSプロトコルは、そのWebサイトにアクセスする前にまず特定のクライアントと、SSL証明書が設定されたサーバーとの間でSSLセッションを確立し、その中で暗号化通信を行います。
　セッションを確立する際にはまだクライアントがアクセスしたいドメインをサーバーは予測することが出来ないので、例えば１つのサーバーに複数のドメインが設定されていたとしても、ドメインごとにSSL証明書を使い分けることが出来ませんでした。
　例えばHTTPS通信を行いたいWebサイトを、複数のユーザーが利用しているレンタルサーバーで運用していて、全員が独自ドメインを取得していた場合はどうなるでしょう。あるサーバーに対してSSL証明書は１枚１ドメイン分しか利用できないので、ユーザー全員が同じドメインを使ってSSL通信を行わなければいけないことになります。

　名前ベースバーチャルホスト
　１つのサーバー（１つのグローバルIPアドレス）で複数のドメインを利用する技術のことを「名前ベースバーチャルホスト」と呼びます。
　一方、１つのサーバーに複数のグローバルIPアドレスを割り当てる技術のことを「IPベースバーチャルホスト」と呼びますが、この場合であれば各グローバルIPアドレスに対してユニークなSSL証明書を設定することが可能です。 ただし１つのサーバーに対して複数のグローバルIPアドレスを割り当てるには技術的にも金銭的にもコストが高くなり、HTTPS通信の実現に対するハードルは高まってしまいます。

　この問題を解決するためにSNI（Server Name Indication）が登場
　名前ベースバーチャルホストの技術が使われている場合において、SNIはドメインごとに異なるSSL証明書の運用を実現します。
　具体的にはSSLセッションを確立する際、クライアントブラウザがHTTPリクエストのHostヘッダを利用して、アクセスしたいドメインをサーバーへ通知します。するとサーバーも応答すべきドメインを理解することが出来るので、名前ベースバーチャルホストの場合でも正しいドメインでHTTPS通信が出来るという仕組みです。
　SNIはSSL/TLSの拡張的な仕様としてRFC（Request for Comments）にも記載されており、現在では多くのブラウザ、サーバーで対応しています。

但し、installer.php の最後のステップで、「Admin Login」をクリックすると、

「wp-login.php」へのアクセスで、無限リダイレクトループに陥る。

参考：WordPressを強制的にSSL化せずにインストールを実行すると、画面が崩れるがインストールは可能である。

nginxリバース プロキシ サーバーの構築

Raspberry Pi Webサーバーの構築 Nginx リバースプロキシ サーバー 複数の ドメイン別サーバーに振り分ける   これまで『Raspberry Pi』で、【3つのドメイン別サ

2020-03-26

2025-03-30

nginx-WordPress リバースプロキシにおける バッファの最適化

Webサーバー サイトの運用 nginx Reverse Proxy Server プロキシバッファの最適な設定   nginx で構築したリバースプロキシの下で、nginx + WordPr

2020-07-30

2022-08-01

Raspberry Pi – nginx プロキシキャッシュの RAMディスク化

Webサーバー サイトの運用 nginx Reverse Proxy プロキシキャッシュの RAMディスク化   Webサーバーを「Raspberry Pi 4 4GB」にアップグレードしてか

2020-08-25

2022-07-28