Forçar HTTPS no ASP.NET Core

Projetos API

Projetos que utilizam APIs Web devem ou:

• Não escutar em HTTP.
• Feche a conexão com o código de status 400 (Solicitação incorreta) e não atenda a solicitação.

Para desabilitar o redirecionamento HTTP em uma API, defina a variável de ambiente ASPNETCORE_URLS ou use o sinalizador de linha de comando --urls. Para obter mais informações, consulte ASP.NET ambientes de tempo de execução Core e 8 maneiras de definir as URLs para um aplicativo ASP.NET Core de Andrew Lock.

Projetos HSTS e API

A abordagem segura para o HTTP Strict Transport Security Protocol (HSTS) é configurar projetos API para apenas ouvirem e responderem via HTTPS.

Redirecionamento HTTP para HTTPS (ERR_INVALID_REDIRECT no pedido de pré-voo do CORS)

Quando um pedido para um endpoint que utiliza HTTP é redirecionado para HTTPS com o método UseHttpsRedirection, o redirecionamento falha com o erro ERR_INVALID_REDIRECT no pedido de preflight do CORS.

Projetos de API podem rejeitar pedidos HTTP em vez de usar o UseHttpsRedirection método para redirecionar pedidos para HTTPS.

Exigir HTTPS

Para aplicações web ASP.NET Core de produção, recomenda-se a seguinte abordagem:

• Para redirecionar pedidos HTTP para HTTPS, use o middleware de redirecionamento de HTTPS (UseHttpsRedirection).

• Para enviar cabeçalhos HSTS aos clientes, utilize o HSTS Middleware através do método UseHsts .

UseHttpsRedirection

O seguinte código chama o UseHttpsRedirection método no ficheiro 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();

O código destacado anterior:

• Utiliza a propriedade predefinida HttpsRedirectionOptions.RedirectStatusCode com o código Status307TemporaryRedirect.
• Utiliza a propriedade predefinida HttpsRedirectionOptions.HttpsPort (ao passar null), salvo substituição pela variável de ambiente ASPNETCORE_HTTPS_PORT ou por IServerAddressesFeature.

A abordagem recomendada é usar redirecionamentos temporários em vez de redirecionamentos permanentes. O cache de link pode causar um comportamento instável em ambientes de desenvolvimento. Se preferir enviar um código de estado de redirecionamento permanente quando a aplicação está num ambiente não-ambienteDevelopment , consulte a secção Configurar redirecionamentos permanentes em produção . Use o HSTS para sinalizar aos clientes que apenas pedidos de recursos seguros devem ser enviados para a aplicação (apenas em produção).

Configuração da porta

Uma porta deve estar disponível para que o middleware redirecione uma solicitação insegura para HTTPS. Se nenhuma porta estiver disponível:

• O redirecionamento para HTTPS não ocorre.
• O middleware regista o aviso Não foi possível determinar a porta HTTPS para o redirecionamento.

Especifique a porta HTTPS utilizando qualquer uma das seguintes abordagens:

• Defina HttpsRedirectionOptions.HttpsPort.

• Defina a configuração de host https_port:

  • Na configuração do host.

  • Definindo a variável de ambiente ASPNETCORE_HTTPS_PORT.

  • Ao adicionar uma entrada de nível superior no ficheiro appsettings.json:

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

• Indique uma porta com o esquema seguro usando a variável de ambiente ASPNETCORE_URLS. A variável de ambiente configura o servidor. O middleware descobre indiretamente a porta HTTPS via IServerAddressesFeature. Essa abordagem não funciona em implementações de proxy reverso.

• Os modelos web ASP.NET Core definem uma URL HTTPS no ficheiro Properties/launchsettings.json tanto para Kestrel como para IIS Express. O ficheirolaunchsettings.json é usado apenas na máquina local.

• Configure um endpoint de URL HTTPS para uma implantação periférica voltada para uso público de um servidor Kestrel ou servidor HTTP.sys. Apenas uma porta HTTPS é usada pelo aplicativo. O middleware descobre a porta via IServerAddressesFeature.

Implantações de borda

Quando Kestrel ou HTTP.sys é usado como um servidor de borda voltado para o público, Kestrel ou HTTP.sys devem ser configurados para escutar em ambos:

• A porta segura para onde o cliente é redirecionado (normalmente, 443 em produção e 5001 em desenvolvimento).
• O porto inseguro (normalmente, 80 em produção e 5000 em desenvolvimento).

A porta insegura deve ser acessível pelo cliente para que a aplicação receba um pedido inseguro e redirecione o cliente para a porta segura.

Para obter mais informações, consulte a Kestrel ou a implementação do servidor Web HTTP.sys no ASP.NET Core.

Cenários de implementação

Qualquer firewall entre o cliente e o servidor também deve ter portas de comunicação abertas para tráfego.

Se as solicitações forem encaminhadas numa configuração de proxy reverso, use Middleware de Encaminhamento de Cabeçalhos antes de chamar o Middleware de Redirecionamento HTTPS. O Middleware de Cabeçalhos Reencaminhados atualiza o Request.Scheme utilizando o cabeçalho X-Forwarded-Proto. O middleware permite redirecionar URIs e outras políticas de segurança para funcionar corretamente. Quando o Middleware de Cabeçalhos Encaminhados não é utilizado, a aplicação de back-end poderá não receber o esquema correto e entrar num ciclo de redirecionamento. Uma mensagem de erro comum do utilizador final é que há demasiados redirecionamentos.

Ao implementar para Serviço de Aplicações do Azure, siga as orientações em Ative HTTPS para um domínio personalizado em Serviço de Aplicações do Azure.

Opções

O seguinte código destacado chama o AddHttpsRedirection método para configurar opções de middleware:

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

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

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

var app = builder.Build();

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

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

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Chamar AddHttpsRedirection só é necessário para alterar os valores de HttpsPort ou RedirectStatusCode.

O código destacado anterior:

• Define a HttpsRedirectionOptions.RedirectStatusCode propriedade para o Status307TemporaryRedirect código, que é o valor padrão. Use os campos da classe StatusCodes para atribuições a RedirectStatusCode.
• Define a porta HTTPS como 5001.

Configurar redirecionamentos permanentes na produção

O middleware envia por defeito um Status307TemporaryRedirect código com todos os redirecionamentos. Se preferires enviar um código de estado de redirecionamento permanente quando a aplicação não está num ambienteDevelopment, envolve a configuração das opções do middleware numa verificação condicional de um ambiente não-Development.

O seguinte código mostra a configuração dos serviços no ficheiro 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();

Abordagem alternativa para o middleware de redirecionamento HTTPS

Uma alternativa ao uso do Middleware de Redirecionamento HTTPS (com o UseHttpsRedirection método) é usar o Middleware de Reescrita de URL (através do AddRedirectToHttps método). AddRedirectToHttps também pode definir o código de status e a porta quando o redirecionamento é executado. Para obter mais informações, consulte URL Rewriting Middleware.

Quando a aplicação redireciona para HTTPS sem necessidade de outras regras de redirecionamento, a recomendação é usar o HTTPS Redirection Middleware (UseHttpsRedirection) conforme descrito neste artigo.

Protocolo HSTS (Strict Transport Security Protocol) HTTP

Segundo o OWASP, o HSTS é uma melhoria de segurança opt-in especificada por uma aplicação web através de um cabeçalho de resposta. Quando um navegador que suporta HSTS recebe este cabeçalho:

• O navegador armazena a configuração para o domínio que impede o envio de qualquer comunicação por HTTP. O navegador força toda a comunicação através de HTTPS.
• O navegador impede que o usuário use certificados não confiáveis ou inválidos. O navegador desativa os prompts que permitem que um usuário confie temporariamente em tal certificado.

Como o cliente aplica os HSTS, existem algumas limitações:

• O cliente deve suportar HSTS.
• O HSTS requer pelo menos uma solicitação HTTPS bem-sucedida para estabelecer a política HSTS.
• O aplicativo deve verificar cada solicitação HTTP e redirecionar ou rejeitar a solicitação HTTP.

ASP.NET Core implementa HSTS com o método de extensão UseHsts. O código a seguir chama UseHsts quando a aplicação não está no modo de desenvolvimento :

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 não é recomendado no desenvolvimento porque as configurações de HSTS são altamente armazenáveis em cache pelos navegadores. Por padrão, UseHsts exclui o endereço de loopback local.

Em ambientes de produção que estejam a implementar HTTPS pela primeira vez, defina o valor inicial da propriedade HstsOptions.MaxAge para um valor baixo, utilizando um dos métodos TimeSpan. Define o valor de horas para não mais do que um único dia, caso precises de reverter a infraestrutura HTTPS para HTTP. Depois de ter confiança na sustentabilidade da configuração HTTPS, aumente o valor do HSTS max-age (normalmente, um ano).

O seguinte código destacado:

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

• Define o parâmetro preload do cabeçalho Strict-Transport-Security. A pré-carga não faz parte da especificação RFC 6797 HSTS. Os navegadores web suportam a pré-carga dos sites HSTS numa instalação limpa. Para obter mais informações, consulte https://hstspreload.org/.
• Ativa a diretiva includeSubDomain, que aplica a política HSTS aos subdomínios do host. Para mais informações, consulte a especificação HSTS da RFC 6797 (Secção 6.1.2).
• Define explicitamente o parâmetro max-age do cabeçalho Strict-Transport-Security para 60 dias. Se não estiver definido, o valor por defeito é 30 dias. Para mais informações, consulte a max-age diretiva na especificação do RFC 6797 HSTS (Secção 6.1.1).
• Adiciona example.com à lista de anfitriões a excluir.

UseHsts exclui os seguintes hosts de loopback:

• localhost: O endereço de loopback IPv4.
• 127.0.0.1: O endereço de loopback IPv4.
• [::1]: O endereço de loopback IPv6.

Optar por não usar HTTPS/HSTS na criação do projeto

Em alguns cenários de serviços de backend em que a segurança da conexão é assegurada no perímetro público da rede, não é necessário configurar a segurança da conexão em cada nó. Os aplicativos Web gerados a partir dos modelos no Visual Studio ou do comando dotnet new habilitam redirecionamento HTTPS e HSTS. Para implementações que não requerem estes cenários, pode optar por não usar HTTPS/HSTS quando a aplicação for criada a partir do modelo.

Para optar por não participar no HTTPS/HSTS:

dotnet new webapp --no-https

Confie no certificado de desenvolvimento HTTPS do ASP.NET Core

O SDK .NET inclui um certificado de desenvolvimento HTTPS. O certificado é instalado como parte da experiência de utilização inicial. Por exemplo, o dotnet --info comando produz uma variação da seguinte saída:

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.

A instalação do SDK do .NET instala o certificado de desenvolvimento HTTPS do ASP.NET Core no repositório de certificados do usuário local. O certificado está instalado, mas não é de confiança. Para confiar no certificado, execute a etapa única para executar a ferramenta dotnet dev-certs:

dotnet dev-certs https --trust

O comando a seguir fornece ajuda sobre a ferramenta dotnet dev-certs:

dotnet dev-certs https --help

Configurar certificado de programador para o Docker

Para configurar o certificado de programador para o Docker, veja GitHub dotnet/aspnetcore.docs edição #6199 - Como configurar o certificado de desenvolvimento ao usar o Docker em desenvolvimento.

Considerações específicas do Linux

As distribuições Linux diferem substancialmente na forma como marcam os certificados como confiáveis.

Espera-se que a dotnet dev-certs ferramenta seja amplamente aplicável, mas o suporte oficial está disponível apenas para Ubuntu e Fedora. O suporte visa especificamente garantir a confiança nos navegadores baseados em Firefox e Chromium (Microsoft Edge, Chrome e Chromium).

Dependencies

• Para estabelecer a confiança do OpenSSL, a ferramenta openssl deve estar no PATH.
• Para estabelecer a confiança do navegador (por exemplo, no Microsoft Edge ou no Firefox), a ferramenta certutil tem de estar na variável PATH.

Confiança OpenSSL

Quando um certificado de desenvolvimento ASP.NET Core é confiável, o certificado é exportado para uma pasta no diretório pessoal do utilizador atual. Para que OpenSSL (e os clientes que a consomem) peguem essa pasta, você precisa definir a variável de ambiente SSL_CERT_DIR. Podes definir a variável numa única sessão executando um comando como export SSL_CERT_DIR=$HOME/.aspnet/dev-certs/trust:/usr/lib/ssl/certs (o valor exato está na saída quando --verbose é passado) ou adicionando-o ao teu ficheiro de configuração (específico da distribuição e shell) (por exemplo , .profile).

Esta abordagem é necessária para fazer com que ferramentas como curl confiem no certificado de desenvolvimento. Alternativamente, podes passar -CAfile ou -CApath para cada invocação individual curl .

Se a cadeia de confiança do OpenSSL ficar num estado incorreto (por exemplo, se dotnet dev-certs https --clean não a remover), muitas vezes pode resolver a situação com a ferramenta c_rehash.

Overrides

Se estiver a usar outro navegador com o seu próprio repositório NSS (Network Security Services), pode usar a variável de ambiente DOTNET_DEV_CERTS_NSSDB_PATHS para especificar uma lista de diretórios NSS delimitada por dois-pontos (por exemplo, o diretório que contenha cert9.db). Pode então adicionar a localização do certificado de desenvolvimento à lista na variável.

Se armazenar os certificados em que quer que a OpenSSL confie num diretório específico, pode usar a DOTNET_DEV_CERTS_OPENSSL_CERTIFICATE_DIRECTORY variável ambiente para indicar a localização do certificado.

Usando sudo

Como em outras plataformas, os certificados de desenvolvimento são armazenados e confiáveis separadamente para cada usuário.

Se correr dotnet dev-certs como um utilizador diferente (por exemplo, usando sudo), então esse utilizador específico (por exemplo root) confia no certificado de desenvolvimento.

Confie no certificado HTTPS no Linux com linux-dev-certs

linux-dev-certs é uma ferramenta global .NET de código aberto e suportada pela comunidade que fornece uma maneira conveniente de criar e confiar em um certificado de desenvolvedor no Linux. A Microsoft não mantém nem suporta a ferramenta.

Os comandos a seguir instalam a ferramenta e criam um certificado de desenvolvedor confiável:

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

Para obter mais informações ou relatar problemas, consulte o repositório GitHub linux-dev-certs.

SUSE Linux Enterprise Server (SLES Linux)

Se a sua configuração incluir o SUSE Linux Enterprise Server, consulte o problema #28292 do GitHub dotnet/aspnetcore.docs - Confiar no certificado HTTPS no SLES.

Resolver problemas com certificados (certificado não confiável)

Por vezes, quando um certificado de desenvolvimento ASP.NET Core HTTPS é instalado e confiável, o navegador avisa que o certificado não é confiável. As secções seguintes fornecem ajuda para resolver este problema.

O certificado de desenvolvimento HTTPS ASP.NET Core é usado pelo Kestrel.

Para reparar o certificado IIS Express, veja Stack Overflow issue #20036984 / resposta #20048613 - Como posso restaurar um certificado SSL IIS Express em falta?

Todas as plataformas - certificado não confiável

Para todas as plataformas, tente resolver os problemas de certificados não confiáveis com os seguintes passos:

1. Execute os seguintes comandos:

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

2. Fecha todas as instâncias abertas do navegador e abre a aplicação numa nova janela do navegador.

   A cache do navegador armazena se um certificado é confiável. O processo de fechar/abrir ajuda a atualizar as definições de cache do navegador para os certificados.

Os dotnet dev-certs https comandos normalmente resolvem a maioria dos problemas de confiança do navegador. Se o dotnet dev-certs https --clean comando falhar e o navegador continuar sem confiar no certificado, experimente as sugestões específicas da plataforma nas secções seguintes.

Docker - certificado não confiável

Se estiveres a usar Docker, tenta resolver o problema com os seguintes passos:

1. Eliminar a pasta C:\Users{USER}\AppData\Roaming\ASP.NET\Https.

2. Limpe a solução. Exclua os pastas dos compartimentos , e os pastas obj ,.

3. Reinicie a ferramenta de desenvolvimento. Por exemplo, Visual Studio ou Visual Studio Code.

Windows - certificado não confiável

Se estiver a trabalhar no Windows, complete os seguintes passos de resolução de problemas:

1. Verifique os certificados no repositório de certificados. Procure um certificado localhost com o nome amigável ASP.NET Core HTTPS development certificate em duas pastas:

   • Certificados Pessoais > de Utilizadores > Atuais
   • Utilizador atual > Autoridades de certificação de raiz fidedignas > Certificados

2. Remova todos os certificados das autoridades de certificação Pessoal e das autoridades de certificação de raiz fidedignas.

   Important

   Não remova o certificado localhost do IIS Express.

3. Execute os seguintes comandos:

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

4. Fecha todas as instâncias abertas do navegador e abre a aplicação numa nova janela do navegador.

OS X - certificado não confiável

Se estiver a trabalhar com o OS X, tente resolver o problema com os seguintes passos:

1. Abra o Acesso ao Chaveiro e depois selecione o Chaveiro do Sistema.

2. Verifique a presença de um certificado localhost.

3. Confirme que o certificado mostra o símbolo mais (+) no ícone, que indica que o certificado é confiável para todos os utilizadores.

4. Remova o certificado das chaves do sistema.

5. Execute os seguintes comandos:

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

6. Fecha todas as instâncias abertas do navegador e abre a aplicação numa nova janela do navegador.

Para mais informações sobre a resolução de problemas de certificados com Visual Studio, consulte GitHub dotnet/aspnetcore issue #16892) - HTTPS Erro usando IIS Express.

Linux - certificado não confiável

Se estiver a usar Linux, siga estes passos para diagnosticar o certificado não confiável:

1. Confirme que o certificado que está a investigar é o certificado de desenvolvedor HTTPS do utilizador planeado para uso pelo Kestrel servidor.

2. Verifique o certificado de desenvolvedor HTTPS Kestrel padrão do usuário atual no seguinte local:

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

   O ficheiro de certificado Kestrel do desenvolvedor HTTPS é o certificado de impressão digital SHA1. Quando o ficheiro é eliminado com o dotnet dev-certs https --clean comando, o ficheiro é regenerado quando necessário com uma impressão digital diferente.

3. Verifique se a impressão digital do certificado exportado corresponde executando o seguinte comando:

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

   Se a impressão digital do certificado não corresponder, investigue as seguintes condições:

   • Verifica se o certificado é antigo.

   • Verifique se o certificado é um certificado de programador exportado para o utilizador root.

     • Se assim for, exporte o certificado.

4. Verifique o certificado de utilizador root na seguinte pasta:

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

Certificado SSL do IIS Express usado com o Visual Studio

Para resolver problemas com o certificado IIS Express, selecione Reparação no instalador Visual Studio. Para mais informações, consulte GitHub dotnet/aspnetcore edição #16892) - HTTPS Erro usando IIS Express.

A política de grupo impede a confiança em certificados auto-assinados

Em alguns casos, a política de grupo pode impedir que certificados auto-assinados sejam confiáveis. Para mais informações, consulte GitHub dotnet/aspnetcore problema n.º 21173 - Erro ao confiar no certificado de programador HTTPS.

Conteúdo relacionado

• Configurar o ASP.NET Core para trabalhar com servidores proxy e balanceadores de carga
• Hospedar ASP.NET Core no Linux com Nginx: Configuração HTTPS
• Configurar SSL no IIS 7 ou posterior
• Configurar endpoints para Kestrel servidor web
• Suporte a navegadores OWASP HSTS

O redirecionamento HTTP para HTTPS causa ERR_INVALID_REDIRECT na requisição de pré-verificação CORS

As solicitações feitas a um endpoint utilizando HTTP que são redirecionadas para HTTPS por UseHttpsRedirection falham com ERR_INVALID_REDIRECT na requisição preflight do CORS.

Os projetos de API podem rejeitar solicitações HTTP em vez de usar UseHttpsRedirection para redirecionar solicitações para HTTPS.

Exigir HTTPS

Recomendamos que os aplicativos Web de produção ASP.NET Core usem:

• HTTPS Redirection Middleware (UseHttpsRedirection) para redirecionar solicitações HTTP para HTTPS.
• Middleware HSTS (UseHsts) para enviar cabeçalhos HSTS (HTTP Strict Transport Security Protocol) aos clientes.

UseHttpsRedirection

O seguinte código chama UseHttpsRedirection no ficheiro 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();

O código destacado anterior:

• Usa o HttpsRedirectionOptions.RedirectStatusCode padrão (Status307TemporaryRedirect).
• Usa a HttpsRedirectionOptions.HttpsPort padrão (null), a menos que seja substituída pela variável de ambiente ASPNETCORE_HTTPS_PORT ou IServerAddressesFeature.

Recomendamos o uso de redirecionamentos temporários em vez de permanentes. O cache de link pode causar um comportamento instável em ambientes de desenvolvimento. Se preferir enviar um código de estado de redirecionamento permanente quando a aplicação está num ambiente não-ambienteDevelopment , consulte a secção Configurar redirecionamentos permanentes em produção . Recomendamos o uso de HSTS para indicar aos clientes que apenas pedidos de recursos seguros devem ser enviados para a aplicação (apenas em produção).

Configuração da porta

Uma porta deve estar disponível para que o middleware redirecione uma solicitação insegura para HTTPS. Se nenhuma porta estiver disponível:

• O redirecionamento para HTTPS não ocorre.
• O middleware registra o aviso "Falha ao determinar a porta https para redirecionamento".

Especifique a porta HTTPS usando qualquer uma das seguintes abordagens:

• Defina HttpsRedirectionOptions.HttpsPort.

• Defina a configuração de host https_port:

  • Na configuração do host.

  • Definindo a variável de ambiente ASPNETCORE_HTTPS_PORT.

  • Ao adicionar uma entrada de nível superior em appsettings.json:

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

• Indique uma porta com o esquema seguro usando a variável de ambiente ASPNETCORE_URLS. A variável de ambiente configura o servidor. O middleware descobre indiretamente a porta HTTPS via IServerAddressesFeature. Essa abordagem não funciona em implementações de proxy reverso.

• Os modelos da Web ASP.NET Core definem uma URL HTTPS em Properties/launchsettings.json para Kestrel e IIS Express. launchsettings.json é usado apenas na máquina local.

• Configure um endpoint de URL HTTPS para uma implantação periférica voltada para uso público de um servidor Kestrel ou servidor HTTP.sys. Apenas uma porta HTTPS é usada pelo aplicativo. O middleware descobre a porta via IServerAddressesFeature.

Implantações de borda

Quando Kestrel ou HTTP.sys é usado como um servidor de borda voltado para o público, Kestrel ou HTTP.sys devem ser configurados para escutar em ambos:

• A porta segura para onde o cliente é redirecionado (normalmente, 443 em produção e 5001 em desenvolvimento).
• O porto inseguro (normalmente, 80 em produção e 5000 em desenvolvimento).

A porta insegura deve ser acessível pelo cliente para que o aplicativo receba uma solicitação insegura e redirecione o cliente para a porta segura.

Para obter mais informações, consulte a Kestrel ou a implementação do servidor Web HTTP.sys no ASP.NET Core.

Cenários de implementação

Qualquer firewall entre o cliente e o servidor também deve ter portas de comunicação abertas para tráfego.

Se as solicitações forem encaminhadas numa configuração de proxy reverso, use Middleware de Encaminhamento de Cabeçalhos antes de chamar o Middleware de Redirecionamento HTTPS. O Middleware de Cabeçalhos Encaminhados atualiza o Request.Scheme, usando o cabeçalho X-Forwarded-Proto. O middleware permite redirecionar URIs e outras políticas de segurança para funcionar corretamente. Quando o middleware de cabeçalhos encaminhados não é utilizado, a aplicação de back-end pode não receber o esquema correto e acabar num loop de redirecionamento. Uma mensagem de erro comum do usuário final é que ocorreram muitos redirecionamentos.

Ao implantar no Serviço de Aplicativo do Azure, siga as orientações em Tutorial: Vincular um certificado SSL personalizado existente ao Azure Aplicações Web.

Opções

As seguintes linhas de código realçadas invocam o AddHttpsRedirection para configurar opções de middleware:

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

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

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

var app = builder.Build();

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

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

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Chamar AddHttpsRedirection só é necessário para alterar os valores de HttpsPort ou RedirectStatusCode.

O código destacado anterior:

• Define HttpsRedirectionOptions.RedirectStatusCode como Status307TemporaryRedirect, que é o valor padrão. Use os campos da classe StatusCodes para atribuições a RedirectStatusCode.
• Define a porta HTTPS como 5001.

Configurar redirecionamentos permanentes na produção

O middleware assume como padrão o envio de um Status307TemporaryRedirect com todos os redirecionamentos. Se preferires enviar um código de estado de redirecionamento permanente quando a aplicação não está num ambienteDevelopment, envolve a configuração das opções do middleware numa verificação condicional de um ambiente não-Development.

Ao configurar serviços em 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();

Abordagem alternativa para o middleware de redirecionamento HTTPS

Uma alternativa ao uso do HTTPS Redirection Middleware (UseHttpsRedirection) é usar o URL Rewriting Middleware (AddRedirectToHttps). AddRedirectToHttps também pode definir o código de status e a porta quando o redirecionamento é executado. Para obter mais informações, consulte URL Rewriting Middleware.

Ao redirecionar para HTTPS sem a necessidade de regras de redirecionamento adicionais, recomendamos o uso do middleware de redirecionamento HTTPS (UseHttpsRedirection) descrito neste artigo.

Protocolo HSTS (Strict Transport Security Protocol) HTTP

De acordo com OWASP, HTTP Strict Transport Security (HSTS) é um aprimoramento de segurança opcional especificado por um aplicativo Web por meio do uso de um cabeçalho de resposta. Quando um navegador que suporta HSTS recebe este cabeçalho:

• O navegador armazena a configuração para o domínio que impede o envio de qualquer comunicação por HTTP. O navegador força toda a comunicação através de HTTPS.
• O navegador impede que o usuário use certificados não confiáveis ou inválidos. O navegador desativa os prompts que permitem que um usuário confie temporariamente em tal certificado.

Porque HSTS é aplicado pelo cliente, existem algumas limitações:

• O cliente deve suportar HSTS.
• O HSTS requer pelo menos uma solicitação HTTPS bem-sucedida para estabelecer a política HSTS.
• O aplicativo deve verificar cada solicitação HTTP e redirecionar ou rejeitar a solicitação HTTP.

ASP.NET Core implementa HSTS com o método de extensão UseHsts. O código a seguir chama UseHsts quando a aplicação não está no modo de desenvolvimento :

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 não é recomendado no desenvolvimento porque as configurações de HSTS são altamente armazenáveis em cache pelos navegadores. Por padrão, UseHsts exclui o endereço de loopback local.

Para ambientes de produção que estão implementando HTTPS pela primeira vez, defina o HstsOptions.MaxAge inicial para um pequeno valor usando um dos métodos TimeSpan. Defina o valor de horas para não mais do que um único dia, caso precise reverter a infraestrutura HTTPS para HTTP. Depois de confiar na sustentabilidade da configuração HTTPS, aumente o valor do HSTS max-age; um valor normalmente utilizado é de um ano.

O seguinte código destacado:

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

• Define o parâmetro preload do cabeçalho Strict-Transport-Security. O pré-carregamento não faz parte da especificação RFC HSTS , mas é suportado pelos navegadores da Web para pré-carregar sites HSTS em nova instalação. Para obter mais informações, consulte https://hstspreload.org/.
• Permite includeSubDomain, que aplica a política HSTS aos subdomínios do host.
• Define explicitamente o parâmetro max-age do cabeçalho Strict-Transport-Security para 60 dias. Se não estiver definido, o padrão é de 30 dias. Para obter mais informações, consulte a diretiva max-age.
• Adiciona example.com à lista de anfitriões a excluir.

UseHsts exclui os seguintes hosts de loopback:

• localhost : O endereço de retorno IPv4.
• 127.0.0.1 : O endereço de retorno IPv4.
• [::1] : O endereço de retorno IPv6.

Exclusão de HTTPS/HSTS na criação de projetos

Em alguns cenários de serviço de back-end em que a segurança da conexão é tratada na extremidade pública da rede, não é necessário configurar a segurança da conexão em cada nó. Os aplicativos Web gerados a partir dos modelos no Visual Studio ou do comando dotnet new habilitam redirecionamento HTTPS e HSTS. Para implantações que não exigem esses cenários, você pode desativar HTTPS/HSTS quando o aplicativo é criado a partir do modelo.

Para desativar HTTPS/HSTS:

dotnet new webapp --no-https

Confie no certificado de desenvolvimento HTTPS do ASP.NET Core no Windows e macOS

Para o navegador Firefox, consulte a próxima seção.

O SDK do .NET Core inclui um certificado de desenvolvimento HTTPS. O certificado é instalado como parte da experiência de utilização inicial. Por exemplo, dotnet --info produz uma variação da seguinte saída:

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.

A instalação do SDK do .NET Core instala o certificado de desenvolvimento HTTPS do ASP.NET Core no repositório de certificados do usuário local. O certificado foi instalado, mas não é confiável. Para confiar no certificado, execute a etapa única para executar a ferramenta dotnet dev-certs:

dotnet dev-certs https --trust

O comando a seguir fornece ajuda sobre a ferramenta dotnet dev-certs:

dotnet dev-certs https --help

Confirme o certificado HTTPS no Firefox para evitar o erro SEC_ERROR_INADEQUATE_KEY_USAGE

O navegador Firefox usa o seu próprio armazenamento de certificados e, portanto, não confia nos certificados de desenvolvedores do IIS Express ou Kestrel.

Há duas abordagens para confiar no certificado HTTPS com o Firefox, criar um arquivo de política ou configurar com o navegador FireFox. A configuração com o navegador cria o arquivo de política, de modo que as duas abordagens são equivalentes.

Crie um arquivo de política para confiar no certificado HTTPS com o Firefox

Crie um arquivo de política (policies.json) em:

• Windows: %PROGRAMFILES%\Mozilla Firefox\distribution\
• MacOS: Firefox.app/Contents/Resources/distribution
• Linux: Consulte Confiar no certificado no Linux com o Firefox neste artigo.

Adicione o seguinte JSON ao arquivo de política do Firefox:

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

O arquivo de política anterior faz com que o Firefox confie nos certificados confiáveis no repositório de certificados do Windows. A próxima seção fornece uma abordagem alternativa para criar o arquivo de política anterior usando o navegador Firefox.

Configurar a confiança do certificado HTTPS usando o navegador Firefox

Defina security.enterprise_roots.enabled = true usando as seguintes instruções:

1. Digite about:config no navegador FireFox.
2. Selecione Aceitar o risco e continuar se aceitar o risco.
3. Selecione mostrar todas
4. Definir security.enterprise_roots.enabled = true
5. Saia e reinicie o Firefox

Para obter mais informações, consulte Configurando autoridades de certificação (CAs) no Firefox e o arquivo mozilla/policy-templates/README.

Como configurar um certificado de desenvolvedor para o Docker

Veja o sobre este problema do GitHub.

Confiar no certificado HTTPS no Linux

Estabelecer confiança depende especificamente da distribuição e do navegador. As seções a seguir fornecem instruções para algumas distribuições populares e os navegadores Chromium (Edge e Chrome) e para o Firefox.

Ubuntu confia no certificado para comunicação entre serviços

As instruções a seguir não funcionam para algumas versões do Ubuntu, como a 20.04. Para obter mais informações, consulte a Questão do GitHub dotnet/AspNetCore.Docs #23686.

1. Instale OpenSSL 1.1.1h ou posterior. Consulte a sua distribuição para obter instruções sobre como atualizar o OpenSSL.

2. Execute os seguintes comandos:

   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
   

Os comandos anteriores:

• Verifique se o certificado de desenvolvedor do usuário atual foi criado.
• Exporta o certificado com permissões elevadas necessárias para a pasta ca-certificates, usando o ambiente do usuário atual.
• A remoção do sinalizador -E exporta o certificado de usuário raiz, gerando-o se necessário. Cada certificado recém-gerado tem uma impressão digital diferente. Ao executar como root, sudo e -E não são necessários.

O caminho no comando anterior é específico para o Ubuntu. Para outras distribuições, selecione um caminho apropriado ou use o caminho para as Autoridades de Certificação (CAs).

Confiar no certificado HTTPS no Linux usando Edge ou 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

Confie no certificado com o Fedora 34

See:

• Este comentário do GitHub
• Fedora: Usando certificados de sistema compartilhados
• Configure um ambiente de desenvolvimento .NET no Fedora.

Confie no certificado com outras distribuições

Veja o sobre este problema do GitHub.

Confiar no certificado HTTPS do Subsistema Windows para Linux

As instruções a seguir não funcionam para algumas distribuições Linux, como o Ubuntu 20.04. Para obter mais informações, consulte a Questão do GitHub dotnet/AspNetCore.Docs #23686.

O do Subsistema Windows para Linux (WSL) gera um certificado de desenvolvimento autoassinado HTTPS, que por padrão não é confiável no Windows. A maneira mais fácil de fazer com que o Windows confie no certificado WSL é configurar o WSL para usar o mesmo certificado que o Windows:

• No Windows, exporte o certificado de desenvolvedor para um arquivo:

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

  Onde $CREDENTIAL_PLACEHOLDER$ é uma senha.

• Em uma janela WSL, importe o certificado exportado na instância WSL:

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

A abordagem anterior é uma operação única por certificado e por distribuição WSL. É mais fácil do que exportar o certificado repetidamente. Se você atualizar ou regenerar o certificado no Windows, talvez seja necessário executar os comandos anteriores novamente.

Solucionar problemas de certificado, como certificado não confiável

Esta seção fornece ajuda quando o certificado de desenvolvimento ASP.NET Core HTTPS foi instalado e confiável, mas você ainda tem avisos do navegador de que o certificado não é confiável. O certificado de desenvolvimento HTTPS ASP.NET Core é usado pelo Kestrel.

Para reparar o certificado do IIS Express, consulte este problema no Stackoverflow.

Todas as plataformas - certificado não confiável

Execute os seguintes comandos:

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

Feche todas as instâncias do navegador abertas. Abra uma nova janela do navegador para o aplicativo. A confiança do certificado é armazenada em cache pelos navegadores.

O comando "dotnet dev-certs https --clean" falhou

Os comandos anteriores resolvem a maioria dos problemas de confiança do navegador. Se o navegador ainda não estiver confiando no certificado, siga as sugestões específicas da plataforma a seguir.

Docker - certificado não confiável

• Eliminar a pasta C:\Users{USER}\AppData\Roaming\ASP.NET\Https.
• Limpe a solução. Exclua os pastas dos compartimentos , e os pastas obj ,.
• Reinicie a ferramenta de desenvolvimento. Por exemplo, Visual Studio ou Visual Studio Code.

Windows - certificado não confiável

• Verifique os certificados no repositório de certificados. Deve existir um certificado localhost com um nome amigável ASP.NET Core HTTPS development certificate tanto em Current User > Personal > Certificates como em Current User > Trusted root certification authorities > Certificates.
• Remova todos os certificados encontrados das autoridades de certificação raiz Pessoais e Confiáveis. Não remova o certificado localhost do IIS Express.
• Execute os seguintes comandos:

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

Feche todas as instâncias do navegador abertas. Abra uma nova janela do navegador para o aplicativo.

OS X - certificado não confiável

• Abra o KeyChain Access.
• Selecione o Porta-chaves do sistema.
• Verifique a presença de um certificado localhost.
• Verifique se ele contém um símbolo de + no ícone para indicar que é confiável para todos os usuários.
• Remova o certificado das chaves do sistema.
• Execute os seguintes comandos:

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

Feche todas as instâncias do navegador abertas. Abra uma nova janela do navegador para o aplicativo.

Consulte Erro HTTPS usando o IIS Express (dotnet/AspNetCore #16892) para solucionar problemas de certificado com o Visual Studio.

Certificado Linux não confiável

Verifique se o certificado que está sendo configurado para confiança é o certificado de desenvolvedor HTTPS do usuário que será usado pelo servidor Kestrel.

Verifique o certificado de desenvolvedor HTTPS Kestrel padrão do usuário atual no seguinte local:

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

O ficheiro de certificado Kestrel do desenvolvedor HTTPS é o certificado de impressão digital SHA1. Quando o arquivo é excluído via dotnet dev-certs https --clean, ele é regenerado quando necessário com uma impressão digital diferente. Verifique se a impressão digital do certificado exportado corresponde ao seguinte comando:

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

Se o certificado não corresponder, pode ser um dos seguintes:

• Um certificado antigo.
• Exportou-se um certificado de desenvolvedor para o usuário raiz. Para este caso, exporte o certificado.

O certificado de usuário raiz pode ser verificado em:

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

Certificado SSL do IIS Express usado com o Visual Studio

Para corrigir problemas com o certificado do IIS Express, selecione Reparar no instalador do Visual Studio. Para obter mais informações, consulte esta questão do GitHub.

A política de grupo impede que certificados autoassinados sejam confiáveis

Em alguns casos, a política de grupo pode impedir que certificados autoassinados sejam confiáveis. Para obter mais informações, consulte esta questão do GitHub.

Informações adicionais

• Configurar o ASP.NET Core para trabalhar com servidores proxy e balanceadores de carga
• Hospedar ASP.NET Core no Linux com Nginx: Configuração HTTPS
• Como configurar SSL no IIS
• Configurar endpoints para Kestrel servidor web
• Suporte a navegadores OWASP HSTS

Exigir HTTPS

Recomendamos que os aplicativos Web de produção ASP.NET Core usem:

• HTTPS Redirection Middleware (UseHttpsRedirection) para redirecionar solicitações HTTP para HTTPS.
• Middleware HSTS (UseHsts) para enviar cabeçalhos HSTS (HTTP Strict Transport Security Protocol) aos clientes.

UseHttpsRedirection

O seguinte código chama UseHttpsRedirection na classe 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();
    });
}

O código destacado anterior:

• Usa o HttpsRedirectionOptions.RedirectStatusCode padrão (Status307TemporaryRedirect).
• Usa a HttpsRedirectionOptions.HttpsPort padrão (null), a menos que seja substituída pela variável de ambiente ASPNETCORE_HTTPS_PORT ou IServerAddressesFeature.

Recomendamos o uso de redirecionamentos temporários em vez de permanentes. O cache de link pode causar um comportamento instável em ambientes de desenvolvimento. Se preferir enviar um código de estado de redirecionamento permanente quando a aplicação está num ambiente não-ambienteDevelopment , consulte a secção Configurar redirecionamentos permanentes em produção . Recomendamos o uso de HSTS para indicar aos clientes que apenas pedidos de recursos seguros devem ser enviados para a aplicação (apenas em produção).

Configuração da porta

Uma porta deve estar disponível para que o middleware redirecione uma solicitação insegura para HTTPS. Se nenhuma porta estiver disponível:

• O redirecionamento para HTTPS não ocorre.
• O middleware registra o aviso "Falha ao determinar a porta https para redirecionamento".

Especifique a porta HTTPS usando qualquer uma das seguintes abordagens:

• Defina HttpsRedirectionOptions.HttpsPort.

• Defina a configuração de host https_port:

  • Na configuração do host.

  • Definindo a variável de ambiente ASPNETCORE_HTTPS_PORT.

  • Ao adicionar uma entrada de nível superior em appsettings.json:

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

• Indique uma porta com o esquema seguro usando a variável de ambiente ASPNETCORE_URLS. A variável de ambiente configura o servidor. O middleware descobre indiretamente a porta HTTPS via IServerAddressesFeature. Essa abordagem não funciona em implementações de proxy reverso.

• No desenvolvimento, defina uma URL HTTPS em launchsettings.json. Ative o HTTPS ao usar o IIS Express.

• Configure um endpoint de URL HTTPS para uma implantação periférica voltada para uso público de um servidor Kestrel ou servidor HTTP.sys. Apenas uma porta HTTPS é usada pelo aplicativo. O middleware descobre a porta via IServerAddressesFeature.

Implantações de borda

Quando Kestrel ou HTTP.sys é usado como um servidor de borda voltado para o público, Kestrel ou HTTP.sys devem ser configurados para ouvir em ambas as interfaces:

• A porta segura para onde o cliente é redirecionado (normalmente, 443 em produção e 5001 em desenvolvimento).
• O porto inseguro (normalmente, 80 em produção e 5000 em desenvolvimento).

A porta insegura deve ser acessível pelo cliente para que o aplicativo receba uma solicitação insegura e redirecione o cliente para a porta segura.

Para obter mais informações, consulte a Kestrel ou a implementação do servidor Web HTTP.sys no ASP.NET Core.

Cenários de implementação

Qualquer firewall entre o cliente e o servidor também deve ter portas de comunicação abertas para tráfego.

Se as solicitações forem encaminhadas numa configuração de proxy reverso, use Middleware de Encaminhamento de Cabeçalhos antes de chamar o Middleware de Redirecionamento HTTPS. O Middleware de Cabeçalhos Encaminhados atualiza o Request.Scheme, usando o cabeçalho X-Forwarded-Proto. O middleware permite redirecionar URIs e outras políticas de segurança para funcionar corretamente. Quando o middleware de cabeçalhos encaminhados não é utilizado, a aplicação de back-end pode não receber o esquema correto e acabar num loop de redirecionamento. Uma mensagem de erro comum do usuário final é que ocorreram muitos redirecionamentos.

Ao implantar no Serviço de Aplicativo do Azure, siga as orientações em Tutorial: Vincular um certificado SSL personalizado existente ao Azure Aplicações Web.

Opções

As seguintes linhas de código realçadas invocam o AddHttpsRedirection para configurar opções de middleware:

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

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

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

Chamar AddHttpsRedirection só é necessário para alterar os valores de HttpsPort ou RedirectStatusCode.

O código destacado anterior:

• Define HttpsRedirectionOptions.RedirectStatusCode como Status307TemporaryRedirect, que é o valor padrão. Use os campos da classe StatusCodes para atribuições a RedirectStatusCode.
• Define a porta HTTPS como 5001.

Configurar redirecionamentos permanentes na produção

O middleware assume como padrão o envio de um Status307TemporaryRedirect com todos os redirecionamentos. Se preferires enviar um código de estado de redirecionamento permanente quando a aplicação não está num ambienteDevelopment, envolve a configuração das opções do middleware numa verificação condicional de um ambiente não-Development.

Ao configurar serviços em 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;
        });
    }
}

Abordagem alternativa para o middleware de redirecionamento HTTPS

Uma alternativa ao uso do HTTPS Redirection Middleware (UseHttpsRedirection) é usar o URL Rewriting Middleware (AddRedirectToHttps). AddRedirectToHttps também pode definir o código de status e a porta quando o redirecionamento é executado. Para obter mais informações, consulte URL Rewriting Middleware.

Ao redirecionar para HTTPS sem a necessidade de regras de redirecionamento adicionais, recomendamos o uso do middleware de redirecionamento HTTPS (UseHttpsRedirection) descrito neste artigo.

Protocolo HSTS (Strict Transport Security Protocol) HTTP

De acordo com OWASP, HTTP Strict Transport Security (HSTS) é um aprimoramento de segurança opcional especificado por um aplicativo Web por meio do uso de um cabeçalho de resposta. Quando um navegador que suporta HSTS recebe este cabeçalho:

• O navegador armazena a configuração para o domínio que impede o envio de qualquer comunicação por HTTP. O navegador força toda a comunicação através de HTTPS.
• O navegador impede que o usuário use certificados não confiáveis ou inválidos. O navegador desativa os prompts que permitem que um usuário confie temporariamente em tal certificado.

Como o HSTS é aplicado pelo cliente, ele tem algumas limitações:

• O cliente deve suportar HSTS.
• O HSTS requer pelo menos uma solicitação HTTPS bem-sucedida para estabelecer a política HSTS.
• O aplicativo deve verificar cada solicitação HTTP e redirecionar ou rejeitar a solicitação HTTP.

ASP.NET Core implementa HSTS com o método de extensão UseHsts. O código a seguir chama UseHsts quando a aplicação não está no modo de desenvolvimento :

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 não é recomendado no desenvolvimento porque as configurações de HSTS são altamente armazenáveis em cache pelos navegadores. Por padrão, UseHsts exclui o endereço de loopback local.

Para ambientes de produção que estão implementando HTTPS pela primeira vez, defina o HstsOptions.MaxAge inicial para um pequeno valor usando um dos métodos TimeSpan. Defina o valor de horas para não mais do que um único dia, caso precise reverter a infraestrutura HTTPS para HTTP. Depois de confiar na sustentabilidade da configuração HTTPS, aumente o valor do HSTS max-age; um valor normalmente utilizado é de um ano.

O seguinte código:

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;
    });
}

• Define o parâmetro preload do cabeçalho Strict-Transport-Security. O pré-carregamento não faz parte da especificação RFC HSTS , mas é suportado pelos navegadores da Web para pré-carregar sites HSTS em nova instalação. Para obter mais informações, consulte https://hstspreload.org/.
• Permite includeSubDomain, que aplica a política HSTS aos subdomínios do host.
• Define explicitamente o parâmetro max-age do cabeçalho Strict-Transport-Security para 60 dias. Se não estiver definido, o padrão é de 30 dias. Para obter mais informações, consulte a diretiva max-age.
• Adiciona example.com à lista de anfitriões a excluir.

UseHsts exclui os seguintes hosts de loopback:

• localhost : O endereço de retorno IPv4.
• 127.0.0.1 : O endereço de retorno IPv4.
• [::1] : O endereço de retorno IPv6.

Exclusão de HTTPS/HSTS na criação de projetos

Em alguns cenários de serviço de back-end em que a segurança da conexão é tratada na extremidade pública da rede, não é necessário configurar a segurança da conexão em cada nó. Os aplicativos Web gerados a partir dos modelos no Visual Studio ou do comando dotnet new habilitam redirecionamento HTTPS e HSTS. Para implantações que não exigem esses cenários, você pode desativar HTTPS/HSTS quando o aplicativo é criado a partir do modelo.

Para desativar HTTPS/HSTS:

dotnet new webapp --no-https

Confie no certificado de desenvolvimento HTTPS do ASP.NET Core no Windows e macOS

Para o navegador Firefox, consulte a próxima seção.

O SDK do .NET Core inclui um certificado de desenvolvimento HTTPS. O certificado é instalado como parte da experiência de utilização inicial. Por exemplo, executar dotnet new webapp pela primeira vez produz uma variação da seguinte saída:

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

A instalação do SDK do .NET Core instala o certificado de desenvolvimento HTTPS do ASP.NET Core no repositório de certificados do usuário local. O certificado foi instalado, mas não é confiável. Para confiar no certificado, execute a etapa única para executar a ferramenta dotnet dev-certs:

dotnet dev-certs https --trust

O comando a seguir fornece ajuda sobre a ferramenta dotnet dev-certs:

dotnet dev-certs https --help

Confirme o certificado HTTPS no Firefox para evitar o erro SEC_ERROR_INADEQUATE_KEY_USAGE

O navegador Firefox usa o seu próprio armazenamento de certificados e, portanto, não confia nos certificados de desenvolvedores do IIS Express ou Kestrel.

Há duas abordagens para confiar no certificado HTTPS com o Firefox, criar um arquivo de política ou configurar com o navegador FireFox. A configuração com o navegador cria o arquivo de política, de modo que as duas abordagens são equivalentes.

Crie um arquivo de política para confiar no certificado HTTPS com o Firefox

Crie um arquivo de política (policies.json) em:

• Windows: %PROGRAMFILES%\Mozilla Firefox\distribution\
• MacOS: Firefox.app/Contents/Resources/distribution
• Linux: Consulte Confiar no certificado com o Firefox no Linux mais adiante neste artigo.

Adicione o seguinte JSON ao arquivo de política do Firefox:

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

O arquivo de política anterior faz com que o Firefox confie nos certificados confiáveis no repositório de certificados do Windows. A próxima seção fornece uma abordagem alternativa para criar o arquivo de política anterior usando o navegador Firefox.

Configurar a confiança do certificado HTTPS usando o navegador Firefox

Defina security.enterprise_roots.enabled = true usando as seguintes instruções:

1. Digite about:config no navegador FireFox.
2. Selecione Aceitar o risco e continuar se aceitar o risco.
3. Selecione Mostrar todos os.
4. Defina security.enterprise_roots.enabled = true.
5. Saia e reinicie o Firefox.

Para obter mais informações, consulte Configurando autoridades de certificação (CAs) no Firefox e o arquivo mozilla/policy-templates/README.

Como configurar um certificado de desenvolvedor para o Docker

Veja o sobre este problema do GitHub.

Confiar no certificado HTTPS no Linux

Estabelecer confiança depende especificamente da distribuição e do navegador. As seções a seguir fornecem instruções para algumas distribuições populares e os navegadores Chromium (Edge e Chrome) e para o Firefox.

Ubuntu confia no certificado para comunicação entre serviços

1. Instale OpenSSL 1.1.1h ou posterior. Consulte a sua distribuição para obter instruções sobre como atualizar o OpenSSL.

2. Execute os seguintes comandos:

   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
   

Os comandos anteriores:

• Verifique se o certificado de desenvolvedor do usuário atual foi criado.
• Exporte o certificado com as permissões elevadas necessárias para a pasta ca-certificates, usando o ambiente do usuário atual.
• Remova o sinalizador -E para exportar o certificado de usuário raiz, gerando-o se necessário. Cada certificado recém-gerado tem uma impressão digital diferente. Ao executar como root, sudo e -E não são necessários.

O caminho no comando anterior é específico para o Ubuntu. Para outras distribuições, selecione um caminho apropriado ou use o caminho para as Autoridades de Certificação (CAs).

Confiar no certificado HTTPS no Linux usando Edge ou Chrome

Para navegadores chromium no Linux:

• Instale o libnss3-tools para sua distribuição.

• Crie ou verifique se a pasta $HOME/.pki/nssdb existe na máquina.

• Exporte o certificado com o seguinte comando:

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

  O caminho no comando anterior é específico para o Ubuntu. Para outras distribuições, selecione um caminho apropriado ou use o caminho para as Autoridades de Certificação (CAs).

• Execute os seguintes comandos:

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

• Saia e reinicie o navegador.

Confie no certificado com o Firefox no Linux

• Exporte o certificado com o seguinte comando:

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

  O caminho no comando anterior é específico para o Ubuntu. Para outras distribuições, selecione um caminho apropriado ou use o caminho para as Autoridades de Certificação (CAs).

• Crie um arquivo JSON no /usr/lib/firefox/distribution/policies.json com o seguinte conteúdo:

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

Consulte Configurar a confiança do certificado HTTPS usando o navegador Firefox neste artigo para obter uma maneira alternativa de configurar o arquivo de política usando o navegador.

Confie no certificado com o Fedora 34

Firefox no 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

"Confie em 'dotnet-to-dotnet' no Fedora"

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

Consulte este comentário no GitHub para obter mais informações.

Confie no certificado com outras distribuições

Veja o sobre este problema do GitHub.

Confiar no certificado HTTPS do Subsistema Windows para Linux

O Subsistema Windows para Linux (WSL) gera um certificado de desenvolvimento HTTPS autossinado. Para configurar o armazenamento de certificados do Windows para confiar no certificado WSL:

• Exporte o certificado de desenvolvedor para um arquivo no Windows:

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

  Onde $CREDENTIAL_PLACEHOLDER$ é uma senha.

• Em uma janela WSL, importe o certificado exportado na instância WSL:

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

A abordagem anterior é uma operação única por certificado e por distribuição WSL. É mais fácil do que exportar o certificado repetidamente. Se você atualizar ou regenerar o certificado no Windows, talvez seja necessário executar os comandos anteriores novamente.

Solucionar problemas de certificado, como certificado não confiável

Esta seção fornece ajuda quando o certificado de desenvolvimento ASP.NET Core HTTPS foi instalado e confiável, mas você ainda tem avisos do navegador de que o certificado não é confiável. O certificado de desenvolvimento HTTPS ASP.NET Core é usado pelo Kestrel.

Para reparar o certificado do IIS Express, consulte este problema no Stackoverflow.

Todas as plataformas - certificado não confiável

Execute os seguintes comandos:

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

Feche todas as instâncias do navegador que estiverem abertas. Abra uma nova janela do navegador para o aplicativo. A confiança do certificado é armazenada em cache pelos navegadores.

dotnet dev-certs https --clean falha

Os comandos anteriores resolvem a maioria dos problemas de confiança do navegador. Se o navegador ainda não estiver confiando no certificado, siga as sugestões específicas da plataforma a seguir.

Docker - certificado não confiável

• Eliminar a pasta C:\Users{USER}\AppData\Roaming\ASP.NET\Https.
• Limpe a solução. Exclua os pastas dos compartimentos , e os pastas obj ,.
• Reinicie a ferramenta de desenvolvimento. Por exemplo, Visual Studio, Visual Studio Code ou Visual Studio para Mac.

Windows - certificado não confiável

• Verifique os certificados no repositório de certificados. Deve existir um certificado localhost com um nome amigável ASP.NET Core HTTPS development certificate tanto em Current User > Personal > Certificates como em Current User > Trusted root certification authorities > Certificates.
• Remova todos os certificados encontrados das autoridades de certificação raiz Pessoais e Confiáveis. Não remova o certificado localhost do IIS Express.
• Execute os seguintes comandos:

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

Feche todas as instâncias do navegador que estiverem abertas. Abra uma nova janela do navegador para o aplicativo. A confiança do certificado é armazenada em cache pelos navegadores.

OS X - certificado não confiável

• Abra o KeyChain Access.
• Selecione o Porta-chaves do sistema.
• Verifique a presença de um certificado localhost.
• Verifique se ele contém um símbolo de + no ícone para indicar que é confiável para todos os usuários.
• Remova o certificado das chaves do sistema.
• Execute os seguintes comandos:

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

Feche todas as instâncias do navegador que estiverem abertas. Abra uma nova janela do navegador para o aplicativo. A confiança do certificado é armazenada em cache pelos navegadores.

Consulte Erro HTTPS usando o IIS Express (dotnet/AspNetCore #16892) para solucionar problemas de certificado com o Visual Studio.

Certificado Linux não confiável

Verifique se o certificado que está sendo configurado para confiança é o certificado de desenvolvedor HTTPS do usuário que será usado pelo servidor Kestrel.

Verifique o certificado de desenvolvedor HTTPS Kestrel padrão do usuário atual no seguinte local:

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

O ficheiro de certificado Kestrel do desenvolvedor HTTPS é o certificado de impressão digital SHA1. Quando o arquivo é excluído via dotnet dev-certs https --clean, ele é regenerado quando necessário com uma impressão digital diferente. Verifique se a impressão digital do certificado exportado corresponde ao seguinte comando:

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

Se o certificado não corresponder, pode ser um dos seguintes:

• Um certificado antigo.
• Exportou-se um certificado de desenvolvedor para o usuário raiz. Para este caso, exporte o certificado.

O certificado de usuário raiz pode ser verificado em:

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

Certificado SSL do IIS Express usado com o Visual Studio

Para corrigir problemas com o certificado do IIS Express, selecione Reparar no instalador do Visual Studio. Para obter mais informações, consulte esta questão do GitHub.

Informações adicionais

• Configurar o ASP.NET Core para trabalhar com servidores proxy e balanceadores de carga
• Hospedar ASP.NET Core no Linux com Nginx: Configuração HTTPS
• Como configurar SSL no IIS
• Suporte a navegadores OWASP HSTS
• dotnet dev-certs

O redirecionamento HTTP para HTTPS causa ERR_INVALID_REDIRECT na requisição de pré-verificação CORS

As solicitações feitas a um endpoint utilizando HTTP que são redirecionadas para HTTPS por UseHttpsRedirection falham com ERR_INVALID_REDIRECT na requisição preflight do CORS.

Os projetos de API podem rejeitar solicitações HTTP em vez de usar UseHttpsRedirection para redirecionar solicitações para HTTPS.

Exigir HTTPS

Recomendamos que os aplicativos Web de produção ASP.NET Core usem:

• HTTPS Redirection Middleware (UseHttpsRedirection) para redirecionar solicitações HTTP para HTTPS.
• Middleware HSTS (UseHsts) para enviar cabeçalhos HSTS (HTTP Strict Transport Security Protocol) aos clientes.

UseHttpsRedirection

O seguinte código chama UseHttpsRedirection no ficheiro 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();

O código destacado anterior:

• Usa o HttpsRedirectionOptions.RedirectStatusCode padrão (Status307TemporaryRedirect).
• Usa a HttpsRedirectionOptions.HttpsPort padrão (null), a menos que seja substituída pela variável de ambiente ASPNETCORE_HTTPS_PORT ou IServerAddressesFeature.

Recomendamos o uso de redirecionamentos temporários em vez de permanentes. O cache de link pode causar um comportamento instável em ambientes de desenvolvimento. Se preferir enviar um código de estado de redirecionamento permanente quando a aplicação está num ambiente não-ambienteDevelopment , consulte a secção Configurar redirecionamentos permanentes em produção . Recomendamos o uso de HSTS para indicar aos clientes que apenas pedidos de recursos seguros devem ser enviados para a aplicação (apenas em produção).

Configuração da porta

Uma porta deve estar disponível para que o middleware redirecione uma solicitação insegura para HTTPS. Se nenhuma porta estiver disponível:

• O redirecionamento para HTTPS não ocorre.
• O middleware registra o aviso "Falha ao determinar a porta https para redirecionamento".

Especifique a porta HTTPS usando qualquer uma das seguintes abordagens:

• Defina HttpsRedirectionOptions.HttpsPort.

• Defina a configuração de host https_port:

  • Na configuração do host.

  • Definindo a variável de ambiente ASPNETCORE_HTTPS_PORT.

  • Ao adicionar uma entrada de nível superior em appsettings.json:

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

• Indique uma porta com o esquema seguro usando a variável de ambiente ASPNETCORE_URLS. A variável de ambiente configura o servidor. O middleware descobre indiretamente a porta HTTPS via IServerAddressesFeature. Essa abordagem não funciona em implementações de proxy reverso.

• Os modelos da Web ASP.NET Core definem uma URL HTTPS em Properties/launchsettings.json para Kestrel e IIS Express. launchsettings.json é usado apenas na máquina local.

• Configure um endpoint de URL HTTPS para uma implantação periférica voltada para uso público de um servidor Kestrel ou servidor HTTP.sys. Apenas uma porta HTTPS é usada pelo aplicativo. O middleware descobre a porta via IServerAddressesFeature.

Implantações de borda

Quando Kestrel ou HTTP.sys é usado como um servidor de borda voltado para o público, Kestrel ou HTTP.sys devem ser configurados para escutar em ambos:

• A porta segura para onde o cliente é redirecionado (normalmente, 443 em produção e 5001 em desenvolvimento).
• O porto inseguro (normalmente, 80 em produção e 5000 em desenvolvimento).

A porta insegura deve ser acessível pelo cliente para que o aplicativo receba uma solicitação insegura e redirecione o cliente para a porta segura.

Para obter mais informações, consulte a Kestrel ou a implementação do servidor Web HTTP.sys no ASP.NET Core.

Cenários de implementação

Qualquer firewall entre o cliente e o servidor também deve ter portas de comunicação abertas para tráfego.

Se as solicitações forem encaminhadas numa configuração de proxy reverso, use Middleware de Encaminhamento de Cabeçalhos antes de chamar o Middleware de Redirecionamento HTTPS. O Middleware de Cabeçalhos Encaminhados atualiza o Request.Scheme, usando o cabeçalho X-Forwarded-Proto. O middleware permite redirecionar URIs e outras políticas de segurança para funcionar corretamente. Quando o middleware de cabeçalhos encaminhados não é utilizado, a aplicação de back-end pode não receber o esquema correto e acabar num loop de redirecionamento. Uma mensagem de erro comum do usuário final é que ocorreram muitos redirecionamentos.

Ao implantar no Serviço de Aplicativo do Azure, siga as orientações em Tutorial: Vincular um certificado SSL personalizado existente ao Azure Aplicações Web.

Opções

As seguintes linhas de código realçadas invocam o AddHttpsRedirection para configurar opções de middleware:

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

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

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

var app = builder.Build();

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

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

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Chamar AddHttpsRedirection só é necessário para alterar os valores de HttpsPort ou RedirectStatusCode.

O código destacado anterior:

• Define HttpsRedirectionOptions.RedirectStatusCode como Status307TemporaryRedirect, que é o valor padrão. Use os campos da classe StatusCodes para atribuições a RedirectStatusCode.
• Define a porta HTTPS como 5001.

Configurar redirecionamentos permanentes na produção

O middleware assume como padrão o envio de um Status307TemporaryRedirect com todos os redirecionamentos. Se preferires enviar um código de estado de redirecionamento permanente quando a aplicação não está num ambienteDevelopment, envolve a configuração das opções do middleware numa verificação condicional de um ambiente não-Development.

Ao configurar serviços em 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();

Abordagem alternativa para o middleware de redirecionamento HTTPS

Uma alternativa ao uso do HTTPS Redirection Middleware (UseHttpsRedirection) é usar o URL Rewriting Middleware (AddRedirectToHttps). AddRedirectToHttps também pode definir o código de status e a porta quando o redirecionamento é executado. Para obter mais informações, consulte URL Rewriting Middleware.

Ao redirecionar para HTTPS sem a necessidade de regras de redirecionamento adicionais, recomendamos o uso do middleware de redirecionamento HTTPS (UseHttpsRedirection) descrito neste artigo.

Protocolo HSTS (Strict Transport Security Protocol) HTTP

De acordo com OWASP, HTTP Strict Transport Security (HSTS) é um aprimoramento de segurança opcional especificado por um aplicativo Web por meio do uso de um cabeçalho de resposta. Quando um navegador que suporta HSTS recebe este cabeçalho:

• O navegador armazena a configuração para o domínio que impede o envio de qualquer comunicação por HTTP. O navegador força toda a comunicação através de HTTPS.
• O navegador impede que o usuário use certificados não confiáveis ou inválidos. O navegador desativa os prompts que permitem que um usuário confie temporariamente em tal certificado.

Porque HSTS é aplicado pelo cliente, existem algumas limitações:

• O cliente deve suportar HSTS.
• O HSTS requer pelo menos uma solicitação HTTPS bem-sucedida para estabelecer a política HSTS.
• O aplicativo deve verificar cada solicitação HTTP e redirecionar ou rejeitar a solicitação HTTP.

ASP.NET Core implementa HSTS com o método de extensão UseHsts. O código a seguir chama UseHsts quando a aplicação não está no modo de desenvolvimento :

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 não é recomendado no desenvolvimento porque as configurações de HSTS são altamente armazenáveis em cache pelos navegadores. Por padrão, UseHsts exclui o endereço de loopback local.

Para ambientes de produção que estão implementando HTTPS pela primeira vez, defina o HstsOptions.MaxAge inicial para um pequeno valor usando um dos métodos TimeSpan. Defina o valor de horas para não mais do que um único dia, caso precise reverter a infraestrutura HTTPS para HTTP. Depois de confiar na sustentabilidade da configuração HTTPS, aumente o valor do HSTS max-age; um valor normalmente utilizado é de um ano.

O seguinte código destacado:

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

• Define o parâmetro preload do cabeçalho Strict-Transport-Security. O pré-carregamento não faz parte da especificação RFC HSTS , mas é suportado pelos navegadores da Web para pré-carregar sites HSTS em nova instalação. Para obter mais informações, consulte https://hstspreload.org/.
• Permite includeSubDomain, que aplica a política HSTS aos subdomínios do host.
• Define explicitamente o parâmetro max-age do cabeçalho Strict-Transport-Security para 60 dias. Se não estiver definido, o padrão é de 30 dias. Para obter mais informações, consulte a diretiva max-age.
• Adiciona example.com à lista de anfitriões a excluir.

UseHsts exclui os seguintes hosts de loopback:

• localhost : O endereço de retorno IPv4.
• 127.0.0.1 : O endereço de retorno IPv4.
• [::1] : O endereço de retorno IPv6.

Exclusão de HTTPS/HSTS na criação de projetos

Em alguns cenários de serviço de back-end em que a segurança da conexão é tratada na extremidade pública da rede, não é necessário configurar a segurança da conexão em cada nó. Os aplicativos Web gerados a partir dos modelos no Visual Studio ou do comando dotnet new habilitam redirecionamento HTTPS e HSTS. Para implantações que não exigem esses cenários, você pode desativar HTTPS/HSTS quando o aplicativo é criado a partir do modelo.

Para desativar HTTPS/HSTS:

dotnet new webapp --no-https

Confie no certificado de desenvolvimento HTTPS do ASP.NET Core no Windows e macOS

Para o navegador Firefox, consulte a próxima seção.

O SDK do .NET Core inclui um certificado de desenvolvimento HTTPS. O certificado é instalado como parte da experiência de utilização inicial. Por exemplo, dotnet --info produz uma variação da seguinte saída:

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.

A instalação do SDK do .NET Core instala o certificado de desenvolvimento HTTPS do ASP.NET Core no repositório de certificados do usuário local. O certificado foi instalado, mas não é confiável. Para confiar no certificado, execute a etapa única para executar a ferramenta dotnet dev-certs:

dotnet dev-certs https --trust

O comando a seguir fornece ajuda sobre a ferramenta dotnet dev-certs:

dotnet dev-certs https --help

Confirme o certificado HTTPS no Firefox para evitar o erro SEC_ERROR_INADEQUATE_KEY_USAGE

O navegador Firefox usa o seu próprio armazenamento de certificados e, portanto, não confia nos certificados de desenvolvedores do IIS Express ou Kestrel.

Há duas abordagens para confiar no certificado HTTPS com o Firefox, criar um arquivo de política ou configurar com o navegador FireFox. A configuração com o navegador cria o arquivo de política, de modo que as duas abordagens são equivalentes.

Crie um arquivo de política para confiar no certificado HTTPS com o Firefox

Crie um arquivo de política (policies.json) em:

• Windows: %PROGRAMFILES%\Mozilla Firefox\distribution\
• MacOS: Firefox.app/Contents/Resources/distribution
• Linux: Consulte Confiar no certificado no Linux com o Firefox neste artigo.

Adicione o seguinte JSON ao arquivo de política do Firefox:

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

O arquivo de política anterior faz com que o Firefox confie nos certificados confiáveis no repositório de certificados do Windows. A próxima seção fornece uma abordagem alternativa para criar o arquivo de política anterior usando o navegador Firefox.

Configurar a confiança do certificado HTTPS usando o navegador Firefox

Defina security.enterprise_roots.enabled = true usando as seguintes instruções:

1. Digite about:config no navegador FireFox.
2. Selecione Aceitar o risco e continuar se aceitar o risco.
3. Selecione mostrar todas
4. Definir security.enterprise_roots.enabled = true
5. Saia e reinicie o Firefox

Para obter mais informações, consulte Configurando autoridades de certificação (CAs) no Firefox e o arquivo mozilla/policy-templates/README.

Como configurar um certificado de desenvolvedor para o Docker

Veja o sobre este problema do GitHub.

Confiar no certificado HTTPS no Linux

Estabelecer confiança depende especificamente da distribuição e do navegador. As seções a seguir fornecem instruções para algumas distribuições populares e os navegadores Chromium (Edge e Chrome) e para o Firefox.

Ubuntu confia no certificado para comunicação entre serviços

As instruções a seguir não funcionam para algumas versões do Ubuntu, como a 20.04. Para obter mais informações, consulte a Questão do GitHub dotnet/AspNetCore.Docs #23686.

1. Instale OpenSSL 1.1.1h ou posterior. Consulte a sua distribuição para obter instruções sobre como atualizar o OpenSSL.

2. Execute os seguintes comandos:

   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
   

Os comandos anteriores:

• Verifique se o certificado de desenvolvedor do usuário atual foi criado.
• Exporta o certificado com permissões elevadas necessárias para a pasta ca-certificates, usando o ambiente do usuário atual.
• A remoção do sinalizador -E exporta o certificado de usuário raiz, gerando-o se necessário. Cada certificado recém-gerado tem uma impressão digital diferente. Ao executar como root, sudo e -E não são necessários.

O caminho no comando anterior é específico para o Ubuntu. Para outras distribuições, selecione um caminho apropriado ou use o caminho para as Autoridades de Certificação (CAs).

Confiar no certificado HTTPS no Linux usando Edge ou 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

Confie no certificado com o Fedora 34

See:

• Este comentário do GitHub
• Fedora: Usando certificados de sistema compartilhados
• Configure um ambiente de desenvolvimento .NET no Fedora.

Confie no certificado com outras distribuições

Veja o sobre este problema do GitHub.

Confiar no certificado HTTPS do Subsistema Windows para Linux

As instruções a seguir não funcionam para algumas distribuições Linux, como o Ubuntu 20.04. Para obter mais informações, consulte a Questão do GitHub dotnet/AspNetCore.Docs #23686.

O do Subsistema Windows para Linux (WSL) gera um certificado de desenvolvimento autoassinado HTTPS, que por padrão não é confiável no Windows. A maneira mais fácil de fazer com que o Windows confie no certificado WSL é configurar o WSL para usar o mesmo certificado que o Windows:

• No Windows, exporte o certificado de desenvolvedor para um arquivo:

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

  Onde $CREDENTIAL_PLACEHOLDER$ é uma senha.

• Em uma janela WSL, importe o certificado exportado na instância WSL:

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

A abordagem anterior é uma operação única por certificado e por distribuição WSL. É mais fácil do que exportar o certificado repetidamente. Se você atualizar ou regenerar o certificado no Windows, talvez seja necessário executar os comandos anteriores novamente.

Solucionar problemas de certificado, como certificado não confiável

Esta seção fornece ajuda quando o certificado de desenvolvimento ASP.NET Core HTTPS foi instalado e confiável, mas você ainda tem avisos do navegador de que o certificado não é confiável. O certificado de desenvolvimento HTTPS ASP.NET Core é usado pelo Kestrel.

Para reparar o certificado do IIS Express, consulte este problema no Stackoverflow.

Todas as plataformas - certificado não confiável

Execute os seguintes comandos:

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

Feche todas as instâncias do navegador abertas. Abra uma nova janela do navegador para o aplicativo. A confiança do certificado é armazenada em cache pelos navegadores.

O comando "dotnet dev-certs https --clean" falhou

Os comandos anteriores resolvem a maioria dos problemas de confiança do navegador. Se o navegador ainda não estiver confiando no certificado, siga as sugestões específicas da plataforma a seguir.

Docker - certificado não confiável

• Eliminar a pasta C:\Users{USER}\AppData\Roaming\ASP.NET\Https.
• Limpe a solução. Exclua os pastas dos compartimentos , e os pastas obj ,.
• Reinicie a ferramenta de desenvolvimento. Por exemplo, Visual Studio ou Visual Studio Code.

Windows - certificado não confiável

• Verifique os certificados no repositório de certificados. Deve existir um certificado localhost com um nome amigável ASP.NET Core HTTPS development certificate tanto em Current User > Personal > Certificates como em Current User > Trusted root certification authorities > Certificates.
• Remova todos os certificados encontrados das autoridades de certificação raiz Pessoais e Confiáveis. Não remova o certificado localhost do IIS Express.
• Execute os seguintes comandos:

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

Feche todas as instâncias do navegador abertas. Abra uma nova janela do navegador para o aplicativo.

OS X - certificado não confiável

• Abra o KeyChain Access.
• Selecione o Porta-chaves do sistema.
• Verifique a presença de um certificado localhost.
• Verifique se ele contém um símbolo de + no ícone para indicar que é confiável para todos os usuários.
• Remova o certificado das chaves do sistema.
• Execute os seguintes comandos:

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

Feche todas as instâncias do navegador abertas. Abra uma nova janela do navegador para o aplicativo.

Consulte Erro HTTPS usando o IIS Express (dotnet/AspNetCore #16892) para solucionar problemas de certificado com o Visual Studio.

Certificado Linux não confiável

Verifique se o certificado que está sendo configurado para confiança é o certificado de desenvolvedor HTTPS do usuário que será usado pelo servidor Kestrel.

Verifique o certificado de desenvolvedor HTTPS Kestrel padrão do usuário atual no seguinte local:

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

O ficheiro de certificado Kestrel do desenvolvedor HTTPS é o certificado de impressão digital SHA1. Quando o arquivo é excluído via dotnet dev-certs https --clean, ele é regenerado quando necessário com uma impressão digital diferente. Verifique se a impressão digital do certificado exportado corresponde ao seguinte comando:

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

Se o certificado não corresponder, pode ser um dos seguintes:

• Um certificado antigo.
• Exportou-se um certificado de desenvolvedor para o usuário raiz. Para este caso, exporte o certificado.

O certificado de usuário raiz pode ser verificado em:

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

Certificado SSL do IIS Express usado com o Visual Studio

Para corrigir problemas com o certificado do IIS Express, selecione Reparar no instalador do Visual Studio. Para obter mais informações, consulte esta questão do GitHub.

A política de grupo impede que certificados autoassinados sejam confiáveis

Em alguns casos, a política de grupo pode impedir que certificados autoassinados sejam confiáveis. Para obter mais informações, consulte esta questão do GitHub.

Informações adicionais

• Configurar o ASP.NET Core para trabalhar com servidores proxy e balanceadores de carga
• Hospedar ASP.NET Core no Linux com Nginx: Configuração HTTPS
• Como configurar SSL no IIS
• Configurar endpoints para Kestrel servidor web
• Suporte a navegadores OWASP HSTS

O redirecionamento HTTP para HTTPS causa ERR_INVALID_REDIRECT na requisição de pré-verificação CORS

As solicitações feitas a um endpoint utilizando HTTP que são redirecionadas para HTTPS por UseHttpsRedirection falham com ERR_INVALID_REDIRECT na requisição preflight do CORS.

Os projetos de API podem rejeitar solicitações HTTP em vez de usar UseHttpsRedirection para redirecionar solicitações para HTTPS.

Exigir HTTPS

Recomendamos que os aplicativos Web de produção ASP.NET Core usem:

• HTTPS Redirection Middleware (UseHttpsRedirection) para redirecionar solicitações HTTP para HTTPS.
• Middleware HSTS (UseHsts) para enviar cabeçalhos HSTS (HTTP Strict Transport Security Protocol) aos clientes.

UseHttpsRedirection

O seguinte código chama UseHttpsRedirection no ficheiro 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();

O código destacado anterior:

• Usa o HttpsRedirectionOptions.RedirectStatusCode padrão (Status307TemporaryRedirect).
• Usa a HttpsRedirectionOptions.HttpsPort padrão (null), a menos que seja substituída pela variável de ambiente ASPNETCORE_HTTPS_PORT ou IServerAddressesFeature.

Recomendamos o uso de redirecionamentos temporários em vez de permanentes. O cache de link pode causar um comportamento instável em ambientes de desenvolvimento. Se preferir enviar um código de estado de redirecionamento permanente quando a aplicação está num ambiente não-ambienteDevelopment , consulte a secção Configurar redirecionamentos permanentes em produção . Recomendamos o uso de HSTS para indicar aos clientes que apenas pedidos de recursos seguros devem ser enviados para a aplicação (apenas em produção).

Configuração da porta

Uma porta deve estar disponível para que o middleware redirecione uma solicitação insegura para HTTPS. Se nenhuma porta estiver disponível:

• O redirecionamento para HTTPS não ocorre.
• O middleware registra o aviso "Falha ao determinar a porta https para redirecionamento".

Especifique a porta HTTPS usando qualquer uma das seguintes abordagens:

• Defina HttpsRedirectionOptions.HttpsPort.

• Defina a configuração de host https_port:

  • Na configuração do host.

  • Definindo a variável de ambiente ASPNETCORE_HTTPS_PORT.

  • Ao adicionar uma entrada de nível superior em appsettings.json:

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

• Indique uma porta com o esquema seguro usando a variável de ambiente ASPNETCORE_URLS. A variável de ambiente configura o servidor. O middleware descobre indiretamente a porta HTTPS via IServerAddressesFeature. Essa abordagem não funciona em implementações de proxy reverso.

• Os modelos da Web ASP.NET Core definem uma URL HTTPS em Properties/launchsettings.json para Kestrel e IIS Express. launchsettings.json é usado apenas na máquina local.

• Configure um endpoint de URL HTTPS para uma implantação periférica voltada para uso público de um servidor Kestrel ou servidor HTTP.sys. Apenas uma porta HTTPS é usada pelo aplicativo. O middleware descobre a porta via IServerAddressesFeature.

Implantações de borda

Quando Kestrel ou HTTP.sys é usado como um servidor de borda voltado para o público, Kestrel ou HTTP.sys devem ser configurados para escutar em ambos:

• A porta segura para onde o cliente é redirecionado (normalmente, 443 em produção e 5001 em desenvolvimento).
• O porto inseguro (normalmente, 80 em produção e 5000 em desenvolvimento).

A porta insegura deve ser acessível pelo cliente para que o aplicativo receba uma solicitação insegura e redirecione o cliente para a porta segura.

Para obter mais informações, consulte a Kestrel ou a implementação do servidor Web HTTP.sys no ASP.NET Core.

Cenários de implementação

Qualquer firewall entre o cliente e o servidor também deve ter portas de comunicação abertas para tráfego.

Se as solicitações forem encaminhadas numa configuração de proxy reverso, use Middleware de Encaminhamento de Cabeçalhos antes de chamar o Middleware de Redirecionamento HTTPS. O Middleware de Cabeçalhos Encaminhados atualiza o Request.Scheme, usando o cabeçalho X-Forwarded-Proto. O middleware permite redirecionar URIs e outras políticas de segurança para funcionar corretamente. Quando o middleware de cabeçalhos encaminhados não é utilizado, a aplicação de back-end pode não receber o esquema correto e acabar num loop de redirecionamento. Uma mensagem de erro comum do usuário final é que ocorreram muitos redirecionamentos.

Ao implantar no Serviço de Aplicativo do Azure, siga as orientações em Tutorial: Vincular um certificado SSL personalizado existente ao Azure Aplicações Web.

Opções

As seguintes linhas de código realçadas invocam o AddHttpsRedirection para configurar opções de middleware:

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

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

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

var app = builder.Build();

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

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

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Chamar AddHttpsRedirection só é necessário para alterar os valores de HttpsPort ou RedirectStatusCode.

O código destacado anterior:

• Define HttpsRedirectionOptions.RedirectStatusCode como Status307TemporaryRedirect, que é o valor padrão. Use os campos da classe StatusCodes para atribuições a RedirectStatusCode.
• Define a porta HTTPS como 5001.

Configurar redirecionamentos permanentes na produção

O middleware assume como padrão o envio de um Status307TemporaryRedirect com todos os redirecionamentos. Se preferires enviar um código de estado de redirecionamento permanente quando a aplicação não está num ambienteDevelopment, envolve a configuração das opções do middleware numa verificação condicional de um ambiente não-Development.

Ao configurar serviços em 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();

Abordagem alternativa para o middleware de redirecionamento HTTPS

Uma alternativa ao uso do HTTPS Redirection Middleware (UseHttpsRedirection) é usar o URL Rewriting Middleware (AddRedirectToHttps). AddRedirectToHttps também pode definir o código de status e a porta quando o redirecionamento é executado. Para obter mais informações, consulte URL Rewriting Middleware.

Ao redirecionar para HTTPS sem a necessidade de regras de redirecionamento adicionais, recomendamos o uso do middleware de redirecionamento HTTPS (UseHttpsRedirection) descrito neste artigo.

Protocolo HSTS (Strict Transport Security Protocol) HTTP

De acordo com OWASP, HTTP Strict Transport Security (HSTS) é um aprimoramento de segurança opcional especificado por um aplicativo Web por meio do uso de um cabeçalho de resposta. Quando um navegador que suporta HSTS recebe este cabeçalho:

• O navegador armazena a configuração para o domínio que impede o envio de qualquer comunicação por HTTP. O navegador força toda a comunicação através de HTTPS.
• O navegador impede que o usuário use certificados não confiáveis ou inválidos. O navegador desativa os prompts que permitem que um usuário confie temporariamente em tal certificado.

Porque HSTS é aplicado pelo cliente, existem algumas limitações:

• O cliente deve suportar HSTS.
• O HSTS requer pelo menos uma solicitação HTTPS bem-sucedida para estabelecer a política HSTS.
• O aplicativo deve verificar cada solicitação HTTP e redirecionar ou rejeitar a solicitação HTTP.

ASP.NET Core implementa HSTS com o método de extensão UseHsts. O código a seguir chama UseHsts quando a aplicação não está no modo de desenvolvimento :

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 não é recomendado no desenvolvimento porque as configurações de HSTS são altamente armazenáveis em cache pelos navegadores. Por padrão, UseHsts exclui o endereço de loopback local.

Para ambientes de produção que estão implementando HTTPS pela primeira vez, defina o HstsOptions.MaxAge inicial para um pequeno valor usando um dos métodos TimeSpan. Defina o valor de horas para não mais do que um único dia, caso precise reverter a infraestrutura HTTPS para HTTP. Depois de confiar na sustentabilidade da configuração HTTPS, aumente o valor do HSTS max-age; um valor normalmente utilizado é de um ano.

O seguinte código destacado:

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

• Define o parâmetro preload do cabeçalho Strict-Transport-Security. O pré-carregamento não faz parte da especificação RFC HSTS , mas é suportado pelos navegadores da Web para pré-carregar sites HSTS em nova instalação. Para obter mais informações, consulte https://hstspreload.org/.
• Permite includeSubDomain, que aplica a política HSTS aos subdomínios do host.
• Define explicitamente o parâmetro max-age do cabeçalho Strict-Transport-Security para 60 dias. Se não estiver definido, o padrão é de 30 dias. Para obter mais informações, consulte a diretiva max-age.
• Adiciona example.com à lista de anfitriões a excluir.

UseHsts exclui os seguintes hosts de loopback:

• localhost : O endereço de retorno IPv4.
• 127.0.0.1 : O endereço de retorno IPv4.
• [::1] : O endereço de retorno IPv6.

Exclusão de HTTPS/HSTS na criação de projetos

Em alguns cenários de serviço de back-end em que a segurança da conexão é tratada na extremidade pública da rede, não é necessário configurar a segurança da conexão em cada nó. Os aplicativos Web gerados a partir dos modelos no Visual Studio ou do comando dotnet new habilitam redirecionamento HTTPS e HSTS. Para implantações que não exigem esses cenários, você pode desativar HTTPS/HSTS quando o aplicativo é criado a partir do modelo.

Para desativar HTTPS/HSTS:

dotnet new webapp --no-https

Confie no certificado de desenvolvimento HTTPS do ASP.NET Core no Windows e macOS

Para o navegador Firefox, consulte a próxima seção.

O SDK .NET inclui um certificado de desenvolvimento HTTPS. O certificado é instalado como parte da experiência de utilização inicial. Por exemplo, dotnet --info produz uma variação da seguinte saída:

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.

A instalação do SDK do .NET instala o certificado de desenvolvimento HTTPS do ASP.NET Core no repositório de certificados do usuário local. O certificado foi instalado, mas não é confiável. Para confiar no certificado, execute a etapa única para executar a ferramenta dotnet dev-certs:

dotnet dev-certs https --trust

O comando a seguir fornece ajuda sobre a ferramenta dotnet dev-certs:

dotnet dev-certs https --help

Confirme o certificado HTTPS no Firefox para evitar o erro SEC_ERROR_INADEQUATE_KEY_USAGE

O navegador Firefox usa o seu próprio armazenamento de certificados e, portanto, não confia nos certificados de desenvolvedores do IIS Express ou Kestrel.

Há duas abordagens para confiar no certificado HTTPS com o Firefox, criar um arquivo de política ou configurar com o navegador FireFox. A configuração com o navegador cria o arquivo de política, de modo que as duas abordagens são equivalentes.

Crie um arquivo de política para confiar no certificado HTTPS com o Firefox

Crie um arquivo de política (policies.json) em:

• Windows: %PROGRAMFILES%\Mozilla Firefox\distribution\
• MacOS: Firefox.app/Contents/Resources/distribution
• Linux: Consulte Confiar no certificado no Linux com o Firefox neste artigo.

Adicione o seguinte JSON ao arquivo de política do Firefox:

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

O arquivo de política anterior faz com que o Firefox confie nos certificados confiáveis no repositório de certificados do Windows. A próxima seção fornece uma abordagem alternativa para criar o arquivo de política anterior usando o navegador Firefox.

Configurar a confiança do certificado HTTPS usando o navegador Firefox

Defina security.enterprise_roots.enabled = true usando as seguintes instruções:

1. Digite about:config no navegador FireFox.
2. Selecione Aceitar o risco e continuar se aceitar o risco.
3. Selecione mostrar todas
4. Definir security.enterprise_roots.enabled = true
5. Saia e reinicie o Firefox

Para obter mais informações, consulte Configurando autoridades de certificação (CAs) no Firefox e o arquivo mozilla/policy-templates/README.

Como configurar um certificado de desenvolvedor para o Docker

Veja o sobre este problema do GitHub.

Confiar no certificado HTTPS no Linux

Estabelecer confiança depende especificamente da distribuição e do navegador. As seções a seguir fornecem instruções para algumas distribuições populares e os navegadores Chromium (Edge e Chrome) e para o Firefox.

Confie no certificado HTTPS no Linux com linux-dev-certs

linux-dev-certs é uma ferramenta global .NET de código aberto e suportada pela comunidade que fornece uma maneira conveniente de criar e confiar em um certificado de desenvolvedor no Linux. A ferramenta não é mantida ou suportada pela Microsoft.

Os comandos a seguir instalam a ferramenta e criam um certificado de desenvolvedor confiável:

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

Para obter mais informações ou relatar problemas, consulte o repositório GitHub linux-dev-certs.

Ubuntu confia no certificado para comunicação entre serviços

As instruções a seguir não funcionam para algumas versões do Ubuntu, como a 20.04. Para obter mais informações, consulte a Questão do GitHub dotnet/AspNetCore.Docs #23686.

1. Instale OpenSSL 1.1.1h ou posterior. Consulte a sua distribuição para obter instruções sobre como atualizar o OpenSSL.

2. Execute os seguintes comandos:

   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
   

Os comandos anteriores:

• Verifique se o certificado de desenvolvedor do usuário atual foi criado.
• Exporta o certificado com permissões elevadas necessárias para a pasta ca-certificates, usando o ambiente do usuário atual.
• A remoção do sinalizador -E exporta o certificado de usuário raiz, gerando-o se necessário. Cada certificado recém-gerado tem uma impressão digital diferente. Ao executar como root, sudo e -E não são necessários.

O caminho no comando anterior é específico para o Ubuntu. Para outras distribuições, selecione um caminho apropriado ou use o caminho para as Autoridades de Certificação (CAs).

Confiar no certificado HTTPS no Linux usando Edge ou 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

Confie no certificado com o Fedora 34

See:

• Este comentário do GitHub
• Fedora: Usando certificados de sistema compartilhados
• Configure um ambiente de desenvolvimento .NET no Fedora.

Confie no certificado com outras distribuições

Veja o sobre este problema do GitHub.

Confiar no certificado HTTPS do Subsistema Windows para Linux

As instruções a seguir não funcionam para algumas distribuições Linux, como o Ubuntu 20.04. Para obter mais informações, consulte a Questão do GitHub dotnet/AspNetCore.Docs #23686.

O do Subsistema Windows para Linux (WSL) gera um certificado de desenvolvimento autoassinado HTTPS, que por padrão não é confiável no Windows. A maneira mais fácil de fazer com que o Windows confie no certificado WSL é configurar o WSL para usar o mesmo certificado que o Windows:

• No Windows, exporte o certificado de desenvolvedor para um arquivo:

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

  Onde $CREDENTIAL_PLACEHOLDER$ é uma senha.

• Em uma janela WSL, importe o certificado exportado na instância WSL:

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

A abordagem anterior é uma operação única por certificado e por distribuição WSL. É mais fácil do que exportar o certificado repetidamente. Se você atualizar ou regenerar o certificado no Windows, talvez seja necessário executar os comandos anteriores novamente.

Solucionar problemas de certificado, como certificado não confiável

Esta seção fornece ajuda quando o certificado de desenvolvimento ASP.NET Core HTTPS foi instalado e confiável, mas você ainda tem avisos do navegador de que o certificado não é confiável. O certificado de desenvolvimento HTTPS ASP.NET Core é usado pelo Kestrel.

Para reparar o certificado do IIS Express, consulte este problema no Stackoverflow.

Todas as plataformas - certificado não confiável

Execute os seguintes comandos:

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

Feche todas as instâncias do navegador abertas. Abra uma nova janela do navegador para o aplicativo. A confiança do certificado é armazenada em cache pelos navegadores.

O comando "dotnet dev-certs https --clean" falhou

Os comandos anteriores resolvem a maioria dos problemas de confiança do navegador. Se o navegador ainda não estiver confiando no certificado, siga as sugestões específicas da plataforma a seguir.

Docker - certificado não confiável

• Eliminar a pasta C:\Users{USER}\AppData\Roaming\ASP.NET\Https.
• Limpe a solução. Exclua os pastas dos compartimentos , e os pastas obj ,.
• Reinicie a ferramenta de desenvolvimento. Por exemplo, Visual Studio ou Visual Studio Code.

Windows - certificado não confiável

• Verifique os certificados no repositório de certificados. Deve existir um certificado localhost com um nome amigável ASP.NET Core HTTPS development certificate tanto em Current User > Personal > Certificates como em Current User > Trusted root certification authorities > Certificates.
• Remova todos os certificados encontrados das autoridades de certificação raiz Pessoais e Confiáveis. Não remova o certificado localhost do IIS Express.
• Execute os seguintes comandos:

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

Feche todas as instâncias do navegador abertas. Abra uma nova janela do navegador para o aplicativo.

OS X - certificado não confiável

• Abra o KeyChain Access.
• Selecione o Porta-chaves do sistema.
• Verifique a presença de um certificado localhost.
• Verifique se ele contém um símbolo de + no ícone para indicar que é confiável para todos os usuários.
• Remova o certificado das chaves do sistema.
• Execute os seguintes comandos:

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

Feche todas as instâncias do navegador abertas. Abra uma nova janela do navegador para o aplicativo.

Consulte Erro HTTPS usando o IIS Express (dotnet/AspNetCore #16892) para solucionar problemas de certificado com o Visual Studio.

Certificado Linux não confiável

Verifique se o certificado que está sendo configurado para confiança é o certificado de desenvolvedor HTTPS do usuário que será usado pelo servidor Kestrel.

Verifique o certificado de desenvolvedor HTTPS Kestrel padrão do usuário atual no seguinte local:

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

O ficheiro de certificado Kestrel do desenvolvedor HTTPS é o certificado de impressão digital SHA1. Quando o arquivo é excluído via dotnet dev-certs https --clean, ele é regenerado quando necessário com uma impressão digital diferente. Verifique se a impressão digital do certificado exportado corresponde ao seguinte comando:

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

Se o certificado não corresponder, pode ser um dos seguintes:

• Um certificado antigo.
• Exportou-se um certificado de desenvolvedor para o usuário raiz. Para este caso, exporte o certificado.

O certificado de usuário raiz pode ser verificado em:

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

Certificado SSL do IIS Express usado com o Visual Studio

Para corrigir problemas com o certificado do IIS Express, selecione Reparar no instalador do Visual Studio. Para obter mais informações, consulte esta questão do GitHub.

A política de grupo impede que certificados autoassinados sejam confiáveis

Em alguns casos, a política de grupo pode impedir que certificados autoassinados sejam confiáveis. Para obter mais informações, consulte esta questão do GitHub.

Informações adicionais

• Configurar o ASP.NET Core para trabalhar com servidores proxy e balanceadores de carga
• Hospedar ASP.NET Core no Linux com Nginx: Configuração HTTPS
• Como configurar SSL no IIS
• Configurar endpoints para Kestrel servidor web
• Suporte a navegadores OWASP HSTS