Certificación de macOS Catalina y el impacto en las descargas y proyectos de .NET
A partir de macOS Catalina (versión 10.15), se debe conceder la certificación a todo el software creado después del 1 de junio de 2019 y que se distribuya con el identificador de desarrollador. Este requisito se aplica al entorno de ejecución de .NET, al SDK de .NET y al software creado con .NET. En este artículo se describen los escenarios comunes con los que puede encontrarse con la certificación de .NET y macOS.
Instalación de .NET
Desde el 18 de febrero de 2020, se ha concedido la certificación a los instaladores de .NET (tanto el runtime como el SDK). A las versiones publicadas anteriores no se les ha concedido la certificación. Puede instalar manualmente una versión de .NET Core no certificada ante notario si descarga primero el instalador y, después, usa el comando sudo installer.
appHost nativo
En el SDK de .NET 7 y versiones posteriores, un appHost, que es un ejecutable Mach-O nativo, se genera para la aplicación. .NET suele invocar este archivo ejecutable cuando el proyecto se compila, se publica o se ejecuta con el comando dotnet run. La versión que no es appHost de la aplicación es un archivo dll que el comando dotnet <app.dll> puede invocar.
Cuando se ejecuta localmente, el SDK firma el apphost mediante la firma ad hoc, lo que permite que la aplicación se ejecute localmente. Al distribuir la aplicación, deberá firmarla correctamente según las instrucciones de Apple.
También puede distribuir la aplicación sin apphost y confiar en que los usuarios la ejecuten mediante dotnet. Para desactivar la generación de appHost, agregue la configuración booleana UseAppHost en el archivo del proyecto y establézcala en false. También puede alternar appHost con el parámetro -p:UseAppHost en la línea de comandos para el comando dotnet específico que ejecute:
Archivo del proyecto
<PropertyGroup> <UseAppHost>false</UseAppHost> </PropertyGroup>Parámetro de línea de comandos
dotnet run -p:UseAppHost=false
Se requiere un appHost al publicar la aplicación independiente y no se puede deshabilitar.
Para obtener más información sobre la configuración de UseAppHost, vea Propiedades de MSBuild para Microsoft.NET.Sdk.
Contexto de appHost
Cuando appHost está habilitado en el proyecto y se usa el comando dotnet run para ejecutar la aplicación, la aplicación se invoca en el contexto de appHost y no en el host predeterminado (que es el comando dotnet). Si appHost está deshabilitado en el proyecto, el comando dotnet run ejecuta la aplicación en el contexto del host predeterminado. Incluso si appHost está deshabilitado, la publicación de la aplicación como independiente genera un ejecutable appHost que los usuarios utilizan para ejecutar la aplicación. La ejecución de la aplicación con dotnet <filename.dll> invoca la aplicación con el host predeterminado, el entorno de ejecución compartido.
Cuando se invoca una aplicación que usa appHost, la partición de certificado a la que accede la aplicación es diferente del host predeterminado certificado. Si la aplicación tiene que acceder a los certificados instalados a través del host predeterminado, use el comando dotnet run para ejecutarla desde su archivo del proyecto, o bien use el comando dotnet <filename.dll> para iniciar la aplicación directamente.
En la sección ASP.NET Core y macOS y los certificados se proporciona más información sobre este escenario.
ASP.NET Core, macOS y certificados
.NET proporciona la capacidad de administrar certificados en la cadena de claves de macOS con la clase System.Security.Cryptography.X509Certificates. El acceso a la cadena de claves de macOS usa la identidad de las aplicaciones como clave principal al decidir qué partición se debe tener en cuenta. Por ejemplo, las aplicaciones sin firmar almacenan secretos en la partición sin firmar, pero las aplicaciones con firma almacenan sus secretos en particiones a las que solo ellas pueden acceder. El origen de ejecución que invoca la aplicación decide qué partición se va a usar.
.NET proporciona tres orígenes de ejecución: appHost, host predeterminado (el comando dotnet) y un host personalizado. Cada modelo de ejecución puede tener identidades diferentes, con firma o sin firma, y tiene acceso a diferentes particiones dentro de la cadena de claves. Es posible que los certificados importados por un modo no sean accesibles desde otro. Por ejemplo, las versiones certificadas de .NET tienen un host predeterminado que está firmado. Los certificados se importan en una partición segura en función de su identidad. No se puede acceder a estos certificados desde un archivo appHost generado, ya que appHost está firmado ad hoc.
Otro ejemplo, de forma predeterminada, ASP.NET Core importa un certificado SSL predeterminado a través del host predeterminado. Las aplicaciones ASP.NET Core que usan appHost no tendrán acceso a este certificado y recibirán un error cuando .NET detecte que el certificado no es accesible. El mensaje de error proporciona instrucciones sobre cómo corregir este problema.
Si se requiere el uso compartido de certificados, macOS proporciona opciones de configuración con la utilidad security.
Para obtener más información sobre cómo solucionar problemas de certificados de ASP.NET Core, vea Aplicación de HTTPS en ASP.NET Core.
Derechos predeterminados
El host predeterminado de .NET (el comando dotnet) tiene un conjunto de derechos predeterminados. Estos derechos son necesarios para el funcionamiento correcto de .NET. Es posible que la aplicación necesite derechos adicionales, en cuyo caso tendrá que generar y usar un archivo appHost y, después, agregar los derechos necesarios de forma local.
Conjunto predeterminado de derechos para .NET:
com.apple.security.cs.allow-jitcom.apple.security.cs.allow-unsigned-executable-memorycom.apple.security.cs.allow-dyld-environment-variablescom.apple.security.cs.disable-library-validation
Certificación de una aplicación .NET
Si quiere que la aplicación se ejecute en macOS Catalina (versión 10.15) o superior, le interesará certificarla. El archivo appHost que envíe con la aplicación para la certificación se debe usar con al menos los mismos derechos predeterminados para .NET Core.
