【対策】独自ドメイン設定後のAzure App Serviceで証明書が払い出せない【解決】

今回も小ネタなのですが、自身が結構な時間を溶かしてまったのと、エラー内容が実際に起きていた問題とアンマッチだったため解決に時間がかかり、他にも困る方が居ると良くないなと思い投稿します。

# App Service構築直後にアクセス元IPアドレスを絞る
インフラエンジニアやってるとこの辺はまっさきに設定しますよね。
構築直後、本格開発が始まるまでに攻撃に遭うなんて目も当てられませんからね。
DDoSだけではなく、特に個人の検証環境ではEDoSも怖いですからね。
具体的な設定方法としてはApp Serviceの[設定]から[ネットワーク]を選択し、[受信トラフィックの構成]内にある最上位の項目[公衆ネットワークアクセス]の[アクセス制限なしで有効]をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/643392/715ada5d-25b3-5491-4f04-6811b33fd84c.png)
デフォルトだと[すべてのネットワークから有効(現在のアクセス制限がすべてクリアされます)]という項目がラジオボタンで選択されていますが、これを[選択した仮想ネットワークとIPアドレスから有効]に変更します。
デフォルトだと以下の通り。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/643392/90cd53b6-0b39-c5ae-fbde-0b7eafb28f3c.png)
デフォルト設定から[選択した仮想ネットワークとIPアドレスから有効]に変更します。
変更することで、それまで不活性だった[サイトのアクセスとルール]の項目が活性化し、アクセス元IPアドレスの制限やアクセス元仮想ネットワークの設定ができるようになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/643392/7b3d9cf6-1f2c-c88d-4102-185fbcc4f95e.png)
ここから送信元IPアドレスを制限していきます。
[一致しないルールのアクション]がデフォルトだと[許可]になっているので、これを[拒否]に変更します。
そして[＋追加]をクリックし、規則の追加をします。
ここでは[規則]と[ルール]と日本語訳が入り乱れていますが、どちらも[ルール]か[規則]に名寄せ(？)すると理解しやすいですね。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/643392/570c2297-74f0-bc17-a41c-9c5888d53c75.png)
規則(ルール)では[名前]、[アクション]、[優先度]、[IPアドレスブロック]の4項目が必須項目になっていますので、それぞれ設定しましょう。
優先度はNSGと違って100が最小ではなく、300が最小です。
(なんで揃えなかったんだろう・・・？)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/643392/ffdc0c7b-8062-896a-1921-2a02bfe0e39a.png)
なんやかんやで設定して、設定を確認後、[高度なツールサイト]をクリックします。
**私の環境のApp ServiceだとGitのような開発ツール、サイトと連携していないので自由に設定できますが、これらの開発関連のツールやサイトと連携している場合はどうなるかわからないので各自検証、動作確認してください。**
デフォルトだと以下のようになっていますが
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/643392/e80535ef-12e0-d9a7-1540-5a635548cc69.png)
[一致しないルールのアクション]は[拒否]に、[メインサイトルールを使用する]にチェックを入れ、最後に[保存]をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/643392/724d5071-d636-3ee0-cdec-e9cb28ff3a63.png)
これでApp Serviceのメインサイトと構築用サイトへのアクセス元IPアドレスを絞ることができました。

# App Serviceで独自ドメインを設定する
これはまぁ簡単ですね。
対象のApp Serviceの中から[カスタム ドメイン]を選択し、[カスタム ドメインの追加]をクリック、[ドメイン プロバイダー]の項目は各自の設定に依存しますが、私の場合は[その他のすべてのドメイン サービス]を選択します。
[ドメイン]の項目に利用したい独自ドメインを入力すると、[ドメインの検証]の項目にAレコード、テキストレコードが出てきますので、指定の通り独自ドメインを司るDNSサーバに値を入力します。
サブドメインにするとCNAMEとテキストレコードになります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/643392/890193a4-0cdf-676c-dc3e-0d274a2efb82.png)

これらの値をDNSサーバに登録しTTLが経過するまで待ち、[検証]をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/643392/0dc87e2c-eef7-ee0f-02fa-be95f18c4bab.png)

検証が完了すると以下の画面のように[状態]にチェックが入り、[検証に合格しました。]というメッセージが出るとともに、[追加]のボタンが活性化しますので、[追加]をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/643392/37c90155-3e4f-df2a-f53e-7c75b114fac7.png)
ドメインの追加と同時に証明書の作成に入ってくれるのですが、<font color="red">**ここでコケる**</font>んですよね・・・
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/643392/5ec63f83-11a0-677e-785e-ecc75ed043f3.png)
と思ったら今日はコケなかった・・・
なぜだ・・・
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/643392/7fdb0550-82fb-0a62-6073-d12c215b890a.png)
2週間前や昨日検証した際は何度もコケたので再現性はあるはずなのですが今回はコケませんでした。
ただ他の皆様もコケる可能性はあるので、解決策というか対策を記載しておきます。

# 証明書の作成でコケた場合はネットワークの制限を無効にする
はい。
これだけで回避できました。
もう簡単な手順なのでわざわざ画像貼り付ける必要もないかもしれませんが念のため。
[ネットワーク]の項目内の[アクセス制限付きで有効]になっている部分をクリックします。(最初に設定変更しているのでここの名称も変わっています)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/643392/3407eb4b-a8d3-fb65-129d-9a2a4da190a4.png)

先ほど[選択した仮想ネットワークとIPアドレスから有効]と選択したラジオボタンを、上の[すべてのネットワークから有効(現在のアクセス制限がすべてクリアされます)]に変更します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/643392/f7b917f3-b97d-62cb-7e8b-f1e42b1a8d08.png)
**ちなみのこの選択肢を選んで[保存]を押し、証明書の発行とバインド設定が完了後に元の選択肢[選択した仮想ネットワークとIPアドレスから有効]を選択しても、<font color="red">先ほど設定した許可設定は復活しません！**
<font color="red">**復元するために設定のバックアップは必須ですのでお忘れなく！**

以上、小ネタでしかも再現しなかったですが、私の環境では何度か再現していますので他の方が引っ掛かった場合参考になればと思い記事にしました。

本日はこれまで。