Aplicación de HTTPS en ASP.NET Core
Por David Galvan y Rick Anderson
En este artículo se muestra cómo:
- Requerir HTTPS para todas las solicitudes.
- Redirija todas las solicitudes HTTP a HTTPS.
Ninguna API puede impedir que un cliente envíe datos confidenciales en la primera solicitud.
Advertencia
Proyectos de API
No use RequireHttpsAttribute en las API web que reciben información confidencial. RequireHttpsAttribute
usa códigos de estado HTTP para redirigir exploradores de HTTP a HTTPS. Es posible que los clientes de API no entiendan u obedezcan los redireccionamientos de HTTP a HTTPS. Estos clientes pueden enviar información a través de HTTP. Las API web deberían:
- No escuchar en HTTP.
- Cerrar la conexión con el código de estado 400 (Solicitud incorrecta) y no atender la solicitud.
Para deshabilitar el redireccionamiento HTTP en una API, establezca la variable de entorno ASPNETCORE_URLS
o use la marca de línea de comandos --urls
. Para más información, consulte Uso de varios entornos en ASP.NET Core y 8 maneras de establecer las direcciones URL de una aplicación de ASP.NET Core por Andrew Lock.
Proyectos de HSTS y API
Los proyectos de API predeterminados no incluyen HSTS porque HSTS suele ser una instrucción solo del explorador. Otros autores de llamadas, como las aplicaciones de teléfono o de escritorio, no obedecen la instrucción. Incluso dentro de los exploradores, una sola llamada autenticada a una API a través de HTTP tiene riesgos en redes no seguras. El enfoque seguro consiste en configurar proyectos de API para que solo escuchen y respondan a través de HTTPS.
El redireccionamiento de HTTP a HTTPS provoca ERR_INVALID_REDIRECT en la solicitud de preparación de CORS
Las solicitudes a un punto de conexión 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.
Nota
Las aplicaciones implementadas en una configuración de proxy inverso permiten que el proxy controle la seguridad de conexión (HTTPS). Si el proxy también controla el redireccionamiento HTTPS, no es necesario usar el middleware de redireccionamiento HTTPS. Si el servidor proxy también controla la escritura de encabezados HSTS (por ejemplo, la compatibilidad nativa con HSTS en IIS 10.0 (1709) o posterior), la aplicación no necesitará Middleware de HSTS. Para más información, consulte No participar en HTTPS/HSTS en la creación del proyecto.
UseHttpsRedirection
El siguiente código llama a UseHttpsRedirection en el archivo Program.cs
:
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRazorPages();
var app = builder.Build();
if (!app.Environment.IsDevelopment())
{
app.UseExceptionHandler("/Error");
app.UseHsts();
}
app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();
app.UseAuthorization();
app.MapRazorPages();
app.Run();
El código resaltado anterior:
- Usa el valor predeterminado HttpsRedirectionOptions.RedirectStatusCode (Status307TemporaryRedirect).
- Usa el valor predeterminado HttpsRedirectionOptions.HttpsPort (null) a menos que se invalide mediante la variable de entorno
ASPNETCORE_HTTPS_PORTS
o IServerAddressesFeature.
Se recomienda usar redireccionamientos temporales en lugar de redireccionamientos permanentes. El almacenamiento en caché de vínculos puede producir un comportamiento inestable en los entornos de desarrollo. Si prefiere enviar un código de estado de redirección permanente cuando la aplicación se encuentra en un entorno que no es de desarrollo, consulte la sección Configurar redireccionamientos permanentes en producción. Se recomienda usar HSTS para indicar a los clientes que solo se deben enviar solicitudes de recursos seguras a la aplicación (solo en producción).
Configuración de puerto
Un puerto debe estar disponible para que el middleware redirija una solicitud no segura a HTTPS. Si no hay ningún puerto disponible:
- No se produce el redireccionamiento a HTTPS.
- El middleware registra la advertencia "No se pudo determinar el puerto https para la redirección".
Especifique el puerto HTTPS mediante cualquiera de los métodos siguientes:
Establezca HttpsRedirectionOptions.HttpsPort.
Establezca la
https_port
configuración del host:En la configuración del host.
Estableciendo la variable de entorno
ASPNETCORE_HTTPS_PORTS
.Agregando una entrada de nivel superior en
appsettings.json
:{ "https_port": 443, "Logging": { "LogLevel": { "Default": "Information", "Microsoft.AspNetCore": "Warning" } }, "AllowedHosts": "*" }
Indique un puerto con el esquema seguro mediante la variable de entorno ASPNETCORE_URLS. La variable de entorno configura el servidor. El middleware detecta indirectamente el puerto HTTPS a través de IServerAddressesFeature. Este enfoque no funciona en implementaciones de proxy inverso.
Las plantillas web de ASP.NET Core establecen una dirección URL HTTPS en
Properties/launchsettings.json
para Kestrel y IIS Express.launchsettings.json
solo se usa en la máquina local.Configure un punto de conexión de dirección URL HTTPS para una implementación perimetral orientada al público del servidor Kestrel o HTTP.sys. La aplicación usa solo un puerto HTTPS . El middleware detecta el puerto a través de IServerAddressesFeature.
Nota
Cuando se ejecuta una aplicación en una configuración de proxy inverso, IServerAddressesFeature no está disponible. Establezca el puerto con uno de los otros enfoques descritos en esta sección.
Implementaciones de Edge
Cuando Kestrel o HTTP.sys se usa como servidor perimetral orientado al público, Kestrel o HTTP.sys deben configurarse para escuchar en ambos:
- El puerto seguro al que se redirige el cliente (normalmente, 443 en producción y 5001 en desarrollo).
- El puerto no seguro (normalmente, 80 en producción y 5000 en desarrollo).
El cliente debe tener acceso al puerto no seguro para que la aplicación reciba una solicitud no segura y redirija el cliente al puerto seguro.
Para más información, consulte Configuración del punto de conexión Kestrel o Implementación del servidor web HTTP.sys en JavaScript.NET Core.
Escenarios de implementación
Cualquier firewall entre el cliente y el servidor también debe tener puertos de comunicación abiertos para el tráfico.
Si las solicitudes se reenvían en una configuración de proxy inverso, use el Middleware de encabezados reenviados antes de llamar al Middleware de redireccionamiento HTTPS. El Middleware de encabezados reenviados actualiza el Request.Scheme
, usando el encabezado X-Forwarded-Proto
. El middleware permite que los URI de redirección y otras directivas de seguridad funcionen correctamente. Cuando no se usa el Middleware de encabezados reenviados, es posible que la aplicación de back-end no reciba el esquema correcto y termine en un bucle de redireccionamiento. Un mensaje de error de usuario final común es que se han producido demasiadas redirecciones.
Al implementar en Azure App Service, siga las instrucciones de Tutorial: Enlace de un certificado SSL personalizado existente a Azure Web Apps.
Opciones
El siguiente código resaltado llama a AddHttpsRedirection para configurar las opciones del middleware:
using static Microsoft.AspNetCore.Http.StatusCodes;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRazorPages();
builder.Services.AddHsts(options =>
{
options.Preload = true;
options.IncludeSubDomains = true;
options.MaxAge = TimeSpan.FromDays(60);
options.ExcludedHosts.Add("example.com");
options.ExcludedHosts.Add("www.example.com");
});
builder.Services.AddHttpsRedirection(options =>
{
options.RedirectStatusCode = Status307TemporaryRedirect;
options.HttpsPort = 5001;
});
var app = builder.Build();
if (!app.Environment.IsDevelopment())
{
app.UseExceptionHandler("/Error");
app.UseHsts();
}
app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();
app.UseAuthorization();
app.MapRazorPages();
app.Run();
Llamar AddHttpsRedirection
solo es necesario para cambiar los valores de HttpsPort
o RedirectStatusCode
.
El código resaltado anterior:
- Establece HttpsRedirectionOptions.RedirectStatusCode en Status307TemporaryRedirect, que es el valor predeterminado. Use los campos de la clase StatusCodes para las asignaciones a
RedirectStatusCode
. - Establece el puerto HTTPS en 5001.
Configuración de redireccionamientos permanentes en producción
El middleware tiene como valor predeterminado enviar un elemento Status307TemporaryRedirect con todos los redireccionamientos. Si prefiere enviar un código de estado de redirección permanente cuando la aplicación se encuentra en un entorno que no es de desarrollo, encapsule la configuración de opciones de middleware en una comprobación condicional de un entorno que no es de desarrollo.
Al configurar los servicios en Program.cs
:
using static Microsoft.AspNetCore.Http.StatusCodes;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRazorPages();
if (!builder.Environment.IsDevelopment())
{
builder.Services.AddHttpsRedirection(options =>
{
options.RedirectStatusCode = Status308PermanentRedirect;
options.HttpsPort = 443;
});
}
var app = builder.Build();
if (!app.Environment.IsDevelopment())
{
app.UseExceptionHandler("/Error");
app.UseHsts();
}
app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();
app.UseAuthorization();
app.MapRazorPages();
app.Run();
Enfoque alternativo de middleware de redirección HTTPS
Una alternativa al uso de Middleware de redirección HTTPS (UseHttpsRedirection
) es usar Middleware de reescritura de URL (AddRedirectToHttps
). AddRedirectToHttps
también puede establecer el código de estado y el puerto cuando se ejecuta el redireccionamiento. Para más información, consulte Middleware de reescritura de direcciones URL.
Al redirigir a HTTPS sin necesidad de reglas de redirección adicionales, recomendamos usar el Middleware de redirección HTTPS (UseHttpsRedirection
) descrito en este 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 encabezadoStrict-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:
Desactive la casilla Configurar para 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
Advertencia
No cree un certificado de desarrollo en un entorno que se redistribuya, como una imagen de contenedor o una máquina virtual. Si lo hace, puede provocar suplantación de identidad y elevación de privilegios. Para evitarlo, establezca la variable de entorno DOTNET_GENERATE_ASPNET_CERTIFICATE
en false
antes de llamar a la CLI de .NET por primera vez. Esto omitirá la generación automática del certificado de desarrollo de ASP.NET Core durante la experiencia de primera ejecución de la CLI.
Confiar en el certificado HTTPS con Firefox para evitar el error SEC_ERROR_INADEQUATE_KEY_USAGE
El explorador Firefox usa su propio almacén de certificados y, por lo tanto, no confía en los certificados de IIS Express o Kestrel de desarrollador.
Hay dos enfoques para confiar en el certificado HTTPS con Firefox, crear un archivo de directiva o configurar con el explorador FireFox. La configuración con el explorador crea el archivo de directiva, por lo que los dos enfoques son equivalentes.
Creación de un archivo de directiva para confiar en el certificado HTTPS con Firefox
Cree un archivo de directiva (policies.json
) en:
- Windows:
%PROGRAMFILES%\Mozilla Firefox\distribution\
- MacOS:
Firefox.app/Contents/Resources/distribution
- Linux: consulte Confiar en el certificado con Firefox en Linux en este artículo.
Agregue el siguiente JSON en el archivo de directiva de Firefox:
{
"policies": {
"Certificates": {
"ImportEnterpriseRoots": true
}
}
}
El archivo de directiva anterior hace que Firefox confíe en los certificados de confianza en el almacén de certificados de Windows. En la sección siguiente se proporciona un enfoque alternativo para crear el archivo de directiva anterior mediante el explorador Firefox.
Configuración de la confianza del certificado HTTPS mediante el explorador Firefox
Establezca security.enterprise_roots.enabled
= true
usando las siguientes instrucciones:
- Escriba
about:config
en el explorador FireFox. - Seleccione Aceptar el riesgo y Continuar si acepta el riesgo.
- Seleccione Mostrar todos
- Establezca
security.enterprise_roots.enabled
=true
- 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.
Instale OpenSSL 1.1.1h o posterior. Consulte la distribución para obtener instrucciones sobre cómo actualizar OpenSSL.
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
Para exploradores de Chromium en Linux:
Instale
libnss3-tools
para su distribución.Cree o compruebe que la carpeta
$HOME/.pki/nssdb
existe en la máquina.Exporte el certificado con el siguiente comando:
dotnet dev-certs https sudo -E dotnet dev-certs https -ep /usr/local/share/ca-certificates/aspnet/https.crt --format PEM
La ruta de acceso del comando anterior es específica para Ubuntu. Para otras distribuciones, seleccione una ruta de acceso adecuada o use la ruta de acceso para las entidades de certificación (CA).
Ejecute los comandos siguientes:
certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n localhost -i /usr/local/share/ca-certificates/aspnet/https.crt certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n localhost -i /usr/local/share/ca-certificates/aspnet/https.crt
Salga y reinicie el navegador.
Confiar en el certificado con Firefox en Linux
Exporte el certificado con el siguiente comando:
dotnet dev-certs https sudo -E dotnet dev-certs https -ep /usr/local/share/ca-certificates/aspnet/https.crt --format PEM
La ruta de acceso del comando anterior es específica para Ubuntu. Para otras distribuciones, seleccione una ruta de acceso adecuada o use la ruta de acceso para las entidades de certificación (CA).
Cree un archivo JSON en
/usr/lib/firefox/distribution/policies.json
con el siguiente comando:
cat <<EOF | sudo tee /usr/lib/firefox/distribution/policies.json
{
"policies": {
"Certificates": {
"Install": [
"/usr/local/share/ca-certificates/aspnet/https.crt"
]
}
}
}
EOF
Nota: Ubuntu 21.10 Firefox viene como un paquete snap y la carpeta de instalación es /snap/firefox/current/usr/lib/firefox
.
Consulte Configuración de la confianza del certificado HTTPS mediante el explorador Firefox en este artículo para obtener una manera alternativa de configurar el archivo de directiva mediante el explorador.
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 descriptivoASP.NET Core HTTPS development certificate
tanto enCurrent User > Personal > Certificates
como enCurrent 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
Advertencia
Proyectos de API
No use RequireHttpsAttribute en las API web que reciben información confidencial. RequireHttpsAttribute
usa códigos de estado HTTP para redirigir exploradores de HTTP a HTTPS. Es posible que los clientes de API no entiendan u obedezcan los redireccionamientos de HTTP a HTTPS. Estos clientes pueden enviar información a través de HTTP. Las API web deberían:
- No escuchar en HTTP.
- Cerrar la conexión con el código de estado 400 (Solicitud incorrecta) y no atender la solicitud.
Para deshabilitar el redireccionamiento HTTP en una API, establezca la variable de entorno ASPNETCORE_URLS
o use la marca de línea de comandos --urls
. Para más información, consulte Uso de varios entornos en ASP.NET Core y 5 maneras de establecer las direcciones URL de una aplicación de ASP.NET Core por Andrew Lock.
Proyectos de HSTS y API
Los proyectos de API predeterminados no incluyen HSTS porque HSTS suele ser una instrucción solo del explorador. Otros autores de llamadas, como las aplicaciones de teléfono o de escritorio, no obedecen la instrucción. Incluso dentro de los exploradores, una sola llamada autenticada a una API a través de HTTP tiene riesgos en redes no seguras. El enfoque seguro consiste en configurar proyectos de API para que solo escuchen y respondan a través de HTTPS.
Requerir HTTPS
Se recomienda que las aplicaciones web de producción de ASP.NET Core usen:
- El middleware de redireccionamiento de HTTPS (UseHttpsRedirection) redirige las solicitudes HTTP a HTTPS.
- Middleware de HSTS (UseHsts) para enviar encabezados de Protocolo de seguridad de transporte estricta de HTTP (HSTS) a los clientes.
Nota
Las aplicaciones implementadas en una configuración de proxy inverso permiten que el proxy controle la seguridad de conexión (HTTPS). Si el proxy también controla el redireccionamiento HTTPS, no es necesario usar el middleware de redireccionamiento HTTPS. Si el servidor proxy también controla la escritura de encabezados HSTS (por ejemplo, la compatibilidad nativa con HSTS en IIS 10.0 (1709) o posterior), la aplicación no necesitará Middleware de HSTS. Para más información, consulte No participar en HTTPS/HSTS en la creación del proyecto.
UseHttpsRedirection
El siguiente código llama a UseHttpsRedirection
en 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_PORTS
o IServerAddressesFeature.
Se recomienda usar redireccionamientos temporales en lugar de redireccionamientos permanentes. El almacenamiento en caché de vínculos puede producir un comportamiento inestable en los entornos de desarrollo. Si prefiere enviar un código de estado de redirección permanente cuando la aplicación se encuentra en un entorno que no es de desarrollo, consulte la sección Configurar redireccionamientos permanentes en producción. Se recomienda usar HSTS para indicar a los clientes que solo se deben enviar solicitudes de recursos seguras a la aplicación (solo en producción).
Configuración de puerto
Un puerto debe estar disponible para que el middleware redirija una solicitud no segura a HTTPS. Si no hay ningún puerto disponible:
- No se produce el redireccionamiento a HTTPS.
- El middleware registra la advertencia "No se pudo determinar el puerto https para la redirección".
Especifique el puerto HTTPS mediante cualquiera de los métodos siguientes:
Establezca HttpsRedirectionOptions.HttpsPort.
Establezca la
https_port
configuración del host:En la configuración del host.
Estableciendo la variable de entorno
ASPNETCORE_HTTPS_PORTS
.Agregando una entrada de nivel superior en
appsettings.json
:{ "https_port": 443, "Logging": { "LogLevel": { "Default": "Information", "Microsoft": "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.
Nota
Cuando se ejecuta una aplicación en una configuración de proxy inverso, IServerAddressesFeature no está disponible. Establezca el puerto con uno de los otros enfoques descritos en esta sección.
Implementaciones de Edge
Cuando Kestrel o HTTP.sys se usa como servidor perimetral orientado al público, Kestrel o HTTP.sys deben configurarse para escuchar en ambos:
- El puerto seguro al que se redirige el cliente (normalmente, 443 en producción y 5001 en desarrollo).
- El puerto no seguro (normalmente, 80 en producción y 5000 en desarrollo).
El cliente debe tener acceso al puerto no seguro para que la aplicación reciba una solicitud no segura y redirija el cliente al puerto seguro.
Para más información, consulte Configuración del punto de conexión Kestrel o Implementación del servidor web HTTP.sys en JavaScript.NET Core.
Escenarios de implementación
Cualquier firewall entre el cliente y el servidor también debe tener puertos de comunicación abiertos para el tráfico.
Si las solicitudes se reenvían en una configuración de proxy inverso, use el Middleware de encabezados reenviados antes de llamar al Middleware de redireccionamiento HTTPS. El Middleware de encabezados reenviados actualiza el Request.Scheme
, usando el encabezado X-Forwarded-Proto
. El middleware permite que los URI de redirección y otras directivas de seguridad funcionen correctamente. Cuando no se usa el Middleware de encabezados reenviados, es posible que la aplicación de back-end no reciba el esquema correcto y termine en un bucle de redireccionamiento. Un mensaje de error de usuario final común es que se han producido demasiadas redirecciones.
Al implementar en Azure App Service, siga las instrucciones de Tutorial: Enlace de un certificado SSL personalizado existente a Azure Web Apps.
Opciones
El siguiente código resaltado llama a AddHttpsRedirection para configurar las opciones del middleware:
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 encabezadoStrict-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:
Desactive la casilla Configurar para 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
Advertencia
No cree un certificado de desarrollo en un entorno que se redistribuya, como una imagen de contenedor o una máquina virtual. Si lo hace, puede provocar suplantación de identidad y elevación de privilegios. Para evitarlo, establezca la variable de entorno DOTNET_GENERATE_ASPNET_CERTIFICATE
en false
antes de llamar a la CLI de .NET por primera vez. Esto omitirá la generación automática del certificado de desarrollo de ASP.NET Core durante la experiencia de primera ejecución de la CLI.
Confiar en el certificado HTTPS con Firefox para evitar el error SEC_ERROR_INADEQUATE_KEY_USAGE
El explorador Firefox usa su propio almacén de certificados y, por lo tanto, no confía en los certificados de IIS Express o Kestrel de desarrollador.
Hay dos enfoques para confiar en el certificado HTTPS con Firefox, crear un archivo de directiva o configurar con el explorador FireFox. La configuración con el explorador crea el archivo de directiva, por lo que los dos enfoques son equivalentes.
Creación de un archivo de directiva para confiar en el certificado HTTPS con Firefox
Cree un archivo de directiva (policies.json
) en:
- Windows:
%PROGRAMFILES%\Mozilla Firefox\distribution\
- MacOS:
Firefox.app/Contents/Resources/distribution
- Linux: consulte Confiar en el certificado con Firefox en Linux más adelante en este artículo.
Agregue el siguiente JSON en el archivo de directiva de Firefox:
{
"policies": {
"Certificates": {
"ImportEnterpriseRoots": true
}
}
}
El archivo de directiva anterior hace que Firefox confíe en los certificados de confianza en el almacén de certificados de Windows. En la sección siguiente se proporciona un enfoque alternativo para crear el archivo de directiva anterior mediante el explorador Firefox.
Configuración de la confianza del certificado HTTPS mediante el explorador Firefox
Establezca security.enterprise_roots.enabled
= true
usando las siguientes instrucciones:
- Escriba
about:config
en el explorador FireFox. - Seleccione Aceptar el riesgo y Continuar si acepta el riesgo.
- Seleccione Mostrar todos.
- Establezca
security.enterprise_roots.enabled
=true
. - 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
Instale OpenSSL 1.1.1h o posterior. Consulte la distribución para obtener instrucciones sobre cómo actualizar OpenSSL.
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 certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n localhost -i /usr/local/share/ca-certificates/aspnet/https.crt
Salga y reinicie el navegador.
Confiar en el certificado con Firefox en Linux
Exporte el certificado con el siguiente comando:
dotnet dev-certs https sudo -E dotnet dev-certs https -ep /usr/local/share/ca-certificates/aspnet/https.crt --format PEM
La ruta de acceso del comando anterior es específica para Ubuntu. Para otras distribuciones, seleccione una ruta de acceso adecuada o use la ruta de acceso para las entidades de certificación (CA).
Cree un archivo JSON en
/usr/lib/firefox/distribution/policies.json
con el siguiente 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 descriptivoASP.NET Core HTTPS development certificate
tanto enCurrent User > Personal > Certificates
como enCurrent 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.