2024年4月にMicrosoftからAzureを用いたコード署名のマネジメントサービスであるTrusted Signingが公開されました。有償ですが、Basicモデルであれば月額$9.99で毎月コード署名を5000回行うことが可能です。
なお、コード署名には通常のコード署名の他にEV (Extended Validation)コード署名というものもあり、後者ではソフトウェアのインストール時などにMicrosoft SmartScreenに最初から引っかからないようなのですが、その分他社のコード署名サービスは非常に高額なのです。一方Trusted Signingは流石Microsoft公式だからなのか、EVコード署名ではないものの、EVコード署名と同等で、最初からSmartScreenに引っかからないとのことです。
設定方法は公式のものもありますが、下記の非公式のものが英語ではあるもののstep by stepで丁寧に解説されておりとても分かりやすいです。
Code signing on Windows with Azure Trusted Signing
とは言え上記英語の解説を読んでも何点か躓くところがありましたので、忘備録としてここにポイントを書いておきます。
Microsoft Entra テナント ID
早速上記英語ページに書かれていないのですが、特に法人の場合、ID認証において申請者がなりすましの偽者であるかどうかをチェックするのに、おそらくこのEntraテナントIDを見ているのではないかと想像しています。あくまで想像ですので間違っている可能性も大いにあるのですが、Trusted Signingの設定においてはドメイン名関連の確認事項が多く、上記のstep by stepのウェブサイトでもドメイン名の請求書の提出やwhois情報の提出を求められたと書かれています。
Microsoft Entra テナント IDではカスタムドメインを追加することが出来ますが、そのためにはドメインのDNSレコードを追加する必要があります。流石になりすましアカウントでは通常はDNSレコードを操作することは出来ませんので、Microsoft Entra テナント IDで正しくドメインが設定されており、且つそれがTrusted Signingで設定するドメイン名と一致していればID検証が迅速に行われるのではないかと想像しています。プライマリドメインがxxx.onmicrosoft.comのように初期状態のままの場合は、上記Microsoftのドキュメントに従って会社のドメインを追加し、プライマリドメインとして設定しておくと良いと思います。
…という事前情報の他は、以下は基本的にCode signing on Windows with Azure Trusted Signingの章立ての補足としてのコメントです。例えばStep 2と書かれていたら、それはCode signing on Windows with Azure Trusted SigningのStep 2の補足です。
Step 2: Create a Subscription
AzureアカウントのSubscriptionを作る際に従量課金制にする必要があると書かれていますが、これが本当かどうかは検証出来ていません。私はよくわからずに従量課金制で設定しました。
Step 3: Create a “Trusted Signing Account”
Regionの選択で、日本に少しでも近いほうが良いのかなと思いWest USを選択してみたところ、サービスを提供出来ないと何故か弾かれました…。初期設定のEast USを選択すると大丈夫でした。
Step 4: Create “App Registration” user credentials
最初に躓いたところです。「App Registrations」で何度検索しても該当するものが出てこないためとても焦りました。ひょっとしてひょっとすると言語の問題か？？と思い試しに「アプリの」で検索すると「アプリの登録」というサービスが出てきました。
…これですね。。。似たようなものに「App Configuration」というものがあり、こちらは英語のみで日本語が無さそうなのですが全く別物ですので注意して下さい。日本語環境では、日本語訳されているものは元々の英語名で検索しても出てこない仕様のようです。
もう1つは非常に非常に重要なのですがstep by stepのウェブサイトには書かれていないため要注意です。Client credentialsのところでsecretを追加するのですが、このときに表示されるsecret value（日本語環境では単に「値」と表示されます。秘密鍵のことだと思います）は、ポップアップに「作成直後を除き、クライアント シークレットの値を表示できません。ページを終了する前に、シークレットを作成するときに必ず保存してください。」と書かれている通りで、生成したときにコピーしておかないと値の確認が二度と出来ないことになります。コード署名を行う際にローカル環境では環境変数AZURE_CLIENT_SECRETとして必要ですので、必ずコピーしておきましょう。生成時にexpiray dateを最長の24カ月にするのも忘れないようにしましょう。
なお、ここに書かれている通り、Application (client) IDがAZURE_CLIENT_ID、Directory (tenant) IDがAZURE_TENANT_IDになります。
Step 5: Add “identity verifier” role to your Azure account
Trusted Signing Identity Verifierというロールは現在はCode Signing Identity Verifierというロールに名称が変わっているようでした。step by stepのウェブサイトに書かれているように、このロールはAzureユーザーに追加します。
Step 5b: Add the signer role to your “App Registration” user
Trusted Signing Certificate Profile Signerというロールは現在はCode Signing Certificate Profile Signerというロールに名称が変わっているようでした。この後がstep by stepのウェブサイトでも強調されているようにとても大事な部分です。このロールを追加するのはAzureユーザーではなく、App Registrationユーザーです。しかも、Add role assignmentのところでSelect membersをクリックしても初期設定では表示されず、Azureユーザーしか選択出来ないように見えるという落とし穴があります。ここでstep by stepのウェブサイトのように、Step 4で作ったApp Registrationの名前を入れるとしっかり出てきます。ここが最大の難所のように思います。
Step 6: Identity Validation
まずこれがどれに対して行うものなのかがわからずに躓きました。これはStep 3で作ったTrusted Signing Accoutに対して行う作業です。Trusted Signing Accountsで検索し、作ったアカウントをクリックします。そのあと、左側のメニューからObjectsをクリックするとCertificate profilesとIdentity validationsの2つが表示されるので、Identity validationsをクリックして作業を進めます。メールアドレスは同じドメイン名のものが2つ必要なので、1つしかない場合にはもう1つ作る必要があります。おそらく、このドメイン名がMicrosoft Entra テナント IDのプライマリドメインと同じであることが大事なのではないかと思います（繰り返しますが想像です）。
Business Identifierは初期状態ではDuns Numberが選択されていますが、日本の会社の場合はTax Idを選択して法人番号を入力すると良いようです。下記の日本語記事にもあるように、法人番号は国税庁が管理している13桁の番号のことです。法務局が管理している12桁の会社法人等番号とは異なるので注意して下さい。
参考：AzureがよくわからなくてもTrustedSigningを設定するまで
Duns Numberで行おうとすると色々面倒なようです。
参考：https://x.com/espresso3389/status/1868675496839672251
ここまでの作業は、なりすましでもほぼ進められてしまうので（法人番号は検索ですぐにわかりますし…）、やはり申請者が本物かどうかのチェックはMicrosoft Entra テナント IDが鍵なのではないかと想像しています。
なお、公式のドキュメントによると、パブリック認証の場合にはこのID検証（Identify Validation）に1から7営業日かかるとのことですが、私の場合はドメインに関する追加資料の提出なども何も無く、15分で認証が完了してしまいました。
Step 7: Create a Certificate Profile
公式のドキュメントによると、Trusted Signingの証明書は毎日更新され、それぞれ72時間しか有効でないようです。おそらくはAzure側で良いようにやってくれる…のだと思います。
2025/2/7追記：証明書の悪用防止のために有効期間は72時間ですが、有効期間の範囲内で署名されたタイムスタンプが作られるため、証明書自体の有効期間が切れてもインストーラやアプリの起動時に警告が出たりすることは無いようです。
ここまで出来れば完了です。あとはローカル環境でsigntool.exeを用いて署名するか、GitHub Actionsで署名するかのどちらかです。signtool.exeでは公式のドキュメントにあるように、.exe, .dll, .msiなどにコード署名を行うことが出来ます。
参考になれば幸いです！