Azure Front DoorでKey VaultのBYOC証明書を利用してHTTPS

Last updated at 2024-12-07Posted at 2024-12-07

Azure Front DoorにBYOC証明書を設定してみたときのメモ。

公開鍵基盤とは

PKIとはPublic Key Infrastructureの略であり、公開鍵暗号基盤のこと。公開鍵ペアを用いて暗号化、複合化、デジタル署名を行う。

いつもながらわかりやすいPiyoさんの説明。

①公開鍵は通信の暗号、②通信元の身元の保証の2点を目的とする。

１．公開鍵暗号方式で通信内容を暗号化する
２．電子証明書の仕組みを使って、公開鍵の身元を保証する

公開鍵暗号なのだから、南京錠のようにこれは僕Aの鍵だよ、僕にメッセージを送るときはこれで暗号化してね、と皆に配ってしまっても一見問題ないように思える。その南京錠を開けられる（複合化できる）秘密鍵を持っているのは自分だけだから。

でも悪意のある第三者がこれはＡさんの鍵だよ、と別の鍵を勝手にばらまいてしまったら？メールを盗聴したハッカーが付随している鍵をすり替えてしまったら？Man in middleアタックで通信の内容を改ざんされてしまったら？

なので、暗号化基盤は以下3点のリスクを防ぐことができなくてはいけない。

なりすまし
盗聴
改ざん

よってこの鍵は真にＡに属した鍵であることを証明できる機構がないといけない。

どうやって自分の身元を証明するのか　認証局モデル

そこで出てくるのが認証局。

信頼できる第三者機関（Trusted Third Party）に公開鍵の所有者を保証してもらう仕組み。公開鍵の発行の際に本人性を確認し、公開鍵と証明書を発行してもらう。鍵と証明書には第三者機関による署名が施されている。

認証局とは

電子証明書とは

認証局にはパブリックとプライベートがあり、パブリック認証局の場合は一般的なOSやWebブラウザにあらかじめ同梱されているケースがあり、その場合は証明書の配布やインストールが不要になる。
対して企業などの組織内で運用するプライベート認証局があり、こちらは証明書の配布や設定などの手間が必要になる。

証明書も色々な種類があり、例えばEV SSL証明書は認証プロセスが厳格で１年ごとに外部監査を受ける等の制限がある。EV SSL証明書の場合はアドレスバーが緑色になるなど見た目にも変化がある。有名なところではGlobalSignとか。

Azure Front Doorでカスタムドメインを設定する

さて前置きが長くなってしまったがAzure Front Doorで証明書を設定してみる。

と、調べていたところAzureデフォルトで提供されるマネージド証明書の手順をまとめていた人がすでにいましたので、以下記事の焼き直しです。

Front Door 構築

Standardでもカスタムドメインはサポートされているので、検証のためにStandardで立てる。

証明書は一旦なしで。

Endpointはほとんどデフォルトで作成、配信元はテスト用にwww.yahoo.co.jpを設定してしまう。

Front Doorのエンドポイントに接続するとYahooが表示される状態にできた。

カスタムドメイン購入・構築

App Service Domainを購入する。今回はテスト用にsimari11.comというものをたてた。

自動的にPublic DNS Zoneができていた。

Front Doorでカスタムドメインを設定

simari11.comをカスタムドメインとして設定。証明書は一旦AFDマネージドを設定。

カスタムドメインが追加できた。ドメインの検証はまだ。ドメインの検証というのは、このsimari11.comというURLを自分が持ってるものですよ、と証明すること。これがないとGoogleとかYahooとかのURLを簡単に乗っ取ることができてしまう。

保留中になっているところをクリックすると「カスタムドメイン所有権を検証する」というのが出てきた。

追加をぽちっとすると緑になった。

検証の状態が承認済みになった。
DNS Zoneを見てみると_dnsauth.wwwというレコードが追加されていた。TXTレコードはドメインの所有権によく使われる。要するに特定文字列をドメインに入れられたら、よしあなたのドメインだね、といえるらしい。

当初、ドメイン所有者の検証はTXTレコードの機能ではありませんでしたが、このアプローチは一部のウェブマスターツールやクラウドプロバイダーで採用されています。

管理者は、特定の情報を含んだ新しいTXTレコードをアップロードするか、現在のTXTレコードを編集することで、そのドメインの管理者であることを証明することができます。ツールやクラウドプロバイダーは、そのTXTレコードをチェックして要求通りに変更されていることを確認できます。これは、送られてきたリンクをユーザーが開いてクリックすることで電子メールアドレスを確認し、そのアドレスの所有者であることを証明する行為と似ています。

エンドポイントとの紐づけ

右のほうから関連付けを選択。

エンドポイントとの関連付けができた。でもDNSの状態がダメぽい。

DNSにCNAMEレコードを追加。

今はあくまでもまだこのドメイン私が本当にもってるよ！と検証しただけ。このwww.simari11.comにアクセスしたときにどこに飛ばせばいいかまでは、まだCNAMEレコードがない。

なのでCNAMEレコードの作成をぽちっと。www.simari11.comにアクセスしたら、Front DoorのURLに飛ばしてね、というCNAMEになっている。

DNSの状態が「トラフィックは安全に配信されます」になっている。

wwwのレコードがちゃんとFront Doorのエンドポイントに更新されている。

カスタムドメインのエンドポイントにアクセスするとちゃんと接続できるようになった。

ちなみにこの状態だとxxx.azurefd.netとwww.simari11.comの両方でアクセスできてしまうので、元のものはルートからドメインを外してしまうといい。

BYOCの証明書でやってみる

上ではカスタムドメインはAzure Domainを利用したが、実際にはその会社が使っているDNSサービスを利用した場合や証明書を渡される場合もあるだろう。

DNSの設定は基本的にTXTとCNAMEレコードをいれるだけだからこちらは割愛するとして。証明書を渡された場合の手順を実施してみる。

Let's Encryptで証明書発行

win-acmeを利用する。

win-acmeを利用したときのコンソールログ

PS C:\win-acme.v2.2.9.1701.x64.pluggable> .\wacs.exe

 A simple Windows ACMEv2 client (WACS)
 Software version 2.2.9.1701 (release, pluggable, standalone, 64-bit)
 Connecting to https://acme-v02.api.letsencrypt.org/...
 Connection OK!
 Running without administrator credentials, some options disabled
 Scheduled task not configured yet
 Please report issues at https://github.com/win-acme/win-acme

 N: Create certificate (default settings)
 M: Create certificate (full options)
 R: Run renewals (0 currently due)
 A: Manage renewals (1 total)
 O: More options...
 Q: Quit

 Please choose from the menu: M

 Running in mode: Interactive, Advanced
 Source plugin IIS not available: Run as administrator to allow access to IIS.

 Please specify how the list of domain names that will be included in the
 certificate should be determined. If you choose for one of the "all bindings"
 options, the list will automatically be updated for future renewals to
 reflect the bindings at that time.

 1: Read bindings from IIS
 2: Manual input
 3: CSR created by another program
 C: Abort

 How shall we determine the domain(s) to include in the certificate?: 2

Description:         A host name to get a certificate for. This may be a
                     comma-separated list.

 Host: simari11.com

 Source generated using plugin Manual: simari11.com

 Friendly name '[Manual] simari11.com'. <Enter> to accept or type desired name:
                                                                                <Enter>

 By default your source identifiers are covered by a single certificate. But
 if you want to avoid the 100 domain limit, want to prevent information
 disclosure via the SAN list, and/or reduce the operational impact of a single
 validation failure, you may choose to convert one source into multiple
 certificates, using different strategies.

 1: Separate certificate for each domain (e.g. *.example.com)
 2: Separate certificate for each host (e.g. sub.example.com)
 3: Separate certificate for each IIS site
 4: Single certificate
 C: Abort

 Would you like to split this source into multiple certificates?: 4

 Validation plugin SelfHosting not available: Run as administrator to allow opening a HTTP listener.

 The ACME server will need to verify that you are the owner of the domain
 names that you are requesting the certificate for. This happens both during
 initial setup *and* for every future renewal. There are two main methods of
 doing so: answering specific http requests (http-01) or create specific dns
 records (dns-01). For wildcard identifiers the latter is the only option.
 Various additional plugins are available from
 https://github.com/win-acme/win-acme/.

 1: [http] Save verification files on (network) path
 2: [http] Serve verification files from memory
 3: [http] Upload verification files via FTP(S)
 4: [http] Upload verification files via SSH-FTP
 5: [http] Upload verification files via WebDav
 6: [dns] Create verification records manually (auto-renew not possible)
 7: [dns] Create verification records with acme-dns (https://github.com/joohoi/acme-dns)
 8: [dns] Create verification records with your own script
 9: [tls-alpn] Answer TLS verification request from win-acme
 C: Abort

 How would you like prove ownership for the domain(s)?: 7

Description:         Root URI of the acme-dns service

 AcmeDnsServer: https://auth.acme-dns.io

 Creating new acme-dns registration for domain simari11.com

Domain:              simari11.com
Record:              _acme-challenge.simari11.com
Type:                CNAME
Content:             39432cc8-fb4b-479f-9522-fee22bfb00ee.auth.acme-dns.io.
Note:                Some DNS control panels add the final dot automatically.
                     Only one is required.

 Please press <Enter> after you've created and verified the record

 Verification failed, _acme-challenge.simari11.com found value (null) but expected 39432cc8-fb4b-479f-9522-fee22bfb00ee.auth.acme-dns.io at server 208.84.5.5

 Press 'Y' or <Enter> to retry, or 'N' to skip this step. (y*/n)
PS C:\win-acme.v2.2.9.1701.x64.pluggable> ^C
PS C:\win-acme.v2.2.9.1701.x64.pluggable> ^C
PS C:\win-acme.v2.2.9.1701.x64.pluggable> .\wacs.exe

 A simple Windows ACMEv2 client (WACS)
 Software version 2.2.9.1701 (release, pluggable, standalone, 64-bit)
 Connecting to https://acme-v02.api.letsencrypt.org/...
 Connection OK!
 Running without administrator credentials, some options disabled
 Scheduled task not configured yet
 Please report issues at https://github.com/win-acme/win-acme

 N: Create certificate (default settings)
 M: Create certificate (full options)
 R: Run renewals (0 currently due)
 A: Manage renewals (1 total)
 O: More options...
 Q: Quit

 Please choose from the menu: M

 Running in mode: Interactive, Advanced
 Source plugin IIS not available: Run as administrator to allow access to IIS.

 Please specify how the list of domain names that will be included in the
 certificate should be determined. If you choose for one of the "all bindings"
 options, the list will automatically be updated for future renewals to
 reflect the bindings at that time.

 1: Read bindings from IIS
 2: Manual input
 3: CSR created by another program
 C: Abort

 How shall we determine the domain(s) to include in the certificate?: 2

Description:         A host name to get a certificate for. This may be a
                     comma-separated list.

 Host: www.simari11.com

 Source generated using plugin Manual: www.simari11.com

 Friendly name '[Manual] www.simari11.com'. <Enter> to accept or type desired name:
                                                                                    <Enter>

 By default your source identifiers are covered by a single certificate. But
 if you want to avoid the 100 domain limit, want to prevent information
 disclosure via the SAN list, and/or reduce the operational impact of a single
 validation failure, you may choose to convert one source into multiple
 certificates, using different strategies.

 1: Separate certificate for each domain (e.g. *.example.com)
 2: Separate certificate for each host (e.g. sub.example.com)
 3: Separate certificate for each IIS site
 4: Single certificate
 C: Abort

 Would you like to split this source into multiple certificates?: 4

 Validation plugin SelfHosting not available: Run as administrator to allow opening a HTTP listener.

 The ACME server will need to verify that you are the owner of the domain
 names that you are requesting the certificate for. This happens both during
 initial setup *and* for every future renewal. There are two main methods of
 doing so: answering specific http requests (http-01) or create specific dns
 records (dns-01). For wildcard identifiers the latter is the only option.
 Various additional plugins are available from
 https://github.com/win-acme/win-acme/.

 1: [http] Save verification files on (network) path
 2: [http] Serve verification files from memory
 3: [http] Upload verification files via FTP(S)
 4: [http] Upload verification files via SSH-FTP
 5: [http] Upload verification files via WebDav
 6: [dns] Create verification records manually (auto-renew not possible)
 7: [dns] Create verification records with acme-dns (https://github.com/joohoi/acme-dns)
 8: [dns] Create verification records with your own script
 9: [tls-alpn] Answer TLS verification request from win-acme
 C: Abort

 How would you like prove ownership for the domain(s)?: 7

Description:         Root URI of the acme-dns service

 AcmeDnsServer: https://auth.acme-dns.io

 Existing acme-dns registration for domain www.simari11.com found
 Record: _acme-challenge.www.simari11.com
 CNAME: 26f19509-3c87-4007-95ea-96ee3bd9ef8c.auth.acme-dns.io
 Verification failed, _acme-challenge.www.simari11.com found value (null) but expected 26f19509-3c87-4007-95ea-96ee3bd9ef8c.auth.acme-dns.io at server 150.171.21.5

 Press 'Y' or <Enter> to retry, or 'N' to skip this step. (y*/n) - <Enter>

 Verification of acme-dns configuration succesful.

 After ownership of the domain(s) has been proven, we will create a
 Certificate Signing Request (CSR) to obtain the actual certificate. The CSR
 determines properties of the certificate like which (type of) key to use. If
 you are not sure what to pick here, RSA is the safe default.

 1: Elliptic Curve key
 2: RSA key
 C: Abort

 What kind of private key should be used for the certificate?: 2

 Store plugin CertificateStore not available: Run as administrator to allow certificate store access.

 When we have the certificate, you can store in one or more ways to make it
 accessible to your applications. The Windows Certificate Store is the default
 location for IIS (unless you are managing a cluster of them).

 1: IIS Central Certificate Store (.pfx per host)
 2: PEM encoded files (Apache, nginx, etc.)
 3: PFX archive
 4: Windows Certificate Store (Local Computer)
 5: No (additional) store steps

 How would you like to store the certificate?: 3

Description:         Path to write the .pfx file to.

 File path: C:\ssl

Description:         Password to set for .pfx file exported to the folder.

 1: None
 2: Type/paste in console
 3: Search in vault

 Choose from the menu: 2

 PfxPassword: *********

 Save to vault for future reuse? (y/n*) - no

 1: IIS Central Certificate Store (.pfx per host)
 2: PEM encoded files (Apache, nginx, etc.)
 3: PFX archive
 4: Windows Certificate Store (Local Computer)
 5: No (additional) store steps

 Would you like to store it in another way too?: 2

Description:         .pem files are exported to this folder.

 File path: C:\ssl

Description:         Password to set for the private key .pem file.

 1: None
 2: Type/paste in console
 3: Search in vault

 Choose from the menu: 2

 PemPassword: *********

 Save to vault for future reuse? (y/n*) - no

 1: IIS Central Certificate Store (.pfx per host)
 2: PEM encoded files (Apache, nginx, etc.)
 3: PFX archive
 4: Windows Certificate Store (Local Computer)
 5: No (additional) store steps

 Would you like to store it in another way too?: n

 Would you like to store it in another way too?: 5

 Installation plugin IIS not available: Run as administrator to allow access to IIS.

 With the certificate saved to the store(s) of your choice, you may choose one
 or more steps to update your applications, e.g. to configure the new
 thumbprint, or to update bindings.

 1: Create or update bindings in IIS
 2: Start external script or program
 3: No (additional) installation steps

 Which installation step should run first?: 3

Existing renewal:    [Manual] www.simari11.com - 1 renewal, due 2025/1/31

 Overwrite settings? (y*/n) - yes

 Overwriting previously created renewal

 Plugin Manual generated source www.simari11.com with 1 identifiers
 Plugin Single created 1 order
 Renewing [Manual] www.simari11.com
 Using cache for [Manual] www.simari11.com. To get a new certificate within 1 days, run with --nocache.
 Store step 1/2: PfxFile...
 Copying certificate to the pfx folder C:\ssl\www.simari11.com.pfx
 Store step 2/2: PemFiles...
 Exporting .pem files to C:\ssl
 Adding Task Scheduler entry with the following settings
 - Name win-acme renew (acme-v02.api.letsencrypt.org)
 - Path C:\win-acme.v2.2.9.1701.x64.pluggable
 - Command wacs.exe --renew --baseuri "https://acme-v02.api.letsencrypt.org/"
 - Start at 09:00:00
 - Random delay 04:00:00
 - Time limit 02:00:00

 Do you want to specify the user the task will run as? (y/n*) - <Enter>

 Unable to register scheduled task, please run as administrator or equivalent
 Next renewal due after 2025/1/31
 Certificate [Manual] www.simari11.com created

 N: Create certificate (default settings)
 M: Create certificate (full options)
 R: Run renewals (0 currently due)
 A: Manage renewals (1 total)
 O: More options...
 Q: Quit

 Please choose from the menu: Q

形式はpemとpfxで保存する。こんな感じで出力された。

pem? pfx?よく聞くけど、理解が微妙。。
フォーマットを説明してくれる素晴らしいページ。

もう少し補うためにPerplexityに質問。

PEMとは

PEM (Privacy Enhanced Mail):
テキストベースの形式で、Base64エンコードされたデータを含みます。証明書、秘密鍵、公開鍵などを個別のファイルとして保存できます。証明書は、公開鍵とその公開鍵を発行した認証局（CA）の署名を含むデータです。証明書は、特定の公開鍵が誰に属しているかを証明します。

多くのソフトウェアで使用される、より単純な仕様です。inuxやUnix環境で広く使用され、ApacheやNginxなどのWebサーバーで一般的ですテキスト形式なので、人間が読みやすく、簡単に編集や確認ができます。また、複数のファイルに分けて管理できるため、柔軟性があります。

ファイル拡張子は通常 .pem, .crt, .cer, .key などです。

Begin,Endの形式になっていればpeと判断できる。が、実際何が入っているか中身を見ないとわからないので、ヘッダとフッタを見て中身を判断する。

証明書の場合：
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
RSA秘密鍵:
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----
一般的な秘密鍵:
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----

秘密鍵は、データを復号したり、デジタル署名を作成するために使用されます。

PFXとは

PFX（Personal Information Exchange）
バイナリ形式で、PKCS#12規格に基づいています。PFXファイルは、通常、秘密鍵とそれに対応する公開鍵証明書を含みます。これにより、証明書と秘密鍵を一つのファイルにまとめて管理できます。また、中間証明書やルート証明書も同じファイルに含めることができ、証明書チェーン全体を保持できます。
パスワードで保護され、暗号化されています。

主にWindows環境（IISやAzureなど）で使用されます。複数の証明書（ルート証明書、中間証明書、秘密鍵）を一つのファイルにまとめることができるため、移動やインポートが容易です。

ファイル拡張子は通常 .pfx または .p12 です。

PEMからPFXへの変換、またはその逆の変換が必要な場合があり、OpenSSLなどのツールを使用して変換できます35。

なぜ異なる形式があるのか

互換性: 異なるオペレーティングシステムやアプリケーションは、それぞれ異なる証明書管理方法を持っています。PEMは主にUnix/Linux環境で使用される一方、PFXはWindows環境で広く使われています。

用途の違い: PEMは個別の証明書や鍵を扱う際に便利ですが、PFXは複数の証明書をまとめて扱う必要がある場合に適しています。

セキュリティ要件: PFX形式はパスワード保護が可能であり、高いセキュリティ要件を満たすために設計されています。（とはいいつつ、pemも秘密鍵を生成する場合はパスワードをつけられるね。）