2026年6月5日

マルチドメインSSL（SAN証明書）の更新手順：ホスト名の棚卸しからドメイン認証・差し替え確認まで

ドメイン管理

マルチドメインSSL（SAN証明書）の更新は、「含めるホスト名の棚卸し → 新しい鍵とCSRの作成 → ドメインごとの認証 → TLSを終端する全箇所への設置 → ホスト名ごとの確認」の順に進めると漏れが出にくくなります。1枚の証明書に複数のホスト名が入っているため、どれか1つの認証が止まると全体の発行が止まり、どれか1つの設置を忘れるとそのホスト名だけエラーになる、というのがSAN証明書の更新でつまずく典型です。この記事では、各手順で何を確認するのか、どこで失敗しやすいのかを説明します。

SAN証明書の更新で注意すること

SAN（Subject Alternative Name）は、証明書が有効なホスト名を列挙する欄です。ブラウザはこの欄に、アクセスしたホスト名が含まれているかで証明書を判定します。マルチドメインSSLは、ここに example.com、www.example.com、shop.example.net のように、異なるドメインを含む複数のホスト名を入れた証明書です。

更新作業では次の3点を意識します。

すべてのホスト名で認証が必要: 認証局はSANに入っている各ドメインについて管理権限を確認します。1つでも認証が終わらないと発行されません。
設置場所が複数になりやすい: ホスト名ごとに別のサーバーやロードバランサーで同じ証明書を使っていることが多く、差し替え漏れが起きやすくなります。
更新の頻度が上がっている: 証明書の最大有効期間は2026年3月から段階的に短縮されており、ドメイン認証の結果を使い回せる期間も短くなっています（2026年10月現在）。手作業の更新は回数が増えるほど負担になります。

手順1：含めるホスト名を棚卸しする

更新は、SANの中身を見直す機会でもあります。まず現在の証明書に入っているホスト名を一覧にします。

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

-ext オプションは OpenSSL 1.1.1 以降で使えます。表示された一覧を、Webサーバーの設定（nginx の server_name、Apache の ServerName / ServerAlias）やDNSの登録内容と突き合わせ、次のように仕分けます。

継続して使うホスト名: そのまま含める
使わなくなったホスト名: 外す。閉鎖したサービスや手放したドメインを残すと、認証が通らず更新全体が止まる原因になります
新しく必要になったホスト名: 追加する。WordPressのマルチサイトでドメインを割り当てている場合は、割り当てたドメインの漏れに注意します

あわせて、1枚にまとめ続けるべきかも考えます。証明書の発行記録は Certificate Transparency のログで公開されるため、社内向けのホスト名を一緒に入れると、その名前と他のドメインの関係が外部から見えます。また、1枚にまとめるほど「1つの認証失敗で全体が止まる」影響が大きくなります。ACME で自動化できる環境なら、サービスごとに証明書を分けたほうが運用は楽になることが多いです。

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

更新時は秘密鍵も新しく作るのが基本です。OpenSSL 1.1.1 以降なら、-addext でSANを指定したCSRを1行で作れます。

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

# 作成したCSRの中身を確認
openssl req -in example.com.csr -noout -text | grep -A1 "Subject Alternative Name"

コモンネーム（CN）に入れたホスト名も、SANに含めておきます。現在のブラウザはCNではなくSANを見て判定するためです。

多くの認証局や販売代理店では、SANのホスト名をCSRからではなく注文画面の入力欄で指定します。その場合、CSRのSANと注文画面の内容が食い違うとどちらが優先されるかは認証局によって異なるため、両方を同じ内容にそろえておくのが安全です。製品によっては www 付きのホスト名を自動で追加するものもあるため、注文前に仕様を確認してください。

秘密鍵のファイルは、権限を絞ったうえで（chmod 600 など）、作業用のPCや共有フォルダに残さないようにします。

手順3：ドメインごとに認証を済ませる

注文を出したら、SANに含まれるドメインごとにドメイン認証（DCV）を行います。ここが更新全体の待ち時間を決める工程です。

DNS認証: 指定されたTXTレコードなどを各ドメインのDNSに登録します。ドメインごとにDNSの管理会社が違う場合、それぞれの管理画面で作業が必要です。
メール認証: 各ドメインの admin@ などに承認メールが届きます。ドメインごとにメールの受け口があるかを先に確かめます。
ファイル認証: 各ホスト名で指定のパスにファイルを置きます。ワイルドカード（*.example.com）を含む場合、ファイル認証は使えず、DNS認証などが必要です。

注文の管理画面でドメインごとの認証状況が表示されることが多いので、どのドメインが未完了かを確認しながら進めます。止まっているドメインがあり、そのホスト名が不要なものであれば、注文からそのホスト名を外すほうが早い場合もあります。

手順4：TLSを終端するすべての場所に設置する

発行された証明書と中間証明書を設置します。差し替え前に、現在の証明書・秘密鍵・設定ファイルをバックアップしてください。

nginx では、サーバー証明書の後に中間証明書を連結したファイルを ssl_certificate に指定します。

ssl_certificate     /etc/ssl/example.com/fullchain.pem;  # サーバー証明書 + 中間証明書
ssl_certificate_key /etc/ssl/example.com/example.com.key;

Apache 2.4.8 以降では、SSLCertificateFile に中間証明書を連結したファイルを指定できます。古い SSLCertificateChainFile は非推奨になっています。

設定後は、構文チェックをしてから再読み込みします。

sudo nginx -t && sudo systemctl reload nginx

SAN証明書で漏れやすいのは、同じ証明書を使っている別の場所です。複数台のWebサーバー、ロードバランサー、CDN、メールサーバーなど、どこでこの証明書を使っているかを手順1の棚卸しと合わせて洗い出し、一覧に沿って差し替えます。

手順5：ホスト名ごとに配信される証明書を確かめる

最後に、SANに含めたホスト名すべてについて、新しい証明書が配信されているかを確かめます。1つのホスト名だけを確認して終わりにしないことが重要です。

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

有効期限が新しい日付になり、SANに想定どおりのホスト名が並んでいれば完了です。ホスト名によって古い期限が出る場合は、そのホスト名を担当しているサーバーやCDNの差し替えが漏れています。中間証明書の入れ忘れはブラウザでは気づきにくいため、外部のSSL診断サービスで証明書チェーンも確認しておくと安心です。

古い証明書は、秘密鍵の漏えいなどがなければ失効させる必要はありません。新しい証明書で問題が出たときに戻せるよう、確認が済むまではバックアップを残しておきます。

次回の更新に向けて

棚卸しした一覧（ホスト名・ドメインの管理会社・認証方式・設置場所）を残しておくと、次回の更新が短時間で済みます。
有効期間の短縮で更新回数が増えるため、ACME に対応した認証局や、クラウドの証明書管理サービスでの自動更新を検討します。
期限の監視は、代表のホスト名だけでなく、設置場所ごとに行います。

まとめ

SAN証明書の更新は、ホスト名の棚卸しから始め、不要なものを外し、必要なものを追加します。
新しい秘密鍵でCSRを作り、SANの内容は注文画面とCSRでそろえます。
認証はドメインごとに必要で、1つでも止まると全体が発行されません。ワイルドカードを含む場合はファイル認証が使えません。
設置は証明書を使うすべての場所で行い、ホスト名ごとに期限とSANを確認して完了とします。