0

I'm using the newer v4.x version of the Azure .NET SDKS - https://www.nuget.org/packages/Azure.Security.KeyVault.Secrets/4.1.0

In my case this is to access Key Vault secrets but the question probably applies globally. When using the above nuget package to retrieve a secret through a .NET Core 3.1 app, all seems to work OK.

var credential = new ClientSecretCredential("<TENANT_ID>", "<CLIENT_ID>", "<SECRET>");

var client = new SecretClient(new Uri("https://MyVault.vault.azure.net/"), credential);
var secret = await client.GetSecretAsync("MySecret");

However I need it to run in a .NET Framework 4.7.1, the call eventually times out after retrying 4 times.

I fully suspect this is down to the corporate proxy I work behind (although if there may be other reasons please tell me).

There is a SecretClientOptions that inherits from ClientOptions which contains a Transport property but it is not immediately obvious how to use this.

I see on other versions of the Node SDK they have a proxyOptions property but that doesn't exist in the .NET version. Is there another way to configure this?

I also wanted to try an diagnose a bit further but am not sure how to use the Diagnostics property and I struggle to get Fiddler to capture any .NET traffic these days.

UPDATE: Looks like a fix for this was committed 9 days ago so expecting a fix soon which will make .NET Framework use the system proxy correctly - https://github.com/Azure/azure-sdk-for-net/issues/16990

Zak
  • 361
  • 1
  • 5
  • 12
  • Normally a proxy issue the error will occur in 30 seconds. So setting the client.Proxy = null stops the search for the proxy. The issue may also be a TLS version. So adding to code the following sometimes helps : System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12. You and also add support for TLS13 by or'ing the two. Old version of Net do not have the enumeration so you need to use the number instead. See : https://learn.microsoft.com/en-us/dotnet/api/system.net.securityprotocoltype?view=net-5.0 – jdweng Nov 13 '20 at 18:14
  • Check out this: https://learn.microsoft.com/en-us/azure/key-vault/general/vs-key-vault-add-connected-service#access-your-secrets-aspnet – Harshita Singh Nov 16 '20 at 11:16
  • @jdweng I don't see any Proxy property on the SecretClient. The TLS was a good shout but didn't seem to change anything – Zak Nov 20 '20 at 19:22

2 Answers2

1

After diving into the library code it appears that the normal proxy as used with HttpClient isn't used. By setting the HTTP_PROXY and HTTPS_PROXY environment variables I was able to get this to work.

Environment.SetEnvironmentVariable("HTTP_PROXY", "http://my.corporate.proxy/");
Environment.SetEnvironmentVariable("HTTPS_PROXY", "http://my.corporate.proxy/");

UPDATE: Looks like a fix for this was committed 9 days ago so expecting a fix soon which will make .NET Framework use the system proxy correctly - https://github.com/Azure/azure-sdk-for-net/issues/16990

Zak
  • 361
  • 1
  • 5
  • 12
0

An alternative solution here can be the answer by Mun here. He suggests to cache the Key Vault values in App Settings Data structure.

You can also try this approach suggested by Docs if you don't prefer above approach.

Harshita Singh
  • 4,590
  • 1
  • 10
  • 13
  • 1
    The caching is exactly what I am trying to do however I couldn't get access to the key vault even once. I would use the second app settings method but I need to fit into a bespoke settings provider the company has used for years – Zak Nov 20 '20 at 19:24