WordPress制作会社向けSSL証明書期限を一括管理する方法
「SSL証明書の期限が切れていました」を保守担当者が言ってはいけない
WordPress保守サービスを提供している制作会社にとって、クライアントサイトのSSL証明書期限切れは最も恥ずかしい障害のひとつです。「自動更新があるから大丈夫」という思い込みが、深夜や週末のトラブルを招きます。
本記事では、複数のWordPressサイトを管理する制作会社が、SSL証明書の期限を一括で把握・管理し、更新失敗を事前に検知する方法を解説します。前提として、外形監視の基本的な組み込み方は「WordPress保守サービスに死活監視を組み込む方法」を参照してください。SSL証明書監視の一般的な解説は「SSL証明書の期限切れ事故を防ぐ!自動監視で安全なサイト運用を」にまとめています。
WordPress環境でSSL自動更新が失敗する典型パターン
一般的なSSL更新失敗の原因はどの環境でも共通ですが、WordPress特有の要因がいくつか存在します。
WordPress固有の落とし穴
1. レンタルサーバーの自動更新は「全サイト共通設定」ではない
さくらインターネット・エックスサーバーなどのレンタルサーバーでは、Let's Encryptの自動更新が「管理画面からドメインごとに有効化」する設定になっているケースがあります。新規ドメイン追加時に設定を忘れると、次の更新タイミングまで気づきません。
2. WordPress移行時にサーバー設定が引き継がれない
WordPressのサーバー移行時には、ドメインやデータベースの移行に集中するため、cerbot設定やcronジョブの引き継ぎが抜けることがあります。移行直後は証明書が有効期限内でも、更新タイミングに失敗します。
3. WordPressのキャッシュプラグインがACMEチャレンジを妨害する
W3 Total CacheやWP Super CacheがLet's EncryptのACMEチャレンジURL(.well-known/acme-challenge/)をキャッシュしてしまい、ドメイン認証に失敗するケースがあります。キャッシュ除外設定が必要ですが、プラグイン更新や設定変更で除外が外れることがあります。
4. WordFenceがACMEチャレンジをブロック
セキュリティプラグインのWordFenceが、ボット判定でcertbotのアクセスをブロックすることがあります。更新が成功していた環境でも、WordFenceの設定変更後に失敗し始めるケースがあります。
# ACMEチャレンジのアクセス状況を確認(Nginxの場合)
grep "acme-challenge" /var/log/nginx/access.log | tail -20
# 403や404が返っている場合はキャッシュプラグインまたはファイアウォールが原因の可能性
# 200が返っているかを確認する
Miterlで複数クライアントのSSL証明書を一括管理する
SSL監視モニターを作成する
MiterlはSSL証明書の有効期限を専用の ssl タイプのモニターとして監視します。期限が近づくと指定した連絡先(Slack・Chatwork・LINE等)にアラートが届きます。
# WordPressクライアントサイトのSSL監視モニターを作成する
curl -X POST https://miterl.com/api/v1/monitors \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"name": "クライアントA - SSL証明書",
"type": "ssl",
"url": "https://client-a.co.jp",
"interval_seconds": 3600,
"ssl_expiry_alert_days": 30,
"alert_contact_ids": [1]
}'
ssl_expiry_alert_days に30を指定すると、期限30日前にアラートが届きます。制作会社の推奨設定は「30日前・14日前・7日前」の3段階です。複数の閾値を設定する場合は、閾値ごとに別々のモニターを作成します。
複数サイトをまとめてSSL監視に追加する
管理サイトが10件以上ある場合は、APIを活用した一括登録が効率的です。
# 複数サイトを一括でSSL監視に追加するシェルスクリプト例
DOMAINS=(
"client-a.co.jp"
"client-b.com"
"client-c.jp"
)
for DOMAIN in "${DOMAINS[@]}"; do
curl -X POST https://miterl.com/api/v1/monitors \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d "{
\"name\": \"${DOMAIN} - SSL\",
\"type\": \"ssl\",
\"url\": \"https://${DOMAIN}\",
\"interval_seconds\": 3600,
\"ssl_expiry_alert_days\": 30
}"
echo "登録完了: $DOMAIN"
sleep 1
done
SSL監視と死活監視は別々のモニターとして設定する
重要な点として、SSL監視(type: ssl)は死活監視(type: http)とは独立したモニターです。同一ドメインに対して両方のモニターを設定してください。
| モニタータイプ | 検知内容 | 推奨間隔 |
|---|---|---|
http |
サイトのダウン・応答遅延・HTTPステータスエラー | 60秒 |
ssl |
SSL証明書の期限切れ・証明書チェーンの問題 | 1時間 |
SSL監視モニターが down になった場合は、証明書が既に期限切れまたは証明書チェーンに問題が発生しています。ssl_expiry_alert_days の閾値到達前でも即座に対応が必要です。
期限ダッシュボードで全クライアントの証明書期限を一覧確認
Miterlには証明書期限の一覧ダッシュボードがあり、管理している全サイトのSSL証明書の残り日数を一目で確認できます。ダッシュボード内の「期限管理」セクションに、各モニターの expires_at が表示されます。
# APIで全SSLモニターの期限情報を取得する
curl -s "https://miterl.com/api/v1/monitors?per_page=100" \
-H "Authorization: Bearer YOUR_API_KEY" \
| jq -r '.data[] | select(.type == "ssl") | "\(.name)\t\(.status)\t\(.expires_at)"'
月次の保守報告書作成前にこのコマンドを実行すれば、期限が近いサイトをまとめて確認できます。
ACMEチャレンジ失敗を事前に防ぐWordPress設定
SSL更新失敗の根本原因を取り除くWordPress側の設定もあわせて確認しましょう。
キャッシュプラグインのACMEチャレンジ除外設定
W3 Total Cache・WP Super Cache・WP Fastest Cacheなどで、以下のパスをキャッシュ除外に追加します。
/.well-known/acme-challenge/
WordPressの.htaccessに直接設定する場合は以下の記述を追加します。
# ACMEチャレンジはキャッシュを通さない
<IfModule mod_rewrite.c>
RewriteRule ^\.well-known/acme-challenge/ - [L]
</IfModule>
certbotの自動更新が正常かを定期確認する
# 自動更新のドライランで動作確認
sudo certbot renew --dry-run
# タイマーの状態確認(systemd環境の場合)
systemctl status certbot.timer
--dry-run が正常終了すれば更新処理自体は問題ありません。これを月1回実施する習慣をつけておくと、更新失敗の早期発見につながります。
SSL証明書期限監視を保守サービスとして訴求する
SSL証明書の監視は、制作会社の保守サービスとして最も説明しやすい項目のひとつです。
保守報告書への組み込み方
月次の保守報告書に以下の一行を追加するだけで、クライアントにとっての保守価値が可視化されます。
SSL証明書の状態: 正常(残り XX 日)
次回更新予定: YYYY年MM月
「先月は証明書の期限に問題はありませんでした」という報告は、何事も起きていない月でも保守の価値を伝えます。
WordPress保守プランへの価格反映
SSL証明書監視を保守プランに組み込む場合の目安です。
| 保守プラン | 含まれるSSL監視 | 月額追加の目安 |
|---|---|---|
| ベーシック | 期限30日前のアラートのみ | +1,000〜2,000円 |
| スタンダード | 30日・14日・7日の3段階アラート | +2,000〜3,000円 |
| プレミアム | 3段階アラート + 月次証明書レポート | +3,000〜5,000円 |
証明書の更新自体がトラブルになる前に検知できるという安心感を訴求することで、単価アップの根拠になります。WordPress保守サービス全体への死活監視の組み込みについては「WordPress保守サービスに死活監視を組み込む方法」を参照してください。
まとめ
WordPress制作会社がSSL証明書の期限切れ事故を防ぐには、更新の仕組みと監視の二段構えが必要です。
- WordPress特有の落とし穴(キャッシュプラグインのACMEブロック、セキュリティプラグインの干渉、サーバー移行時の設定漏れ)を把握する
- Miterlの
sslタイプのモニターで全クライアントサイトを一括監視し、30日前・14日前・7日前の段階アラートを設定する - 死活監視(
type: http)と SSL 監視(type: ssl)は別々のモニターとして並行設定する - 期限ダッシュボードで全サイトの証明書残り日数を一覧確認し、月次報告に活用する
- ACMEチャレンジ除外設定と
certbot renew --dry-runで更新の健全性を維持する
SSL証明書の監視を保守メニューに正式に組み込み、月次報告に証明書の状態を載せることで、保守サービスの価値をクライアントに可視化できます。まずは無料で登録して実際の動作を確認してください。詳細な設定方法はドキュメントをご覧ください。制作会社向けの活用シナリオはユースケース一覧もあわせて参考にしてください。