🔐 Nova Configuração de Segurança no .NET

Bom dia, boa tarde ou boa noite a todos que estão realizando o bootcamp da avanade, trago a vocês mais uma pequena contribuição.

Se você atualizou seu projeto .NET e começou a ver erros como

“A cadeia de certificação foi emitida por uma autoridade que não é de confiança.”

ao rodar o comando dotnet ef database update,

saiba que isso não é um bug — é uma mudança de segurança.

A partir do .NET 6, o .NET passou a criptografar automaticamente todas as conexões com o SQL Server, o que pegou muitos desenvolvedores de surpresa.

Vamos entender o motivo disso e como resolver.

🧭 O que mudou?

Antes do .NET 6, uma connection string simples como esta:


"ConnectionStrings": {
"ConexaoPadrao": "Server=localhost\\sqlexpress;Initial Catalog=Agenda;Integrated Security=True"
}

funcionava sem problemas.

Mas agora, o .NET passou a aplicar Encrypt=True por padrão, o que faz com que toda comunicação com o banco seja criptografada via SSL/TLS.

⚠️ Por que o erro aparece?

O problema é que o SQL Server Express (ou versões locais do SQL Server) normalmente usa certificados autoassinados, ou seja, certificados que o Windows não reconhece como confiáveis.

Quando o .NET tenta criptografar a conexão, o Windows rejeita o certificado — e surge o erro:


A cadeia de certificação foi emitida por uma autoridade que não é de confiança.

🧩 A solução simples: `TrustServerCertificate=True`

Para resolver isso em ambiente local, basta dizer ao .NET para confiar no certificado, mesmo que ele não seja “oficial”.

Você faz isso adicionando o parâmetro TrustServerCertificate=True à sua connection string:


"ConnectionStrings": {
"ConexaoPadrao": "Server=localhost\\sqlexpress;Initial Catalog=Agenda;Integrated Security=True;TrustServerCertificate=True"
}

Pronto!

Depois de salvar, é só rodar novamente:


dotnet ef database update

E a conexão deve funcionar normalmente.

💡 Isso é uma gambiarra?

Não!

O TrustServerCertificate=True é uma configuração oficial da Microsoft, pensada exatamente para cenários de desenvolvimento.

Em produção, o ideal é usar um certificado válido e confiável (como os fornecidos por autoridades certificadoras ou pelo Azure SQL).

Mas para o dia a dia do desenvolvimento local, tudo bem usar esse parâmetro.

⚙️ Exemplos práticos

💻 Ambiente de desenvolvimento local:


"ConnectionStrings": {
"ConexaoPadrao": "Server=localhost\\sqlexpress;Database=Agenda;Integrated Security=True;TrustServerCertificate=True"
}

☁️ Ambiente de produção (com certificado válido):


"ConnectionStrings": {
"ConexaoPadrao": "Server=tcp:meuservidor.database.windows.net,1433;Database=Agenda;User ID=usuario;Password=senha;Encrypt=True;TrustServerCertificate=False"
}