Loading
BLOG 開発者ブログ

2023年5月30日

【Auth0】証明書付きドメインをVerifyできなかった原因を探る

 

Auth0のカスタムドメインを検証中なぜか有効化できず、思わぬトラップにより時間を浪費してしまったのでここに書き留めます。

 

目次

 

はじめに

こんにちは、クラウドソリューショングループのmiyajima.yです。

先日Auth0のカスタムドメイン機能を使用する際に有効化できず、調べても原因が全くわからないという事案が発生しました。

サポートへの問い合わせにより判明しましたが、おそらく自力で原因を突き止めることは難しいかと思います。

これ以上マイナーな被害を拡大させないために備忘録としてここに記すことにしました。

当記事のターゲットは主にカスタムドメインの利用を検討/実装されている方へ向けています。

 

カスタムドメインとは

簡単な説明ですが、Auth0では認証ページに独自ドメインを用いることができます

この機能をカスタムドメインと呼びます。

下記の例では、Webアプリケーションのログイン画面のURLをカスタムしています。

デフォルト: YOUR_DOMAIN.auth0.com

カスタムドメイン: login.YOUR_DOMAIN.com

 

何が起きたのか

問題

まずカスタムドメインを利用するためには、下記の手順を実施します。

  1. Auth0側でドメイン名を定め、CNAMEを発行する
  2. DNS側 (Route53など) でCNAMEを登録する
  3. Auth0側でドメインをVerifyする

非常に簡単です。が、今回の問題は手順3で発生しました。
「 V e r i f y で き な い ・ ・ ! ! 」

Error! Your verification record was not found. You might need to wait a few minutes before we can discover it.

 

仮説

仮説を2つ考えてみました。が、残念どちらもハズれです。

  • 仮説A: DNSレコードの反映時差
    • 結果: 数日経過後にリトライするも結果変わらず
  • 仮説B: 手順2のRoute53設定時に間違えて正しくドメインを登録できなかった
    • 結果: nslookup YOUR_DOMAIN で正常なドメイン情報レスポンスを取得

 

結論

Auth0サポートからこのような回答がありました。

「CNAME発行からカスタムドメインをVerifyするまで1週間以内に実施しないと失敗する可能性があります。詳しくはCloudflareのドキュメントからLet’s Encryptのスケジュールをご確認ください。」

Domain control validation (以降DCV) は、Certificate Authority (以降CA) がドメインの証明書を発行する前に行わなければなりません。DCVが失敗した場合、Cloudflareはスケジュールに従って自動的に再試行します。

DCVは、以下のスケジュールに従って、CloudflareのCAパートナーとの間で行われます:

Let’s Encrypt – 7日間

(https://developers.cloudflare.com/ssl/reference/validation-backoff-schedule/ から引用)

どうやらCNAMEを発行してから1週間以内にカスタムドメインを有効化する必要があったようです。

次の章ではここで登場するDCVやCA、なぜ1週間なのか、そもそもCNAMEとは?をもう少し深掘りしようと思います。

 

Domain control validation (DCV) とは

まず初めに、CNAMEとはDNS(IPアドレスとドメインを関連付けて管理するシステム)におけるリソースレコードの一種です。CNAMEレコードは、あるドメイン名を別のドメイン名に関連付けるために使用されます。

つまり、ドメインAをドメインBに紐づけた状態であれば、ドメインAにアクセスするとドメインBにリダイレクトすることが可能になります。

次に、DCVとはSSL証明書を発行する前にCAが「証明書発行リクエスト者がリクエストに関連するドメインを使用する権限を持っているか」を確認する手続きのことです。 (CAはデジタル証明書を発行する信頼できる組織・認証局のこと)

DCVには複数の方式があり、その1つにCNAMEレコードやTXTレコードを用いたドメイン認証方式が存在します。

そして、Auth0 (Cloudflare) ではDCVを実施するCAパートナーとしてLet’s Encryptを選択しています。

またTXTレコードの有効期限に関して、Let’s EncryptによるDCVではトークンとなるTXTレコードの有効期限が7日間に設定されています。

このTXTレコードの有効期限こそが、今回の事象の原因であることがようやくわかりました。

 

まとめ

  • Auth0のカスタムドメインを利用する場合は、CNAMEの設定後7日以内にドメインの検証を完了しよう
  • ドメインの所有権を確認するための手続きをDomain Control Validation(DCV)と呼び、Auth0ではLet’s Encryptがその手続きを実施する
  • Let’s EncryptのDCVにおいて、TXTレコードの有効期限は7日間となっており、発生した問題の根底にいる原因

 

所感

執筆にあたり色々と調べましたが、正直理解したとはまだまだ言い切れません。

DCVの仕組みを図解できたらより良い記事になったと思います。実力不足を噛み締めて努めます。

それと、ChatGPTに記事をレビューしてもらいましたが、信じられないほど的確なレビューをくれたので驚きました。

これ記事書かなくてもChatGPTに聞けばいいんじゃ・・など思いつつも、はい。(苦笑)

 

最後に、Auth0導入を検討中の方々、Auth0をご利用中の方々へ有意義な情報をお届けできておりましたら嬉しく思います。

 

参考

  • https://community.letsencrypt.org/t/token-has-an-expiration-date/19022
  • https://auth0.com/docs/customize/custom-domains
  • https://developers.cloudflare.com/ssl/reference/validation-backoff-schedule/

 

ananのブログ