🔐 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"
}
🚀 Conclusão
Essa mudança no comportamento do .NET pode ter causado algum susto, mas ela é uma evolução importante na segurança da plataforma.
Agora, todas as conexões com o SQL Server são criptografadas por padrão — e isso é algo positivo.
Para o ambiente local, basta adicionar TrustServerCertificate=True e continuar o trabalho normalmente.
Em produção, use certificados confiáveis e mantenha a criptografia ativa.
