Aplicación de HTTPS en ASP.NET Core

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 se encuentra en un entorno que no es de desarrollo, consulte la sección Configurar redireccionamientos permanentes en producción. Se recomienda usar HSTS para indicar a los clientes que solo se deben enviar solicitudes de recursos seguras a la aplicación (solo en producción).

Configuración de puerto

Un puerto debe estar disponible para que el middleware redirija una solicitud no segura a HTTPS. Si no hay ningún puerto disponible:

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

Especifique el puerto HTTPS mediante cualquiera de los métodos siguientes:

• Establezca HttpsRedirectionOptions.HttpsPort.

• Establezca la https_port configuració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 de Edge

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

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

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

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

Escenarios de implementación

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

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

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

Opciones

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

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

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

builder.Services.AddHttpsRedirection(options =>
{
    options.RedirectStatusCode = Status307TemporaryRedirect;
    options.HttpsPort = 5001;
});

var app = builder.Build();

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

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

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

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

El código resaltado anterior:

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

Configuración de redireccionamientos permanentes en producción

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

Al configurar los servicios en Program.cs:

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

if (!builder.Environment.IsDevelopment())
{
    builder.Services.AddHttpsRedirection(options =>
    {
        options.RedirectStatusCode = Status308PermanentRedirect;
        options.HttpsPort = 443;
    });
}

var app = builder.Build();

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

    app.UseHsts();
}

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

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Enfoque alternativo de middleware de redirección HTTPS

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

Al redirigir a HTTPS sin necesidad de reglas de redirección adicionales, recomendamos usar el Middleware de redirección HTTPS (UseHttpsRedirection) descrito en este 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

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

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

Configuración de un certificado de desarrollador para Docker

Consulte este problema de GitHub.

Consideraciones específicas de Linux

Las distribuciones de Linux difieren considerablemente en cómo marcan los certificados como de confianza. Aunque se espera que dotnet dev-certs sea de aplicación generalizada, solo se admite oficialmente en Ubuntu y Fedora, y su objetivo específico es garantizar la confianza en los exploradores basados en Firefox y Chromium (Edge, Chrome y Chromium).

Dependencias

Para establecer la confianza de OpenSSL, la herramienta openssl debe estar en la ruta de acceso.

Para establecer la confianza del explorador (por ejemplo, en Edge o Firefox), la herramienta certutil debe estar en la ruta de acceso.

Confianza de OpenSSL

Cuando el certificado de desarrollo principal de ASP.NET es de confianza, se exporta a una carpeta en el directorio de home del usuario actual. Para que OpenSSL (y los clientes que lo consuman) seleccione esta carpeta, debes establecer la variable de entorno SSL_CERT_DIR. Puedes hacerlo en una sola sesión ejecutando un comando como export SSL_CERT_DIR=$HOME/.aspnet/dev-certs/trust:/usr/lib/ssl/certs (el valor exacto aparecerá en la salida cuando se pasa --verbose) o agregándolo a tu archivo de configuración (específico de la distribución y del shell) (por ejemplo, .profile).

Esto es necesario para que herramientas como curl confíen en el certificado de desarrollo. (O, como alternativa, puedes pasar -CAfile o -CApath a cada invocación individual de curl).

Ten en cuenta que esto requiere 1.1.1h o posterior o 3.0.0 o posterior, en función de la versión principal que uses.

Si la confianza de OpenSSL entra en un estado incorrecto (por ejemplo, si dotnet dev-certs https --clean no consigue quitarla), con frecuencia es posible arreglar las cosas con la herramienta c_rehash.

Invalidaciones

Si usas otro explorador con su propio almacén de Servicios de seguridad de red (NSS), puedes usar la variable de entorno DOTNET_DEV_CERTS_NSSDB_PATHS para especificar una lista delimitada por dos puntos de directorios NSS (es decir, el directorio que contiene cert9.db) a los que agregar el certificado de desarrollo.

Si almacenas los certificados en los que deseas que OpenSSL confíe en un directorio específico, puedes usar la variable de entorno DOTNET_DEV_CERTS_OPENSSL_CERTIFICATE_DIRECTORY para indicar dónde está.

Uso de sudo

Al igual que en otras plataformas, los certificados de desarrollo se almacenan y son de confianza por separado para cada usuario. Como resultado, si ejecutas dotnet dev-certs como un usuario diferente (por ejemplo mediante sudo), es ese usuario (por ejemplo root) el que confiará 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 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.

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

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

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

Todas las plataformas: certificado no de confianza

Ejecute los comandos siguientes:

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

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

dotnet dev-certs https --clean Fails

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

Docker: certificado que no es de confianza

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

Windows: certificado que no es de confianza

• Compruebe los certificados en el almacén de certificados. Debería haber un certificado localhost con el nombre descriptivo ASP.NET Core HTTPS development certificate tanto en Current User > Personal > Certificates como en Current User > Trusted root certification authorities > Certificates.
• Quite todos los certificados encontrados de las entidades de certificación raíz personales y de confianza. No quite el certificado de IIS Express localhost.
• Ejecute los comandos siguientes:

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

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

OS X: certificado que no es de confianza

• Abra Acceso a Llaveros.
• Seleccione el llavero del Sistema.
• Compruebe la presencia de un certificado localhost.
• Compruebe que contiene un símbolo + en el icono para indicar que es de confianza para todos los usuarios.
• Quite el certificado del llavero del sistema.
• Ejecute los comandos siguientes:

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

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

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

Certificado de Linux que no es de confianza

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

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

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

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

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

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

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

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

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

Certificado SSL de IIS Express usado con Visual Studio

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

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

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

Información adicional

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

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 se encuentra en un entorno que no es de desarrollo, consulte la sección Configurar redireccionamientos permanentes en producción. Se recomienda usar HSTS para indicar a los clientes que solo se deben enviar solicitudes de recursos seguras a la aplicación (solo en producción).

Configuración de puerto

Un puerto debe estar disponible para que el middleware redirija una solicitud no segura a HTTPS. Si no hay ningún puerto disponible:

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

Especifique el puerto HTTPS mediante cualquiera de los métodos siguientes:

• Establezca HttpsRedirectionOptions.HttpsPort.

• Establezca la https_port configuració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 de Edge

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

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

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

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

Escenarios de implementación

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

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

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

Opciones

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

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

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

builder.Services.AddHttpsRedirection(options =>
{
    options.RedirectStatusCode = Status307TemporaryRedirect;
    options.HttpsPort = 5001;
});

var app = builder.Build();

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

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

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

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

El código resaltado anterior:

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

Configuración de redireccionamientos permanentes en producción

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

Al configurar los servicios en Program.cs:

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

if (!builder.Environment.IsDevelopment())
{
    builder.Services.AddHttpsRedirection(options =>
    {
        options.RedirectStatusCode = Status308PermanentRedirect;
        options.HttpsPort = 443;
    });
}

var app = builder.Build();

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

    app.UseHsts();
}

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

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Enfoque alternativo de middleware de redirección HTTPS

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

Al redirigir a HTTPS sin necesidad de reglas de redirección adicionales, recomendamos usar el Middleware de redirección HTTPS (UseHttpsRedirection) descrito en este 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.

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

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

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

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

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

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

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

Configuración de un certificado de desarrollador para Docker

Consulte este problema de GitHub.

Confiar en el certificado HTTPS en Linux

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

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

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

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

2. Ejecute los comandos siguientes:

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

Los comandos anteriores:

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

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

Confiar en el certificado HTTPS en Linux mediante Edge o Chrome

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

Vea:

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

Confiar en el certificado con otras distribuciones

Consulte este problema de GitHub.

Confiar en el certificado HTTPS de Subsistema de Windows para Linux

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

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

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

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

  Donde $CREDENTIAL_PLACEHOLDER$ es una contraseña.

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

  dotnet dev-certs https --clean --import <<path-to-pfx>> --password $CREDENTIAL_PLACEHOLDER$
  

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

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

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

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

Todas las plataformas: certificado no de confianza

Ejecute los comandos siguientes:

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

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

dotnet dev-certs https --clean Fails

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

Docker: certificado que no es de confianza

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

Windows: certificado que no es de confianza

• Compruebe los certificados en el almacén de certificados. Debería haber un certificado localhost con el nombre descriptivo ASP.NET Core HTTPS development certificate tanto en Current User > Personal > Certificates como en Current User > Trusted root certification authorities > Certificates.
• Quite todos los certificados encontrados de las entidades de certificación raíz personales y de confianza. No quite el certificado de IIS Express localhost.
• Ejecute los comandos siguientes:

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

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

OS X: certificado que no es de confianza

• Abra Acceso a Llaveros.
• Seleccione el llavero del Sistema.
• Compruebe la presencia de un certificado localhost.
• Compruebe que contiene un símbolo + en el icono para indicar que es de confianza para todos los usuarios.
• Quite el certificado del llavero del sistema.
• Ejecute los comandos siguientes:

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

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

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

Certificado de Linux que no es de confianza

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

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

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

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

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

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

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

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

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

Certificado SSL de IIS Express usado con Visual Studio

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

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

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

Información adicional

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

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 se encuentra en un entorno que no es de desarrollo, consulte la sección Configurar redireccionamientos permanentes en producción. Se recomienda usar HSTS para indicar a los clientes que solo se deben enviar solicitudes de recursos seguras a la aplicación (solo en producción).

Configuración de puerto

Un puerto debe estar disponible para que el middleware redirija una solicitud no segura a HTTPS. Si no hay ningún puerto disponible:

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

Especifique el puerto HTTPS mediante cualquiera de los métodos siguientes:

• Establezca HttpsRedirectionOptions.HttpsPort.

• Establezca la https_port configuració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 de Edge

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

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

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

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

Escenarios de implementación

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

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

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

Opciones

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

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 que no es de desarrollo, encapsule la configuración de opciones de middleware en una comprobación condicional de un entorno que no es de desarrollo.

Al configurar los servicios en 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.

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

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

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

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

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

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

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

Configuración de un certificado de desarrollador para Docker

Consulte este problema de GitHub.

Confiar en el certificado HTTPS en Linux

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

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

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

• Crea 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
• Procedimientos para 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 se encuentra en un entorno que no es de desarrollo, consulte la sección Configurar redireccionamientos permanentes en producción. Se recomienda usar HSTS para indicar a los clientes que solo se deben enviar solicitudes de recursos seguras a la aplicación (solo en producción).

Configuración de puerto

Un puerto debe estar disponible para que el middleware redirija una solicitud no segura a HTTPS. Si no hay ningún puerto disponible:

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

Especifique el puerto HTTPS mediante cualquiera de los métodos siguientes:

• Establezca HttpsRedirectionOptions.HttpsPort.

• Establezca la https_port configuració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 de Edge

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

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

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

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

Escenarios de implementación

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

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

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

Opciones

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

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

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

builder.Services.AddHttpsRedirection(options =>
{
    options.RedirectStatusCode = Status307TemporaryRedirect;
    options.HttpsPort = 5001;
});

var app = builder.Build();

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

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

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

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

El código resaltado anterior:

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

Configuración de redireccionamientos permanentes en producción

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

Al configurar los servicios en Program.cs:

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

if (!builder.Environment.IsDevelopment())
{
    builder.Services.AddHttpsRedirection(options =>
    {
        options.RedirectStatusCode = Status308PermanentRedirect;
        options.HttpsPort = 443;
    });
}

var app = builder.Build();

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

    app.UseHsts();
}

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

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Enfoque alternativo de middleware de redirección HTTPS

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

Al redirigir a HTTPS sin necesidad de reglas de redirección adicionales, recomendamos usar el Middleware de redirección HTTPS (UseHttpsRedirection) descrito en este 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.

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

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

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

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

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

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

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

Configuración de un certificado de desarrollador para Docker

Consulte este problema de GitHub.

Confiar en el certificado HTTPS en Linux

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

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

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

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

2. Ejecute los comandos siguientes:

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

Los comandos anteriores:

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

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

Confiar en el certificado HTTPS en Linux mediante Edge o Chrome

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

Vea:

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

Confiar en el certificado con otras distribuciones

Consulte este problema de GitHub.

Confiar en el certificado HTTPS de Subsistema de Windows para Linux

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

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

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

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

  Donde $CREDENTIAL_PLACEHOLDER$ es una contraseña.

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

  dotnet dev-certs https --clean --import <<path-to-pfx>> --password $CREDENTIAL_PLACEHOLDER$
  

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

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

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

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

Todas las plataformas: certificado no de confianza

Ejecute los comandos siguientes:

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

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

dotnet dev-certs https --clean Fails

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

Docker: certificado que no es de confianza

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

Windows: certificado que no es de confianza

• Compruebe los certificados en el almacén de certificados. Debería haber un certificado localhost con el nombre descriptivo ASP.NET Core HTTPS development certificate tanto en Current User > Personal > Certificates como en Current User > Trusted root certification authorities > Certificates.
• Quite todos los certificados encontrados de las entidades de certificación raíz personales y de confianza. No quite el certificado de IIS Express localhost.
• Ejecute los comandos siguientes:

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

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

OS X: certificado que no es de confianza

• Abra Acceso a Llaveros.
• Seleccione el llavero del Sistema.
• Compruebe la presencia de un certificado localhost.
• Compruebe que contiene un símbolo + en el icono para indicar que es de confianza para todos los usuarios.
• Quite el certificado del llavero del sistema.
• Ejecute los comandos siguientes:

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

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

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

Certificado de Linux que no es de confianza

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

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

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

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

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

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

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

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

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

Certificado SSL de IIS Express usado con Visual Studio

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

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

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

Información adicional

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

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 se encuentra en un entorno que no es de desarrollo, consulte la sección Configurar redireccionamientos permanentes en producción. Se recomienda usar HSTS para indicar a los clientes que solo se deben enviar solicitudes de recursos seguras a la aplicación (solo en producción).

Configuración de puerto

Un puerto debe estar disponible para que el middleware redirija una solicitud no segura a HTTPS. Si no hay ningún puerto disponible:

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

Especifique el puerto HTTPS mediante cualquiera de los métodos siguientes:

• Establezca HttpsRedirectionOptions.HttpsPort.

• Establezca la https_port configuració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 de Edge

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

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

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

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

Escenarios de implementación

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

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

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

Opciones

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

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

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

builder.Services.AddHttpsRedirection(options =>
{
    options.RedirectStatusCode = Status307TemporaryRedirect;
    options.HttpsPort = 5001;
});

var app = builder.Build();

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

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

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

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

El código resaltado anterior:

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

Configuración de redireccionamientos permanentes en producción

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

Al configurar los servicios en Program.cs:

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

if (!builder.Environment.IsDevelopment())
{
    builder.Services.AddHttpsRedirection(options =>
    {
        options.RedirectStatusCode = Status308PermanentRedirect;
        options.HttpsPort = 443;
    });
}

var app = builder.Build();

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

    app.UseHsts();
}

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

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Enfoque alternativo de middleware de redirección HTTPS

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

Al redirigir a HTTPS sin necesidad de reglas de redirección adicionales, recomendamos usar el Middleware de redirección HTTPS (UseHttpsRedirection) descrito en este 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.

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

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

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

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

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

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

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

Configuración de un certificado de desarrollador para Docker

Consulte este problema de GitHub.

Confiar en el certificado HTTPS en Linux

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

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

Vea:

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

Confiar en el certificado con otras distribuciones

Consulte este problema de GitHub.

Confiar en el certificado HTTPS de Subsistema de Windows para Linux

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

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

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

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

  Donde $CREDENTIAL_PLACEHOLDER$ es una contraseña.

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

  dotnet dev-certs https --clean --import <<path-to-pfx>> --password $CREDENTIAL_PLACEHOLDER$
  

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

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

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

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

Todas las plataformas: certificado no de confianza

Ejecute los comandos siguientes:

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

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

dotnet dev-certs https --clean Fails

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

Docker: certificado que no es de confianza

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

Windows: certificado que no es de confianza

• Compruebe los certificados en el almacén de certificados. Debería haber un certificado localhost con el nombre descriptivo ASP.NET Core HTTPS development certificate tanto en Current User > Personal > Certificates como en Current User > Trusted root certification authorities > Certificates.
• Quite todos los certificados encontrados de las entidades de certificación raíz personales y de confianza. No quite el certificado de IIS Express localhost.
• Ejecute los comandos siguientes:

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

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

OS X: certificado que no es de confianza

• Abra Acceso a Llaveros.
• Seleccione el llavero del Sistema.
• Compruebe la presencia de un certificado localhost.
• Compruebe que contiene un símbolo + en el icono para indicar que es de confianza para todos los usuarios.
• Quite el certificado del llavero del sistema.
• Ejecute los comandos siguientes:

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

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

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

Certificado de Linux que no es de confianza

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

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

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

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

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

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

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

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

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

Certificado SSL de IIS Express usado con Visual Studio

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

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

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

Información adicional

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