SSL 証明書デプロイ障害の解決と HTTPS アクセス回復 - Certificate Management Service

このトピックでは、手動でデプロイした SSL 証明書が有効にならない場合や、Web サイトが安全ではないと報告される場合のトラブルシューティング方法について説明します。以下のステップバイステップガイドに従って、デプロイメントの失敗原因を特定し、解決してください。

トラブルシューティング手順

サーバーのポート 443 が開いているかの確認
- ECS サーバーをご利用の場合は、ECS コンソールのセキュリティグループページにアクセスして、ポート 443 が開いているかどうかを確認します。セキュリティグループの設定方法の詳細については、「セキュリティグループの管理」をご参照ください。
- Web Application Firewall (WAF) をご利用の場合は、サーバーのファイアウォール設定を確認し、ポート 443 への外部アクセスがブロックされていないことを確認します。そのために、以下の操作を実行してください。
  [Web Application Firewall 3.0 コンソール] にログインします。上部のメニューバーから、WAF インスタンスのリソースグループとリージョン（中国本土 または 中国本土以外）を選択します。
  
  左側のナビゲーションウィンドウで、[アクセス管理] をクリックします。
  
  [CNAME アクセス] タブで、ポート 443 への外部アクセスが許可されているかどうかを確認します。
Web サーバー構成ファイルの確認
- 構成ファイル内の証明書ファイル名およびパスが正しいかどうかを確認します。構成ファイルで指定された証明書の保存パスおよびファイル名が、サーバー上の実際のパスおよびファイル名と一致していることを確認してください。以下は Nginx 構成の例です。
```
server {
    # Port 443 is the default port for HTTPS
    listen 443 ssl;
    server_name example.com;

    # Replace the following paths with your own SSL certificate and private key file paths
    ssl_certificate /etc/nginx/ssl/example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;

    # Other configurations...
}
```
- 構成ファイルを変更後に正常に保存されたかどうかを確認します。
- Nginx や Apache などの一部の Web サーバーでは、変更した構成を有効にするためにサービスを再起動する必要があります。
  - Nginx サービスを再起動します。
    sudo nginx -s reload
  - Apache サービスを再起動します。
    sudo systemctl restart httpd
証明書の有効性の確認
- 証明書が有効期間内にあるかどうかを確認します。そのために、以下の操作を実行してください。
  [Certificate Management Service コンソール] にログインします。
  
  左側のナビゲーションウィンドウで、[証明書管理 > SSL 証明書管理] を選択します。
  
  [SSL 証明書管理] ページで、デプロイした証明書を見つけ、期限切れになっていないかを確認します。
  
  証明書が期限切れになっている場合は、できるだけ早く更新してください。公式証明書の更新方法の詳細については、「SSL 証明書の更新と期限切れ対応」をご参照ください。
- 証明書の ステータス が 発行済み であり、ドメイン名のバインド が正しいかどうかを確認します。
- 証明書が正しくインストールされていることを確認します。これには、証明書ファイルを正しいディレクトリに配置し、Web サーバー構成ファイル（Nginx や Apache など）の証明書セクションを設定して証明書を適用することが含まれます。
- 自己署名証明書をご利用の場合は、ブラウザが証明書を信頼しているかどうかを確認します。
  以下は、Google Chrome でブラウザが証明書を信頼しているかどうかを確認する方法の例です。
  
  自己署名証明書を使用している Web サイトをブラウザで開きます。
  
  アドレスバーのアイコンをクリックします。ブラウザが証明書を信頼している場合、警告アイコンは表示されません。ブラウザが証明書を信頼していない場合、次の図のように赤い警告アイコンが表示されます。
  
  証明書の詳細を表示します。ブラウザが証明書を信頼していない場合、証明書情報ウィンドウに警告メッセージが表示されます。
- 公式証明書をご利用の場合は、信頼できる認証局 (CA) によって発行されていることを確認します。そうでない場合、ブラウザが接続をブロックする可能性があります。
  以下は、Chrome ブラウザを使用して、自己署名ではない証明書が信頼できる認証局 (CA) によって発行されているかどうかを確認する方法の例です。
  
  証明書情報を表示します。
  
  アドレスバーの左側にあるアイコンをクリックします。
  
  [接続は安全です] をクリックすると、接続の詳細が表示されます。
  
  [Certificate (Valid)] または類似のオプションをクリックします。信頼できる CA が証明書を発行している場合、ブラウザは証明書が有効であることを示し、警告メッセージを表示しません。
  
  発行者情報を表示します。証明書情報ウィンドウで「Issuer」フィールドを見つけ、共通名 (CN) や組織名 (O) などの情報を確認し、有名な CA の名前が含まれているかどうかをチェックします。
ドメイン名の名前解決の確認
- DNS レコードが正しい IP アドレスを指しているかどうかを確認します。特に、最近ホストまたは IP アドレスを変更した場合は注意が必要です。
  Alibaba Cloud DNS コンソールにログインします。
  
  [権威 DNS 名前解決] ページの [権威ドメイン名] タブで、設定したいドメイン名をクリックして [解決設定] ページに移動します。
  
  [解決設定] ページで、[Add Record] ボタンをクリックします。レコード値 がご利用の IP アドレスと一致しているかどうかを確認します。一致していない場合は、[Edit] ボタンをクリックして更新します。
- 最近ドメイン名の名前解決設定を変更した場合、変更が有効になるまでに時間がかかることがあります。ローカル DNS キャッシュをクリアして再試行するか、変更が反映されるまで待機してください。
  以下のセクションでは、異なるオペレーティングシステムでローカル DNS キャッシュをクリアする方法について説明します。
  
  Windows
  
  コマンドプロンプトを開きます。Win+R キーを押して、cmd と入力し、Enter キーを押します。
  
  コマンドプロンプトで、次のコマンドを実行します。
  ipconfig /flushdns
  
  「Successfully flushed the DNS Resolver Cache.」というメッセージが返され、ローカル DNS キャッシュがクリアされたことを示します。
  
  macOS
  
  Terminal アプリケーションを開きます。
  
  Command+Space キーを押して Spotlight 検索を開き、「Terminal」と入力します。
  
  Terminal で、次のコマンドを実行して DNS キャッシュをクリアします。
  # dscacheutil is a command-line tool for interacting with the system's caching service. sudo dscacheutil -flushcache
  
  次に、次のコマンドを実行して mDNSResponder プロセスを HUP シグナルで再起動します。
  # mDNSResponder is the background process responsible for DNS services. Restarting it ensures the cache is fully flushed. sudo killall -HUP mDNSResponder
  
  エラーメッセージが返されない場合、コマンドは成功しています。
  
  説明
  管理者パスワードの入力を求められる場合があります。パスワードを入力したら、Enter キーを押します。
  
  Linux
  
  Linux では、ローカル DNS キャッシュをクリアする方法は、システムで使用されている DNS キャッシュサービスによって異なります。以下のセクションでは、一般的な DNS キャッシュサービスの方法について説明します。
  
  systemd-resolved
  
  Linux システムで systemd-resolved を使用して DNS キャッシュを管理している場合、次のコマンドを実行してキャッシュをクリアします。
  sudo systemd-resolve --flush-caches
  
  nscd (Name Service Cache Daemon)
  
  Linux システムで nscd を使用して DNS キャッシュを管理している場合、nscd サービスを再起動してキャッシュをクリアします。
  sudo service nscd restart
  
  または:
  sudo systemctl restart nscd
  
  dnsmasq
  
  Linux システムで dnsmasq を使用して DNS キャッシュを管理している場合、dnsmasq サービスを再起動してキャッシュをクリアします。
  sudo service dnsmasq restart
  
  または:
  sudo systemctl restart dnsmasq
  
  BIND
  
  Linux システムで BIND (Berkeley Internet Name Domain) を使用して DNS キャッシュを管理している場合、次のコマンドを実行してキャッシュをクリアします。
  sudo rndc flush
  
  NetworkManager
  
  一部の Linux ディストリビューションでは、NetworkManager を使用してネットワーク設定（DNS キャッシュを含む）を管理しています。NetworkManager サービスを再起動してキャッシュをクリアします。
  sudo service network-manager restart
  
  または:
  sudo systemctl restart NetworkManager
  
  説明
  ご利用のシステムで使用されている DNS キャッシュサービスに適したコマンドを選択してください。これらのコマンドを実行するには通常、管理者権限が必要なため、コマンドの前に sudo を追加する必要がある場合があります。DNS キャッシュをクリアすると、システムは DNS サーバーから最新のドメイン名解決情報を取得します。これにより、ネットワークアクセスの問題を解決できる場合があります。
ブラウザキャッシュのクリア
- ブラウザは古い SSL 証明書情報をキャッシュしている可能性があります。ブラウザのキャッシュをクリアしてから、再度 Web サイトにアクセスしてください。
- シークレットモードまたはプライベートモードで Web サイトにアクセスしてみてください。次の図は Google Chrome での操作を示しています。Microsoft Edge をご利用の場合は、[New InPrivate window] をクリックします。
証明書チェーンの完全性の確認
中間証明書およびルート証明書を含む証明書チェーン全体が完全であることを確認します。ブラウザは通常、ルート証明書からサーバー証明書までの完全な証明書チェーンを検証します。証明書チェーンが不完全な場合、ブラウザが証明書を信頼しない可能性があります。
説明

ルート証明書は証明書の信頼チェーンの起点であり、認証局 (CA) が発行するすべての下位証明書の真正性を検証するために使用されます。信頼できる CA によって発行された SSL 証明書のルート証明書は、主流の Web ブラウザー（Google Chrome、Mozilla Firefox、Microsoft Edge など）、オペレーティングシステム（Windows や macOS など）、モバイルオペレーティングシステム（iOS や Android など）を実行するモバイルデバイスにプリインストール済みです。ただし、アプリ、Java クライアント、古いブラウザ、IoT デバイスなどの一部のクライアントでは、サーバー証明書と同じタイプのルート証明書を手動でダウンロードしてインストールする必要があります。これにより、クライアントがサーバーとの安全な HTTPS 接続を確立できます。ルート証明書を手動でダウンロードする方法の詳細については、「ルート証明書のダウンロードとインストール」をご参照ください。

中間証明書 はルート証明書とエンドエンティティ証明書（SSL 証明書など）の間に位置し、上位の認証局 (CA) によって下位の CA に発行されます。Alibaba Cloud Certificate Management Service では、ダウンロードする PEM ファイルにサーバー証明書と中間証明書が含まれています。サーバー証明書は秘密鍵 (KEY ファイル) とペアになり、安全な HTTPS 通信を保証します。中間証明書を使用することで、ルート証明書が直接 SSL 証明書を発行することに関連するリスクを軽減できます。ルート証明書が取り消された場合、それによって直接署名された証明書は信頼されなくなります。中間証明書の秘密鍵を使用して SSL 証明書に署名することで、このリスクを軽減できます。中間証明書のダウンロード方法の詳細については、「SSL 証明書のダウンロード」をご参照ください。
証明書チェーンの欠落は、SSL 証明書検証の失敗の一般的な原因です。通常、PC のブラウザは Authority Information Access (AIA) URL リンクを使用して中間証明書を取得できます。ただし、一部の Android ブラウザはこの機能をサポートしていません。これにより、証明書が信頼できないという警告や Web サイトにアクセスできないなどの問題が発生する可能性があります。これを解決するには、SSL 証明書チェーン構造に基づいて証明書チェーンファイルを 1 つのファイルにマージし、サーバーに再デプロイします。ブラウザがサーバーに接続すると、ユーザ証明書と中間証明書をダウンロードし、証明書を信頼できるようになります。以下のコードは SSL 証明書チェーン構造を示しています。
```
-----BEGIN CERTIFICATE-----
Website certificate
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
CA intermediate certificate
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
CA root certificate
-----END CERTIFICATE-----
```
説明
SSL 証明書チェーン構造は通常、Web サイト証明書 > CA 中間証明書 > CA ルート証明書 です。中間証明書チェーンには複数のレイヤーが存在する場合もあります。
- SSL 証明書チェーンの表示方法
  
  この例では Google Chrome を使用します。
  
  ブラウザのアドレスバーでアイコンをクリックし、ポップアップウィンドウで [Connection is secure] をクリックします。
  
  ポップアップの [Connection is secure] ウィンドウで、[Certificate is valid] をクリックします。
  
  [Details] をクリックして、[Certification hierarchy] を表示し、SSL 証明書チェーンを確認します。次の図はその例です。
- SSL 証明書チェーンの補完方法
  
  Alibaba Cloud から証明書をリクエストした場合は、証明書ファイルを再度ダウンロードしてください。ダウンロードしたファイルには完全な証明書チェーンが含まれています。
  
  Windows オペレーティングシステムで、証明書を手動で開き、中間証明書を見つけて Base64 形式でエクスポートします。その後、エクスポートした内容を元の証明書ファイルにコピーします。
秘密鍵の正確性の確認
- Web サーバーにアップロードした証明書と秘密鍵が一致しており、正しいフォーマットであることを確認します。
  証明書署名要求 (CSR) を生成する際に、秘密鍵が作成されます。この秘密鍵は対応する証明書とともに使用する必要があります。以下は、Linux システムで秘密鍵が証明書と一致しているかどうかを検証する方法の例です。
  
  ECS インスタンスにログインし、次のコマンドを実行して証明書のインストールディレクトリに移動します。
  # The path /ssl is an example where / is the root directory. Replace it with the actual installation directory of your certificate. cd / ssl
  
  次のコマンドを実行して、証明書の公開鍵情報を表示し、MD5 ハッシュを取得します。
  # Change your_certificate.pem to the PEM file in your Elastic Compute Service certificate directory. sudo openssl x509 -in your_certificate.pem -noout -pubkey | openssl md5
  
  次のコマンドを実行して、秘密鍵ファイル内の公開鍵情報を表示し、MD5 ハッシュを取得します。
  # Change your_private_key.key to the private key file in your Elastic Compute Service certificate directory. sudo openssl rsa -in your_private_key.key -pubout | openssl md5
  
  2 つのコマンドによって返された MD5 ハッシュを比較します。同じであれば、秘密鍵は証明書と一致しています。
- 秘密鍵が紛失または破損している場合は、秘密鍵を再生成して新しい証明書をリクエストする必要がある場合があります。
ブラウザ互換性の確認
- 証明書フォーマットおよび暗号スイートが主流のブラウザと互換性があることを確認します。
  サーバー上の証明書フォーマットおよび暗号スイートが主流のブラウザと互換性があることを確認することは、Web サイトのセキュリティを確保するための重要なステップです。以下の方法で互換性を確保できます。
  
  信頼できる認証局 (CA) の使用
  
  SSL/TLS 証明書の発行に信頼できる CA を選択します。主流のブラウザは、これらの CA によって発行された証明書を自動的に信頼します。
  
  正しい証明書フォーマットの使用
  
  証明書が X.509 フォーマットであることを確認します。これは SSL/TLS 証明書の標準フォーマットです。
  
  証明書が X.509 フォーマットであるかどうかを確認するには、証明書ファイルの内容およびフォーマットをチェックします。
  
  openssl コマンドラインツールを使用して証明書の内容を表示します
  # Replace /ssl/cert.pem with the actual installation path of your certificate file. sudo openssl x509 -in /ssl/cert.pem -text -noout
  
  証明書が X.509 フォーマットの場合、このコマンドはバージョン、シリアル番号、署名アルゴリズム、発行者、有効期間、公開鍵情報などの詳細な証明書情報を返します。
  
  出力例:
  Certificate: Data: Version: 3 (0x2) Serial Number: 01:23:45:67:89:ab:cd:ef:01:23:45:67:89:ab:cd:ef Signature Algorithm: sha256WithRSAEncryption Issuer: C = US, O = DigiCert Inc Validity Not Before: Jan 17 00:00:00 2025 GMT Not After : Jan 17 23:59:59 2026 GMT Subject: CN = example.com Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (2048 bit) ......
  
  このコマンドが正常に実行され、詳細な証明書情報が表示される場合、証明書は X.509 フォーマットです。
  
  証明書および中間証明書チェーンを PEM フォーマット（通常は .crt または .pem ファイル）で保存します。
  
  最新の暗号スイートの使用
  
  TLS 1.2 または TLS 1.3 などの最新の暗号スイートを使用するようにサーバーを構成します。これらのバージョンは、セキュリティと互換性を向上させます。
  
  SSL 2.0、SSL 3.0、TLS 1.0、TLS 1.1、RC4、3DES などの安全でないプロトコルおよび暗号化アルゴリズムを無効にします。
- 異なるブラウザおよびデバイスで接続性をテストします。
証明書ファイルディレクトリの読み取り権限の確認
証明書ファイルが保存されているディレクトリに正しい読み取り権限が設定されていることを確認し、Web サーバーがこれらのファイルにアクセスできるようにします。
以下は、Linux サーバーで証明書ファイルディレクトリに適切な読み取り権限があるかどうかを確認する方法の例です。
1. ls -ld コマンドを実行してディレクトリの権限を表示します。
  # Replace the example path /ssl with the actual installation path of your certificate file. sudo ls -ld /ssl
  
  コマンドは次のような情報を返します。
  
  説明
  権限フィールド（例: drwxr-xr-x）について以下に説明します。
  
  最初の文字 d はディレクトリを示します。
  
  次の 3 文字 rwx は所有者の権限を示します: 読み取り (r)、書き込み (w)、実行 (x)。
  
  中央の 3 文字 r-x は同じグループ内のユーザーの権限を示します: 読み取り (r) および実行 (x)。
  
  最後の 3 文字 r-x は他のユーザーの権限を示します: 読み取り (r) および実行 (x)。
2. 権限が適切かどうかを確認します。
  
  読み取り権限: 関連するユーザーまたはサービスがディレクトリに対して読み取り (r) 権限を持っていることを確認します。
  
  実行権限: ディレクトリの場合、実行 (x) 権限によりユーザーはディレクトリに入ることができます。たとえば、cd コマンドを使用できます。
3. （任意）権限を変更します。
  
  権限を変更するには、chmod コマンドを実行します。
  # Replace the example path /ssl with the actual installation path of your certificate file. sudo chmod 750 /ssl
  
  説明
  750 権限は以下を示します。
  
  所有者は読み取り、書き込み、実行の権限を持ちます。
  
  同じグループ内のユーザーは読み取りおよび実行の権限を持ちます。
  
  他のユーザーは権限を持ちません。
これらの手順により、Linux サーバー上のディレクトリの読み取り権限を確認および調整し、セキュリティと適切な機能を確保できます。