2026年8月17日

マルチドメインSSL（SAN証明書）を更新する方法：ホスト名の棚卸しから全サーバーへの差し替えまで

ドメイン管理

マルチドメインSSL（SAN証明書）の更新は、「今の証明書に入っているホスト名を確認する」「残す・追加する・外すホスト名を決める」「新しい鍵と CSR で申請し、すべてのホスト名のドメイン認証を済ませる」「証明書を使っているすべてのサーバーで差し替えて確認する」の4段階で進めます。1枚の証明書に複数のホスト名が入っているため、1つのホスト名の認証が通らないだけで全体の発行が止まり、差し替え漏れが1台あるだけでそのサーバーだけ期限切れになる、という点が単一ドメインの証明書との違いです。この記事では、商用の認証局（CA）で更新する場合と、Let's Encrypt（Certbot）で更新する場合の両方の手順を説明します。

手順1：現在の証明書に含まれるホスト名を確認する

まず、公開中の証明書の SAN（サブジェクト代替名）を一覧にします。管理画面の注文情報だけで判断せず、実際に配信されている証明書を確認するのが確実な方法です。

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

X509v3 Subject Alternative Name の行に DNS:example.com, DNS:www.example.com, DNS:shop.example.net のように並んでいるのが、この証明書でカバーしているホスト名です。現在のブラウザはホスト名の照合に SAN を使うため、ここに載っていないホスト名は証明書の対象外です。

あわせて、この証明書を「どこで使っているか」を洗い出します。マルチドメイン証明書は、複数の Web サーバー、ロードバランサー、CDN、メールサーバーなどに同じものを配っていることが多く、更新の失敗で最も多いのはこの差し替え漏れです。ホスト名ごとに名前解決の向き先を調べると、使っている機器が見えてきます。

for h in example.com www.example.com shop.example.net; do
  echo "== $h"; dig +short "$h"
done

手順2：残す・追加する・外すホスト名を決める

更新は、ホスト名の構成を見直すよい機会です。次の観点で整理します。

使われなくなったホスト名を外す: 閉鎖したサービスのホスト名を残すと、そのドメインの認証ができずに更新全体が止まる原因になります。
別の組織や部署のドメインが混ざっていないか: 管理者が違うドメインが入っていると、認証のたびに他部署の協力が必要になります。運用が分かれているなら、証明書を分けたほうが更新は楽になります。
ホスト名が増え続けていないか: 頻繁に追加があるなら、ワイルドカード証明書や、ホスト名ごとの自動発行（ACME）に切り替える選択肢もあります。

商用の CA では、含められるホスト名の数や追加の扱いが商品ごとに決まっています。追加や削除が更新時にしかできない商品もあるため、注文前に販売元の説明を確認してください。

手順3：新しい秘密鍵と CSR を作る

更新では秘密鍵も新しく作るのが一般的です。古い鍵を使い回すと、過去に鍵が漏れていた場合のリスクを引き継ぐことになります。

openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.com-2026.key -out example.com-2026.csr \
  -subj "/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:www.example.com,DNS:shop.example.net"

-addext は OpenSSL 1.1.1 以降で使えます。多くの商用 CA では、CSR に書いた SAN ではなく、注文画面で入力したホスト名の一覧で証明書を発行しますが、CSR と注文内容をそろえておけば確認のやり取りを減らせます。作った秘密鍵は権限を絞って保管し、メールやチャットで送らないようにします。

chmod 600 example.com-2026.key
openssl req -in example.com-2026.csr -noout -text | grep -A1 "Subject Alternative Name"

手順4：申請し、すべてのホスト名のドメイン認証を済ませる

マルチドメイン証明書では、含めるホスト名のそれぞれについて、ドメインの管理権限を確認するドメイン認証（DCV）が必要です。1つでも未完了なら発行されません。メール・DNS・HTTP（ファイル）のどの方法を使うかはホスト名ごとに選べることが多いため、DNS を操作できるドメインは DNS 認証、DNS を触れないドメインは HTTP 認証、のように分けると進めやすくなります。

以前の認証結果には再利用できる期間があり、期間内なら再認証なしで発行されることがあります。ただし、CA/Browser フォーラムの決定でこの再利用期間は段階的に短くなっているため、前回は不要だった再認証を今回は求められる、ということが起こります（2026年10月現在）。

認証方法ごとの手順や、通らないときの確認方法は量が多いため、ここでは「ホスト名ごとに方法を決め、管理画面で全件が完了になったことを確認してから次に進む」ことだけ押さえてください。

Let’s Encrypt（Certbot）の場合

Certbot では、1つの証明書名に複数の -d を指定するとマルチドメイン証明書になります。ホスト名の構成を変える場合は、既存の証明書名を指定して、残すものも含めた全ホスト名を並べ直します。

# 今の構成を確認
sudo certbot certificates

# ホスト名を追加・削除して取り直す（残すホスト名もすべて指定する）
sudo certbot certonly --cert-name example.com \
  -d example.com -d www.example.com -d shop.example.net \
  --webroot -w /var/www/html

ホスト名ごとにドキュメントルートが違う場合は、-w と -d の組み合わせを複数並べます。ホスト名を外すと、その名前は新しい証明書から消えるため、まだ使っているサーバーがないかを手順1の結果で確認してから実行します。構成が決まった後の定期更新は certbot renew に任せられます。

手順5：すべてのサーバーで差し替えて確認する

証明書が発行されたら、手順1で洗い出したすべての設置場所で差し替えます。作業前に現在の証明書・鍵・設定ファイルをバックアップし、設定ファイルの構文を確認してから再読み込みします。

sudo cp -a /etc/nginx/ssl /etc/nginx/ssl.bak-$(date +%Y%m%d)
sudo nginx -t && sudo systemctl reload nginx

差し替え後は、ホスト名ごとに配信される証明書の有効期限を確認します。同じ IP アドレスで複数のホスト名を扱うサーバーでは、-servername を付けないと別の証明書が返ることがあるので、ホスト名ごとに指定します。

for h in example.com www.example.com shop.example.net; do
  printf "%s: " "$h"
  openssl s_client -connect "$h:443" -servername "$h" </dev/null 2>/dev/null \
    | openssl x509 -noout -enddate
done

すべてのホスト名で新しい有効期限が表示されれば完了です。ロードバランサーの配下に複数台のサーバーがある場合は、ロードバランサーを経由した確認だけでなく、各サーバーに直接つないだ確認も行うと、1台だけ古い証明書が残っている状態に気付けます。

更新の回数が増える前提で仕組みにする

公開サーバー証明書の最長有効期間は CA/Browser フォーラムの決定で段階的に短くなっており、2026年3月以降の発行分は最長200日程度です（2026年10月現在）。手作業で更新する回数が増えるため、商用 CA でも ACME に対応している場合は自動化を検討し、手作業を続ける場合は期限監視とホスト名・設置場所の一覧を常に最新にしておくことが重要です。

まとめ

公開中の証明書から SAN の一覧を取り出し、その証明書を使っているサーバーや機器をすべて洗い出します。
使わなくなったホスト名は外し、管理者が違うドメインは証明書を分けることも検討します。
新しい秘密鍵と CSR を作り、含めるすべてのホスト名についてドメイン認証を完了させます。再利用期間の短縮で再認証が増えています。
差し替えはバックアップと構文確認の後に行い、ホスト名ごと・サーバーごとに有効期限を確認します。