ワイルドカードSSL証明書を取得してWordPressのサブドメインに適用する手順

ワイルドカードSSL証明書（*.example.com）を使うと、blog.example.com や shop.example.com など同じ階層のサブドメインを1枚の証明書でHTTPS化できます。Let's Encryptで取得する場合はDNS認証（DNS-01）が必須で、自動更新まで考えるとDNSプロバイダーのAPIと連携するのが現実的です。この記事では、ワイルドカード証明書が向いているケースと対象範囲の注意点、certbotでの取得と自動更新、Nginx・Apacheへの適用、WordPress側（マルチサイトを含む）の設定と確認方法を説明します。

証明書の発行条件やツールの仕様は変わることがあります。以下は執筆時点（2026年10月現在）の Let's Encrypt と certbot を前提にした内容です。サーバーの設定を変える前に、設定ファイルのバックアップを取っておいてください。

ワイルドカード証明書が向いているケース

ワイルドカード証明書が役に立つのは、次のような場面です。

• WordPressマルチサイトをサブドメイン型（site1.example.com のような形）で運用していて、サイトが増えるたびに証明書を発行し直したくない
• 1台のサーバーで複数のサブドメイン（ステージング、会員サイトなど）を動かしている

一方、サブドメインが2〜3個で増える予定がないなら、サブドメインごとの証明書や、複数の名前を1枚に入れる証明書（SAN証明書）のほうが、DNS認証の手間がかからず簡単です。レンタルサーバーの多くは、管理画面からサブドメインごとに無料SSLを設定できるので、まずそちらで足りないか検討してください。ワイルドカード証明書を有料オプションで提供しているサーバー会社もあります。

対象範囲の注意点

ワイルドカード証明書でつまずきやすいのが、どの名前が対象になるかです。

• *.example.com は blog.example.com などの1階層だけが対象です。a.blog.example.com のような2階層下は含まれません。
• ルートドメインの example.com も含まれません。ルートドメインも使うなら、証明書に example.com と *.example.com の両方を入れます。
• www.example.com は *.example.com に含まれます。

この範囲を外れた名前にアクセスすると、ブラウザに証明書の名前が一致しないという警告が出ます。

事前の準備：DNSとCAAレコード

まず、使うサブドメインがサーバーのIPアドレスを指すようにDNSを設定します。サブドメインを都度増やすなら、*.example.com のワイルドカードDNSレコードを作っておくと便利です。

次に、DNSにCAAレコードを設定している場合は確認が必要です。CAAレコードは「このドメインの証明書を発行してよい認証局」を指定するもので、ワイルドカード証明書には issuewild というタグが使われます。issuewild で Let's Encrypt（letsencrypt.org）が許可されていないと発行に失敗します。CAAレコードを設定していなければ、この確認は不要です。

certbotで取得する（DNSプラグインを使う方法）

Let's Encrypt のワイルドカード証明書は、DNS-01 チャレンジでしか発行できません。これは、指定された値をDNSのTXTレコード（_acme-challenge.example.com）に書き込んで、ドメインを管理していることを証明する方式です。

手作業でTXTレコードを書き込む方法（--manual）もありますが、その場合は更新のたびに手作業が必要になり、自動更新ができません。DNSをAPIで操作できるサービス（Cloudflare、Amazon Route 53 など）を使っているなら、certbotのDNSプラグインで自動化します。ここでは Cloudflare の例を示します。

1. APIトークンを用意する

Cloudflareの管理画面で、対象のゾーンのDNSを編集できる権限だけを持つAPIトークンを作ります。全権限を持つキーではなく、必要最小限の権限に絞ったトークンを使ってください。

トークンはサーバー上のファイルに保存し、root以外が読めないように権限を絞ります。

sudo mkdir -p /root/.secrets
sudo sh -c 'cat > /root/.secrets/cloudflare.ini' <<'EOF'
dns_cloudflare_api_token = your-api-token
EOF
sudo chmod 600 /root/.secrets/cloudflare.ini

このファイルはGitリポジトリやWebから見える場所に置かないでください。

2. 証明書を取得する

certbot と Cloudflare 用のプラグイン（certbot-dns-cloudflare）をインストールしてから、次のように実行します。インストール方法はOSや導入方式（snap、pip、OSのパッケージ）で違うので、certbot の公式手順に従ってください。

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/cloudflare.ini \
  -d example.com \
  -d '*.example.com'

'*.example.com' は、シェルがワイルドカードとして展開しないよう引用符で囲みます。成功すると、証明書は /etc/letsencrypt/live/example.com/ に保存されます。DNSの反映が遅いサービスでは認証に失敗することがあり、その場合は --dns-cloudflare-propagation-seconds で待ち時間を延ばします。

Webサーバーに適用する

Nginxの場合

server {
    listen 443 ssl;
    http2 on;
    server_name example.com *.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    root /var/www/example.com;
    index index.php;
    # PHP-FPM などの設定は既存の内容をそのまま残す
}

server {
    listen 80;
    server_name example.com *.example.com;
    return 301 https://$host$request_uri;
}

ssl_certificate には、サーバー証明書と中間証明書がつながった fullchain.pem を指定します。cert.pem を指定すると、一部の環境で中間証明書が足りないというエラーになります。http2 on; は Nginx 1.25.1 以降の書き方で、それより古いバージョンでは listen 443 ssl http2; と書きます。

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

sudo nginx -t && sudo systemctl reload nginx

Apacheの場合

<VirtualHost *:443>
    ServerName example.com
    ServerAlias *.example.com
    DocumentRoot /var/www/example.com

    SSLEngine on
    SSLCertificateFile    /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
</VirtualHost>

Apache 2.4.8 以降では、SSLCertificateFile に fullchain.pem を指定すれば中間証明書も送られます。sudo apachectl configtest で構文を確認してから再読み込みしてください。

自動更新の設定

Let's Encrypt の証明書は有効期間が短く、定期的な更新が前提です（有効期間はさらに短くする方針が発表されているため、手動更新に頼らない仕組みにしておくのが安心です）。certbot をパッケージや snap で入れた場合、更新用のタイマーやcronが自動で登録されることが多いので、まず動作を確認します。

# 更新を本番に影響させずに試す
sudo certbot renew --dry-run

更新後にWebサーバーを再読み込みしないと、新しい証明書が使われません。デプロイフックを登録しておきます。

sudo certbot reconfigure --cert-name example.com \
  --deploy-hook "systemctl reload nginx"

reconfigure サブコマンドが無い古い certbot では、/etc/letsencrypt/renewal-hooks/deploy/ に再読み込み用のスクリプトを置く方法が使えます。また、Let's Encrypt は有効期限の通知メールの送信を2025年に終了しています。期限切れに気づけるよう、外部の監視サービスや、次のようなコマンドでの定期確認を用意しておきます。

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

WordPress側の設定

通常のサイト

サブドメインごとに別のWordPressを置いている場合は、それぞれの管理画面の「設定」→「一般」で、「WordPressアドレス（URL）」と「サイトアドレス（URL）」を https:// に変更します。その後、記事内に残っている http:// の画像やリンクを置き換えます。

# まず --dry-run で件数を確認してから実行する（事前にDBのバックアップを取る）
wp search-replace 'http://blog.example.com' 'https://blog.example.com' --all-tables --dry-run

サブドメイン型マルチサイト

サブドメイン型のマルチサイトは、wp-config.php に define( 'SUBDOMAIN_INSTALL', true ); が入っている構成です。ワイルドカード証明書とワイルドカードDNSがあれば、サイトを追加したときに証明書を追加発行する必要はありません。

既存のマルチサイトをHTTPS化する場合は、各サイトの siteurl と home のほか、ネットワークのテーブルに保存されたURLも対象になります。wp search-replace に --network を付けると、ネットワーク内のすべてのサイトのテーブルが対象になります。対象が広くなるので、まず --dry-run で件数を確認し、データベースのバックアップを取ってから実行してください。

適用後の確認

• 各サブドメインをブラウザで開き、アドレスバーの鍵マークから証明書の対象名と有効期限を確認する
• ブラウザの開発者ツールのコンソールで、混在コンテンツ（HTTPSページ内のHTTPの画像やスクリプト）の警告が出ていないか確認する
• 管理画面へのログインとログアウトが正常にできるか（Cookieのドメインやリダイレクトの問題がないか）
• http:// でアクセスしたときに https:// へ転送されるか

混在コンテンツが多い場合は、Really Simple SSL（現在は Really Simple Security という名称で提供）などのプラグインで補う方法もありますが、根本的にはデータベースとテーマ内のURLを直すのが望ましい対処です。

まとめ

• *.example.com は1階層のサブドメインだけが対象。ルートドメインは別途 -d example.com を加える。
• Let's Encrypt のワイルドカード証明書は DNS-01 認証のみ。自動更新するなら DNS プロバイダーの API とcertbotのDNSプラグインを使う。
• APIトークンは権限を絞り、chmod 600 で保護する。
• Webサーバーには fullchain.pem を指定し、構文チェックしてから再読み込みする。
• certbot renew --dry-run とデプロイフックで更新を自動化し、期限切れの監視も用意する。

• WordPressマルチサイトをサブドメイン型で構築する方法
• WordPressのSSL証明書の期限切れを監視してアラートを出す方法