Aplicación de HTTPS en ASP.NET Core

Por David Galvan y 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 exploradores de HTTP a HTTPS. Es posible que los clientes de API no entiendan u obedezcan los redireccionamientos de HTTP a HTTPS. Estos clientes pueden enviar información a través de HTTP. Las API web deberían:

• No escuchar en HTTP.
• Cerrar la conexión con el código de estado 400 (Solicitud incorrecta) y no atender la solicitud.

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

Proyectos de HSTS y API

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 obedecen la instrucción. 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 consiste en configurar proyectos de API para que solo escuchen y respondan a través de HTTPS.

El redireccionamiento de HTTP a HTTPS provoca ERR_INVALID_REDIRECT en la solicitud de preparación de CORS

Las solicitudes a un punto de conexión usando HTTP que son redirigidas a HTTPS por UseHttpsRedirection fallan con ERR_INVALID_REDIRECT on the CORS preflight request.

Los proyectos de API pueden rechazar solicitudes HTTP en lugar de usar UseHttpsRedirection para redirigir solicitudes a HTTPS.

Requerir HTTPS

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

• El middleware de redireccionamiento de HTTPS (UseHttpsRedirection) redirige las solicitudes HTTP a HTTPS.
• Middleware de HSTS (UseHsts) para enviar encabezados de Protocolo de seguridad de transporte estricta de HTTP (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 el middleware de redireccionamiento HTTPS. Si el servidor proxy también controla la escritura de encabezados HSTS (por ejemplo, la compatibilidad nativa con HSTS en IIS 10.0 (1709) o posterior), la aplicación no necesitará Middleware de HSTS. Para más información, consulte No participar en HTTPS/HSTS en la creación del proyecto.

UseHttpsRedirection

El siguiente código llama a UseHttpsRedirection en el 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();

El código resaltado anterior:

• Usa el valor predeterminado HttpsRedirectionOptions.RedirectStatusCode (Status307TemporaryRedirect).
• Usa el valor predeterminado HttpsRedirectionOptions.HttpsPort (null) a menos que se invalide mediante la variable de entorno ASPNETCORE_HTTPS_PORTS o IServerAddressesFeature.

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 redirección permanente cuando la aplicación se encuentra en un entorno que no es de desarrollo, consulte la sección Configurar 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

Un puerto debe estar 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 métodos siguientes:

• Establezca HttpsRedirectionOptions.HttpsPort.

• Establezca la https_portconfiguración del host:

  • En la configuración del host.

  • Estableciendo la variable de entorno ASPNETCORE_HTTPS_PORTS.

  • 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 de entorno ASPNETCORE_URLS. 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 plantillas web de ASP.NET Core establecen una dirección URL HTTPS en Properties/launchsettings.json para Kestrel y IIS Express. launchsettings.json solo se usa en la máquina local.

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

Nota

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

Implementaciones de Edge

Cuando Kestrel o HTTP.sys se usa como servidor perimetral orientado al público, Kestrel o HTTP.sys deben configurarse para escuchar en ambos:

• El puerto seguro al que se redirige el cliente (normalmente, 443 en producción y 5001 en desarrollo).
• El 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 más información, consulte Configuración del punto de conexión Kestrel o Implementación del servidor web HTTP.sys en JavaScript.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ían en una configuración de proxy inverso, use el Middleware de encabezados reenviados antes de llamar al Middleware de redireccionamiento HTTPS. El Middleware de encabezados reenviados actualiza el Request.Scheme, usando 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 el Middleware de encabezados reenviados, es posible que la aplicación de back-end no reciba el esquema correcto y termine en un bucle de redireccionamiento. Un mensaje de error de usuario final común es que se han producido demasiadas redirecciones.

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

Opciones

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

using static Microsoft.AspNetCore.Http.StatusCodes;

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 = Status307TemporaryRedirect;
    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();

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

El código resaltado anterior:

• Establece HttpsRedirectionOptions.RedirectStatusCode en Status307TemporaryRedirect, que es el valor predeterminado. Use los campos de la clase StatusCodes para las asignaciones a RedirectStatusCode.
• Establece el puerto HTTPS en 5001.

Configuración de redireccionamientos permanentes en producción

El middleware tiene como valor predeterminado enviar un elemento Status307TemporaryRedirect con todos los redireccionamientos. Si prefiere enviar un código de estado de redirección permanente cuando la aplicación se encuentra en un entorno que no es de desarrollo, encapsule la configuración de opciones de middleware en una comprobación condicional de un entorno que no es de desarrollo.

Al configurar los servicios en Program.cs:

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

if (!builder.Environment.IsDevelopment())
{
    builder.Services.AddHttpsRedirection(options =>
    {
        options.RedirectStatusCode = Status308PermanentRedirect;
        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 redirección HTTPS

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

Al redirigir a HTTPS sin necesidad de reglas de redirección adicionales, recomendamos usar el Middleware de redirección HTTPS (UseHttpsRedirection) descrito en este tema.

Protocolo de seguridad de transporte estricta de HTTP (HSTS)

Según OWASP, la Seguridad de transporte estricta HTTP (HSTS) es una mejora de seguridad opcional 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 del 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 son de confianza o no válidos. El explorador deshabilita las indicaciones 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 de extensión UseHsts. El código siguiente llama a UseHsts 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 desarrollo porque la configuración HSTS es muy almacenable en caché por los navegadores. De forma predeterminada, UseHsts excluye la dirección de bucle invertido local.

Para 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 métodos TimeSpan. Establezca el valor de horas en no más de un solo día en caso de que necesite revertir la infraestructura HTTPS a HTTP. Después de confiar en la sostenibilidad de la configuración HTTPS, aumente el valor de HSTS max-age ; un valor usado normalmente es de un año.

El código resaltado siguiente:

using static Microsoft.AspNetCore.Http.StatusCodes;

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 = Status307TemporaryRedirect;
    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 de precarga del encabezado Strict-Transport-Security. La precarga no forma parte de la especificación RFC HSTS, pero es compatible con los exploradores web para precargar sitios HSTS en una nueva instalación. Para obtener más información, vea https://hstspreload.org/.
• Habilita includeSubDomain, que aplica la directiva HSTS a subdominios de host.
• Establece explícitamente el parámetro max-age del encabezado Strict-Transport-Security en 60 días. Si no se establece, el valor predeterminado es de 30 días. Para más información, consulte la directiva max-age.
• Agrega example.com a la lista de hosts que se van a excluir.

UseHsts excluye los siguientes hosts de bucle invertido:

• localhost : dirección de bucle invertido IPv4.
• 127.0.0.1 : dirección de bucle invertido IPv4.
• [::1] : dirección de bucle invertido IPv6.

No participar en HTTPS/HSTS en la creación del proyecto

En algunos escenarios de servicio back-end en los que la seguridad de conexión se controla en el perímetro 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 optar por no participar en HTTPS/HSTS cuando se crea la aplicación a partir de la plantilla.

Para no participar en HTTPS/HSTS:

Visual Studio

Desactive la casilla Configurar para HTTPS .

CLI de .NET Core

Use la opción --no-https. Por ejemplo,

dotnet new webapp --no-https

Confiar en el certificado de desarrollo HTTPS de JavaScript.NET Core 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 produce una variación de la siguiente salida:

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. Se ha instalado el certificado, pero no es de confianza. Para confiar en el certificado, realice el paso puntual para ejecutar la herramienta dev-certs de 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 redistribuya, como una imagen de contenedor o una máquina virtual. Si lo hace, puede provocar suplantación de identidad y elevación de privilegios. Para evitarlo, establezca la variable de entorno DOTNET_GENERATE_ASPNET_CERTIFICATE en false antes de llamar a la CLI de .NET por primera vez. Esto omitirá la generación automática del certificado de desarrollo de ASP.NET Core durante la experiencia de primera ejecución de la CLI.

Confiar en el certificado HTTPS con Firefox para evitar el error SEC_ERROR_INADEQUATE_KEY_USAGE

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

Hay dos enfoques para confiar en el certificado HTTPS con Firefox, crear un archivo de directiva o configurar 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 (policies.json) en:

• Windows: %PROGRAMFILES%\Mozilla Firefox\distribution\
• MacOS: Firefox.app/Contents/Resources/distribution
• Linux: consulte Confiar en el certificado con Firefox en Linux en este documento.

Agregue el siguiente JSON en el archivo de directiva de Firefox:

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

El archivo de directiva anterior hace que Firefox confíe en los certificados de confianza en el almacén de certificados de Windows. 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 usando las siguientes instrucciones:

1. Escriba about:config en el explorador FireFox.
2. Seleccione Aceptar el riesgo y Continuar si acepta el riesgo.
3. Seleccione Mostrar todos
4. Establezca security.enterprise_roots.enabled = true
5. Salga y reinicie Firefox

Para más información, vea Configuración de entidades 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

Establecer la confianza es la distribución y el explorador específicos. 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

Las instrucciones siguientes no funcionan para algunas versiones de Ubuntu, como 20.04. Para más información, consulte la incidencia de GitHub dotnet/AspNetCore.Docs #23686.

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 permisos elevados necesarios para la carpeta ca-certificates mediante el entorno del usuario actual.
• Al quitar la marca -E, se exporta el certificado de usuario raíz, lo que lo 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 entidades de certificación (CA).

Confiar en el certificado HTTPS en Linux mediante Edge o Chrome

Ubuntu

Para exploradores de Chromium en Linux:

• Instale libnss3-tools para su distribución.

• Cree o compruebe que la carpeta $HOME/.pki/nssdb 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 entidades 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 navegador.

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 entidades de certificación (CA).

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

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

Nota: Ubuntu 21.10 Firefox viene como un paquete snap y la carpeta de instalación es /snap/firefox/current/usr/lib/firefox.

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.

Red Hat Enterprise Linux

Advertencia

Las siguientes instrucciones están pensadas solo para fines de desarrollo. No use los certificados generados en estas instrucciones para un entorno de producción.

Estas instrucciones usan la herramienta heredada de Mozilla certutil en https://firefox-source-docs.mozilla.org/security/nss/legacy/tools/nss_tools_certutil/index.html. Las instrucciones podrán actualizarse a medida que se descubran nuevas utilidades y procedimientos.

Precaución

El uso inadecuado de los certificados TLS podría dar lugar a suplantación de identidad.

Sugerencia

Las instrucciones para los certificados de producción válidos se pueden encontrar en la documentación de RHEL. Certificados TLS RHEL8Certificados TLS RHEL9Sistema de certificados RHEL9

Instalación de las dependencias

dnf install nss-tools

Exportación del certificado de desarrollo de ASP.NET Core

Importante

Reemplace ${ProjectDirectory} por el directorio de sus proyectos. Reemplace ${CertificateName} por un nombre que podrá identificar en el futuro.

cd ${ProjectDirectory}
dotnet dev-certs https -ep ${ProjectDirectory}/${CertificateName}.crt --format PEM

Precaución

Si usa Git, agregue el certificado a ${ProjectDirectory}/.gitignore o ${ProjectDirectory}/.git/info/exclude. Vea la documentación de Git para obtener información sobre estos archivos.

Sugerencia

Puede mover su certificado exportado fuera de su repositorio Git y reemplazar las apariciones de ${ProjectDirectory}, en las siguientes instrucciones, por la nueva ubicación.

Importación del certificado de desarrollo de ASP.NET Core

Importante

Reemplace ${UserProfile} por el perfil que piensa usar. No reemplace $HOME, es la variable de entorno en el directorio de usuario.

Exploradores basados en Chromium

certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt
certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt

Mozilla Firefox

certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -A -t "P,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt
certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -A -t "C,," -n ${CertificateName} -i ${ProjectDirectory}/${CertificateName}.crt

Creación de un alias para probar con Curl

Importante

No elimine el certificado exportado si tiene previsto probarlo con curl. Tendrá que crear un alias haciendo referencia a él en el perfil de su $SHELL.

alias curl="curl --cacert ${ProjectDirectory}/${CertificateName}.crt"

Limpieza de los certificados de desarrollo

certutil -d sql:$HOME/.pki/nssdb -D -n ${CertificateName}
certutil -d sql:$HOME/.mozilla/firefox/${UserProfile}/ -D -n ${CertificateName}
rm ${ProjectDirectory}/${CertificateName}.crt
dotnet dev-certs https --clean

Nota

Quitar el alias de curl que creó anteriormente

SUSE Linux Enterprise Server

Consulte este problema de GitHub

Confiar en el certificado con Fedora 34

Vea:

• Este comentario de GitHub
• Fedora: Uso de certificados de sistema compartidos
• Configure un entorno de desarrollo de .NET en Fedora.

Confiar en el certificado con otras distribuciones

Consulte este problema de GitHub.

Confiar en el certificado HTTPS de Subsistema de Windows para Linux

Las instrucciones siguientes no funcionan para algunas distribuciones de Linux, como Ubuntu 20.04. Para más información, consulte la incidencia de GitHub dotnet/AspNetCore.Docs #23686.

El Subsistema de Windows para Linux (WSL) genera un certificado de desarrollo autofirmado HTTPS, que de forma predeterminada no es de confianza en Windows. La forma más sencilla de hacer que Windows confíe en el certificado de WSL, es configurar WSL para que use el mismo certificado que Windows:

• En Windows, exporte el certificado de desarrollador a un archivo:

  dotnet dev-certs https -ep https.pfx -p $CREDENTIAL_PLACEHOLDER$ --trust
  

  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 <<path-to-pfx>> --password $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 los certificados que no son de confianza

Esta sección proporciona ayuda cuando el certificado de desarrollo de ASP.NET Core HTTPS ha sido instalado y es de confianza, pero sigue teniendo advertencias del navegador de que el certificado no es de confianza. Kestrel usa el certificado de desarrollo de ASP.NET Core HTTPS.

Para reparar el certificado de 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 en la aplicación. Los exploradores almacenan en caché la confianza del certificado.

dotnet dev-certs https --clean Fails

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 que no es 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 o Visual Studio Code.

Windows: certificado que no es de confianza

• Compruebe los certificados en el almacén de certificados. Debería haber un certificado localhost con el nombre descriptivo ASP.NET Core HTTPS development certificate tanto en Current User > Personal > Certificates como en Current User > Trusted root certification authorities > Certificates.
• Quite todos los certificados encontrados de las entidades de certificación raíz personales y de confianza. No quite el certificado de 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 en la aplicación.

OS X: certificado que no es de confianza

• Abra Acceso a Llaveros.
• Seleccione el llavero 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 del llavero 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 en la aplicación.

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

Certificado de Linux que no es de confianza

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

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

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

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

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

Certificado SSL de IIS Express usado con Visual Studio

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

La directiva de grupo impide que los certificados autofirmados sean de confianza

En algunos casos, la directiva de grupo puede impedir que los certificados autofirmados sean de confianza. Para más información, consulte este problema de GitHub.

Información adicional

• Configurar ASP.NET Core para trabajar con servidores proxy y equilibradores de carga
• Hospedaje de ASP.NET Core en Linux con Apache: configuración HTTPS
• Hospedaje de ASP.NET Core en Linux con Nginx: configuración HTTPS
• Procedimientos para configurar SSL en IIS
• Configuración de puntos de conexión para el servidor web Kestrel de ASP.NET Core
• Compatibilidad con el explorador HSTS de OWASP