Alternative Architecture DOJO

オルターブースのクラウドネイティブ特化型ブログです。

SSL認証での所有者確認失敗談

みなさんこんにちは。
ようやくロードバイクが届いたかとぅーんです。

箱から取り出し組み立てを終え、テスト走行してみたんですが
初ロードバイクは、踏むと加速し、路面の振動も拾わず快適に前に進み驚きました。
クロスバイクに乗っていた感覚とは別の感覚を味わえました。

1時間半程乗りましたが、常に前傾姿勢で早くもお尻と腰にダメージです。
筋力も必要そうで、筋トレも再開したいと思います。

f:id:kattoon:20211217225515p:plain
helmet

今回は、SSL認証での所有者確認失敗談です。


サーバー証明書の認証方式で、ファイル認証は知っていたのですが
その他にもメール認証や、DNS認証があることは知りませんでした。
メールサーバーやWebサーバーが公開できないような場合などに
DNS認証が使われたりするようです。

それで、今回DNS認証として、DNSのTXTレコードに認証文字列を設定し
認証する認証方式をやりました。

その最中、Azure Front Doorにカスタムドメインを設定する際に失敗してしまいまして。。。

docs.microsoft.com


今回は、独自証明書を取得していたので、証明書の管理の種類で
自分の証明書を使用する
の方で設定しないといけない部分をうっかり
管理されているフロントドア
のマネージドの方で設定してしまっていました。

f:id:kattoon:20211217232503p:plain
証明書の管理の種類

しかしながら、一旦ドメインの所有権の確認が入ると
設定のやり直しなどできない状態となってしまっていました。(設定前に気付け自分!!)

途中でのキャンセルなど、うまく効かないようなので
いろいろとドキュメントを探した結果、以下のような記述がありました。

docs.microsoft.com

ドメインの承認には 6 営業日が必要です。 6 営業日以内に承認されない要求は、自動的に取り消されます。

6営業日と書いてますね。
確かに6営業日後にはチェックも終了して再設定できるようになっていました。6営業日。。。

テンパった状態で設定しようとするといろいろとやらかすんだよなぁと凹みつつ
フォローいただいている周囲や先輩に感謝しながら、改めてInfrastructure as Codeの重要性を再認識しました。

みなさんも、うっかり設定ミスなど無いようご注意くださいませ。

そろそろクリスマスですね。クリスマスまで残り6日。アドベントカレンダーを引き続きお楽しみください。