2026年6月16日

ワイルドカードSSL証明書の差し替え手順｜設置箇所の洗い出しから鍵の照合・反映確認まで

ドメイン管理

ワイルドカードSSL証明書の差し替えは、「新しい証明書を1か所に入れて終わり」ではなく、同じ証明書を使っているすべてのサーバーやサービスを洗い出し、それぞれで入れ替えて確認する作業です。1台でも古い証明書が残ると、期限が来た日にそのサブドメインだけが止まります。この記事では、更新や認証局の変更で証明書を入れ替えるときの手順を、洗い出し、新しい証明書の検証、各サーバーへの反映、確認と切り戻しの順に説明します。

作業は本番の設定ファイルを書き換えるため、既存の証明書・秘密鍵・設定ファイルのコピーを取ってから始めてください。管理画面の表記や各クラウドの手順は変わることがあるため、各サービスの最新の案内も合わせて確認します（2026年10月現在）。

差し替えが必要になる場面

有償証明書の期限が近づき、更新した新しい証明書を受け取った
認証局（CA）を変えた、または中間証明書が切り替わった
秘密鍵の漏えいが疑われ、鍵ごと作り直した
証明書の対象（SAN）にドメイン名を追加した

最後の2つは、期限に関係なく急いで入れ替える場面です。鍵の漏えいが疑われる場合は、差し替えに加えて古い証明書の失効手続きも認証局に申請します。

なお、公開用の TLS 証明書の最長有効期間は、CA/Browser Forum の決定で段階的に短くなっています。差し替えの回数は今後増えていくため、手作業で入れている箇所は自動化できないかも合わせて検討しておくとよいでしょう。

手順1：証明書を使っている場所を洗い出す

ワイルドカード証明書は、多くのサブドメインやサーバーで使い回されがちです。差し替え漏れを防ぐため、最初に一覧を作ります。

Web サーバー（Nginx・Apache）が動いている各サーバー
ロードバランサーやリバースプロキシ
CDN や WAF のサービス（独自証明書をアップロードしている場合）
メールサーバー（SMTP・IMAP の TLS）、FTP サーバー
社内ツールや監視システム、ステージング環境

サブドメインごとに、いま返している証明書のシリアル番号と期限を確認すると、古い証明書を使っている場所が分かります。

for h in www.example.com shop.example.com staging.example.com; do
  echo "== $h"
  openssl s_client -connect "$h:443" -servername "$h" </dev/null 2>/dev/null \
    | openssl x509 -noout -serial -enddate
done

メールサーバーは -starttls smtp などを付け、該当ポートに接続して確認します。

手順2：新しい証明書の中身を検証する

受け取った証明書をサーバーに入れる前に、手元で次の3点を確認します。ここで不一致に気づけば、本番を止めずに済みます。

対象のドメイン名と期限

openssl x509 -in new_cert.pem -noout -subject -issuer -dates -ext subjectAltName

*.example.com は1階層分のサブドメインだけが対象です。example.com 自体や a.b.example.com は含まれないため、必要なら SAN に example.com が入っているかを確かめます。

秘密鍵との対応

証明書と秘密鍵の公開鍵部分が一致しているかを比べます。RSA でも ECDSA でも使える方法です。

openssl x509 -in new_cert.pem -noout -pubkey | openssl sha256
openssl pkey -in new_key.pem -pubout | openssl sha256

2つのハッシュが一致すれば対応しています。CSR を作り直したのに古い鍵を指定してしまう、というミスはここで見つかります。

中間証明書の並び

サーバー証明書の後ろに、認証局から案内された中間証明書を順につなげたファイル（fullchain）を作ります。ルート証明書は通常含めません。

cat new_cert.pem intermediate.pem > fullchain.pem

中間証明書が欠けると、パソコンのブラウザでは表示できても、一部のスマートフォンや API クライアントでエラーになることがあります。

手順3：各サーバーに反映する

秘密鍵の置き場所と権限

秘密鍵は Web から見えない場所に置き、所有者だけが読めるようにします。

sudo install -m 600 -o root -g root new_key.pem /etc/ssl/private/example.com-2026.key
sudo install -m 644 -o root -g root fullchain.pem /etc/ssl/certs/example.com-2026.fullchain.pem

ファイル名に年や連番を入れ、古いファイルは消さずに残しておくと、切り戻しが設定の書き換えだけで済みます。秘密鍵をメールやチャットで送るのは避け、SSH などの暗号化された経路で転送します。

Nginx の場合

ssl_certificate     /etc/ssl/certs/example.com-2026.fullchain.pem;
ssl_certificate_key /etc/ssl/private/example.com-2026.key;

sudo nginx -t && sudo systemctl reload nginx

nginx -t で構文と鍵の読み込みを確認してから reload します。restart ではなく reload を使うと、接続中の通信を切らずに切り替えられます。

Apache の場合

Apache 2.4.8 以降は、SSLCertificateFile に中間証明書を含めたファイルを指定できます。

SSLCertificateFile    /etc/ssl/certs/example.com-2026.fullchain.pem
SSLCertificateKeyFile /etc/ssl/private/example.com-2026.key

sudo apachectl configtest && sudo systemctl reload apache2

サービス名はディストリビューションによって httpd の場合があります。

レンタルサーバー・クラウド・CDN の場合

管理画面で証明書・秘密鍵・中間証明書を貼り付ける方式が多く、手順2で検証したファイルの中身をそのまま使います。AWS の ACM に外部の証明書をインポートしている場合は、既存の証明書を再インポートすると ARN が変わらず、ロードバランサー側の設定を変えずに済みます。CDN は反映までに時間がかかることがあるため、旧証明書の期限に余裕を持って作業します。

手順4：反映を確認する

手順1のコマンドをもう一度実行し、すべてのホストで新しいシリアル番号と期限が返ってくるかを確認します。あわせて次も見ます。

ブラウザで主要なサブドメインを開き、証明書の発行者と期限を表示する
中間証明書を含めて送っているかを openssl s_client -showcerts で確認する
WordPress サイトなら、管理画面へのログイン、外部 API の連携、問い合わせフォームの送信を一通り試す
証明書の残り日数を監視するツールに、新しい期限が反映されているか

うまくいかないときの切り戻し

設定ファイルのパスを旧ファイルに戻して reload すれば、元の証明書に戻ります。よくある失敗は、鍵と証明書の組み合わせ違い（Nginx はエラーで起動を拒否します）、中間証明書の欠落、別の VirtualHost や server ブロックに古いパスが残っていることです。設定内で旧ファイル名を検索すると、差し替え漏れを見つけやすくなります。

まとめ

差し替えは、証明書を使っているサーバー・サービスの洗い出しから始めます。シリアル番号を比べると漏れが分かります。
入れる前に、対象のドメイン名、秘密鍵との一致、中間証明書の並びを手元で検証します。
鍵は権限を絞って置き、旧ファイルを残したまま新しいパスに切り替えると切り戻しが簡単です。
反映後は全ホストで証明書を再確認し、有効期間の短縮に備えて自動化も検討します。