[Bug]: Mutual TLS on Windows in .NET 9 does not work

[jvmdc]

Testcontainers version

4.1.0

Using the latest Testcontainers version?

Yes

Host OS

Windows

Host arch

x86

.NET version

9

Docker version

Client:
Version:           26.1.0-rd
API version:       1.45
Go version:        go1.21.9
Git commit:        cca8e72
Built:             Tue Apr 23 16:26:59 2024
OS/Arch:           windows/amd64
Context:           default
 
Server: Docker Engine - Community
Engine:
  Version:          27.4.1
  API version:      1.47 (minimum version 1.24)
  Go version:       go1.22.10
  Git commit:       c710b88
  Built:            Tue Dec 17 15:45:42 2024
  OS/Arch:          linux/amd64
  Experimental:     false
containerd:
  Version:          1.6.32
  GitCommit:        8b3b7ca2e5ce38e8f31a34f35b2b68ceb8470d89
runc:
  Version:          1.1.12
  GitCommit:        v1.1.12-0-g51d5e94
docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Docker info

Client:
Version:    26.1.0-rd
Context:    default
Debug Mode: false
Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.11.0
    Path:     C:\Users\<REDACTED>\.docker\cli-plugins\docker-buildx.exe
  compose: Docker Compose (Docker Inc.)
    Version:  v2.19.0
    Path:     C:\Users\<REDACTED>\.docker\cli-plugins\docker-compose.exe
 
Server:
Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
Images: 12
Server Version: 27.4.1
Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 8b3b7ca2e5ce38e8f31a34f35b2b68ceb8470d89
runc version: v1.1.12-0-g51d5e94
init version: de40ad0
Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
Kernel Version: 5.15.0-107-generic
Operating System: Ubuntu 22.04.3 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 4.93GiB
Name: srvp01669
ID: d20cc868-ff21-47f9-9d77-5e49ad9fe27a
Docker Root Dir: /var/lib/docker
Debug Mode: false
Experimental: false
Insecure Registries:
  127.0.0.0/8
Live Restore Enabled: false

What happened?

We're using a TestContainers properties file with the following lines:

docker.host=tcp://<REDACTED>
docker.tls.verify=true

When TestContainers tries to load our client certificate using the X509CertificateLoader.LoadCertificate method (here: https://github.com/testcontainers/testcontainers-dotnet/blob/4.1.0/src/Testcontainers/Builders/MTlsEndpointAuthenticationProvider.cs#L59), it throws an exception. This is happening because the certificate is being exported as PFX aka. PKCS12 which X509CertificateLoader.LoadCertificate does not support, the method X509CertificateLoader.LoadPkcs12 should be used instead.

Relevant log output

System.TypeInitializationException
  HResult=0x80131534
  Message=The type initializer for 'DotNet.Testcontainers.Configurations.TestcontainersSettings' threw an exception.
  Source=Testcontainers
  StackTrace:
   at DotNet.Testcontainers.Configurations.TestcontainersSettings.get_OS()
   at DotNet.Testcontainers.Builders.AbstractBuilder`4.Init()
   at DotNet.Testcontainers.Builders.ContainerBuilder`3.Init()
   at Testcontainers.MsSql.MsSqlBuilder.Init()
   at Testcontainers.MsSql.MsSqlBuilder..ctor()
   at <REDACTED>
 
  This exception was originally thrown at this call stack:
    System.Security.Cryptography.X509Certificates.X509CertificateLoader.LoadCertificate(Interop.Crypt32.CertQueryObjectType, void*)
    System.Security.Cryptography.X509Certificates.X509CertificateLoader.LoadCertificatePal(System.ReadOnlySpan<byte>)
    System.Security.Cryptography.X509Certificates.X509CertificateLoader.LoadCertificate(System.ReadOnlySpan<byte>)
    System.Security.Cryptography.X509Certificates.X509CertificateLoader.LoadCertificate(byte[])
    DotNet.Testcontainers.Builders.MTlsEndpointAuthenticationProvider.GetClientCertificate()
    DotNet.Testcontainers.Builders.MTlsEndpointAuthenticationProvider.GetAuthConfig()
    DotNet.Testcontainers.Builders.DockerEndpointAuthenticationProvider.IsAvailable()
    DotNet.Testcontainers.Configurations.TestcontainersSettings..cctor.AnonymousMethod__2_1(DotNet.Testcontainers.Builders.IDockerEndpointAuthenticationProvider)
    DotNet.Testcontainers.Configurations.TestcontainersSettings.TestcontainersSettings()
 
Inner Exception 1:
CryptographicException: Cannot find the requested object.

Additional information

No response

[tisonv]

I upgraded TestContainers to 4.1.0 from 4.0.0 in a .net 9 project.

4.0.0 : My certs configuration is working all right. I can start gvenzl/oracle-xe:21.3.0-slim-faststart.
4.1.0 : I get the exact same TypeInitializationException cited in OP
If I rollback to 4.0.0, it works again.

As I'm not fluent in cert configuration, I followed these docs :

• https://docs.docker.com/engine/security/protect-access/#use-tls-https-to-protect-the-docker-daemon-socket
• https://gist.github.com/sz763/3b0a5909a03bf2c9c5a057d032bd98b7?permalink_comment_id=5061703#gistcomment-5061703

The change to X509CertificateLoader.LoadPkcs12 seems a little too drastic.
There should be a test whether to use LoadCerticate or LoadPkcs12 to allow easy compliance with the docker documentation.

[HofmeisterAn]

I had the same thought when I was reviewing the change. For Windows, we already expected the certificate to be in PKCS12 format (that's why I didn't request a change). Checking the format beforehand sounds much better. I agree.

[tisonv]

Could you reopen the bug please ?

[HofmeisterAn]

I prefer to address this in a new issue. I can create one in the next few days.

[jvmdc]

I am confused.

@tisonv The bug fix I created in #1320 has not been released as a packaged version yet. Are you sure you are not just facing the same issue I was and just need version 4.1.1 (or whatever it will be named) to be released?

[tisonv]

I am confused as well now @jvmdc !
I thought your fix was in the 4.1.0 since the release dates were near hence my comment.

I'll wait till next version is released then.

[HofmeisterAn]

I am confused.

@tisonv The bug fix I created in #1320 has not been released as a packaged version yet. Are you sure you are not just facing the same issue I was and just need version 4.1.1 (or whatever it will be named) to be released?

Yes, the fix has not been published yet. I probably mixed something up. I thought @tisonv asked about supporting PEM files in Windows, but that should already work since we initially load PEM files, not PKCS12, which is binary - sorry.