Impor HTTPS no ASP.NET Core

Artigo
07/22/2022
34 minutos para o fim da leitura

Este documento mostra como:

Exigir HTTPS para todas as solicitações.
Redirecione todas as solicitações HTTP para HTTPS.

Nenhuma API pode impedir que um cliente envie dados confidenciais na primeira solicitação.

Aviso

Projetos de API

Não use RequireHttpsAttribute em APIs Web que recebam informações confidenciais. RequireHttpsAttribute usa códigos de status HTTP para redirecionar navegadores de HTTP para HTTPS. Os clientes de API podem não entender ou obedecer redirecionamentos de HTTP para HTTPS. Esses clientes podem enviar informações por HTTP. As APIs Web devem:

Não escute http.
Feche a conexão com o código de status 400 (Solicitação Incorreta) e não atenda à solicitação.

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

Projetos de HSTS e API

Os projetos de API padrão não incluem HSTS porque o HSTS geralmente é uma instrução somente do navegador. Outros chamadores, como aplicativos de telefone ou área de trabalho, não obedecem à instrução. Mesmo dentro de navegadores, uma única chamada autenticada para uma API por HTTP tem riscos em redes inseguras. A abordagem segura é configurar projetos de API para escutar e responder apenas por HTTPS.

O redirecionamento HTTP para HTTPS causa ERR_INVALID_REDIRECT na solicitação de pré-voo do CORS

Solicitações para um ponto de extremidade usando HTTP que são redirecionadas para HTTPS por UseHttpsRedirection falha com ERR_INVALID_REDIRECT on the CORS preflight request.

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

Solicitar HTTPS

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

Middleware de redirecionamento HTTPS (UseHttpsRedirection) para redirecionar solicitações HTTP para HTTPS.
Middleware do HSTS (UseHsts) para enviar cabeçalhos HSTS (Protocolo de Segurança de Transporte Estrito HTTP) para clientes.

Observação

Os aplicativos implantados em uma configuração de proxy reverso permitem que o proxy manipule a segurança de conexão (HTTPS). Se o proxy também tratar o redirecionamento HTTPS, não será necessário usar o Middleware de Redirecionamento HTTPS. Se o servidor proxy também manipular a gravação de cabeçalhos HSTS (por exemplo, suporte a HSTS nativo no IIS 10.0 (1709) ou posterior), o Middleware do HSTS não será exigido pelo aplicativo. Para obter mais informações, consulte Recusar HTTPS/HSTS na criação do projeto.

UseHttpsRedirection

As seguintes chamadas UseHttpsRedirection de código no Program.cs arquivo:

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 realçado anterior:

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

É recomendável usar redirecionamentos temporários em vez de redirecionamentos permanentes. O cache de vínculo pode causar um comportamento instável em ambientes de desenvolvimento. Se você preferir enviar um código de status de redirecionamento permanente quando o aplicativo estiver em um ambiente que não seja de desenvolvimento, consulte a seção Configurar redirecionamentos permanentes na seção de produção . É recomendável usar o HSTS para sinalizar aos clientes que somente solicitações de recursos seguras devem ser enviadas para o aplicativo (somente em produção).

Configuração de portas

Uma porta deve estar disponível para o middleware redirecionar 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 do https_port host:
- Na configuração do host.
- Definindo a variável de ASPNETCORE_HTTPS_PORT ambiente.
- Adicionando 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 por meio IServerAddressesFeaturede . Essa abordagem não funciona em implantações de proxy reverso.
Os modelos da Web ASP.NET Core definem uma URL Properties/launchsettings.json HTTPS para ambos Kestrel e IIS Express. launchsettings.json é usado apenas no computador local.
Configure um ponto de extremidade de URL HTTPS para uma implantação de borda voltada para o público do Kestrel servidor ou servidorHTTP.sys . Apenas uma porta HTTPS é usada pelo aplicativo. O middleware descobre a porta por meio de IServerAddressesFeature.

Observação

Quando um aplicativo é executado em uma configuração de proxy reverso, IServerAddressesFeature não está disponível. Defina a porta usando uma das outras abordagens descritas nesta seção.

Implantações do Edge

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

A porta segura em que o cliente é redirecionado (normalmente, 443 em produção e 5001 em desenvolvimento).
A porta insegura (normalmente, 80 em produção e 5.000 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 Kestrel a configuração do ponto de extremidade ou HTTP.sys implementação do servidor Web no ASP.NET Core.

Cenários de implantaçã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 em uma configuração de proxy reverso, use o Middleware cabeçalhos encaminhados antes de chamar o Middleware de Redirecionamento HTTPS. O Middleware cabeçalhos encaminhados atualiza o Request.Schemecabeçalho usando o X-Forwarded-Proto cabeçalho. O middleware permite que URIs de redirecionamento e outras políticas de segurança funcionem corretamente. Quando o Middleware cabeçalhos encaminhados não é usado, o aplicativo de back-end pode não receber o esquema correto e acabar em um loop de redirecionamento. Uma mensagem de erro comum do usuário final é que ocorreram muitos redirecionamentos.

Ao implantar em Serviço de Aplicativo do Azure, siga as diretrizes no Tutorial: Associar um certificado SSL personalizado existente ao Azure Aplicativos Web.

Opções

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

using System.Net;

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 = (int)HttpStatusCode.TemporaryRedirect;
    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();

A chamada AddHttpsRedirection só é necessária para alterar os valores de HttpsPort ou RedirectStatusCode.

O código realçado anterior:

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

Configurar redirecionamentos permanentes na produção

O middleware é o padrão para enviar um Status307TemporaryRedirect com todos os redirecionamentos. Se você preferir enviar um código de status de redirecionamento permanente quando o aplicativo estiver em um ambiente que não seja de desenvolvimento, encapsule a configuração de opções de middleware em uma verificação condicional para um ambiente que não seja de desenvolvimento.

Ao configurar serviços em Program.cs:

using System.Net;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

if (!builder.Environment.IsDevelopment())
{
    builder.Services.AddHttpsRedirection(options =>
    {
        options.RedirectStatusCode = (int)HttpStatusCode.PermanentRedirect;
        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 de Middleware de Redirecionamento HTTPS

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

Ao redirecionar para HTTPS sem a necessidade de regras de redirecionamento adicionais, recomendamos usar o Middleware de Redirecionamento HTTPS (UseHttpsRedirection) descrito neste tópico.

PROTOCOLO HTTP Strict Transport Security Protocol (HSTS)

Por OWASP, HTTP Strict Transport Security (HSTS) é um aprimoramento de segurança de aceitação especificado por um aplicativo Web por meio do uso de um cabeçalho de resposta. Quando um navegador que dá suporte ao HSTS recebe esse 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 por HTTPS.
O navegador impede que o usuário use certificados não confiáveis ou inválidos. O navegador desabilita prompts que permitem que um usuário confie temporariamente em tal certificado.

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

O cliente deve dar suporte ao 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 o HSTS com o UseHsts método de extensão. O código a seguir chama UseHsts quando o aplicativo 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 do HSTS são altamente armazenadas 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 a inicial HstsOptions.MaxAge como um valor pequeno usando um dos TimeSpan métodos. 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 comumente usado é de um ano.

O seguinte código realçado:

using System.Net;

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 = (int)HttpStatusCode.TemporaryRedirect;
    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 de pré-carregamento do Strict-Transport-Security cabeçalho. O pré-carregamento não faz parte da especificação do RFC HSTS, mas é compatível com navegadores da Web para pré-carregar sites HSTS em instalação recente. Para obter mais informações, consulte https://hstspreload.org/.
Habilita includeSubDomain, que aplica a política HSTS aos subdomínios de host.
Define explicitamente o max-age parâmetro do Strict-Transport-Security cabeçalho como 60 dias. Se não for definido, o padrão será de 30 dias. Para obter mais informações, consulte a diretiva max-age.
Adiciona example.com à lista de hosts a serem excluídos.

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.

Recusar HTTPS/HSTS na criação do projeto

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

Para recusar HTTPS/HSTS:

Visual Studio
CLI do .NET Core

Desmarque a caixa de seleção Configurar para HTTPS .

Nova caixa de diálogo ASP.NET Core Aplicativo Web mostrando a caixa de seleção Configurar para HTTPS não selecionada.

Use a opção --no-https. Por exemplo

dotnet new webapp --no-https

Confiar no certificado de desenvolvimento HTTPS ASP.NET Core no Windows e no 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 primeira execução. 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.

Instalar o 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 para a ferramenta dev-certs:

dotnet dev-certs https --help

Aviso

Não crie um certificado de desenvolvimento em um ambiente que será redistribuído, como uma imagem de contêiner ou uma máquina virtual. Fazer isso pode levar à falsificação e à elevação de privilégios. Para ajudar a evitar isso, defina a variável de DOTNET_GENERATE_ASPNET_CERTIFICATE ambiente para false antes de chamar a CLI do .NET pela primeira vez. Isso ignorará a geração automática do certificado de desenvolvimento ASP.NET Core durante a experiência de primeira execução da CLI.

Confiar no certificado HTTPS com o Firefox para evitar SEC_ERROR_INADEQUATE_KEY_USAGE erro

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

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, portanto, as duas abordagens são equivalentes.

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

Crie um arquivo de política em:

Windows: %PROGRAMFILES%\Mozilla Firefox\distribution\policies.json
MacOS: Firefox.app/Contents/Resources/distribution
Linux: consulte Confiar no certificado com o Firefox no Linux neste documento.

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 em certificados dos 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:

Insira about:config o navegador FireFox.
Selecione Aceitar o Risco e Continuar se você aceitar o risco.
Selecionar Mostrar Tudo
Definir security.enterprise_roots.enabled = true
Sair e reiniciar o Firefox

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

Como configurar um certificado de desenvolvedor para o Docker

Consulte este problema do GitHub.

Confiar no certificado HTTPS no Linux

Estabelecer confiança é específico 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.

O Ubuntu confia no certificado para comunicação serviço a serviço

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

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 ca-certificates pasta, usando o ambiente do usuário atual.
A remoção do -E sinalizador 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 raiz 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 o Edge ou o Chrome

Para navegadores chromium no Linux:

Instale o libnss3-tools para sua distribuição.
Crie ou verifique se a $HOME/.pki/nssdb pasta existe no computador.
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
certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n localhost -i /usr/local/share/ca-certificates/aspnet/https.crt

Saia e reinicie o navegador.

Confiar 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 JSarquivo /usr/lib/firefox/distribution/policies.json ON 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 documento para obter uma maneira alternativa de configurar o arquivo de política usando o navegador.

Confiar no certificado com Fedora 34

Consulte este comentário do GitHub.

Confiar no certificado com outras distribuições

Consulte este problema do GitHub.

Confiar no certificado HTTPS de Subsistema do Windows para Linux

O Subsistema do Windows para Linux (WSL) gera um certificado de desenvolvimento autoassinado https. Para configurar o repositório de certificados do Windows para confiar no certificado WSL:

Exporte o certificado do desenvolvedor para um arquivo no Windows:
```
dotnet dev-certs https -ep https.pfx -p $CREDENTIAL_PLACEHOLDER$ --trust
```
Onde $CREDENTIAL_PLACEHOLDER$ está uma senha.

Em uma janela WSL, importe o certificado exportado na instância do 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 uma e outra vez. Se você atualizar ou regenerar o certificado nas janelas, 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 ASP.NET Core certificado de desenvolvimento 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 por Kestrel.

Para reparar o certificado IIS Express, consulte esse problema de 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 por navegadores.

dotnet dev-certs https --clean Fails

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

Exclua a pasta C:\Users{USER}\AppData\Roaming\ASP.NET\Https .
Limpe a solução. Exclua as pastas bin e 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 haver um localhost certificado com o ASP.NET Core HTTPS development certificate nome amigável em Current User > Personal > Certificates e 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 IIS Express localhost.
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 conjunto de chaves do sistema.
Verifique a presença de um certificado localhost.
Verifique se ele contém um + símbolo no ícone para indicar que ele é confiável para todos os usuários.
Remova o certificado do conjunto de 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 o erro HTTPS usando 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 Kestrel servidor.

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

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

O arquivo de certificado do desenvolvedor Kestrel HTTPS é a impressão digital SHA1. Quando o arquivo é excluído por meio dotnet dev-certs https --clean, ele é regenerado quando necessário com uma impressão digital diferente. Verifique a impressão digital das correspondências do certificado exportado com o seguinte comando:

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

Se o certificado não corresponder, ele poderá ser um dos seguintes:

Um certificado antigo.
Um certificado de desenvolvedor exportado para o usuário raiz. Para esse caso, exporte o certificado.

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

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

IIS Express certificado SSL usado com o Visual Studio

Para corrigir problemas com o certificado IIS Express, selecione Reparar no instalador do Visual Studio. Saiba mais neste tópico 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. Saiba mais neste tópico do GitHub.

Informações adicionais

Aviso

Projetos de API

Não ouça http.
Feche a conexão com o código de status 400 (Solicitação Incorreta) e não atenda à solicitação.

Projetos de HSTS e API

Solicitar HTTPS

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

Middleware de redirecionamento HTTPS (UseHttpsRedirection) para redirecionar solicitações HTTP para HTTPS.
Middleware do HSTS (UseHsts) para enviar cabeçalhos HSTS (Protocolo de Segurança de Transporte Estrito) HTTP aos clientes.

Observação

UseHttpsRedirection

O código a seguir chama UseHttpsRedirection na Startup classe:

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 realçado anterior:

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

Configuração de portas

Uma porta deve estar disponível para o middleware redirecionar 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 do https_port host:

Na configuração do host.
Definindo a variável de ASPNETCORE_HTTPS_PORT ambiente.

Adicionando 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 por meio IServerAddressesFeaturede . Essa abordagem não funciona em implantações de proxy reverso.
No desenvolvimento, defina uma URL HTTPS em launchsettings.json. Habilite HTTPS quando IIS Express for usado.
Configure um ponto de extremidade de URL HTTPS para uma implantação de borda voltada para o público do Kestrel servidor ou servidorHTTP.sys . Apenas uma porta HTTPS é usada pelo aplicativo. O middleware descobre a porta por meio de IServerAddressesFeature.

Observação

Quando um aplicativo é executado em uma configuração de proxy reverso, IServerAddressesFeature não está disponível. Defina a porta usando uma das outras abordagens descritas nesta seção.

Implantações do Edge

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

A porta segura em que o cliente é redirecionado (normalmente, 443 em produção e 5001 em desenvolvimento).
A porta insegura (normalmente, 80 em produção e 5.000 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 Kestrel a configuração do ponto de extremidade ou HTTP.sys implementação do servidor Web no ASP.NET Core.

Cenários de implantação

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

Ao implantar em Serviço de Aplicativo do Azure, siga as diretrizes no Tutorial: Associar um certificado SSL personalizado existente ao Azure Aplicativos Web.

Opções

As seguintes chamadas AddHttpsRedirection de código realçadas 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;
    });
}

A chamada AddHttpsRedirection só é necessária para alterar os valores de HttpsPort ou RedirectStatusCode.

O código realçado anterior:

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

Configurar redirecionamentos permanentes na produção

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 de Middleware de Redirecionamento HTTPS

Ao redirecionar para HTTPS sem a necessidade de regras de redirecionamento adicionais, recomendamos usar o Middleware de Redirecionamento HTTPS (UseHttpsRedirection) descrito neste tópico.

PROTOCOLO HTTP Strict Transport Security Protocol (HSTS)

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 por HTTPS.
O navegador impede que o usuário use certificados não confiáveis ou inválidos. O navegador desabilita prompts que permitem que um usuário confie temporariamente em tal certificado.

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

O cliente deve dar suporte ao 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 o HSTS com o UseHsts método de extensão. O código a seguir chama UseHsts quando o aplicativo 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 do HSTS são altamente armazenadas em cache pelos navegadores. Por padrão, UseHsts exclui o endereço de loopback local.

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 de pré-carregamento do Strict-Transport-Security cabeçalho. O pré-carregamento não faz parte da especificação do RFC HSTS, mas é compatível com navegadores da Web para pré-carregar sites HSTS em instalação recente. Para obter mais informações, consulte https://hstspreload.org/.
Habilita includeSubDomain, que aplica a política HSTS aos subdomínios de host.
Define explicitamente o max-age parâmetro do Strict-Transport-Security cabeçalho como 60 dias. Se não for definido, o padrão será de 30 dias. Para obter mais informações, consulte a diretiva max-age.
Adiciona example.com à lista de hosts a serem excluídos.

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.

Recusar HTTPS/HSTS na criação do projeto

Para recusar HTTPS/HSTS:

Visual Studio
CLI do .NET Core

Desmarque a caixa de seleção Configurar para HTTPS .

Nova caixa de diálogo ASP.NET Core Aplicativo Web mostrando a caixa de seleção Configurar para HTTPS não selecionada.

Use a opção --no-https. Por exemplo

dotnet new webapp --no-https

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

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

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.

dotnet dev-certs https --trust

O comando a seguir fornece ajuda para a ferramenta dev-certs:

dotnet dev-certs https --help

Aviso

Confiar no certificado HTTPS com o Firefox para evitar SEC_ERROR_INADEQUATE_KEY_USAGE erro

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

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

Crie um arquivo de política em:

Windows: %PROGRAMFILES%\Mozilla Firefox\distribution\policies.json
MacOS: Firefox.app/Contents/Resources/distribution
Linux: consulte Confiar no certificado com o Firefox no Linux neste documento.

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

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

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

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

Insira about:config o navegador FireFox.
Selecione Aceitar o Risco e Continuar se você aceitar o risco.
Selecionar Mostrar Tudo
Definir security.enterprise_roots.enabled = true
Sair e reiniciar o Firefox

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

Como configurar um certificado de desenvolvedor para o Docker

Consulte este problema do GitHub.

Confiar no certificado HTTPS no Linux

O Ubuntu confia no certificado para comunicação serviço a serviço

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

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 ca-certificates pasta, usando o ambiente do usuário atual.
A remoção do -E sinalizador 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 raiz 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 o Edge ou o Chrome

Para navegadores chromium no Linux:

Instale o libnss3-tools para sua distribuição.
Crie ou verifique se a $HOME/.pki/nssdb pasta existe no computador.
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
certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n localhost -i /usr/local/share/ca-certificates/aspnet/https.crt

Saia e reinicie o navegador.

Confiar 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 JSarquivo /usr/lib/firefox/distribution/policies.json ON 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 documento para obter uma maneira alternativa de configurar o arquivo de política usando o navegador.

Confiar no certificado com 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

Confiar dotnet a dotnet no Fedora

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

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

Confiar no certificado com outras distribuições

Consulte este problema do GitHub.

Confiar no certificado HTTPS do Subsistema do Windows para Linux

O Subsistema do Windows para Linux (WSL) gera um certificado de desenvolvimento autoassinado https. Para configurar o repositório de certificados do Windows para confiar no certificado WSL:

Exportar o certificado do desenvolvedor para um arquivo no Windows:
```
dotnet dev-certs https -ep C:\<<path-to-folder>>\aspnetcore.pfx -p $CREDENTIAL_PLACEHOLDER$
```
Onde $CREDENTIAL_PLACEHOLDER$ está uma senha.

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

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

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

Esta seção fornece ajuda quando o certificado de desenvolvimento HTTPS ASP.NET Core 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 por Kestrel.

Para reparar o certificado IIS Express, consulte este problema de 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 por navegadores.

dotnet dev-certs https --clean Fails

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

Exclua a pasta C:\Users{USER}\AppData\Roaming\ASP.NET\Https .
Limpe a solução. Exclua as pastas bin e 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 haver um localhost certificado com o ASP.NET Core HTTPS development certificate nome amigável em Current User > Personal > Certificates e 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 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 Acesso ao KeyChain.
Selecione o conjunto de chaves do sistema.
Verifique a presença de um certificado localhost.
Verifique se ele contém um + símbolo no ícone para indicar que ele é confiável para todos os usuários.
Remova o certificado do conjunto de 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 o erro HTTPS usando 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 Kestrel servidor.

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

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

O arquivo de certificado do desenvolvedor Kestrel HTTPS é a 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, ele poderá ser um dos seguintes:

Um certificado antigo.
Um certificado de desenvolvedor exportado para o usuário raiz. Para esse caso, exporte o certificado.

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

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

IIS Express certificado SSL usado com o Visual Studio

Para corrigir problemas com o certificado IIS Express, selecione Reparar no instalador do Visual Studio. Saiba mais neste tópico do GitHub.