Aplicación de HTTPS en ASP.NET Core

Proyectos de API

Los proyectos que usan API web deben:

• 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 obtener más información, consulte entornos de ejecución de ASP.NET Core y 8 formas de configurar las direcciones URL de una aplicación ASP.NET Core por Andrew Lock.

Proyectos de HSTS y API

El enfoque seguro para el Protocolo de seguridad de transporte estricto HTTP (HSTS) es configurar proyectos de API para que solo escuchen y respondan a través de HTTPS.

Redireccionamiento HTTP a HTTPS (ERR_INVALID_REDIRECT en la solicitud preparatoria de CORS)

Cuando una solicitud a un punto de conexión mediante HTTP se redirige a HTTPS con el método UseHttpsRedirection, la redirección falla con el error ERR_INVALID_REDIRECT en la solicitud de comprobación previa de CORS.

Los proyectos de API pueden rechazar solicitudes HTTP en lugar de usar el UseHttpsRedirection método para redirigir las solicitudes a HTTPS.

Requerir HTTPS

En el caso de las aplicaciones web ASP.NET Core de producción, se recomienda el siguiente enfoque:

• Para redirigir las solicitudes HTTP a HTTPS, use el middleware de redirección a HTTPS (UseHttpsRedirection).

• Para enviar encabezados HSTS a los clientes, use el middleware de HSTS mediante el método UseHsts .

UseHttpsRedirection

El código siguiente llama al UseHttpsRedirection método 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 la propiedad predeterminada HttpsRedirectionOptions.RedirectStatusCode con el código Status307TemporaryRedirect.
• Usa la propiedad predeterminada HttpsRedirectionOptions.HttpsPort (pasando null), salvo que la sustituya la variable de entorno ASPNETCORE_HTTPS_PORT o IServerAddressesFeature.

El enfoque recomendado es 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 está en un entorno que no es de Development, consulte la sección Configurar redirecciones permanentes en producción. Use 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 del 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_PORT.

  • Al agregar una entrada de nivel superior en el archivo 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 el archivo Properties/launchsettings.json para Kestrel e IIS Express. El archivo 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 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.

Implementaciones perimetrales

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 al 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 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 el middleware de encabezados reenviados, es posible que la aplicación de back-end no reciba el esquema correcto y quede atrapada en un bucle de redirección. Un mensaje de error de usuario final común es que hay demasiados redireccionamientos.

Al implementar en Azure App Service, siga las instrucciones de Enable HTTPS para un dominio personalizado en Azure App Service.

Options

El código resaltado siguiente llama al AddHttpsRedirection método para configurar las opciones de 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 la HttpsRedirectionOptions.RedirectStatusCode propiedad en el Status307TemporaryRedirect código, 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 Status307TemporaryRedirect código con todas las redirecciones. Si prefiere enviar un código de estado de redirección permanente cuando la aplicación se encuentra en un entorno distinto a Development, envuelva la configuración de opciones de middleware en una comprobación condicional para un entorno diferente a Development.

El código siguiente muestra la configuración de servicios en el archivo 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 del middleware de redireccionamiento HTTPS (con el UseHttpsRedirection método ) es usar middleware de reescritura de url (a través del AddRedirectToHttps método ). 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.

Cuando la aplicación se redirige a HTTPS sin necesidad de otras reglas de redirección, la recomendación es usar middleware de redirección HTTPS (UseHttpsRedirection) como se describe en este artículo.

Protocolo de seguridad de transporte estricta de HTTP (HSTS)

Según OWASP, HSTS es una mejora de seguridad opcional que una aplicación web especifica mediante una cabecera 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, hay 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.

En los entornos de producción que implementan HTTPS por primera vez, establezca el valor inicial de la propiedad HstsOptions.MaxAge en un valor bajo mediante uno de los métodos TimeSpan. Establezca el valor en horas a no más de un día, en caso de que necesite revertir la infraestructura de HTTPS a HTTP. Después de confiar en la sostenibilidad de la configuración HTTPS, aumente el valor de HSTS max-age (normalmente, 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 6797 HSTS. Los exploradores web admiten la precarga de sitios HSTS en la instalación nueva. Para obtener más información, vea https://hstspreload.org/.
• Habilita la directiva includeSubDomain, que aplica la política HSTS a los subdominios del host. Para obtener más información, consulte la especificación HSTS de RFC 6797 (sección 6.1.2).
• 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 obtener más información, consulte la directiva max-age en la especificación HSTS RFC 6797 (sección 6.1.1).
• Agrega example.com a la lista de hosts que se van a excluir.

UseHsts excluye los siguientes hosts de bucle invertido:

• localhost: La dirección de retorno IPv4.
• 127.0.0.1: La dirección de loopback de IPv4.
• [::1]: La dirección de retorno IPv6.

Desactivar 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 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 las implementaciones que no requieren estos escenarios, puede desactivar HTTPS/HSTS al crear la aplicación a partir de la plantilla.

Para no participar en HTTPS/HSTS:

dotnet new webapp --no-https

Confiar en el certificado de desarrollo HTTPS de ASP.NET Core

El SDK de .NET incluye un certificado de desarrollo HTTPS. El certificado se instala como parte de la experiencia de primera ejecución. Por ejemplo, el dotnet --info comando 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, se instala el certificado de desarrollo https de ASP.NET Core en el almacén de certificados de usuario local. El certificado está instalado, pero no es de confianza. Para confiar en el certificado, realice el paso puntual para ejecutar la herramienta dotnet dev-certs:

dotnet dev-certs https --trust

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

dotnet dev-certs https --help

Configuración del certificado de desarrollador para Docker

Para configurar el certificado de desarrollador para Docker, consulte GitHub problema dotnet/aspnetcore.docs #6199 - Cómo configurar el certificado de desarrollo al usar Docker en desarrollo.

Consideraciones específicas de Linux

Las distribuciones de Linux difieren sustancialmente en la forma en que marcan los certificados como de confianza.

Se espera que la dotnet dev-certs herramienta sea ampliamente aplicable, pero la compatibilidad oficial solo está disponible para Ubuntu y Fedora. La compatibilidad tiene como objetivo garantizar específicamente la confianza en los exploradores basados en Firefox y Chromium (Microsoft Edge, Chrome y Chromium).

Dependencies

• Para establecer la confianza de OpenSSL, la herramienta openssl debe estar en la ruta.
• Para establecer la confianza del navegador (por ejemplo, en Microsoft Edge o Firefox), la herramienta certutil debe estar en el PATH.

Confianza de OpenSSL

Cuando se confía en un certificado de desarrollo ASP.NET Core, el certificado se exporta a una carpeta del directorio principal del usuario actual. Para que OpenSSL (y los clientes que lo consumen) recojan esta carpeta, necesitas establecer la variable de entorno SSL_CERT_DIR. Puede establecer la variable para una única sesión ejecutando un comando como export SSL_CERT_DIR=$HOME/.aspnet/dev-certs/trust:/usr/lib/ssl/certs (el valor exacto aparece en la salida cuando se pasa --verbose) o añadiéndola a su archivo de configuración, específico de su distribución y del shell (por ejemplo, .profile).

Este enfoque es necesario para que herramientas como curl confíen en el certificado de desarrollo. Como alternativa, puede pasar -CAfile o -CApath a cada invocación individual de curl.

Si la cadena de confianza de OpenSSL queda en un estado incorrecto (por ejemplo, si dotnet dev-certs https --clean no consigue eliminarla), a menudo puede resolver la situación con la herramienta c_rehash.

Overrides

Si usa otro explorador con su propio almacén de Servicios de seguridad de red (NSS), puede usar la DOTNET_DEV_CERTS_NSSDB_PATHS variable de entorno para especificar una lista delimitada por dos puntos de directorios de NSS (por ejemplo, el directorio que contiene cert9.db). A continuación, puede agregar la ubicación del certificado de desarrollo a la lista de la variable .

Si almacena los certificados en los que quiere que OpenSSL confíe en un directorio específico, puede usar la DOTNET_DEV_CERTS_OPENSSL_CERTIFICATE_DIRECTORY variable de entorno para indicar la ubicación del certificado.

Uso de sudo

Al igual que en otras plataformas, los certificados de desarrollo se almacenan y confían por separado para cada usuario.

Si se ejecuta dotnet dev-certs como un usuario diferente (por ejemplo, mediante sudo), ese usuario específico (por ejemplo root) confía en el certificado de desarrollo.

Confiar en el certificado HTTPS en Linux con linux-dev-certs

linux-dev-certs es una herramienta global de .NET compatible con la comunidad de código abierto que proporciona una manera cómoda de crear y confiar en un certificado de desarrollador en Linux. Microsoft no mantiene ni admite la herramienta.

Los siguientes comandos instalan la herramienta y crean un certificado de desarrollador de confianza:

dotnet tool update -g linux-dev-certs
dotnet linux-dev-certs install

Para obtener más información o notificar problemas, consulte el repositorio de GitHub linux-dev-certs.

SUSE Linux Enterprise Server (SLES Linux)

Si su configuración incluye SUSE Linux Enterprise Server, consulte el problema de GitHub dotnet/aspnetcore.docs n.º 28292 - Confiar en el certificado HTTPS en SLES.

Solucionar problemas de certificados (el certificado no es de confianza)

A veces, cuando un certificado de desarrollo HTTPS de ASP.NET Core es instalado y de confianza, el explorador advierte de que el certificado no es de confianza. En las secciones siguientes se proporciona ayuda para solucionar este problema.

Kestrel usa el certificado de desarrollo de ASP.NET Core HTTPS.

Para reparar el certificado IIS Express, consulte Problema de Stack Overflow #20036984 /respuesta #20048613 - ¿Cómo se restaura un certificado SSL de IIS Express que falta?

Todas las plataformas: certificado no de confianza

Para todas las plataformas, intente resolver los problemas de certificado que no son de confianza con los pasos siguientes:

1. Ejecute los comandos siguientes:

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

2. Cierre todas las instancias del explorador abierto y abra la aplicación en una nueva ventana del explorador.

   La caché del explorador almacena si un certificado es de confianza. El proceso de cierre o apertura ayuda a actualizar la configuración de caché del explorador para los certificados.

Los comandos suelen resolver la mayoría de los dotnet dev-certs https problemas de confianza del explorador. Si se produce un error en el dotnet dev-certs https --clean comando y el explorador todavía no confía en el certificado, pruebe las sugerencias específicas de la plataforma en las secciones siguientes.

Docker: certificado que no es de confianza

Si usa Docker, intente resolver el problema con los pasos siguientes:

1. Elimine la carpeta C:\Users{USER}\AppData\Roaming\ASP.NET\Https .

2. Limpie la solución. Elimine las carpetas bin y obj.

3. Reinicie la herramienta de desarrollo. Por ejemplo, Visual Studio o Visual Studio Code.

Windows: certificado que no es de confianza

Si trabaja en Windows, complete los pasos de solución de problemas siguientes:

1. Compruebe los certificados en el almacén de certificados. Busque un certificado localhost con el nombre descriptivo ASP.NET Core HTTPS development certificate en dos carpetas:

   • Certificados personales > del usuario > actual
   • Usuario actual > Entidades de certificación raíz de confianza > Certificados

2. Quite todos los certificados de las entidades de certificación raíz personal y de confianza.

   Important

   No quite el certificado de IIS Express localhost.

3. Ejecute los comandos siguientes:

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

4. Cierre todas las instancias del explorador abierto y abra la aplicación en una nueva ventana del explorador.

OS X: certificado que no es de confianza

Si está trabajando con OS X, intente resolver el problema con los pasos siguientes:

1. Abra Acceso a llaveros y, a continuación, seleccione la cadena de claves Del sistema.

2. Compruebe la presencia de un certificado localhost.

3. Confirme que el certificado muestra el símbolo más (+) en el icono, que indica que el certificado es de confianza para todos los usuarios.

4. Quite el certificado del llavero del sistema.

5. Ejecute los comandos siguientes:

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

6. Cierre todas las instancias del explorador abierto y abra la aplicación en una nueva ventana del explorador.

Para obtener más información sobre cómo solucionar problemas de certificados con Visual Studio, vea GitHub problema dotnet/aspnetcore #16892) - HTTPS Error using IIS Express.

Linux: certificado que no es de confianza

Si ejecuta Linux, siga estos pasos para solucionar problemas del certificado que no es de confianza:

1. Confirme que el certificado que está investigando es el certificado de desarrollador HTTPS de usuario planeado para su uso por parte del Kestrel servidor.

2. 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 el archivo se elimina con el dotnet dev-certs https --clean comando , el archivo se vuelve a generar cuando es necesario con una huella digital diferente.

3. Verifique que la huella digital del certificado exportado coincida ejecutando el siguiente comando:

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

   Si la huella digital del certificado no coincide, investigue las condiciones siguientes:

   • Compruebe si el certificado es antiguo.

   • Compruebe si el certificado es un certificado de desarrollador exportado para el usuario raíz.

     • Si es así, exporte el certificado.

4. Compruebe el certificado de usuario raíz en la carpeta siguiente:

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

Certificado SSL de IIS Express usado con Visual Studio

Para solucionar problemas con el certificado IIS Express, seleccione Repair en el instalador de Visual Studio. Para obtener más información, consulte la incidencia #16892 de dotnet/aspnetcore en GitHub) - Error HTTPS al usar IIS Express.

La directiva de grupo impide confiar en certificados autofirmados

En algunos casos, la directiva de grupo puede impedir que los certificados autofirmados sean de confianza. Para obtener más información, consulte la incidencia n.º 21173 de dotnet/aspnetcore en GitHub - Error al confiar en el certificado HTTPS de desarrollador.

Contenido relacionado

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

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 mediante HTTP que se redirigen a HTTPS mediante UseHttpsRedirection fallan con ERR_INVALID_REDIRECT en la solicitud preparatoria de CORS.

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.

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_PORT 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 está en un entorno que no es de Development, consulte la sección Configurar redirecciones 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 del 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_PORT.

  • 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.

Implementaciones perimetrales

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.

Options

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 distinto a Development, envuelva la configuración de opciones de middleware en una comprobación condicional para un entorno diferente a Development.

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 artículo.

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:

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 dotnet dev-certs:

dotnet dev-certs https --trust

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

dotnet dev-certs https --help

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 artículo.

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. Establecer 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

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

dnf install nss-tools

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

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

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

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

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

Confiar en el certificado con Fedora 34

See:

• 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 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 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 Nginx: configuración HTTPS
• Configurar SSL en IIS
• Configuración de puntos de conexión para el Kestrel servidor web
• Compatibilidad con el explorador HSTS de OWASP

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.

UseHttpsRedirection

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

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_PORT 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 está en un entorno que no es de Development, consulte la sección Configurar redirecciones 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 del 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_PORT.

  • 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 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.

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

• 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.

Implementaciones perimetrales

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.

Options

El siguiente código resaltado llama a AddHttpsRedirection para configurar las opciones del 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 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 distinto a Development, envuelva la configuración de opciones de middleware en una comprobación condicional para un entorno diferente a Development.

Al configurar los 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 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 artículo.

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:

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 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 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 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:

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, la ejecución de dotnet new webapp por primera vez genera una variación de la salida siguiente:

Installed an ASP.NET Core HTTPS development certificate.
To trust the certificate, run 'dotnet dev-certs https --trust'
Learn about HTTPS: https://aka.ms/dotnet-https

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 dotnet dev-certs:

dotnet dev-certs https --trust

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

dotnet dev-certs https --help

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 más adelante en este artículo.

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. Establecer 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

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.
• Exporte el certificado con permisos elevados necesarios para la carpeta ca-certificates mediante el entorno del usuario actual.
• Quite la marca -E para exportar 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

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
  

• 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 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 artículo para obtener una manera alternativa de configurar el archivo de directiva mediante el explorador.

Confiar en el certificado con Fedora 34

Firefox en Fedora

echo 'pref("general.config.filename", "firefox.cfg");
pref("general.config.obscure_value", 0);' > ./autoconfig.js

echo '//Enable policies.json
lockPref("browser.policies.perUserDir", false);' > firefox.cfg

echo "{
    \"policies\": {
        \"Certificates\": {
            \"Install\": [
                \"aspnetcore-localhost-https.crt\"
            ]
        }
    }
}" > policies.json

dotnet dev-certs https -ep localhost.crt --format PEM

sudo mv autoconfig.js /usr/lib64/firefox/
sudo mv firefox.cfg /usr/lib64/firefox/
sudo mv policies.json /usr/lib64/firefox/distribution/
mkdir -p ~/.mozilla/certificates
cp localhost.crt ~/.mozilla/certificates/aspnetcore-localhost-https.crt
rm localhost.crt

Confiar en dotnet-to-dotnet en Fedora

sudo cp localhost.crt /etc/pki/tls/certs/localhost.pem
sudo update-ca-trust
rm localhost.crt

Consulte este comentario de GitHub para más información.

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 de certificados de Windows 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 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 que estén 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 falla

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, Visual Studio Code o Visual Studio para Mac.

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 que estén abiertas. Abra una nueva ventana del explorador en la aplicación. Los exploradores almacenan en caché la confianza del certificado.

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 que estén abiertas. Abra una nueva ventana del explorador en la aplicación. Los exploradores almacenan en caché la confianza del certificado.

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.

Información adicional

• Configurar ASP.NET Core para trabajar con servidores proxy y equilibradores de carga
• Hospedaje de ASP.NET Core en Linux con Nginx: configuración HTTPS
• Configurar SSL en IIS
• Compatibilidad con el explorador HSTS de OWASP
• dotnet dev-certs

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 mediante HTTP que se redirigen a HTTPS mediante UseHttpsRedirection fallan con ERR_INVALID_REDIRECT en la solicitud preparatoria de CORS.

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.

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_PORT 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 está en un entorno que no es de Development, consulte la sección Configurar redirecciones 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 del 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_PORT.

  • 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.

Implementaciones perimetrales

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.

Options

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 distinto a Development, envuelva la configuración de opciones de middleware en una comprobación condicional para un entorno diferente a Development.

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 artículo.

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:

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 dotnet dev-certs:

dotnet dev-certs https --trust

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

dotnet dev-certs https --help

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 artículo.

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. Establecer 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

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

dnf install nss-tools

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

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

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

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

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

Confiar en el certificado con Fedora 34

See:

• 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 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 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 Nginx: configuración HTTPS
• Configurar SSL en IIS
• Configuración de puntos de conexión para el Kestrel servidor web
• Compatibilidad con el explorador HSTS de OWASP

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 mediante HTTP que se redirigen a HTTPS mediante UseHttpsRedirection fallan con ERR_INVALID_REDIRECT en la solicitud preparatoria de CORS.

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.

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_PORT 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 está en un entorno que no es de Development, consulte la sección Configurar redirecciones 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 del 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_PORT.

  • 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.

Implementaciones perimetrales

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.

Options

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 distinto a Development, envuelva la configuración de opciones de middleware en una comprobación condicional para un entorno diferente a Development.

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 artículo.

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:

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 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, se instala el certificado de desarrollo https de ASP.NET Core en el almacén de certificados de usuario local. Se ha instalado el certificado, pero no es de confianza. Para confiar en el certificado, realice el paso puntual para ejecutar la herramienta dotnet dev-certs:

dotnet dev-certs https --trust

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

dotnet dev-certs https --help

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 artículo.

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. Establecer 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.

Confiar en el certificado HTTPS en Linux con linux-dev-certs

linux-dev-certs es una herramienta global de .NET compatible con la comunidad de código abierto que proporciona una manera cómoda de crear y confiar en un certificado de desarrollador en Linux. Microsoft no realiza el mantenimiento ni el soporte técnico de la herramienta.

Los siguientes comandos instalan la herramienta y crean un certificado de desarrollador de confianza:

dotnet tool update -g linux-dev-certs
dotnet linux-dev-certs install

Para obtener más información o notificar problemas, consulte el repositorio de GitHub linux-dev-certs.

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

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

dnf install nss-tools

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

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

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

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

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

Confiar en el certificado con Fedora 34

See:

• 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 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 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 Nginx: configuración HTTPS
• Configurar SSL en IIS
• Configuración de puntos de conexión para el Kestrel servidor web
• Compatibilidad con el explorador HSTS de OWASP