GlobalSign のSSL証明書を差し替える手順（更新・再発行・中間証明書の入れ替え）

GlobalSign の証明書の差し替えは、「新しい鍵とCSRで証明書を発行する」「サーバーに証明書・中間証明書・秘密鍵を正しい組み合わせで置く」「外から見て新しい証明書が返っているか確かめる」の3段階に分けると失敗しにくくなります。この記事では、期限前の更新、内容変更や鍵漏えいに伴う再発行、中間証明書の入れ替えのそれぞれについて、Nginx・Apache を例に作業手順とつまずきやすい点をまとめます。

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

一口に「差し替え」と言っても、何をきっかけに行うかで手順が少し変わります。最初に自分がどれに当たるかを確認してください。

• 更新: 有効期限が近づいたため、新しい証明書を発行して入れ替える。最も多いケースです。
• 再発行: 秘密鍵が漏えいした（疑いがある）、サーバー移転で鍵を作り直したい、コモンネームやSANを変更したい、といった理由で有効期間中に発行し直す。GlobalSign では管理画面（GlobalSign Certificate Center、GCC と呼ばれることが多い）から手続きします。画面の項目名は変わることがあるため、実際の表示に従ってください。
• 中間証明書の入れ替え: 認証局側の中間CAが切り替わったときや、チェーンの設定漏れを直すときに発生します。サーバー証明書は同じでも、組み合わせる中間証明書が変わります。

なお、公開サーバー証明書の最長有効期間は CA/Browser Forum の決定により段階的に短縮されており、2026年3月から最長200日程度、その後さらに短くなる予定です（2026年10月現在）。年1回の作業という前提が崩れつつあるため、手順を文書化して誰でも再現できるようにしておく価値が上がっています。

作業前の準備

現在の証明書の情報を控える

差し替え前に、いま配信している証明書のサブジェクト、SAN、発行者、有効期限を記録しておきます。新旧の比較ができると、差し替え後の確認が速くなります。

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

-servername を付けないと、同じIPで複数サイトを運用しているサーバーでは別サイトの証明書が返ることがあります。SNI を使う環境では省略しないでください。

古いファイルを上書きしない

設定ファイルが参照している証明書ファイルを直接上書きすると、問題が起きたときに戻せません。新しいファイルは日付入りの別名で置き、設定のパスを切り替える方式にしておくと、ロールバックは設定を戻して再読み込みするだけで済みます。作業前に設定ファイルと証明書ディレクトリのバックアップも取ってください。

証明書を置いている場所を洗い出す

意外に多い失敗が「Webサーバーは差し替えたが、ロードバランサーやCDN、メールサーバーは古いまま」というものです。同じ証明書を複数の機器やサービスに入れている場合は、一覧にしておきます。AWS の ALB、Cloudflare のカスタム証明書、メールサーバー（SMTP/IMAP の TLS）などは見落とされがちです。

手順1: 秘密鍵とCSRを作る

更新でも新しい鍵を作るのが基本です。鍵を使い回すと、過去に鍵が漏れていた場合のリスクを引き継ぐことになります。

openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.com-2026.key \
  -out example.com-2026.csr \
  -subj "/CN=example.com"
chmod 600 example.com-2026.key

SAN（www 付きなど）は申請画面で追加するのが一般的ですが、CSR に含めるよう求められる場合もあります。申請先の案内を確認してください。秘密鍵はサーバーの外に持ち出さず、メールやチャットで送らないことが大切です。

手順2: GlobalSign で申請・認証し、証明書を受け取る

管理画面で更新または再発行を選び、CSR を貼り付けます。ドメイン認証（DCV）はメール・DNS・ファイル設置などから選べることが多く、DNS に TXT レコードを追加する方式はWebサーバーの設定に左右されないため扱いやすい方法です。

発行されたら、サーバー証明書と一緒に提供される中間証明書も取得します。ここで重要なのは、中間証明書は新しい証明書と一緒に配布されたものを使うことです。前回の中間証明書を流用すると、認証局側で中間CAが切り替わっていた場合にチェーンがつながりません。

手順3: 証明書と鍵の組み合わせを確認する

設置前に、証明書と秘密鍵が対応しているかを公開鍵の比較で確かめます。RSA でも ECDSA でも使える方法です。

openssl x509 -in example.com-2026.crt -noout -pubkey | openssl sha256
openssl pkey -in example.com-2026.key -pubout | openssl sha256

2行のハッシュ値が一致すれば正しい組み合わせです。一致しないまま設定を読み込むと、Nginx や Apache は起動・再読み込みに失敗します。

続いて、サーバー証明書と中間証明書をこの順で連結したファイルを作ります。ルート証明書は通常含めません。

cat example.com-2026.crt globalsign-intermediate.crt > example.com-2026.fullchain.pem
openssl verify -untrusted globalsign-intermediate.crt example.com-2026.crt

openssl verify が OK を返せば、手元の環境のルート証明書までチェーンがつながっています。

手順4: サーバーに設置して再読み込みする

Nginx の場合

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

sudo nginx -t && sudo systemctl reload nginx

Nginx では ssl_certificate に連結済みのファイルを指定します。nginx -t で構文エラーが出たら再読み込みはせず、パスや鍵の組み合わせを見直してください。

Apache の場合

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

sudo apachectl configtest && sudo systemctl reload httpd

Apache 2.4.8 以降は SSLCertificateFile に中間証明書を連結したファイルを指定できます。古い構成で SSLCertificateChainFile を使っている場合は、そちらのファイルも新しい中間証明書に差し替える必要があります。サービス名は Debian/Ubuntu では apache2 です。

レンタルサーバーやコントロールパネルの場合

管理画面から証明書・秘密鍵・中間証明書を貼り付ける形式が一般的です。中間証明書の欄が別になっていることが多いので、空欄のまま保存しないよう注意してください。反映までに時間がかかるサービスもあります。

手順5: 外部から差し替えを確認する

再読み込み後、作業前と同じコマンドで発行者と有効期限が新しくなっているかを確認します。加えて、チェーンが送られているかを -showcerts で見ます。

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null \
  | grep -E "^ *[0-9] s:|^ *i:"

サーバー証明書（0番）と中間証明書（1番）の2段が表示されれば正常です。0番しか出ない場合は中間証明書の設定漏れで、パソコンのブラウザでは表示できてもスマートフォンや外部APIからの接続で失敗することがあります。SSL Labs の SSL Server Test のような外部ツールでの確認も有効です。

複数台構成やCDNを使っている場合は、各サーバーのIPを指定して1台ずつ確認するか、CDN 側の証明書設定画面で新しい有効期限になっているかを見てください。

WordPress サイトで気をつけること

証明書の差し替え自体は WordPress の設定変更を必要としません。ただし、次の点は確認しておくと安心です。

• 差し替え後に管理画面へログインし、ログインループやリダイレクトの異常がないか。
• サイトヘルス（ツール → サイトヘルス）で HTTPS 関連の警告が出ていないか。
• 外部サービス（決済、フォーム送信先、Webhook）がサーバー証明書を検証している場合、エラーが出ていないか。

古い証明書の後始末

新しい証明書で問題なく配信できていることを数日確認してから、古い証明書と鍵をサーバーから削除します。再発行の場合、認証局側で旧証明書が一定期間後に失効される運用があります。鍵漏えいが理由の再発行なら、旧証明書の失効手続きを早めに行ってください。具体的な扱いは GlobalSign の案内やサポートで確認してください。

まとめ

• 差し替えは「更新」「再発行」「中間証明書の入れ替え」のどれかを最初に見極める。
• 新しい鍵とCSRを作り、中間証明書は新しい証明書と一緒に配布されたものを使う。
• 設置前に公開鍵のハッシュで鍵と証明書の対応を確認し、古いファイルは上書きせず別名で置く。
• nginx -t や apachectl configtest を通してから再読み込みし、openssl s_client で発行者・期限・チェーンを外部から確認する。
• ロードバランサーやCDN、メールサーバーなど、同じ証明書を使う場所をすべて差し替える。

• 中間証明書が不足しているときの確認と直し方
• WordPressのSSL証明書の期限切れを監視して通知する方法