EF Core未加密连接字符串本身安全,关键在于存放位置;TrustServerCertificate=True仅跳过TLS证书验证,须与Encrypt=True共用且仅限开发环境。
EF Core 使用未加密的连接字符串本身没有问题,但关键在于连接字符串是否暴露在不安全的位置,比如硬编码在代码里、提交到 Git、或明文写在 appsettings.json 中被公开。TrustServerCertificate 是 SQL Server 连接中的一个安全开关,和“加密”与否不是同一维度的事——它解决的是 TLS 证书验证问题,不是连接字符串加解密问题。
所谓“未加密”,是指连接字符串没经过 AES/DES 等算法处理,直接以明文形式存在配置中。这在开发环境常见,只要注意以下几点就基本安全:
IConfiguration.GetConnectionString("Default") 读取,避免散落各处当 EF Core 用 UseSqlServer 连本地 SQL Server(如 LocalDB、SQL Server Express)或自签名证书的 SQL Server 实例时,常会报错:A connection was successfully established with the server, but then an error occurred during the login process.
这是因为 .NET 默认要求服务器证书由受信任的 CA 签发。启用 TrustServerCertificate=True 就是告诉驱动:跳过证书链验证,接受任何证书(包括自签名)。
Encrypt=True 同时出现才有意义(否则连加密都不要,谈不上证书信任)Server=.;Database=DemoDb;User Id=sa;Password=123456;Encrypt=True;TrustServerCertificate=True;
即使不加密,也别写死在 DbContext 的 OnConfiguring 里。推荐标准做法:
"ConnectionStrings": { "Default": "Server=.;Database=DemoDb;...;Encrypt=True;TrustServerCertificate=True;" }
builder.Services.AddDbContext(opt => opt.UseSqlServer(builder.Configuration.GetConnectionString("Default")))
基本上就这些。TrustServerCertificate 是临时绕过证书校验的开关,不是加密开关;未加密连接字符串可用,但得管好存放位置和环境边界。