feat: Add support for RSA private key (RsaPrivateCrtKeyParameters) TLS authentication with protected Docker daemon sockets

[zuntio]

What does this PR do?

Adds switch case to determine if read object is actually AsymmetricCipherKeyPair or RsaPrivateCrtKeyParameters instead of hard casting it to AsymmetricCipherKeyPair.

Why is it important?

Tutorial of protecting socket results in pem key type which resolves as RsaPrivateCrtKeyParameters object type. Same outputs come from many other tutorials too so it is reasonable to support it.

Related issues

• Closes [Bug]: InvalidCastException when running with docker with TLS #813

How to test this PR

Configure TLS protection to docker daemon according to tutorial and write simple hello-world usage.

[netlify]

✅ Deploy Preview for testcontainers-dotnet ready!

Name	Link
🔨 Latest commit	9491afd
🔍 Latest deploy log	https://app.netlify.com/sites/testcontainers-dotnet/deploys/64ecc5db985a67000851a8b6
😎 Deploy Preview	https://deploy-preview-978--testcontainers-dotnet.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[HofmeisterAn]

Thanks for the pull request 🙏. Do you think we can cover the changes with a test?

[zuntio]

Thanks for the pull request 🙏. Do you think we can cover the changes with a test?

Seems that if I replace DockerVersion with newest 24.0.5, object is resolved as RsaPrivateCrtKeyParameters.

If you give me a green light I'll do some refactoring to ProtectDaemonSocket fixture to make version overrideable and add duplicate test with other version including some verification that different type of object was actually resolved?

Edit: verifying type seems a bit nasty since contents of X509Certificate2 are pretty similar between runs with different versions. Only length of raw data byte array differs and not propably goot property to match :)

[HofmeisterAn]

Seems that if I replace DockerVersion with newest 24.0.5, object is resolved as RsaPrivateCrtKeyParameters.

Ah, that is fortunate.

If you give me a green light I'll do some refactoring to ProtectDaemonSocket fixture to make version overrideable and add duplicate test with other version including some verification that different type of object was actually resolved?

Of course, certainly 👍. Couldn't we just verify if the generated key (inside _hostCertsDirectoryPath) matches the type we expect? This won't validate our internal resolution, but I think it's fine as long as we confirm that both types are working and not throwing an exception.

[zuntio]

Couldn't we just verify if the generated key (inside _hostCertsDirectoryPath) matches the type we expect? This won't validate our internal resolution, but I think it's fine as long as we confirm that both types are working and not throwing an exception.

Sounds good. I'll write and commit it tomorrow along with fixture refac.

[HofmeisterAn]

Great, take your time. There's no rush at all. Enjoy the rest of the weekend 🥳.

[zuntio]

Here you go. Lot of patterns to go with but decided to use IClassFixture pattern. Naming is bit off after realising this is all from IETF TLS deprecation and therefore OpenSSL has been updated at some point. Of course open for suggestions.

[HofmeisterAn]

Thank you for making the changes. For your information: I will be able to do the review earliest by the end of this week (possibly at the beginning of next week).

[HofmeisterAn]

Thanks again. PR looks good.

[safalin1]

Just tested it, working great now. Thanks guys!