SqlClient: ef core7 , RemoteCertificateValidationCallback error was throwd in docker container
I try to run an asp.net core api with dotnet7 SDK in a docker container.
I have this connection string:
server=xxx.xxx.xxx.xxx,SqlServerPort;database=DbName;user id=sa;password=DbPassword123;TrustServerCertificate=True;
it works fine on my local pc. but when I run this project in a docker container throws this error:
Microsoft.Data.SqlClient.SqlException (0x80131904): A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: TCP Provider, error: 35 - An internal exception was caught) System.Security.Authentication.AuthenticationException: The remote certificate was rejected by the provided RemoteCertificateValidationCallback.
I use this Dockerfile:
FROM mcr.microsoft.com/dotnet/aspnet:7.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
FROM mcr.microsoft.com/dotnet/sdk:7.0 AS build
WORKDIR /src
COPY ["Project.Api/Project.Api.csproj", "Project.Api/"]
COPY ["Project.Module.Admin/Project.Module.Admin.csproj", "Project.Module.Admin/"]
COPY ["Project.Module.Shared/Project.Module.Shared.csproj", "Project.Module.Shared/"]
COPY ["Project.Data/Project.Data.csproj", "Project.Data/"]
COPY ["Project.Infrastructure/Project.Infrastructure.csproj", "Project.Infrastructure/"]
COPY ["Project.Identity/Project.Identity.csproj", "Project.Identity/"]
COPY ["Project.Job/Project.Job.csproj", "Project.Job/"]
COPY ["Project.Module.Driver/Project.Module.Driver.csproj", "Project.Module.Driver/"]
COPY ["Project.Module.User/Project.Module.User.csproj", "Project.Module.User/"]
RUN dotnet restore "Project.Api/Project.Api.csproj"
COPY . .
WORKDIR "/src/Project.Api"
RUN dotnet build "Project.Api.csproj" -c Release -o /app/build
FROM build AS publish
RUN dotnet publish "Project.Api.csproj" -c Release -o /app/publish
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "Project.Api.dll"]
and use this docker-compose file:
version: "3.4"
services:
db-production:
image: "mcr.microsoft.com/mssql/server:2022-latest"
container_name: db-production
restart: always
environment:
ACCEPT_EULA: "Y"
MSSQL_SA_PASSWORD: "DbPassword123"
volumes:
- /home/volumes/mssql/data/production:/var/opt/mssql/data
ports:
- "1432:1433"
backend-production:
image: "backend_production:${TAG}"
container_name: backend-production
environment:
- "ASPNETCORE_ENVIRONMENT=Production"
build:
context: .
dockerfile: Project.Api/Dockerfile
ports:
- "${EXPOSED_PORT_PRODUCTION}:80"
restart: unless-stopped
depends_on:
- db-production
I add my dbContext and SQL server ef core provider:
builder.Services.AddDbContextPool<AppDbContext>(options =>
{
options.UseSqlServer(builder.Configuration.GetConnectionString("ConnectionStringName"), ss =>
{
ss.EnableRetryOnFailure(3);
});
});
if I downgrade EF Core package version to 6.0.1 its works fine on docker!
EF Core version: 7.0.0 Database provider: (e.g. Microsoft.EntityFrameworkCore.SqlServer) Target framework: (e.g. .NET 7.0) Operating system: Windows, Linux IDE: (e.g. Jetbrains Rider 2022.3 EAP 9)
About this issue
- Original URL
- State: open
- Created 2 years ago
- Reactions: 5
- Comments: 21 (3 by maintainers)
Commits related to this issue
- chore: support EF 7, https://github.com/dotnet/SqlClient/issues/1856 — committed to oliversturm/demo-dx-webapi-js by oliversturm a year ago
This really needs to be resolved as its a significant breaking change/regression.
I currently have the same Issue, tried every possibility of the parameters
Persist Security Info=True; Encrypt=False; TrustServerCertificate=True;
New application, new Databases… tried everything similar to @gjvdree - but still no luck. 😦
Same issue here with EF Core 7 + .NET 7 inside a Lambda docker container. Setting
TrustServerCertificate
andEncrypt
have no effect in the SQL connection string.mssql-scripter doesn’t work on Linux due to same bug.
We just experienced this issue and adding “Trust Server Certificate=True” fix the issue.
Within UAT we use managed instances. When connecting to the SQL Browser Agent, the connection simply dies with the same error. We are not happy with the solution but this was fixed by setting the connect to use TCP and set the Instance port directly
I have the same problem after migrating to dotnet 7