GeoTrust 証明書の更新を自動化する方法（ACME・certbot・API）

GeoTrust の SSL/TLS 証明書は、DigiCert の ACME 対応を使えば certbot や acme.sh で発行・更新を自動化できます。証明書の有効期間の上限は段階的に短くなっており、手作業の年1回更新はすでに成り立たなくなりつつあります。この記事では、GeoTrust と DigiCert の関係、ACME による自動化の設定、更新後のサーバー再読み込み、監視までを順に説明し、手動更新から抜け出せるようにします。

GeoTrust と DigiCert の関係を押さえる

GeoTrust はもともと独立した認証局でしたが、のちに Symantec 傘下となり、2017年に DigiCert が Symantec のウェブサイトセキュリティ事業を買収してからは DigiCert のブランドの1つになっています。現在の GeoTrust 証明書は DigiCert の基盤で発行されており、注文や管理も DigiCert の管理画面（CertCentral）か、GeoTrust を扱う販売代理店・レンタルサーバー会社の画面で行います。

自動化の方法は、どこから購入しているかで変わります。

• DigiCert CertCentral の直接契約：CertCentral の ACME 機能や REST API を使えます
• 販売代理店経由：代理店が独自の ACME や API を提供している場合と、手動の申請画面しかない場合があります
• レンタルサーバーのオプション：サーバー会社が更新と設置まで代行することが多く、自分で自動化する余地は小さくなります

まず自分の契約がどれに当たるかを確認してください。ここが曖昧なまま certbot を設定しても、接続先が分からず先に進めません。

なぜ今、自動化が必要なのか

CA/Browser Forum では、公開 TLS 証明書の最長有効期間を段階的に短くする改定が2025年に可決されています。概要は次のとおりです（2026年10月現在）。詳細は CA/Browser Forum と DigiCert の告知を確認してください。

• 2026年3月から：最長 200 日
• 2027年3月から：最長 100 日
• 2029年3月から：最長 47 日

あわせて、ドメイン認証（DCV）の結果を再利用できる期間も短くなっていきます。年に数回、いずれは毎月のように更新とドメイン認証が発生するため、人手での運用は事故のもとになります。複数年契約のプランでも、証明書そのものは期間内に何度か再発行して差し替える形になるのが一般的です。

ACME で自動化する流れ

ACME は Let's Encrypt で広まった証明書の自動発行プロトコルで、有料の認証局も対応を進めています。DigiCert の ACME では、どのアカウントからの要求かを結び付けるために EAB（External Account Binding）を使います。

全体の流れは次のとおりです。

1. CertCentral（または代理店の画面）で ACME の設定を作成し、ディレクトリ URL、EAB の Key ID と HMAC キーを取得する
2. サーバーに ACME クライアント（certbot や acme.sh）を入れ、EAB 付きでアカウントを登録する
3. ドメイン認証の方式（HTTP か DNS）を決めて証明書を発行する
4. 自動更新のタイマーと、更新後に Web サーバーを再読み込みする仕組みを用意する

ACME で発行できる証明書の種類（DV のほか、組織認証済みであれば OV・EV も対象になるか）や、更新ごとの課金・契約の扱いは、契約内容と時期によって異なります。設定画面の名称も変わることがあるので、手順は DigiCert のドキュメントに従ってください。

EAB の HMAC キーはパスワードと同じ扱いです。チャットや社内 Wiki に貼らない、Git にコミットしない、使い終わったら画面から再表示できない前提で安全な場所に保管する、という扱いにしてください。

certbot での設定例

certbot は --server で接続先の ACME サーバーを、--eab-kid と --eab-hmac-key で EAB 情報を指定できます。以下はダミー値の例です。ディレクトリ URL は管理画面に表示されたものをそのまま使ってください。

sudo certbot certonly \
  --server "https://acme.example-ca.com/directory/your-directory-id" \
  --eab-kid "your-eab-key-id" \
  --eab-hmac-key "your-eab-hmac-key" \
  --webroot -w /var/www/html \
  -d example.com -d www.example.com \
  --email admin@example.com --agree-tos

--webroot は HTTP 認証の方式で、/var/www/html/.well-known/acme-challenge/ に認証用ファイルが置かれます。WordPress の場合、パーマリンク設定の書き換えルールや、セキュリティプラグイン・CDN のキャッシュがこのパスを横取りして 404 になることがあります。発行に失敗したら、まず http://example.com/.well-known/acme-challenge/ 配下にテストファイルを置いてブラウザで開けるか確認してください。

ワイルドカード証明書は HTTP 認証では発行できず、DNS 認証（_acme-challenge の TXT レコード）が必要です。DNS を API で操作できるサービスなら、certbot の DNS プラグインや acme.sh の DNS API 連携で自動化できます。

発行後は、certbot が保存した設定をもとに更新されます。パッケージで導入した場合、systemd タイマーや cron で定期的に certbot renew が実行されるのが一般的です。

# 更新処理を本番に影響なく試す
sudo certbot renew --dry-run

# タイマーが有効か確認（systemd の場合）
systemctl list-timers | grep certbot

--dry-run が接続先の ACME サーバーでどのように扱われるか（テスト用の環境が用意されているか）は認証局ごとに異なります。発行枠を消費する可能性がないか、事前に契約先へ確認しておくと安心です。

更新後に Web サーバーへ反映させる

証明書ファイルが新しくなっても、Nginx や Apache が再読み込みしなければ古い証明書を配り続けます。自動化で見落とされやすいのがこの部分です。certbot では deploy フックで、更新が成功したときだけコマンドを実行できます。

sudo certbot renew --deploy-hook "systemctl reload nginx"

毎回指定しなくても、/etc/letsencrypt/renewal-hooks/deploy/ に実行可能なスクリプトを置けば更新成功時に実行されます。

#!/bin/sh
# /etc/letsencrypt/renewal-hooks/deploy/reload-web.sh
nginx -t && systemctl reload nginx

nginx -t で設定を検査してから再読み込みしているのは、設定に誤りがあったときにサーバーを止めないためです。Apache なら apachectl configtest && systemctl reload apache2（ディストリビューションによっては httpd）に置き換えてください。ロードバランサーや CDN に証明書を載せている場合は、その製品の API でアップロードする処理をフックに書くことになります。

acme.sh を使う場合

acme.sh も EAB に対応しており、アカウント登録時に --eab-kid と --eab-hmac-key を渡します。

acme.sh --register-account \
  --server "https://acme.example-ca.com/directory/your-directory-id" \
  --eab-kid "your-eab-key-id" \
  --eab-hmac-key "your-eab-hmac-key"

acme.sh はインストール時に cron へ更新処理を登録します。証明書の配置先と再読み込みは --install-cert に --reloadcmd を付けて指定しておくと、更新のたびに同じ処理が走ります。

ACME が使えない契約の場合

代理店が ACME に対応していない場合でも、できることはあります。

• CSR の作成、証明書の配置、Web サーバーの再読み込みまでをスクリプト化し、人が行うのは申請と認証だけにする
• 代理店や DigiCert の REST API が使える契約なら、注文と再発行の部分も API で自動化する
• 期間短縮に対応できない契約なら、ACME 対応の契約や、別の認証局への移行を検討する

API の利用には API キーが必要です。キーは環境変数や権限を絞ったファイルで管理し、スクリプトに直接書き込まないでください。

CAA レコードと監視

DNS に CAA レコードを設定している場合、GeoTrust（DigiCert）からの発行を許可する値が入っていないと発行が拒否されます。指定すべき値は DigiCert の案内に従ってください（一般的には digicert.com を指定します）。ACME 移行のタイミングで別の認証局に切り替える場合も、CAA の更新を忘れがちです。

自動化しても、失敗に気付けなければ意味がありません。外部から実際に配信されている証明書の期限を定期的に確認しましょう。

echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null \
  | openssl x509 -noout -issuer -enddate

-issuer で GeoTrust の中間証明書から発行されているか、-enddate で更新後の期限になっているかを確認できます。外形監視サービスで期限の残り日数に閾値を設けておくと、更新の失敗や再読み込み漏れに早めに気付けます。

まとめ

• GeoTrust は DigiCert のブランドで、自動化の手段は「CertCentral 直契約・代理店・レンタルサーバー」のどれで購入しているかで決まる
• 有効期間の上限は 2026年3月から 200 日、その後さらに短くなる予定のため、更新の自動化は避けて通れない
• DigiCert の ACME は EAB を使う。certbot は --server --eab-kid --eab-hmac-key、acme.sh も同様のオプションで登録する
• 更新後の再読み込みは deploy フックや --reloadcmd で自動化し、設定検査を挟む
• CAA レコードの許可値と、外部からの期限監視までそろえて運用を完成させる

• SSL証明書の有効期限を監視してアラートを出す方法
• CAAレコードで証明書を発行できる認証局を制限する