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

使用上の注意

開始する前に、次の要件を満たしていることを確認してください:

ステップ 1: SSL 証明書の準備

1. SSL 証明書 ページに移動します。対象の証明書の 操作 列で、証明書のダウンロード をクリックします。ダウンロード タブで、サーバータイプ が Nginx の証明書をダウンロードします。

2. ダウンロードした証明書パッケージを解凍します:

   • パッケージに証明書ファイル (.pem) と秘密鍵ファイル (.key) が含まれている場合は、両方のファイルを保存します。これらはデプロイメントに必要です。

   • パッケージに証明書ファイル (.pem) のみで秘密鍵ファイル (.key) が含まれていない場合は、ローカルに保存した秘密鍵ファイルを使用して証明書をデプロイする必要があります。

     説明

     証明書を申請する際に OpenSSL や Keytool などのツールを使用して証明書署名リクエスト (CSR) ファイルを生成した場合、秘密鍵ファイルはローカルにのみ保存されます。ダウンロードした証明書パッケージには秘密鍵は含まれません。秘密鍵を紛失した場合、証明書は使用できなくなります。再度 公式証明書を購入 し、新しい CSR と秘密鍵を生成する必要があります。

3. 解凍した証明書ファイル (.pem) と秘密鍵ファイル (.key) をサーバーにアップロードします。これらを /etc/ssl/cert ディレクトリなどの安全なディレクトリに保存します。

   説明

   PuTTY、XShell、WinSCP などのリモートログインツールのローカルファイルアップロード機能を使用してファイルをアップロードできます。Alibaba Cloud Elastic Compute Service インスタンスを使用している場合、ファイルのアップロード方法の詳細については、「ファイルのアップロードまたはダウンロード」をご参照ください。

ステップ 2: システムとネットワーク環境の構成

セキュリティグループとシステムファイアウォールが HTTPS ポート (443) でのインバウンドトラフィックを許可していることを確認してください。

1. サーバーターミナルで次のコマンドを実行して、ポート 443 が開いているかどうかを確認します:

   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 <The public IP address of the current server>:443 の場合、ポート 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 <public IP address of the current server> port [tcp/https] succeeded! または [<public IP address of the current server>] 443 (https) open の場合、ポート 443 は開いています。そうでない場合は、セキュリティグループとファイアウォールでポート 443 を開きます。

2. セキュリティグループの構成でポート 443 を開きます。

   重要

   サーバーがクラウドプラットフォームにデプロイされている場合は、そのセキュリティグループが TCP ポート 443 でのインバウンドトラフィックを許可していることを確認してください。そうしないと、サービスにアクセスできなくなります。以下の手順では、Alibaba Cloud Elastic Compute Service (ECS) を例として使用します。他のクラウドプラットフォームについては、公式ドキュメントをご参照ください。

   Elastic Compute Service インスタンス ページに移動し、対象のインスタンス名をクリックしてインスタンス詳細ページに移動します。「セキュリティグループルールを追加する」を参照して、[セキュリティグループ] に新しいルールを追加します。[アクション] を [許可] に、[プロトコルタイプ] を [カスタム TCP] に、[宛先ポート範囲] を [HTTPS(443)] に、[認証オブジェクト] を [すべての IPv4 アドレス] に設定します。

3. ファイアウォールでポート 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、ufw、nftables、または iptables) に基づいて以下の対応するコマンドを実行して、ポート 443 を開きます:

   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

ステップ 3: Nginx に SSL 証明書をインストールする

1. Nginx 用の SSL モジュールをインストールします。

   次のコマンドを実行します。出力が --with-http_ssl_module の場合、SSL モジュールはすでにインストールされています。そうでない場合は、インストールします。

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

   説明

   システムが nginx: command not found と表示する場合は、/usr/local/nginx/sbin/nginx など、Nginx の実際のインストールパスを使用してコマンドを実行します。例: /usr/local/nginx/sbin/nginx -V 2>&1 | grep -o -- '--with-http_ssl_module'。

   Nginx のインストール方法 (ソースからのコンパイルまたはパッケージマネージャを使用したインストール) に基づいて、SSL モジュールのインストール方法を選択します:

   重要

   • SSL モジュールの追加プロセス中に、Nginx サービスが短時間中断される可能性があり、オンラインビジネスに影響を与える可能性があります。

   • 常に最初に Nginx の構成とデータをバックアップしてください。これらの変更はオフピーク時に実行してください。変更が完了したら、構成を復元し、サービスが正常に実行されていることを確認してください。

   パッケージマネージャを使用する

   サーバーターミナルで次のコマンドを実行します:

   RHEL/CentOS

   # 公式 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

   Debian/Ubuntu

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

   ソースからコンパイルする

   1. 依存関係をインストールします。

      RHEL/CentOS

      sudo yum install -y gcc pcre-devel zlib-devel openssl-devel

      Debian/Ubuntu

      sudo apt-get update
      sudo apt-get install -y build-essential libpcre3 libpcre3-dev zlib1g zlib1g-dev libssl-dev

   2. 現在の Nginx コンパイルパラメーターを表示します。

      nginx -V

      configure arguments: の後にあるすべてのパラメーターを記録します。再コンパイル時にすべてを使用する必要があります。

   3. 現在の Nginx バージョンに一致するソースコードパッケージをダウンロードします。

      nginx -v を実行して現在の Nginx バージョンを表示します (1.14.2 を例として使用)。次に、現在の Nginx バージョンのソースコードパッケージをダウンロードして解凍します:

      wget http://nginx.org/download/nginx-1.14.2.tar.gz
      tar -zxvf nginx-1.14.2.tar.gz
      cd nginx-1.14.2

   4. Nginx を再コンパイルして SSL モジュールを追加します。

      記録した configure arguments: に --with-http_ssl_module を追加して再コンパイルします:

      # 注: 既存の機能モジュールを失わないように、すべての元のパラメーターを保持する必要があります。
      ./configure <Original parameters> --with-http_ssl_module
      make

      説明

      make を実行したときに error: ‘ENGINE_by_id’ is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations] エラーが発生した場合、これは一部の Nginx コードが OpenSSL 3.0 以降で非推奨としてマークされ、コンパイラがそれをエラーとして扱っていることを示します。これらの警告を無視して、make CFLAGS='-Wno-error=deprecated-declarations' を実行してコンパイルを完了できます。

   5. Nginx 実行可能ファイルを置き換えます。

      元の Nginx 実行可能ファイルをバックアップします (パス /usr/local/nginx/sbin/nginx を例として使用):

      # /usr/local/nginx/sbin/nginx を nginx ファイルの実際のパスに置き換えます。
      sudo cp /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.bak

      元の Nginx 実行可能ファイルを上書きします:

      # /usr/local/nginx/sbin/nginx を nginx ファイルの実際のパスに置き換えます。
      sudo cp objs/nginx /usr/local/nginx/sbin/nginx

   6. SSL モジュールがインストールされていることを確認します。

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

      出力が --with-http_ssl_module の場合、SSL モジュールはインストールされています。

2. Nginx で SSL 証明書と秘密鍵ファイルを設定します。

   重要

   このトピックでは、Nginx バージョン 1.14.2 と構成ファイルパス /etc/nginx/nginx.conf を例として使用します。この手順は、Nginx 構成と互換性のある Tengine にも適用されます。構成ファイルを見つけるには、「Linux サーバーでアクティブな Nginx 構成ファイル (nginx.conf) を見つけるにはどうすればよいですか？」をご参照ください。

   1. 次のコマンドを実行して構成ファイルを開きます。

      sudo vim /etc/nginx/nginx.conf

   2. ポート 443 をリッスンするサーバーブロックを追加します。

      ポート 80 用の既存のものをコピーして、HTTPS 用の新しい server ブロックを作成します。新しいブロックで、listen 80 を listen 443 ssl に変更し、ssl_certificate および ssl_certificate_key ディレクティブを含む SSL 証明書の構成を追加します。その他のフィールドは変更しません。

      # ポート 80 をリッスンする元のサーバーブロック
      server {
          listen 80;
          server_name yourdomain.com www.yourdomain.com;
          
          # その他の構成
          location / {
              proxy_pass http://127.0.0.1:8000;
          }
      }
      
      # HTTPS 用の新しいサーバーブロック。
      server {
          # 元の 'listen 80' を 'listen 443 ssl' に変更します。
          listen 443 ssl;
          # 元の server_name。現在の証明書でサポートされているドメイン名を追加できます。
          server_name yourdomain.com www.yourdomain.com;
          
          # ======================= 証明書構成の開始 =======================
          # 証明書ファイルを指定します (中間証明書はこの .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 {
          listen 80;
          server_name yourdomain.com www.yourdomain.com;
              
          # HTTP から HTTPS への自動リダイレクトを設定します。
          return 301 https://$host$request_uri;
          
          # 他の元の構成は到達不能になるため削除できます。
      }

   4. 次のコマンドを実行して、構成ファイルの構文エラーを確認します。出力が syntax is ok と test is successful の場合、テストは成功です。そうでない場合は、テストが成功するまでエラーメッセージに基づいて構成を修正します。

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

3. Nginx サービスを再読み込みします。

   重要

   このトピックでは、Nginx がデフォルトの構成パスで起動されることを前提としています。カスタムのインストールパスまたは構成ファイルがある場合は、コマンドとパスを適宜調整してください。

   Nginx が実行されているかどうかに基づいて、適切な操作を選択します:

   Nginx サービスが実行中の場合

   次のコマンドを実行して、サービスを再起動したり既存の接続を中断したりせずに Nginx 構成を再読み込みします。再読み込みが失敗した場合は、トラブルシューティングについて よくある質問 をご参照ください。

   sudo nginx -s reload

   Nginx サービスが実行されていない場合

   次のコマンドを実行して Nginx サービスを開始します。

   nginx

ステップ 4: デプロイメントの検証

インストールまたは更新後に証明書が機能しない、または HTTPS にアクセスできないのはなぜですか？

この問題は、多くの場合、以下の構成上の問題のいずれかが原因です。順番に確認してください:

• ポート 443 がブロックされている: サーバーのセキュリティグループまたはファイアウォールでポート 443 が開いていません。詳細については、「システムとネットワーク環境の構成」をご参照ください。

• ドメインの不一致: アクセスしているドメインが証明書の ドメイン名のバインド にリストされていません。詳細については、「ドメイン名の一致」をご参照ください。

• Nginx が再読み込みされていない: 構成ファイルを変更した後に Nginx サービスが再読み込みされていません。詳細については、「Nginx サービスを再読み込みする」をご参照ください。

• 証明書の構成が正しくない: 証明書ファイルが正しく置き換えられていないか、Nginx 構成が間違ったファイルパスを指しています。ssl_certificate と ssl_certificate_key のパスが正しいことを確認してください。

• 他のサービスに証明書がない: ドメインがコンテンツ配信ネットワーク (CDN)、Server Load Balancer (SLB)、Web Application Firewall (WAF) などのサービスを使用している場合、証明書はそれらのサービスにもインストールする必要があります。詳細については、「トラフィックが複数の Alibaba Cloud サービスを通過する場合の証明書のデプロイ場所」をご参照ください。

• 複数のサーバーへのデプロイが不完全: ドメインの DNS が複数のサーバーに解決される場合、証明書はそれらすべてにインストールする必要があります。

Nginx サーバーで SSL 証明書を更新または置換する正しい方法は何ですか？

ダウンタイムなしで証明書を更新するには、次の手順に従ってください:

1. 古いファイルのバックアップ: サーバー上の現在の証明書 (.pem) と秘密鍵 (.key) ファイルをバックアップします。

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

3. ファイルの置換: 新しいファイルをサーバーにアップロードし、古いファイルを上書きします。新しいファイルが Nginx 構成で指定されているものとまったく同じパスとファイル名であることを確認してください。

4. Nginx の再読み込み: Nginx サービスを再読み込みして、新しい証明書を適用します。

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

まず、実行時にカスタム構成ファイルが使用されているかどうかを確認します。

1. ターミナルで ps -ef | grep '[n]ginx: master' | grep -- ' -c ' を実行します。出力が -c /etc/nginx/custom.conf に似ている場合、Nginx は /etc/nginx/custom.conf 構成ファイルを使用しています。

2. ステップ 1 で説明したような出力がない場合、Nginx はデフォルトのコンパイル済みパスを使用しています。nginx -V 2>&1 | grep -oP -- '--conf-path=[^ ]*' を実行して、デフォルトの構成ファイルパスを表示します。たとえば、--conf-path=/etc/nginx/nginx.conf は /etc/nginx/nginx.conf がデフォルトで使用されることを示します。

一部のブラウザで「証明書が標準を満たしていません」というメッセージが表示されるのを防ぐために、Nginx で TLSv1.0 と TLSv1.1 を無効にするにはどうすればよいですか？

Nginx 構成ファイルの ssl_protocols ディレクティブを、ssl_protocols に TLSv1.2 と TLSv1.3 のみを使用するように変更します。

最終的な構成は 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 をリッスンしているため、Nginx がそれにバインドできないことを意味します。

1. 競合するプロセスの特定: sudo ss -tlnp | grep :443 コマンドを実行して、どのプロセスがポート 443 を使用しているかを特定します:

2. プロセスの停止または再構成: 特定されたら、競合するプロセス (Apache などの別の Web サーバーやスタックした Nginx インスタンスなど) を停止するか、別のポートを使用するように再構成する必要があります。

Nginx 構成テストがエラー: cannot load certificate "/etc/nginx/ssl/domain.pem" : BIO_new_file() failed で失敗するのはなぜですか？

このエラーは、Nginx が構成で指定された場所で証明書ファイルを見つけられないことを意味します。

これを修正するには、Nginx 構成ファイル内の ssl_certificate または ssl_certificate_key ディレクティブのパスを、証明書ファイルへの正しい絶対パスに修正します。

Nginx の再読み込みがエラー the "ssl" parameter requires ngx_http_ssl_module で失敗するのはなぜですか？

このエラーは、Nginx ビルドに HTTPS トラフィックを処理するために必要な SSL モジュールがないことを示します。

ngx_http_ssl_module を有効にして Nginx をインストールまたは再コンパイルする必要があります。手順については、「Nginx 用の SSL モジュールをインストールする」をご参照ください。

Nginx を再読み込みする際に、証明書ファイルを指す No such file or directory:fopen('/cert/3970497_demo.aliyundoc.com.pem','r') エラーが発生するのはなぜですか？

このエラーは、Nginx 構成で ssl_certificate または ssl_certificate_key に指定されたファイルパスが正しくないことを意味します。

これを解決するには、構成ファイル内のパスが .pem および .key ファイルへの正しい絶対パスであり、ファイルがその場所に存在することを確認します。

SSL 証明書ファイルを読み取ろうとすると、Nginx の再読み込みが permission denied エラーで失敗するのはなぜですか？

このエラーは、Nginx ワーカープロセスが実行されるユーザーが、証明書ファイルまたはその親ディレクトリに対する読み取り権限を持っていないために発生します。

1. Nginx ユーザーの特定: メインの nginx.conf ファイルで user ディレクティブを探します (例: user nginx;)。

2. 権限の確認: このユーザーが証明書ファイルと秘密鍵ファイルに対する読み取り (r) 権限、およびそれらに至るすべての親ディレクトリに対する実行 (x) 権限を持っていることを確認します。