Add support for ignoring SSL certificate for emulator connections

[mitchdenny]

Is your feature request related to a problem? Please describe.
Currently when using the Cosmos DB emulator it is necessary to either download the certificate from the emulator using a well known endpoint and install it into the certificate store, or override the HttpClient to ignore the certificate. I am proposing that the format of the Cosmos DB client connection string be updated to support ignoring the certificate. This is a similar pattern to what SQL Server follows.

Describe the solution you'd like
From a users perspective, ignoring the Cosmos DB emulator certificate should be as simple as appending:

AccountEndpoint=https://localhost:8081/;AccountKey=C2y6yDjf5/R+ob0N8A7Cgv30VRDJIWEHLM+4QDU5DE2nQ9nDuVTqobD4b8mGGyPMbIZnqyMsEcaGQy67XIw/Jw==;IgnoreEndpointCertificate=true;

The default value would be false. Note that the implementation should not restrict ignoring the certificate to the default emulator endpoint because some tools such as .NET Aspire may randomly assign a proxy port in front of the emulator.

Describe alternatives you've considered
The current recommendations (installing the certificate) or having developers write code to ignore the SSL check is cumbersome and easy to mess up.

Additional context
This request is coming from the .NET Aspire team. We've been working with Kevin Pilch (@Pilchie) on adding Cosmos support to Aspire and this was one of the stumbling blocks that we came up against.

[josephaw1022]

🙌🙌

[bartelink]

This would be extremely useful. Some extensions/notes:

• AccountKey=EmulatorKey should also be a shortcut for the well known account key

• there should also be consts in the SDK for the three bits individually and collectively:

  • IgnoreEndpointCertificate=true
  • AccountKey=EmulatorKey
  • AccountEndpoint=https://localhost:8081

i.e. the ideal implementation should allow me to:

• use Direct mode (either implicitly as that's the default, or explicitly)
• use a short connection string e.g. AccountEndpoint=https://localhost:8081;AccountKey=EmulatorKey;IgnoreEndpointCertificate=true OR shorter

---

I implemented something in this direction in jet/equinox#431 (but I did not use it as it hangs during CreateDatabaseIfNotExistAsync in my current implementation in Direct mode, whereas that works OK if I trust the cert - its very important to me that I don't use Gateway mode in all my testing and then switch to Direct when I actually want to run things for me, so I opted to stay with actually trusting the cert via the MacOS Keychain; would love a hint as to what I did wrong, but ideally I'd just use this work when it ships, if it can tick the above boxes...)

[fakhrulhilal]

This will be extremely useful. I can tell you why. I know I can import the self signed cert into my local development machine. But it will be a problem for other environment, let's say a docker container. Yes, I can ignore the certificate warning in the code. But I will do that for Debug mode only. For building docker container, I use Release mode, which I don't prefer for ignoring certificate warning.
By supporting the configuration, then I can separate the connection string between my local machine, docker container, and production (which I have been doing at the moment). Currently, I have to use dotnet run for my development env, regardless the other services use docker container. The only reason is avoiding self-sign certificate problem. Because there is no option to override the Azure Cosmos certificate. I tried before but I just gave up.

[bartelink]

Mitch Denny (@mitchdenny) Sourabh Jain (@sourabh1007) would you see any value in also implementing a AccountKey=EmulatorKey expansion to make the string human readable too?

Also can you confirm the aim is to support Direct and Gateway modes equally?

[sourabh1007]

Ruben Bartelink (@bartelink) What do you mean by human readable string here? Connection String would be same with one more extra information (which is human readable).
Yes, it will support Direct and Gateway mode both, until unless you are using own HttpClientFactory instance because if custom httpclient is used, then we won't have control over it.