macOS Catalina の公証および .NET のダウンロードとプロジェクトへの影響

  • [アーティクル]

macOS Catalina (バージョン 10.15) 以降では、2019 年 6 月 1 日より後に作成され、Developer ID と共に配布されたすべてのソフトウェアは公証される必要があります。 この要件は、.NET ランタイム、.NET SDK、および .NET を使用して作成されたソフトウェアに適用されます。 この記事では、.NET と macOS の公証に関して発生する可能性のある一般的なシナリオについて説明します。

.NET のインストール

.NET (ランタイムと SDK の両方) のインストーラーは、2020 年 2 月 18 日から公証されています。 それより前にリリースされたバージョンは、公証されていません。 公証されていないバージョンの .NET は、最初にインストーラーをダウンロードしてから、sudo installer コマンドを使用して手動でインストールできます。 詳しくは、macOS でのダウンロードと手動インストールに関する記事をご覧ください。

ネイティブ appHost

.NET SDK 7 以降のバージョンでは、ネイティブの Mach-O 実行可能ファイルである appHost がアプリ用に生成されます。 通常、実行可能ファイルは、プロジェクトのコンパイル、公開、または dotnet run コマンドでの実行時に .NET によって呼び出されます。 アプリの非 appHost バージョンは dll ファイルであり、dotnet <app.dll> コマンドで呼び出すことができます。

ローカルで実行する場合、SDK は ad hoc signing を使って apphost に署名し、アプリをローカルで実行できるようにします。 アプリを配布する場合は、Apple のガイダンスに従って、アプリに適切に署名する必要があります。

また、apphost を使わずにアプリを配布し、ユーザーに dotnet を使ってアプリを実行させることもできます。 appHost の生成をオフにするには、プロジェクト ファイルに UseAppHost ブール値の設定を追加して、それを false に設定します。 また、コマンド ラインで -p:UseAppHost パラメーターを使用することにより、実行する特定の dotnet コマンドについて appHost を切り替えることもできます。

  • プロジェクト ファイル

    <PropertyGroup>
  <UseAppHost>false</UseAppHost>
</PropertyGroup>

  • コマンド ライン パラメーター

    dotnet run -p:UseAppHost=false

appHost はアプリを自己完結型で公開する場合に必要で、無効にすることはできません。

UseAppHost 設定の詳細については、Microsoft.NET.Sdk の MSBuild プロパティに関する記事を参照してください。

appHost のコンテキスト

プロジェクトで appHost が有効になっている場合、dotnet run コマンドを使用してアプリを実行すると、アプリは、既定のホスト (既定のホストは dotnet コマンドです) ではなく、appHost のコンテキストで呼び出されます。 プロジェクトで appHost が無効になっている場合は、dotnet run コマンドを使用すると、既定のホストのコンテキストでアプリが実行されます。 appHost が無効になっている場合でも、自己完結型としてアプリを発行すると、appHost 実行可能ファイルが生成され、ユーザーはその実行可能ファイルを使用してアプリを実行します。 dotnet <filename.dll> でアプリを実行すると、共有ランタイムである既定のホストを使用してアプリが呼び出されます。

appHost を使用するアプリが呼び出されるときは、アプリによってアクセスされる証明書パーティションが、公証された既定のホストとは異なります。 既定のホストによってインストールされた証明書にアクセスする必要があるアプリの場合は、dotnet run コマンドを使用してプロジェクト ファイルからアプリを実行するか、dotnet <filename.dll> コマンドを使用してアプリを直接起動します。

このシナリオについて詳しくは、「ASP.NET Core と macOS および証明書」セクションをご覧ください。

ASP.NET Core、macOS、証明書

.NET には、System.Security.Cryptography.X509Certificates クラスを使用して macOS キーチェーンの証明書を管理する機能が用意されています。 macOS キーチェーンへのアクセスでは、考慮するパーティションを決定するときに、アプリケーション ID が主キーとして使用されます。 たとえば、署名されていないアプリケーションでは、署名されていないパーティションにシークレットが格納されますが、署名されたアプリケーションでは、そのアプリケーションだけがアクセスできるパーティションにシークレットが格納されます。 アプリを呼び出す実行のソースによって、使用するパーティションが決まります。

.NET では、実行のソースとして、appHost、既定のホスト (dotnet コマンド)、カスタム ホストの 3 種類が提供されます。 各実行モデルでは、異なる ID を使用でき (署名あり、または署名なし)、キーチェーン内の異なるパーティションにアクセスできます。 あるモードでインポートされた証明書には、別のモードからはアクセスできない可能性があります。 たとえば、.NET の公証されたバージョンには、署名された既定のホストがあります。 証明書は、その ID に基づいて、セキュリティで保護されたパーティションにインポートされます。 appHost がアドホック署名されているため、これらの証明書には、生成された appHost からはアクセスできません。

別の例として、既定では、ASP.NET Core によって既定のホストから既定の SSL 証明書がインポートされます。 appHost を使用する ASP.NET Core アプリケーションでは、この証明書にアクセスできないため、証明書にアクセスできないことが .NET で検出されたときにエラーを受け取ります。 エラー メッセージでは、この問題を解決するための方法が示されています。

証明書の共有が必要な場合、macOS では security ユーティリティで構成オプションが提供されています。

ASP.NET Core 証明書の問題をトラブルシューティングする方法について詳しくは、「ASP.NET Core に HTTPS を適用する」をご覧ください。

既定の権利

.NET の既定のホスト (dotnet コマンド) には、既定のエンタイトルメントのセットがあります。 .NET が適切に動作するには、これらのエンタイトルメントが必要です。 アプリケーションでは追加の権利が必要になることがあり、その場合は、appHost を生成して使用し、必要な権利をローカルに追加する必要があります。

.NET の既定のエンタイトルメントのセット:

  • com.apple.security.cs.allow-jit
  • com.apple.security.cs.allow-unsigned-executable-memory
  • com.apple.security.cs.allow-dyld-environment-variables
  • com.apple.security.cs.disable-library-validation

.NET アプリを公証する

macOS Catalina (バージョン 10.15) 以降でアプリケーションを実行する場合は、アプリを公証することをお勧めします。 公証のためにアプリケーションと共に送信する appHost は、少なくとも .NET Core と同じ既定の権利で使用する必要があります。

次の手順