Aplicación de HTTPS en ASP.NET Core

  • Artículo
  • Tiempo de lectura: 17 minutos

Por Rick Anderson

En este documento se muestra cómo:

  • Requerir HTTPS para todas las solicitudes.
  • Redirija todas las solicitudes HTTP a HTTPS.

Ninguna API puede impedir que un cliente envíe datos confidenciales en la primera solicitud.

Advertencia

Proyectos de API

No use RequireHttpsAttribute en las API web que reciben información confidencial. RequireHttpsAttribute usa códigos de estado HTTP para redirigir los exploradores de HTTP a HTTPS. Es posible que los clientes de API no comprendan ni obedezcan las redirecciones de HTTP a HTTPS. Estos clientes pueden enviar información a través de HTTP. Las API web deben:

  • No escuchar en HTTP.
  • Cierre la conexión con el código de estado 400 (solicitud no segura) y no atienden la solicitud.

Para deshabilitar el redireccionamiento HTTP en una API, establezca la ASPNETCORE_URLS variable de entorno o use la marca de línea de --urls comandos. Para obtener más información, Usar varios entornos en ASP.NET Core vea y 5 maneras de establecer las direcciones URL de una ASP.NET Core aplicación de Andrew Lock.

Proyectos de API y HSTS

Los proyectos de API predeterminados no incluyen HSTS porque HSTS suele ser una instrucción solo del explorador. Otros autores de llamadas, como las aplicaciones de teléfono o de escritorio, no cumplen las instrucciones. Incluso dentro de los exploradores, una sola llamada autenticada a una API a través de HTTP tiene riesgos en redes no seguras. El enfoque seguro es configurar proyectos de API para que solo escuche y responda a través de HTTPS.

Requerir HTTPS

Se recomienda que las aplicaciones web ASP.NET Core producción usen:

  • Middleware de redireccionamiento HTTPS ( UseHttpsRedirection ) para redirigir las solicitudes HTTP a HTTPS.
  • Middleware de HSTS(UseHsts)para enviar encabezados http Strict Transport Security Protocol (HSTS) a los clientes.

Nota

Las aplicaciones implementadas en una configuración de proxy inverso permiten que el proxy controle la seguridad de conexión (HTTPS). Si el proxy también controla el redireccionamiento HTTPS, no es necesario usar middleware de redireccionamiento HTTPS. Si el servidor proxy también controla la escritura de encabezados HSTS (por ejemplo, compatibilidad nativa con HSTS en IIS 10.0 (1709)o posterior), la aplicación no necesita middleware HSTS. Para obtener más información, vea Opt-out of HTTPS/HSTS on project creation (No participar en HTTPS/HSTS al crear el proyecto).

UseHttpsRedirection

El código siguiente llama UseHttpsRedirection al archivo Program.cs:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Código resaltado anterior:

Se recomienda usar redireccionamientos temporales en lugar de redireccionamientos permanentes. El almacenamiento en caché de vínculos puede producir un comportamiento inestable en los entornos de desarrollo. Si prefiere enviar un código de estado de redireccionamiento permanente cuando la aplicación está en un entorno que no es de desarrollo, consulte la sección Configuración de redireccionamientos permanentes en producción. Se recomienda usar HSTS para indicar a los clientes que solo se deben enviar solicitudes de recursos seguras a la aplicación (solo en producción).

Configuración de puerto

Debe haber un puerto disponible para que el middleware redirija una solicitud no segura a HTTPS. Si no hay ningún puerto disponible:

  • No se produce el redireccionamiento a HTTPS.
  • El middleware registra la advertencia "Failed to determine the https port for redirect".

Especifique el puerto HTTPS mediante cualquiera de los enfoques siguientes:

  • Establezca HttpsRedirectionOptions.HttpsPort.

  • Establezca la https_port configuración de host:

    • En la configuración del host.

    • Estableciendo la ASPNETCORE_HTTPS_PORT variable de entorno.

    • Agregando una entrada de nivel superior en appsettings.json :

      {
  "https_port": 443,
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "AllowedHosts": "*"
}

  • Indique un puerto con el esquema seguro mediante la variable ASPNETCORE_URLS de entorno. La variable de entorno configura el servidor. El middleware detecta indirectamente el puerto HTTPS a través de IServerAddressesFeature . Este enfoque no funciona en implementaciones de proxy inverso.

  • Las ASP.NET Core web establecen una dirección URL HTTPS en Properties/launchsettings.json para Kestrel y IIS Express. launchsettings.json solo se usa en el equipo local.

  • Configure un punto de conexión de dirección URL HTTPS para una implementación perimetral pública del servidor Kestrel HTTP.sys servidor. La aplicación solo usa un puerto HTTPS. El middleware detecta el puerto a través de IServerAddressesFeature .

Nota

Cuando una aplicación se ejecuta en una configuración de proxy inverso, IServerAddressesFeature no está disponible. Establezca el puerto mediante uno de los otros enfoques descritos en esta sección.

Implementaciones de Edge

Cuando oHTTP.sysse usa como servidor perimetral de acceso público, o HTTP.sys debe configurarse Kestrel para escuchar en Kestrel ambos:

  • Puerto seguro donde se redirige al cliente (normalmente, 443 en producción y 5001 en desarrollo).
  • Puerto no seguro (normalmente, 80 en producción y 5000 en desarrollo).

El cliente debe tener acceso al puerto no seguro para que la aplicación reciba una solicitud no segura y redirija el cliente al puerto seguro.

Para obtener más información, vea Configuración Kestrel del punto de conexión o Implementación del servidor web HTTP.sys en ASP.NET Core .

Escenarios de implementación

Cualquier firewall entre el cliente y el servidor también debe tener puertos de comunicación abiertos para el tráfico.

Si las solicitudes se reenvía en una configuración de proxy inverso, use middleware de encabezados reenviados antes de llamar al middleware de redireccionamiento HTTPS. El middleware de encabezados reenviados actualiza Request.Scheme , mediante el encabezado X-Forwarded-Proto . El middleware permite que los URI de redirección y otras directivas de seguridad funcionen correctamente. Cuando no se usa middleware de encabezados reenviados, es posible que la aplicación back-end no reciba el esquema correcto y termine en un bucle de redirección. Un mensaje de error común del usuario final es que se han producido demasiadas redirecciones.

Al implementar en Azure App Service, siga las instrucciones del Tutorial: Enlacede un certificado SSL personalizado existente a Azure Web Apps .

Opciones

El código resaltado siguiente llama a AddHttpsRedirection para configurar las opciones de middleware:

using System.Net;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddHsts(options =>
{
    options.Preload = true;
    options.IncludeSubDomains = true;
    options.MaxAge = TimeSpan.FromDays(60);
    options.ExcludedHosts.Add("example.com");
    options.ExcludedHosts.Add("www.example.com");
});

builder.Services.AddHttpsRedirection(options =>
{
    options.RedirectStatusCode = (int)HttpStatusCode.TemporaryRedirect;
    options.HttpsPort = 5001;
});

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

La AddHttpsRedirection llamada solo es necesaria para cambiar los valores de o HttpsPort RedirectStatusCode .

Código resaltado anterior:

Configuración de redireccionamientos permanentes en producción

El middleware envía de forma predeterminada un status307TemporaryRedirect con todas las redirecciones. Si prefiere enviar un código de estado de redirección permanente cuando la aplicación está en un entorno que no es de desarrollo, ajuste la configuración de las opciones de middleware en una comprobación condicional para un entorno que no sea de desarrollo.

Al configurar servicios en Program.cs:

using System.Net;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

if (builder.Environment.IsDevelopment())
{
    builder.Services.AddHttpsRedirection(options =>
    {
        options.RedirectStatusCode = (int)HttpStatusCode.PermanentRedirect;
        options.HttpsPort = 443;
    });
}

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");

    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Enfoque alternativo de middleware de redireccionamiento HTTPS

Una alternativa al uso del middleware de redireccionamiento HTTPS ( UseHttpsRedirection ) es usar middleware de reescritura de direcciones URL ( AddRedirectToHttps ). AddRedirectToHttps también puede establecer el código de estado y el puerto cuando se ejecuta el redireccionamiento. Para obtener más información, vea Middleware de reescritura de direcciones URL.

Al redirigir a HTTPS sin necesidad de reglas de redireccionamiento adicionales, se recomienda usar middleware de redireccionamiento HTTPS ( UseHttpsRedirection ) descrito en este tema.

Protocolo de seguridad de transporte estricto (HSTS) HTTP

Por OWASP, HTTP Strict Transport Security (HSTS) es una mejora de seguridad de exclusión que especifica una aplicación web mediante el uso de un encabezado de respuesta. Cuando un explorador que admite HSTS recibe este encabezado:

  • El explorador almacena la configuración para el dominio que impide el envío de cualquier comunicación a través de HTTP. El explorador fuerza toda la comunicación a través de HTTPS.
  • El explorador impide que el usuario use certificados que no sean de confianza o no sean válidos. El explorador deshabilita los mensajes que permiten a un usuario confiar temporalmente en este tipo de certificado.

Dado que el cliente aplica HSTS, tiene algunas limitaciones:

  • El cliente debe admitir HSTS.
  • HSTS requiere al menos una solicitud HTTPS correcta para establecer la directiva HSTS.
  • La aplicación debe comprobar cada solicitud HTTP y redirigir o rechazar la solicitud HTTP.

ASP.NET Core implementa HSTS con el método UseHsts de extensión. El código siguiente llama UseHsts a cuando la aplicación no está en modo de desarrollo:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

UseHsts no se recomienda en el desarrollo porque los exploradores pueden almacenar en caché la configuración de HSTS. De forma predeterminada, UseHsts excluye la dirección de bucle recuperación local.

Para los entornos de producción que implementan HTTPS por primera vez, establezca el valor inicial HstsOptions.MaxAge en un valor pequeño mediante uno de los TimeSpan métodos . Establezca el valor de hours en no más de un solo día en caso de que necesite revertir la infraestructura HTTPS a HTTP. Una vez que esté seguro de la sostenibilidad de la configuración https, aumente el valor de HSTS; un valor que se usa habitualmente max-age es un año.

El código resaltado siguiente:

using System.Net;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddHsts(options =>
{
    options.Preload = true;
    options.IncludeSubDomains = true;
    options.MaxAge = TimeSpan.FromDays(60);
    options.ExcludedHosts.Add("example.com");
    options.ExcludedHosts.Add("www.example.com");
});

builder.Services.AddHttpsRedirection(options =>
{
    options.RedirectStatusCode = (int)HttpStatusCode.TemporaryRedirect;
    options.HttpsPort = 5001;
});

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();
  • Establece el parámetro preload del Strict-Transport-Security encabezado. La carga previa no forma parte de la especificación RFC HSTS,pero es compatible con los exploradores web para cargar previamente sitios de HSTS en una instalación nueva. Para más información, vea https://hstspreload.org/.
  • Habilita includeSubDomain, que aplica la directiva HSTS a los subdominios host.
  • Establece explícitamente max-age el parámetro del encabezado en Strict-Transport-Security 60 días. Si no se establece, el valor predeterminado es 30 días. Para obtener más información, vea la directiva max-age.
  • Agrega example.com a la lista de hosts que se excluirán.

UseHsts excluye los siguientes hosts de buclesback:

  • localhost : dirección de bucle atrás IPv4.
  • 127.0.0.1 : dirección de bucle atrás IPv4.
  • [::1] : dirección de bucle de retorno IPv6.

No participar en HTTPS/HSTS al crear el proyecto

En algunos escenarios de servicio back-end en los que la seguridad de conexión se controla en el borde público de la red, no es necesario configurar la seguridad de conexión en cada nodo. Las aplicaciones web que se generan a partir de las plantillas de Visual Studio o desde el comando dotnet new habilitan el redireccionamiento HTTPS y HSTS. En el caso de las implementaciones que no requieren estos escenarios, puede no participar en HTTPS/HSTS cuando la aplicación se crea a partir de la plantilla.

Para no participar en HTTPS/HSTS:

Desactive la casilla Configurar para HTTPS.

Nuevo ASP.NET Core de diálogo Aplicación web que muestra la casilla Configurar para HTTPS no seleccionada.

Confiar en el certificado ASP.NET Core desarrollo HTTPS en Windows y macOS

Para el explorador Firefox, consulte la sección siguiente.

El SDK de .NET Core incluye un certificado de desarrollo HTTPS. El certificado se instala como parte de la experiencia de primera ejecución. Por ejemplo, dotnet --info genera una variación de la salida siguiente:

ASP.NET Core
------------
Successfully installed the ASP.NET Core HTTPS Development Certificate.
To trust the certificate run 'dotnet dev-certs https --trust' (Windows and macOS only).
For establishing trust on other platforms refer to the platform specific documentation.
For more information on configuring HTTPS see https://go.microsoft.com/fwlink/?linkid=848054.

Al instalar el SDK de .NET Core se instala el certificado de desarrollo HTTPS de ASP.NET Core en el almacén de certificados local del usuario. El certificado se ha instalado, pero no es de confianza. Para confiar en el certificado, realice el paso único para ejecutar la herramienta dev-certs dotnet:

dotnet dev-certs https --trust

El siguiente comando proporciona ayuda sobre la herramienta dev-certs:

dotnet dev-certs https --help

Advertencia

No cree un certificado de desarrollo en un entorno que se redistribuirá, como una imagen de contenedor o una máquina virtual. Si lo hace, puede provocar suplantación y elevación de privilegios. Para evitarlo, establezca la variable de entorno en antes de llamar a DOTNET_GENERATE_ASPNET_CERTIFICATE false la CLI de .NET por primera vez. Esto omitirá la generación automática del certificado ASP.NET Core desarrollo durante la experiencia de primera ejecución de la CLI.

Confiar en el certificado HTTPS con Firefox para evitar SEC_ERROR_INADEQUATE_KEY_USAGE error

El explorador Firefox usa su propio almacén de certificados y, por tanto, no confía en los certificados IIS Express o de Kestrel desarrollador.

Hay dos enfoques para confiar en el certificado HTTPS con Firefox, crear un archivo de directiva o configurarlo con el explorador FireFox. La configuración con el explorador crea el archivo de directiva, por lo que los dos enfoques son equivalentes.

Creación de un archivo de directiva para confiar en el certificado HTTPS con Firefox

Cree un archivo de directiva en:

Agregue el siguiente json al archivo de directiva de Firefox:

{
  "policies": {
    "Certificates": {
      "ImportEnterpriseRoots": true
    }
  }
}

El archivo de directiva anterior hace que Firefox confíe en los certificados de confianza del Windows certificados. En la sección siguiente se proporciona un enfoque alternativo para crear el archivo de directiva anterior mediante el explorador Firefox.

Configuración de la confianza del certificado HTTPS mediante el explorador Firefox

Establezca security.enterprise_roots.enabled = true con las instrucciones siguientes:

  1. Escriba about:config en el explorador FireFox.
  2. Seleccione Aceptar el riesgo y Continuar si acepta el riesgo.
  3. Seleccione Mostrar todo.
  4. Establecer security.enterprise_roots.enabled = true
  5. Salir y reiniciar Firefox

Para obtener más información, vea Configuración de las autoridades de certificación (CA) en Firefox y el archivo mozilla/policy-templates/README.

Configuración de un certificado de desarrollador para Docker

Consulte este problema de GitHub.

Confiar en el certificado HTTPS en Linux

El establecimiento de confianza es específico de la distribución y del explorador. En las secciones siguientes se proporcionan instrucciones para algunas distribuciones populares y los exploradores Chromium (Edge y Chrome) y para Firefox.

Ubuntu confía en el certificado para la comunicación entre servicios

  1. Instale OpenSSL 1.1.1h o posterior. Consulte la distribución para obtener instrucciones sobre cómo actualizar OpenSSL.

  2. Ejecute los comandos siguientes:

    dotnet dev-certs https
sudo -E dotnet dev-certs https -ep /usr/local/share/ca-certificates/aspnet/https.crt --format PEM
sudo update-ca-certificates

Los comandos anteriores:

  • Asegúrese de que se crea el certificado de desarrollador del usuario actual.
  • Exporta el certificado con los permisos elevados necesarios para ca-certificates la carpeta, mediante el entorno del usuario actual.
  • Al quitar la -E marca se exporta el certificado de usuario raíz y se genera si es necesario. Cada certificado recién generado tiene una huella digital diferente. Cuando se ejecuta como raíz, sudo y -E no son necesarios.

La ruta de acceso del comando anterior es específica para Ubuntu. Para otras distribuciones, seleccione una ruta de acceso adecuada o use la ruta de acceso para las autoridades de certificación (CA).

Confiar en un certificado HTTPS en Linux mediante Edge o Chrome

Para exploradores chromium en Linux:

  • Instale para libnss3-tools la distribución.

  • Cree o compruebe que $HOME/.pki/nssdb la carpeta existe en la máquina.

  • Exporte el certificado con el siguiente comando:

    dotnet dev-certs https
sudo -E dotnet dev-certs https -ep /usr/local/share/ca-certificates/aspnet/https.crt --format PEM

    La ruta de acceso del comando anterior es específica para Ubuntu. Para otras distribuciones, seleccione una ruta de acceso adecuada o use la ruta de acceso para las autoridades de certificación (CA).

  • Ejecute los comandos siguientes:

    certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n localhost -i /usr/local/share/ca-certificates/aspnet/https.crt
certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n localhost -i /usr/local/share/ca-certificates/aspnet/https.crt

  • Salga y reinicie el explorador.

Confiar en el certificado con Firefox en Linux

  • Exporte el certificado con el siguiente comando:

    dotnet dev-certs https
sudo -E dotnet dev-certs https -ep /usr/local/share/ca-certificates/aspnet/https.crt --format PEM

    La ruta de acceso del comando anterior es específica para Ubuntu. Para otras distribuciones, seleccione una ruta de acceso adecuada o use la ruta de acceso para las autoridades de certificación (CA).

  • Cree un archivo JSON en /usr/lib/firefox/distribution/policies.json con el siguiente contenido:

cat <<EOF | sudo tee /usr/lib/firefox/distribution/policies.json
{
    "policies": {
        "Certificates": {
            "Install": [
                "/usr/local/share/ca-certificates/aspnet/https.crt"
            ]
        }
    }
}
EOF

Consulte Configuración de la confianza del certificado HTTPS mediante el explorador Firefox en este documento para obtener una manera alternativa de configurar el archivo de directiva mediante el explorador.

Confiar en el certificado con Fedora 34

Vea este GitHub comentario.

Confiar en el certificado con otras distribuciones

Consulte este problema de GitHub.

Confiar en el certificado HTTPS de Subsistema de Windows para Linux

El Subsistema de Windows para Linux (WSL) genera un certificado de desarrollo autofirmado HTTPS. Para configurar el almacén Windows certificados para confiar en el certificado WSL:

  • Exporte el certificado de desarrollador a un archivo en Windows:

    dotnet dev-certs https -ep C:\<<path-to-folder>>\aspnetcore.pfx -p $CREDENTIAL_PLACEHOLDER$

    Donde $CREDENTIAL_PLACEHOLDER$ es una contraseña.

  • En una ventana de WSL, importe el certificado exportado en la instancia de WSL:

    dotnet dev-certs https --clean --import /mnt/c/<<path-to-folder>>/aspnetcore.pfx -p $CREDENTIAL_PLACEHOLDER$

El enfoque anterior es una operación única por certificado y por distribución de WSL. Es más fácil que exportar el certificado una y otra vez. Si actualiza o vuelve a generar el certificado en Windows, es posible que tenga que volver a ejecutar los comandos anteriores.

Solución de problemas de certificados, como certificados que no son de confianza

En esta sección se proporciona ayuda cuando ASP.NET Core certificado de desarrollo HTTPS se ha instalado y es de confianza,pero sigue teniendo advertencias del explorador de que el certificado no es de confianza. Usa ASP.NET Core certificado de desarrollo Kestrel HTTPS.

Para reparar el certificado IIS Express, consulte este problema de Stackoverflow.

Todas las plataformas: certificado no de confianza

Ejecute los comandos siguientes:

dotnet dev-certs https --clean
dotnet dev-certs https --trust

Cierre todas las instancias del explorador abiertas. Abra una nueva ventana del explorador para la aplicación. Los exploradores almacenan en caché la confianza del certificado.

dotnet dev-certs https --clean Produce un error

Los comandos anteriores resuelven la mayoría de los problemas de confianza del explorador. Si el explorador sigue sin confiar en el certificado, siga las sugerencias específicas de la plataforma siguientes.

Docker: certificado no de confianza

  • Elimine la carpeta C:\Users { USER}\AppData\Roaming\ASP.NET\Https.
  • Limpie la solución. Elimine las carpetas bin y obj.
  • Reinicie la herramienta de desarrollo. Por ejemplo, Visual Studio, Visual Studio Code o Visual Studio para Mac.

Windows: certificado no de confianza

  • Compruebe los certificados en el almacén de certificados. Debe haber un certificado localhost con el nombre descriptivo en ASP.NET Core HTTPS development certificate Current User > Personal > Certificates y Current User > Trusted root certification authorities > Certificates
  • Quite todos los certificados encontrados de las entidades de certificación raíz personal y de confianza. No quite el certificado IIS Express localhost.
  • Ejecute los comandos siguientes:
dotnet dev-certs https --clean
dotnet dev-certs https --trust

Cierre todas las instancias del explorador abiertas. Abra una nueva ventana del explorador para la aplicación.

OS X: certificado no de confianza

  • Abra Acceso a KeyChain.
  • Seleccione la cadena de claves Del sistema.
  • Compruebe la presencia de un certificado localhost.
  • Compruebe que contiene un + símbolo en el icono para indicar que es de confianza para todos los usuarios.
  • Quite el certificado de la cadena de claves del sistema.
  • Ejecute los comandos siguientes:
dotnet dev-certs https --clean
dotnet dev-certs https --trust

Cierre todas las instancias del explorador abiertas. Abra una nueva ventana del explorador para la aplicación.

Consulte Error HTTPS IIS Express (dotnet/AspNetCore #16892) para solucionar problemas de certificados con Visual Studio.

Certificado de Linux no de confianza

Compruebe que el certificado que se configura para la confianza es el certificado de desarrollador HTTPS de usuario que usará el Kestrel servidor.

Compruebe el certificado de desarrollador HTTPS predeterminado del Kestrel usuario actual en la siguiente ubicación:

ls -la ~/.dotnet/corefx/cryptography/x509stores/my

El archivo de certificado para desarrolladores HTTPS Kestrel es la huella digital SHA1. Cuando el archivo se elimina a través dotnet dev-certs https --clean de , se vuelve a generar cuando sea necesario con una huella digital diferente. Compruebe la huella digital de las coincidencias del certificado exportado con el comando siguiente:

openssl x509 -noout -fingerprint -sha1 -inform pem -in /usr/local/share/ca-certificates/aspnet/https.crt

Si el certificado no coincide, podría ser uno de los siguientes:

  • Un certificado antiguo.
  • Un certificado de desarrollador exportado para el usuario raíz. En este caso, exporte el certificado.

El certificado de usuario raíz se puede comprobar en:

ls -la /root/.dotnet/corefx/cryptography/x509stores/my

IIS Express Certificado SSL usado con Visual Studio

Para corregir problemas con el certificado IIS Express, seleccione Reparar en el Visual Studio instalación. Para más información, consulte este problema de GitHub.

Información adicional

Advertencia

Proyectos de API

No use RequireHttpsAttribute en las API web que reciben información confidencial. RequireHttpsAttribute usa códigos de estado HTTP para redirigir los exploradores de HTTP a HTTPS. Es posible que los clientes de API no comprendan ni obedezcan las redirecciones de HTTP a HTTPS. Estos clientes pueden enviar información a través de HTTP. Las API web deben:

  • No escuchar en HTTP.
  • Cierre la conexión con el código de estado 400 (solicitud no segura) y no atienden la solicitud.

Para deshabilitar el redireccionamiento HTTP en una API, establezca la ASPNETCORE_URLS variable de entorno o use la marca de línea de --urls comandos. Para obtener más información, Usar varios entornos en ASP.NET Core vea y 5 maneras de establecer las direcciones URL de una ASP.NET Core aplicación de Andrew Lock.

Proyectos de API y HSTS

Los proyectos de API predeterminados no incluyen HSTS porque HSTS suele ser una instrucción solo del explorador. Otros llamadores, como las aplicaciones de teléfono o de escritorio, no cumplen las instrucciones. Incluso dentro de los exploradores, una sola llamada autenticada a una API a través de HTTP tiene riesgos en redes no seguras. El enfoque seguro es configurar proyectos de API para que solo escuche y respondan a través de HTTPS.

Requerir HTTPS

Se recomienda que las aplicaciones web ASP.NET Core producción usen:

  • Middleware de redireccionamiento HTTPS ( UseHttpsRedirection ) para redirigir las solicitudes HTTP a HTTPS.
  • Middleware de HSTS(UseHsts)para enviar encabezados http Strict Transport Security Protocol (HSTS) a los clientes.

Nota

Las aplicaciones implementadas en una configuración de proxy inverso permiten que el proxy controle la seguridad de conexión (HTTPS). Si el proxy también controla el redireccionamiento HTTPS, no es necesario usar middleware de redireccionamiento HTTPS. Si el servidor proxy también controla la escritura de encabezados HSTS (por ejemplo, compatibilidad nativa con HSTS en IIS 10.0 (1709)o posterior), la aplicación no necesita middleware HSTS. Para obtener más información, vea Opt-out of HTTPS/HSTS on project creation (No participar en HTTPS/HSTS al crear el proyecto).

UseHttpsRedirection

El código siguiente llama UseHttpsRedirection a en la clase Startup :

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }
    else
    {
        app.UseExceptionHandler("/Error");
        // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
        app.UseHsts();
    }

    app.UseHttpsRedirection();
    app.UseStaticFiles();

    app.UseRouting();

    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapRazorPages();
    });
}

Código resaltado anterior:

Se recomienda usar redireccionamientos temporales en lugar de redireccionamientos permanentes. El almacenamiento en caché de vínculos puede producir un comportamiento inestable en los entornos de desarrollo. Si prefiere enviar un código de estado de redireccionamiento permanente cuando la aplicación está en un entorno que no es de desarrollo, consulte la sección Configuración de redireccionamientos permanentes en producción. Se recomienda usar HSTS para indicar a los clientes que solo se deben enviar solicitudes de recursos seguras a la aplicación (solo en producción).

Configuración de puerto

Debe haber un puerto disponible para que el middleware redirija una solicitud no segura a HTTPS. Si no hay ningún puerto disponible:

  • No se produce el redireccionamiento a HTTPS.
  • El middleware registra la advertencia "No se pudo determinar el puerto https para la redirección".

Especifique el puerto HTTPS mediante cualquiera de los enfoques siguientes:

  • Establezca HttpsRedirectionOptions.HttpsPort.

  • Establezca la https_port configuración del host:

    • En la configuración del host.

    • Estableciendo la ASPNETCORE_HTTPS_PORT variable de entorno.

    • Agregando una entrada de nivel superior en appsettings.json :

      {
    "https_port": 443,
    "Logging": {
        "LogLevel": {
            "Default": "Information",
            "Microsoft": "Warning",
            "Microsoft.Hosting.Lifetime": "Information"
        }
    },
    "AllowedHosts": "*"
}

  • Indique un puerto con el esquema seguro mediante la variable ASPNETCORE_URLS de entorno. La variable de entorno configura el servidor. El middleware detecta indirectamente el puerto HTTPS a través de IServerAddressesFeature . Este enfoque no funciona en implementaciones de proxy inverso.

  • En desarrollo, establezca una dirección URL HTTPS en launchsettings.json. Habilite HTTPS cuando IIS Express se usa .

  • Configure un punto de conexión de dirección URL HTTPS para una implementación perimetral pública del Kestrel servidorHTTP.sys servidor. La aplicación solo usa un puerto HTTPS. El middleware detecta el puerto a través de IServerAddressesFeature .

Nota

Cuando una aplicación se ejecuta en una configuración de proxy inverso, IServerAddressesFeature no está disponible. Establezca el puerto mediante uno de los otros enfoques descritos en esta sección.

Implementaciones de Edge

Cuando o HTTP.sys se usa como servidor perimetral de acceso público, o HTTP.sys Kestrel Kestrel debe configurarse para escuchar en ambos:

  • Puerto seguro al que se redirige el cliente (normalmente, 443 en producción y 5001 en desarrollo).
  • Puerto no seguro (normalmente, 80 en producción y 5000 en desarrollo).

El cliente debe tener acceso al puerto no seguro para que la aplicación reciba una solicitud no segura y redirija el cliente al puerto seguro.

Para obtener más información, vea Configuración Kestrel del punto de conexión o Implementación del servidor web HTTP.sys en ASP.NET Core .

Escenarios de implementación

Cualquier firewall entre el cliente y el servidor también debe tener puertos de comunicación abiertos para el tráfico.

Si las solicitudes se reenvía en una configuración de proxy inverso, use middleware de encabezados reenviados antes de llamar al middleware de redireccionamiento HTTPS. El middleware de encabezados reenviados actualiza Request.Scheme , mediante el encabezado X-Forwarded-Proto . El middleware permite que los URI de redirección y otras directivas de seguridad funcionen correctamente. Cuando no se usa middleware de encabezados reenviados, es posible que la aplicación back-end no reciba el esquema correcto y termine en un bucle de redireccionamiento. Un mensaje de error común del usuario final es que se han producido demasiadas redirecciones.

Al implementar en Azure App Service, siga las instrucciones del Tutorial: Enlacede un certificado SSL personalizado existente a Azure Web Apps .

Opciones

El código resaltado siguiente llama a AddHttpsRedirection para configurar las opciones de middleware:

public void ConfigureServices(IServiceCollection services)
{
    services.AddRazorPages();

    services.AddHsts(options =>
    {
        options.Preload = true;
        options.IncludeSubDomains = true;
        options.MaxAge = TimeSpan.FromDays(60);
        options.ExcludedHosts.Add("example.com");
        options.ExcludedHosts.Add("www.example.com");
    });

    services.AddHttpsRedirection(options =>
    {
        options.RedirectStatusCode = (int) HttpStatusCode.TemporaryRedirect;
        options.HttpsPort = 5001;
    });
}

Llamar AddHttpsRedirection a solo es necesario para cambiar los valores de o HttpsPort RedirectStatusCode .

El código resaltado anterior:

Configuración de redireccionamientos permanentes en producción

El middleware envía de forma predeterminada un status307TemporaryRedirect con todas las redirecciones. Si prefiere enviar un código de estado de redireccionamiento permanente cuando la aplicación está en un entorno que no es de desarrollo, ajuste la configuración de las opciones de middleware en una comprobación condicional para un entorno que no sea de desarrollo.

Al configurar servicios en Startup.cs:

public void ConfigureServices(IServiceCollection services)
{
    // IWebHostEnvironment (stored in _env) is injected into the Startup class.
    if (!_env.IsDevelopment())
    {
        services.AddHttpsRedirection(options =>
        {
            options.RedirectStatusCode = (int) HttpStatusCode.PermanentRedirect;
            options.HttpsPort = 443;
        });
    }
}

Enfoque alternativo del middleware de redireccionamiento HTTPS

Una alternativa al uso del middleware de redireccionamiento HTTPS ( UseHttpsRedirection ) es usar middleware de reescritura de direcciones URL ( AddRedirectToHttps ). AddRedirectToHttps también puede establecer el código de estado y el puerto cuando se ejecuta la redirección. Para más información, consulte Middleware de reescritura de direcciones URL.

Al redirigir a HTTPS sin el requisito de reglas de redireccionamiento adicionales, se recomienda usar el middleware de redireccionamiento HTTPS ( UseHttpsRedirection ) descrito en este tema.

Protocolo de seguridad de transporte estricto HTTP (HSTS)

Por OWASP,la seguridad de transporte estricta de HTTP (HSTS) es una mejora de seguridad de opt-in especificada por una aplicación web mediante el uso de un encabezado de respuesta. Cuando un explorador que admite HSTS recibe este encabezado:

  • El explorador almacena la configuración del dominio que impide enviar cualquier comunicación a través de HTTP. El explorador fuerza toda la comunicación a través de HTTPS.
  • El explorador impide que el usuario use certificados que no sean de confianza o no sean válidos. El explorador deshabilita los mensajes que permiten a un usuario confiar temporalmente en dicho certificado.

Dado que el cliente aplica HSTS, tiene algunas limitaciones:

  • El cliente debe admitir HSTS.
  • HSTS requiere al menos una solicitud HTTPS correcta para establecer la directiva HSTS.
  • La aplicación debe comprobar cada solicitud HTTP y redirigir o rechazar la solicitud HTTP.

ASP.NET Core implementa HSTS con el método UseHsts de extensión. El código siguiente llama UseHsts a cuando la aplicación no está en modo de desarrollo:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }
    else
    {
        app.UseExceptionHandler("/Error");
        // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
        app.UseHsts();
    }

    app.UseHttpsRedirection();
    app.UseStaticFiles();

    app.UseRouting();

    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapRazorPages();
    });
}

UseHsts no se recomienda en el desarrollo porque los exploradores pueden almacenar en caché la configuración de HSTS. De forma predeterminada, UseHsts excluye la dirección de bucle recuperación local.

Para los entornos de producción que implementan HTTPS por primera vez, establezca el valor inicial HstsOptions.MaxAge en un valor pequeño mediante uno de los TimeSpan métodos . Establezca el valor de hours en no más de un solo día en caso de que necesite revertir la infraestructura HTTPS a HTTP. Una vez que esté seguro de la sostenibilidad de la configuración https, aumente el valor de HSTS; un valor que se usa habitualmente max-age es un año.

El código siguiente:

public void ConfigureServices(IServiceCollection services)
{
    services.AddRazorPages();

    services.AddHsts(options =>
    {
        options.Preload = true;
        options.IncludeSubDomains = true;
        options.MaxAge = TimeSpan.FromDays(60);
        options.ExcludedHosts.Add("example.com");
        options.ExcludedHosts.Add("www.example.com");
    });

    services.AddHttpsRedirection(options =>
    {
        options.RedirectStatusCode = (int) HttpStatusCode.TemporaryRedirect;
        options.HttpsPort = 5001;
    });
}
  • Establece el parámetro preload del Strict-Transport-Security encabezado. La carga previa no forma parte de la especificación RFC HSTS,pero es compatible con los exploradores web para cargar previamente sitios de HSTS en una instalación nueva. Para más información, vea https://hstspreload.org/.
  • Habilita includeSubDomain, que aplica la directiva HSTS a los subdominios host.
  • Establece explícitamente max-age el parámetro del encabezado en Strict-Transport-Security 60 días. Si no se establece, el valor predeterminado es 30 días. Para obtener más información, vea la directiva max-age.
  • Agrega example.com a la lista de hosts que se excluirán.

UseHsts excluye los siguientes hosts de buclesback:

  • localhost : dirección de bucle atrás IPv4.
  • 127.0.0.1 : dirección de bucle atrás IPv4.
  • [::1] : dirección de bucle de retorno IPv6.

No participar en HTTPS/HSTS al crear el proyecto

En algunos escenarios de servicio back-end en los que la seguridad de conexión se controla en el borde público de la red, no es necesario configurar la seguridad de conexión en cada nodo. Las aplicaciones web que se generan a partir de las plantillas de Visual Studio o desde el comando dotnet new habilitan el redireccionamiento HTTPS y HSTS. En el caso de las implementaciones que no requieren estos escenarios, puede no participar en HTTPS/HSTS cuando la aplicación se crea a partir de la plantilla.

Para no participar en HTTPS/HSTS:

Desactive la casilla Configurar para HTTPS.

Nuevo ASP.NET Core de diálogo Aplicación web que muestra la casilla Configurar para HTTPS no seleccionada.

Confiar en el ASP.NET Core de desarrollo HTTPS en Windows y macOS

Para el explorador Firefox, consulte la sección siguiente.

El SDK de .NET Core incluye un certificado de desarrollo HTTPS. El certificado se instala como parte de la experiencia de primera ejecución. Por ejemplo, dotnet --info genera una variación de la salida siguiente:

ASP.NET Core
------------
Successfully installed the ASP.NET Core HTTPS Development Certificate.
To trust the certificate run 'dotnet dev-certs https --trust' (Windows and macOS only).
For establishing trust on other platforms refer to the platform specific documentation.
For more information on configuring HTTPS see https://go.microsoft.com/fwlink/?linkid=848054.

Al instalar el SDK de .NET Core se instala el certificado de desarrollo HTTPS de ASP.NET Core en el almacén de certificados local del usuario. El certificado se ha instalado, pero no es de confianza. Para confiar en el certificado, realice el paso único para ejecutar la herramienta dev-certs dotnet:

dotnet dev-certs https --trust

El siguiente comando proporciona ayuda sobre la herramienta dev-certs:

dotnet dev-certs https --help

Advertencia

No cree un certificado de desarrollo en un entorno que se redistribuirá, como una imagen de contenedor o una máquina virtual. Si lo hace, puede provocar suplantación y elevación de privilegios. Para evitarlo, establezca la variable de entorno en antes de llamar a la CLI de DOTNET_GENERATE_ASPNET_CERTIFICATE false .NET por primera vez. Esto omitirá la generación automática del certificado ASP.NET Core desarrollo durante la primera ejecución de la CLI.

Confiar en el certificado HTTPS con Firefox para evitar SEC_ERROR_INADEQUATE_KEY_USAGE error

El explorador Firefox usa su propio almacén de certificados y, por lo tanto, no confía en los certificados IIS Express o Kestrel desarrollador.

Hay dos enfoques para confiar en el certificado HTTPS con Firefox, crear un archivo de directiva o configurarlo con el explorador FireFox. La configuración con el explorador crea el archivo de directiva, por lo que los dos enfoques son equivalentes.

Creación de un archivo de directiva para confiar en el certificado HTTPS con Firefox

Cree un archivo de directiva en:

Agregue el siguiente código JSON al archivo de directiva de Firefox:

{
  "policies": {
    "Certificates": {
      "ImportEnterpriseRoots": true
    }
  }
}

El archivo de directiva anterior hace que Firefox confíe en los certificados de confianza del almacén de Windows certificados. En la sección siguiente se proporciona un enfoque alternativo para crear el archivo de directiva anterior mediante el explorador Firefox.

Configuración de la confianza del certificado HTTPS mediante el explorador Firefox

Establezca security.enterprise_roots.enabled = true con las instrucciones siguientes:

  1. Escriba about:config en el explorador FireFox.
  2. Seleccione Aceptar el riesgo y Continuar si acepta el riesgo.
  3. Seleccione Mostrar todo.
  4. Establecer security.enterprise_roots.enabled = true
  5. Salir y reiniciar Firefox

Para obtener más información, vea Configuración de las autoridades de certificación (CA) en Firefox y el archivo mozilla/policy-templates/README.

Configuración de un certificado de desarrollador para Docker

Consulte este problema de GitHub.

Confiar en el certificado HTTPS en Linux

El establecimiento de confianza es específico de la distribución y del explorador. En las secciones siguientes se proporcionan instrucciones para algunas distribuciones populares y los exploradores de Chromium (Edge y Chrome) y para Firefox.

Ubuntu confía en el certificado para la comunicación entre servicios

  1. Instale OpenSSL 1.1.1h o posterior. Consulte la distribución para obtener instrucciones sobre cómo actualizar OpenSSL.

  2. Ejecute los comandos siguientes:

    dotnet dev-certs https
sudo -E dotnet dev-certs https -ep /usr/local/share/ca-certificates/aspnet/https.crt --format PEM
sudo update-ca-certificates

Los comandos anteriores:

  • Asegúrese de que se ha creado el certificado de desarrollador del usuario actual.
  • Exporta el certificado con los permisos elevados necesarios para la ca-certificates carpeta mediante el entorno del usuario actual.
  • Al quitar la -E marca se exporta el certificado de usuario raíz y se genera si es necesario. Cada certificado recién generado tiene una huella digital diferente. Cuando se ejecuta como raíz, sudo y -E no son necesarios.

La ruta de acceso del comando anterior es específica de Ubuntu. Para otras distribuciones, seleccione una ruta de acceso adecuada o use la ruta de acceso para las autoridades de certificación (CA).

Confiar en el certificado HTTPS en Linux mediante Edge o Chrome

Para exploradores chromium en Linux:

  • Instale para libnss3-tools la distribución.

  • Cree o compruebe que $HOME/.pki/nssdb la carpeta existe en la máquina.

  • Exporte el certificado con el siguiente comando:

    dotnet dev-certs https
sudo -E dotnet dev-certs https -ep /usr/local/share/ca-certificates/aspnet/https.crt --format PEM

    La ruta de acceso del comando anterior es específica de Ubuntu. Para otras distribuciones, seleccione una ruta de acceso adecuada o use la ruta de acceso para las autoridades de certificación (CA).

  • Ejecute los comandos siguientes:

    certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n localhost -i /usr/local/share/ca-certificates/aspnet/https.crt
certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n localhost -i /usr/local/share/ca-certificates/aspnet/https.crt

  • Salga y reinicie el explorador.

Confiar en el certificado con Firefox en Linux

  • Exporte el certificado con el siguiente comando:

    dotnet dev-certs https
sudo -E dotnet dev-certs https -ep /usr/local/share/ca-certificates/aspnet/https.crt --format PEM

    La ruta de acceso del comando anterior es específica de Ubuntu. Para otras distribuciones, seleccione una ruta de acceso adecuada o use la ruta de acceso para las autoridades de certificación (CA).

  • Cree un archivo JSON en /usr/lib/firefox/distribution/policies.json con el siguiente contenido:

cat <<EOF | sudo tee /usr/lib/firefox/distribution/policies.json
{
    "policies": {
        "Certificates": {
            "Install": [
                "/usr/local/share/ca-certificates/aspnet/https.crt"
            ]
        }
    }
}
EOF

Consulte Configuración de la confianza del certificado HTTPS mediante el explorador Firefox en este documento para obtener una manera alternativa de configurar el archivo de directiva mediante el explorador.

Confiar en el certificado con Fedora 34

Vea este GitHub comentario.

Confiar en el certificado con otras distribuciones

Consulte este problema de GitHub.

Confiar en el certificado HTTPS de Subsistema de Windows para Linux

El Subsistema de Windows para Linux (WSL) genera un certificado de desarrollo autofirmado HTTPS. Para configurar el Windows de certificados para confiar en el certificado WSL:

  • Exporte el certificado de desarrollador a un archivo en Windows:

    dotnet dev-certs https -ep C:\<<path-to-folder>>\aspnetcore.pfx -p $CREDENTIAL_PLACEHOLDER$

    Donde $CREDENTIAL_PLACEHOLDER$ es una contraseña.

  • En una ventana de WSL, importe el certificado exportado en la instancia de WSL:

    dotnet dev-certs https --clean --import /mnt/c/<<path-to-folder>>/aspnetcore.pfx -p $CREDENTIAL_PLACEHOLDER$

El enfoque anterior es una operación única por certificado y por distribución de WSL. Es más fácil que exportar el certificado una y otra vez. Si actualiza o vuelve a generar el certificado en Windows, es posible que tenga que volver a ejecutar los comandos anteriores.

Solución de problemas de certificados, como certificados que no son de confianza

En esta sección se proporciona ayuda cuando ASP.NET Core certificado de desarrollo HTTPS se ha instalado y es de confianza,pero sigue teniendo advertencias del explorador de que el certificado no es de confianza. Usa ASP.NET Core certificado de desarrollo Kestrel HTTPS.

Para reparar el certificado IIS Express, consulte este problema de Stackoverflow.

Todas las plataformas: certificado no de confianza

Ejecute los comandos siguientes:

dotnet dev-certs https --clean
dotnet dev-certs https --trust

Cierre todas las instancias del explorador abiertas. Abra una nueva ventana del explorador para la aplicación. Los exploradores almacenan en caché la confianza del certificado.

dotnet dev-certs https --clean Produce un error

Los comandos anteriores resuelven la mayoría de los problemas de confianza del explorador. Si el explorador sigue sin confiar en el certificado, siga las sugerencias específicas de la plataforma siguientes.

Docker: certificado no de confianza

  • Elimine la carpeta C:\Users { USER}\AppData\Roaming\ASP.NET\Https.
  • Limpie la solución. Elimine las carpetas bin y obj.
  • Reinicie la herramienta de desarrollo. Por ejemplo, Visual Studio, Visual Studio Code o Visual Studio para Mac.

Windows: certificado no de confianza

  • Compruebe los certificados en el almacén de certificados. Debe haber un certificado localhost con el nombre descriptivo en ASP.NET Core HTTPS development certificate Current User > Personal > Certificates y Current User > Trusted root certification authorities > Certificates
  • Quite todos los certificados encontrados de las entidades de certificación raíz personal y de confianza. No quite el certificado IIS Express localhost.
  • Ejecute los comandos siguientes:
dotnet dev-certs https --clean
dotnet dev-certs https --trust

Cierre todas las instancias del explorador abiertas. Abra una nueva ventana del explorador para la aplicación.

OS X: certificado no de confianza

  • Abra Acceso a KeyChain.
  • Seleccione la cadena de claves Del sistema.
  • Compruebe la presencia de un certificado localhost.
  • Compruebe que contiene un + símbolo en el icono para indicar que es de confianza para todos los usuarios.
  • Quite el certificado de la cadena de claves del sistema.
  • Ejecute los comandos siguientes:
dotnet dev-certs https --clean
dotnet dev-certs https --trust

Cierre todas las instancias del explorador abiertas. Abra una nueva ventana del explorador para la aplicación.

Consulte Error HTTPS IIS Express (dotnet/AspNetCore #16892) para solucionar problemas de certificados con Visual Studio.

Certificado de Linux no de confianza

Compruebe que el certificado que se configura para la confianza es el certificado de desarrollador HTTPS de usuario que usará el Kestrel servidor.

Compruebe el certificado de desarrollador HTTPS predeterminado del Kestrel usuario actual en la siguiente ubicación:

ls -la ~/.dotnet/corefx/cryptography/x509stores/my

El archivo de certificado para desarrolladores HTTPS Kestrel es la huella digital SHA1. Cuando el archivo se elimina a través dotnet dev-certs https --clean de , se vuelve a generar cuando sea necesario con una huella digital diferente. Compruebe la huella digital de las coincidencias del certificado exportado con el comando siguiente:

openssl x509 -noout -fingerprint -sha1 -inform pem -in /usr/local/share/ca-certificates/aspnet/https.crt

Si el certificado no coincide, podría ser uno de los siguientes:

  • Un certificado antiguo.
  • Un certificado de desarrollador exportado para el usuario raíz. En este caso, exporte el certificado.

El certificado de usuario raíz se puede comprobar en:

ls -la /root/.dotnet/corefx/cryptography/x509stores/my

IIS Express Certificado SSL usado con Visual Studio

Para corregir problemas con el certificado IIS Express, seleccione Reparar en el Visual Studio instalación. Para más información, consulte este problema de GitHub.

Información adicional