Certificate Management Service:Nginx または Tengine サーバー (Linux) への SSL 証明書のインストール

ポート 443 が開放されているかの確認

次のコマンドを実行して、ポート 443 の接続性をテストします。<your_server_public_ip> をサーバーのパブリック IP アドレスに置き換えてください。

RHEL/CentOS

command -v nc > /dev/null 2>&1 || sudo yum install -y nc
# <your_server_public_ip> をサーバーのパブリック IP アドレスに置き換えます。
sudo ss -tlnp | grep -q ':443 ' || sudo nc -l 443 & sleep 1; nc -w 3 -vz <your_server_public_ip> 443

出力が Ncat: Connected to <your_server_public_ip>:443 の場合、ポート 443 は開放されています。そうでない場合は、以下の手順を実行してください。

Debian/Ubuntu

command -v nc > /dev/null 2>&1 || sudo apt-get install -y netcat
# <your_server_public_ip> をサーバーのパブリック IP アドレスに置き換えます。
sudo ss -tlnp | grep -q ':443 ' || sudo nc -l -p 443 & sleep 1; nc -w 3 -vz <your_server_public_ip> 443

出力が Connection to <your_server_public_ip> port [tcp/https] succeeded! または [<your_server_public_ip>] 443 (https) open の場合、ポート 443 は開放されています。そうでない場合は、以下の手順を実行してください。

セキュリティグループでのポート 443 の開放

Elastic Compute Service (ECS) インスタンス ページに移動し、対象のインスタンス名をクリックします。 [セキュリティグループの詳細] セクションで、次の設定でルールを追加し、セキュリティグループのルールを追加 をクリックします：

システムファイアウォールでのポート 443 の開放

次のコマンドを実行して、アクティブなファイアウォールを特定します。

if command -v systemctl >/dev/null 2>&1 && systemctl is-active --quiet firewalld; then
    echo "firewalld"
elif command -v ufw >/dev/null 2>&1 && sudo ufw status | grep -qw active; then
    echo "ufw"
elif command -v nft >/dev/null 2>&1 && sudo nft list ruleset 2>/dev/null | grep -q 'table'; then
    echo "nftables"
elif command -v systemctl >/dev/null 2>&1 && systemctl is-active --quiet iptables; then
    echo "iptables"
elif command -v iptables >/dev/null 2>&1 && sudo iptables -L 2>/dev/null | grep -qE 'REJECT|DROP|ACCEPT'; then
    echo "iptables"
else
    echo "none"
fi

出力が none の場合、ファイアウォールのアクションは不要です。そうでない場合は、ファイアウォールの種類に応じたコマンドを実行してください。

firewalld

sudo firewall-cmd --permanent --add-port=443/tcp && sudo firewall-cmd --reload

ufw

sudo ufw allow 443/tcp

nftables

sudo nft add table inet filter 2>/dev/null
sudo nft add chain inet filter input '{ type filter hook input priority 0; }' 2>/dev/null
sudo nft add rule inet filter input tcp dport 443 counter accept 2>/dev/null

iptables

sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT

再起動後も iptables のルールを永続化するには：

• RHEL/CentOS：

  sudo yum install -y iptables-services
  sudo service iptables save

• Debian/Ubuntu：

  sudo apt-get install -y iptables-persistent
  sudo iptables-save | sudo tee /etc/iptables/rules.v4 >/dev/null

SSL モジュールのインストール

次のコマンドを実行します。出力が --with-http_ssl_module の場合、SSL モジュールはすでにインストールされているため、「SSL 証明書の設定」に進むことができます。

nginx -V 2>&1 | grep -o -- '--with-http_ssl_module'

システムが nginx: command not found を返す場合は、/usr/local/nginx/sbin/nginx -V 2>&1 | grep -o -- '--with-http_ssl_module' のように完全なインストールパスを使用してください。

SSL モジュールがない場合は、Nginx のインストール方法に応じて、以下のいずれかの方法でインストールします。

# Nginx の公式リポジトリを追加します。
sudo tee /etc/yum.repos.d/nginx.repo <<EOF
[nginx-stable]
name=nginx stable repo
baseurl=https://nginx.org/packages/centos/\$releasever/\$basearch/
gpgcheck=1
enabled=1
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=true
EOF

# Nginx をアップグレードします。
sudo yum upgrade nginx

# Nginx をアップグレードします。
sudo apt-get update
sudo apt-get install --only-upgrade nginx

SSL 証明書の設定

1. 設定ファイルを開きます。証明書ファイル (.pem または .crt) と秘密鍵ファイル (.key) のファイル名と保存パスはカスタマイズできます。Nginx の設定で指定するパスが正しく、Nginx プロセスがそれらのファイルに対する読み取り権限を持っていることを確認してください。

   sudo vim /etc/nginx/nginx.conf

2. HTTPS 用の server ブロックを追加します。ポート 80 をリッスンしている既存の server ブロックをコピーし、listen 80 を listen 443 ssl に変更し、以下に示す SSL ディレクティブを追加します。他の設定はすべて変更しないでください。

   # ポート 80 をリッスンする元の server ブロック
   server {
       listen 80;
       server_name yourdomain www.yourdomain;
   
       # その他の設定
       location / {
           proxy_pass http://127.0.0.1:8000;
       }
   }
   
   # HTTPS 用の新しい server ブロック
   server {
       # 元の 'listen 80' を 'listen 443 ssl' に変更します。
       listen 443 ssl;
       # 元の server_name。現在の証明書でサポートされているドメイン名を追加できます。
       server_name yourdomain www.yourdomain;
   
       # ======================= 証明書設定の開始 =======================
       # 証明書ファイルを指定します (中間証明書はこの .pem ファイルに追加できます)。/etc/ssl/cert/ssl.pem を証明書ファイルの絶対パスに置き換えます。
       ssl_certificate /etc/ssl/cert/ssl.pem;
       # 秘密鍵ファイルを指定します。/etc/ssl/cert/ssl.key を秘密鍵ファイルの絶対パスに置き換えます。
       ssl_certificate_key /etc/ssl/cert/ssl.key;
       # パフォーマンスを向上させるために SSL セッションキャッシュを設定します。
       ssl_session_cache shared:SSL:1m;
       # SSL セッションのタイムアウト期間を設定します。
       ssl_session_timeout 5m;
       # 使用する TLS プロトコルの種類と暗号スイートをカスタマイズします (以下は設定例です。設定が必要かどうかを評価してください)。
       ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
       # 許可される TLS プロトコルバージョンを指定します。TLS バージョンが高いほど HTTPS 通信のセキュリティが向上しますが、低い TLS バージョンよりもブラウザの互換性が劣ります。
       ssl_protocols TLSv1.2 TLSv1.3;
       # サーバーが指定した暗号スイートを優先します。
       ssl_prefer_server_ciphers on;
       # ======================= 証明書設定の終了 =======================
   
       # その他の設定
   }

3. (任意) HTTP を HTTPS にリダイレクトするには、ポート 80 の server ブロックに return ディレクティブを追加します。

   # ポート 80 をリッスンする元の server ブロック
   server {
       listen 80;
       server_name yourdomain www.yourdomain;
   
       # すべての HTTP トラフィックを HTTPS にリダイレクトします。
       return 301 https://$host$request_uri;
   
       # 他の元の設定は実行されなくなるため、削除できます。
   }

4. (オプション) Nginx または Tengine の Web サービスが Docker コンテナで実行されている場合の証明書パスを設定します。

   コンテナには独自のファイルシステムがあり、ホストサーバーから隔離されているため、Nginx はホストパスから直接証明書ファイルを読み取ることができません。SSL Certificates コンソールからダウンロードしたデジタル証明書 (.pem ファイル、中間証明書チェーンを含む) と秘密鍵ファイルをコンテナにマウントし、コンテナ内のパスを参照します。

   1. コンテナを起動する際に、証明書ファイル、秘密鍵ファイル、設定ファイルをマッピングします。:ro オプションは、それらを読み取り専用としてマウントします。

      # /host/path/to/ をホストサーバー上の証明書ファイル、秘密鍵ファイル、設定ファイルの実際の絶対パスに置き換えます。
      docker run -d --name nginx-ssl \
        -v /host/path/to/cert.pem:/etc/nginx/ssl/cert.pem:ro \
        -v /host/path/to/cert.key:/etc/nginx/ssl/cert.key:ro \
        -v /host/path/to/nginx.conf:/etc/nginx/nginx.conf:ro \
        -p 443:443 \
        nginx

   2. nginx.conf で、ssl_certificate と ssl_certificate_key の設定項目をホストパスではなくコンテナ内のパスに設定します。

      ssl_certificate     /etc/nginx/ssl/cert.pem;
      ssl_certificate_key /etc/nginx/ssl/cert.key;

   3. コンテナを再起動して変更を適用します。

      docker restart nginx-ssl

   ファイルがマウントされていない場合、または nginx.conf がコンテナ内のパスではなくホストパスを指している場合、Nginx は起動に失敗し、cannot load certificate: No such file or directory というエラーを返します。詳細なトラブルシューティングについては、よくある質問をご参照ください。コンテナが再起動した後、ブラウザでサイトを開き、証明書が正しく読み込まれることを確認します。

5. 設定の構文エラーをテストします。

   sudo nginx -t -c /etc/nginx/nginx.conf

   出力に syntax is ok と test is successful の両方が含まれている場合、設定は有効です。そうでない場合は、報告されたエラーを修正し、再度テストを実行してください。

Nginx のリロード

sudo nginx -s reload

nginx

インストール後に HTTPS にアクセスできないのはなぜですか？

以下の項目を順番に確認してください。

• ポート 443 がブロックされている — セキュリティグループまたはファイアウォールがポート 443 でのインバウンドトラフィックを許可していません。「ポート 443 の開放」をご参照ください。

• ドメインの不一致 — アクセスしているドメインが証明書の [バインド済みドメイン] にリストされていません。「前提条件」のドメインカバレッジ表をご参照ください。

• Nginx がリロードされていない — 変更後に設定がリロードされていません。sudo nginx -s reload を実行してください。

• ファイルパスが間違っている — ssl_certificate または ssl_certificate_key ディレクティブが不正なパスを指しています。.pem ファイルと .key ファイルへの絶対パスを確認してください。

• アップストリームサービスに証明書がない — ドメインが Content Delivery Network (CDN)、Server Load Balancer (SLB)、または Web アプリケーションファイアウォール (WAF) を経由している場合、証明書はそれらのサービスにもインストールする必要があります。「トラフィックが複数の Alibaba Cloud サービスを通過する場合の証明書デプロイ場所」をご参照ください。

• 証明書がすべてのサーバーにデプロイされていない — ドメイン DNS が複数のサーバーに解決される場合、それぞれのサーバーに証明書をインストールしてください。

さらにヘルプが必要な場合は、「ブラウザのエラーメッセージに基づく証明書デプロイ問題の解決」および「SSL 証明書デプロイのトラブルシューティングガイド」をご参照ください。

ダウンタイムなしで SSL 証明書を更新または置換するにはどうすればよいですか？

1. サーバー上の現在の .pem ファイルと .key ファイルをバックアップします。

2. Certificate Management Service コンソールから新しい証明書と秘密鍵をダウンロードします。

3. 新しいファイルをサーバーにアップロードし、既存のファイルを上書きします。 Nginx 設定で参照されているものと全く同じファイルパスと名前を使用してください。

4. Nginx をリロードします：sudo nginx -s reload。

Linux サーバーでアクティブな Nginx 設定ファイル (nginx.conf) を見つけるにはどうすればよいですか？

1. ps -ef | grep '[n]ginx: master' | grep -- ' -c ' を実行します。出力に -c /etc/nginx/custom.conf のような出力がある場合、Nginx はそのカスタム設定ファイルを使用しています。

2. ステップ 1 で出力がない場合、Nginx はデフォルトのパスを使用しています。nginx -V 2>&1 | grep -oP -- '--conf-path=[^ ]*' を実行して、--conf-path=/etc/nginx/nginx.conf のようなデフォルトパスを表示します。

「証明書が標準を満たしていません」という警告を修正するために TLSv1.0 と TLSv1.1 を無効にするにはどうすればよいですか？

Nginx の設定で ssl_protocols ディレクティブを次のように設定します。

ssl_protocols TLSv1.2 TLSv1.3;

これにより、安全でない TLSv1.0 および TLSv1.1 プロトコルが無効になります。ファイルを保存した後、nginx -s reload を実行して変更を適用します。

nginx -t が bind() to 0.0.0.0:443 failed (98: Address already in use) で失敗するのはなぜですか？

別のプロセスがすでにポート 443 をリッスンしています。sudo ss -tlnp | grep :443 を実行して特定します。その後、競合するプロセス (別の Web サーバーやハングした Nginx インスタンスなど) を停止するか、別のポートを使用するように再設定してください。

nginx -t が cannot load certificate "/etc/nginx/ssl/domain.pem": BIO_new_file() failed で失敗するのはなぜですか？

Nginx は設定で指定されたパスに証明書ファイルを見つけられません。nginx.conf の ssl_certificate ディレクティブを、.pem ファイルの実際の絶対パスを指すように修正してください。

Nginx のリロードが the "ssl" parameter requires ngx_http_ssl_module で失敗するのはなぜですか？

Nginx のビルドに SSL モジュールがありません。ngx_http_ssl_module を有効にして Nginx をインストールまたは再コンパイルしてください。「SSL モジュールのインストール」をご参照ください。

Nginx をリロードすると No such file or directory: fopen('/cert/3970497_demo.aliyundoc.com.pem','r') が表示されるのはなぜですか？

ssl_certificate または ssl_certificate_key に指定されたパスが正しくありません。設定内のパスが正しい絶対パスであり、ファイルがその場所に存在することを確認してください。

Nginx が permission denied エラーで SSL 証明書ファイルの読み取りに失敗するのはなぜですか？

Nginx のワーカープロセスユーザーが証明書ファイルへの読み取りアクセス権を持っていません。

1. Nginx のワーカーユーザーを見つけます：nginx.conf の user ディレクティブを探します (例：user nginx;)。

2. そのユーザーに証明書と秘密鍵ファイルに対する読み取り (r) 権限と、パス内のすべての親ディレクトリに対する実行 (x) 権限を付与します。

Nginx 1.2 は SSL Certificate Management V2.0 からダウンロードした証明書をサポートしていますか？

はい。SSL Certificate Management V2.0 を通じて発行された証明書は、V1.0 を通じて発行されたものと同じです。唯一の違いは購入方法です。