Vanity URL（独自ドメインのブランドURL）のSSL設定手順｜外部サービス・自社サーバー・顧客ドメイン別

Vanity URLとは、go.example.com/sale や help.example.com のように、自社のドメイン名で見せるURLのことです。短縮URLやヘルプページ、LPなどを外部サービスで作っても、URLは自社ブランドのまま使えます。SSL化の手順は「どこで証明書を発行するか」で決まり、外部サービスに向けるならサービス側、自社サーバーで動かすならcertbotなど、顧客にVanity URLを提供する側なら自動発行の仕組みが必要です。この記事では3つのケースごとに、DNSの設定から証明書の発行、確認方法、つまずきやすい点を説明します。

どのケースに当たるかを確認する

Vanity URLのSSL設定は、次の3つのどれかに当てはまります。

• ケースA: 自社のVanity URLを外部サービスに向ける 短縮URLサービス、ヘルプデスク、LP作成サービスなどに、自社のサブドメインを割り当てる場合です。証明書はサービス側が発行するのが一般的です。
• ケースB: 自社サーバーでVanity URLを運用する go.example.com を自分のサーバーに向け、短いURLから本来のページへ転送する場合です。証明書は自分で用意します。
• ケースC: 顧客にVanity URLを提供する 自社のサービスやWordPressマルチサイトで、顧客が持つドメイン（shop.customer.example など）でサイトを表示させる場合です。顧客の数だけ証明書が必要になります。

ケースA: 外部サービスに向ける場合

多くのサービスでは、次の流れで設定します。サービスごとに画面や手順の名前は違うので、細部はそのサービスのヘルプを確認してください。

1. サービスの管理画面で、使いたいVanity URL（例: go.example.com）を登録する
2. 表示された向き先に、自社のDNSでCNAMEレコードを作る
3. サービス側がDNSの設定を確認し、証明書を発行する（数分から数時間かかることがある）

ここでつまずきやすい点が3つあります。

ルートドメインはCNAMEにできない: example.com そのものにはCNAMEを置けません。Vanity URLにはサブドメインを使うか、DNSサービスの「CNAMEフラットニング」やALIASレコードの機能を使います。

CDNのプロキシが確認を邪魔する: CloudflareのプロキシをオンにしたままCNAMEを作ると、外からはCloudflareのIPアドレスしか見えず、サービス側がドメインの確認や証明書の発行に失敗することがあります。サービスの指示が無い限り、そのレコードはプロキシを使わない設定（DNSのみ）にします。

CAAレコードで認証局を制限している: CAAレコードは、そのドメインの証明書を発行してよい認証局を指定する仕組みです。設定していると、サービスが使う認証局が許可されていないために発行が止まることがあります。dig example.com CAA で確認し、必要ならサービスが案内する認証局を追加してください。

ケースB: 自社サーバーで運用する場合

自社のサーバーで短縮URLを運用するなら、DNSでAレコードを作り、Let's Encryptで証明書を取得するのが手軽です。ここではNginxとcertbotの例を示します。作業前に、Nginxの設定ファイルをバックアップしてください。certbotのNginxプラグインは既存の server ブロックを探して書き換えるので、先にポート80で server_name go.example.com; を持つ server ブロックを作り、Nginxを再読み込みしてから実行します。

# go.example.com のAレコードがこのサーバーを指していることを確認
dig +short go.example.com

# 証明書を取得し、Nginxの設定に組み込む
sudo certbot --nginx -d go.example.com

# 自動更新が動くかを試す（実際には更新しない）
sudo certbot renew --dry-run

証明書を取ったら、certbotが書き換えた設定を開き、次のような形に整えます。短いURLと転送先の対応表をNginxの map で書くと、転送先の追加が1行で済みます。map は http ブロックの中、server ブロックの外に書きます。編集後は nginx -t で文法を確認してから再読み込みしてください。

map $uri $vanity_target {
    default "";
    /sale   https://www.example.com/campaign/autumn-sale/;
    /docs   https://www.example.com/support/manual/;
}

server {
    listen 443 ssl;
    server_name go.example.com;
    # ssl_certificate などは certbot が追記した設定を使う

    if ($vanity_target) {
        return 302 $vanity_target;
    }
    return 404;
}

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

転送には302（一時的）を使っています。キャンペーン用のURLは転送先を後で変えることが多く、301（恒久的）にするとブラウザが転送先を長く覚えてしまい、変更が反映されにくくなるためです。転送先がずっと変わらないものだけ301にします。対応表に無いURLは、メインサイトに飛ばさず404を返すと、誤ったURLが配られたときに気づきやすくなります。

WordPressで管理したい場合は、go.example.com にWordPressを置き、Redirectionなどのリダイレクト管理プラグインで対応表を作る方法もあります。

ケースC: 顧客にVanity URLを提供する場合

自社サービスで顧客独自のドメインを使えるようにするときは、次の仕組みが必要です。

1. 顧客にCNAMEを設定してもらう向き先（例: custom.service.example）を用意する
2. ドメインの所有確認: 顧客にTXTレコードを追加してもらうなど、そのドメインを本当に管理しているかを確かめます。確認せずに受け付けると、他人のドメインを勝手に登録される恐れがあります。
3. 証明書の自動発行と更新: 顧客のCNAMEが自社サーバーを向いた時点で、HTTP認証を使って証明書を取れます。

証明書を自動で発行する仕組みとしては、WebサーバーのCaddyにある「オンデマンドTLS」が知られています。初めてアクセスされたときに証明書を取得する機能で、ask で指定したURLに許可を問い合わせ、許可されたドメインにだけ発行します。

{
	on_demand_tls {
		ask http://127.0.0.1:9123/allowed
	}
}

https:// {
	tls {
		on_demand
	}
	reverse_proxy 127.0.0.1:8080
}

ask の問い合わせ先は自分で作るプログラムで、?domain= に付いてくるドメインが登録済みで所有確認も済んでいるときだけ200を返します。この確認を省くと、適当な名前でアクセスされるたびに発行を試みてしまい、認証局の発行回数の上限（レート制限）に当たる恐れがあります。上限の値は認証局の方針で変わるので、Let's Encryptの最新の説明を確認してください。自前で運用せず、CDN事業者が提供する独自ホスト名向けのサービス（CloudflareのCloudflare for SaaSなど）を使う方法もあります。機能や提供条件は変わることがあるので、各社の資料で確認してください。

WordPressマルチサイトでは、ネットワーク管理画面でサイトのURLを顧客のドメインに変えることで、独自ドメインで表示できます。この場合も、そのドメインを含む証明書をサーバー側で用意する必要があります。

顧客が解約したときは、ドメインの登録と証明書の自動更新を止める手順も用意しておきます。顧客側にCNAMEが残っている間は、そのドメインに来たアクセスを受け付けない状態にしておくと安全です。

設定後の確認方法

どのケースでも、最後に次の点を確認します。

# 証明書の対象の名前と有効期限
echo | openssl s_client -connect go.example.com:443 -servername go.example.com 2>/dev/null \
  | openssl x509 -noout -subject -enddate -ext subjectAltName

# HTTPからHTTPSへの転送と、転送先
curl -sI http://go.example.com/sale
curl -sI https://go.example.com/sale

subjectAltName にVanity URLの名前が入っていれば、証明書は正しく発行されています。-ext オプションが使えない古いOpenSSLでは、-text で全体を表示して確認してください。ブラウザで確かめるときは、別の端末やプライベートウィンドウを使うと、転送のキャッシュに惑わされません。証明書の有効期限は今後短くなっていく予定なので（2026年10月現在）、自動更新の監視も合わせて設定しておくと安心です。

まとめ

• Vanity URLのSSLは、外部サービスに向ける・自社サーバーで動かす・顧客に提供する、の3ケースで手順が変わります。
• 外部サービスに向けるときは、CNAMEの設定、CDNのプロキシ、CAAレコードがつまずきやすい点です。
• 自社サーバーではcertbotで証明書を取り、Nginxの map で転送先を管理すると運用しやすくなります。変わる可能性のある転送は302にします。
• 顧客に提供する場合は、所有確認と許可した名前にだけ発行する仕組みが欠かせません。

• CAAレコードでSSL証明書を発行できる認証局を制限する方法
• DNSのAレコードとCNAMEレコードの違いと設定方法