Does this force TLS 1.0 ?

[StingyJack]

it seems to be attempting to use it and our network policies block this TLS version.

[dmitrybakaev]

I am getting an exception at an attempt to call ReadNamespacedService: System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel. any modifications of ServicePointManager do not help

[brendandburns]

I don't think it tries to force TLS 1.0, it's possible that it can't negotiate the right cypher.

Can you print out what your server(s) support?

[tg123]

csharp/src/KubernetesClient/Kubernetes.ConfigInit.cs

Line 174 in ae9dd04

ServicePointManager.SecurityProtocol |= SecurityProtocolType.Tls12;

our code for .net452 only add compatibility for tls1.2 which is not flagged as true by default

[dmitrybakaev]

After network settings adjustment, we have resolved this issue for local machines. However, if we run a client from Azure WebJob, it still throws The request was aborted: Could not create SSL/TLS secure channel exception.
'SkipTlsVerify = true' did not help.

We use the regular AKS cluster.

[dmitrybakaev]

Currently, AKS API does not provide a trusted certificate. Since Azure App Service does not allow us to connect to websites that do not have valid certificates, we have a blocker, where we can not use Kubernetes API from Azure App Service. So far I did not find any suitable solution on how to overcome this issue.

[brendandburns]

Can you load a custom certificate authority in App Service? That's what you need to do to make it work.

this library should load the custom certificate authority for you, assuming it is in the kubeconfig file

How are you making the requests to Kubernetes?

[JennyLawrance]

The exception in .NET is not very helpful when the SSL connection fails:
If attaching a debugger is an option, I'd encourage that to see the inner exceptions (before the WebException is thrown).
If network capture is an option, it helps to use that to see at which stage of TLS handshake, the connection is dropped. For client certificate related issues, the drop happens after server side sends a SERVER-HELLO + Certificate + Certificate Request. For TLS 1.x version issues, the disconnect happens before that.

That said, we use this in our code, along with SkipTlsVerify. So try this perhaps?

        configuration.ClientCertificateKeyStoreFlags = X509KeyStorageFlags.PersistKeySet |
            X509KeyStorageFlags.UserKeySet |
            X509KeyStorageFlags.Exportable;

[brendandburns]

Be warned that setting SkipTlsVerify means that someone can theoretically person-in-the-middle your communications.

[dmitrybakaev]

Thanks, everyone! @JennyLawrance, your snippet helped to identify the real reason for App Service misconfiguration. After setting ClientCertificateKeyStoreFlags I've started getting The credentials supplied to the package were not recognized exception which related to WEBSITE_LOAD_USER_PROFILE flag. After fixing that option within Azure App Service the client has started working. I believe the issue can be closed and probably documentation needs to be updated for everyone who plans to utilize k8s sharp client within Azure App Services.

Thanks,
Dmitry.

[brendandburns]

Thanks @JennyLawrance this seems to be addressed, so I will close this issue.

[StingyJack]

So to summarize the problem (and so I can find this easier later), we could not connect from an Azure AppService WebJob to an Azure Kubernetes Service due to the AKS instance not providing a trustable cert and the AppService will only connect to sites with a cert it can trust.

Trying to do this resulted in "The request was aborted: Could not create SSL/TLS secure channel" errors.

The fix was to add an app setting (to the configuration blade in the app service) for WEBSITE_LOAD_USER_PROFILE with a value of 1. I cant find any documentation on what this setting actually does or how it ties into certificate handling other than maybe its allowing the user certificate store to be used, and that one is more flexible than the machine store.