cc @JamesNK

That setting is removed in #2008

Although I'm not sure if AddCosmosDbContext builds the right connection string to ignore the cert.

@JamesNK it looks like it doesn't use the right connection string - I'm getting errors.

That change is for preview 4. It isn't publicly released.

Are you using preview 3 or a nightly build?

Preview 3 - to allow easier checks for my technical reviewers

And this is an exception I see with the emulator:

System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception.
       ---> System.IO.IOException: Received an unexpected EOF or 0 bytes from the transport stream.
         at System.Net.Security.SslStream.ReceiveHandshakeFrameAsync[TIOAdapter](CancellationToken cancellationToken)
         at System.Net.Security.SslStream.ForceAuthenticationAsync[TIOAdapter](Boolean receiveFirst, Byte[] reAuthenticationData, CancellationToken cancellationToken)
         at System.Net.Security.SslStream.ProcessAuthenticationWithTelemetryAsync(Boolean isAsync, CancellationToken cancellationToken)
         at System.Net.Http.ConnectHelper.EstablishSslConnectionAsync(SslClientAuthenticationOptions sslOptions, HttpRequestMessage request, Boolean async, Stream stream, CancellationToken cancellationToken)
         --- End of inner exception stack trace ---

@christiannagel I am getting the same. The only workaround I have found is when setting up my DB context is to do as the documentation says as so:

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    optionsBuilder.UseCosmos("AccountEndpoint = https://localhost:8081/;AccountKey=C2y6yDjf5/R+ob0N8A7Cgv30VRDJIWEHLM+4QDU5DE2nQ9nDuVTqobD4b8mGGyPMbIZnqyMsEcaGQy67XIw/Jw==", "cosmos",
        x => {
            x.HttpClientFactory(() => new HttpClient(new HttpClientHandler()
            {
                ServerCertificateCustomValidationCallback = HttpClientHandler.DangerousAcceptAnyServerCertificateValidator
            }));
            x.ConnectionMode(Microsoft.Azure.Cosmos.ConnectionMode.Gateway);
        });
}

Doing the above still gives me SSL errors, so in my Web project for my Aspire app I have had to:

ServicePointManager.ServerCertificateValidationCallback += (sender, certificate, chain, sslPolicyErrors) => true;

Obviously this is not ideal, but for testing it does allow me to at least make a connection to the Cosmos Emulator.

@JamesNK I missed updating one of the packages with this project. The IgnoreEmulatorCertificate option indeed is available with preview 3. However, it still throws with the same error.

@JamesLMiller - thanks for the workaround.

I'm not changing the DbContext as I'm usingt a NuGet package that's also used with Cosmos running in Azure: https://www.nuget.org/packages/CNinnovation.Codebreaker.Cosmos/, but managed to use your workaround with the DI container configuration ignoring the Cosmos component in the debug case:

#if DEBUG
            builder.Services.AddDbContext<IGamesRepository, GamesCosmosContext>(options =>
            {
                options.UseCosmos("AccountEndpoint = https://localhost:8081/;AccountKey=C2y6yDjf5/R+ob0N8A7Cgv30VRDJIWEHLM+4QDU5DE2nQ9nDuVTqobD4b8mGGyPMbIZnqyMsEcaGQy67XIw/Jw==", "codebreaker",
                 cosmosOptions => {
                    cosmosOptions.HttpClientFactory(() => new HttpClient(new HttpClientHandler()
                    {
                        ServerCertificateCustomValidationCallback = HttpClientHandler.DangerousAcceptAnyServerCertificateValidator
                    }));
                    cosmosOptions.ConnectionMode(ConnectionMode.Gateway);
                });
            });
#else
            builder.AddCosmosDbContext<GamesCosmosContext>("codebreaker", "codebreaker",
                configureDbContextOptions: static options =>
                {
                    options.UseQueryTrackingBehavior(QueryTrackingBehavior.NoTracking);
                });

            builder.Services.AddScoped<IGamesRepository, DataContextProxy<GamesCosmosContext>>();
#endif

Looking forward to updating this with preview 4.

I was using preview 3 and I had the same issue - but I tested the latest code from main using the playground and I didn't have any problems.

Also, seems the package used by preview 3 have the issue Azure/azure-cosmos-dotnet-v3#4315. Now their latest non-preview release (which contains the fix) is the same one already being used by Aspire.

Just posting it here for correlation, since the issue experimented by you @christiannagel may be related to that, although already fixed by Aspire.

I'm going to close this as fixed with preview4. If the problem still exists in the preview4 builds, please re-open.

@JamesNK I missed updating one of the packages with this project. The IgnoreEmulatorCertificate option indeed is available with preview 3. However, it still throws with the same error.

@JamesLMiller - thanks for the workaround.

I'm not changing the DbContext as I'm usingt a NuGet package that's also used with Cosmos running in Azure: https://www.nuget.org/packages/CNinnovation.Codebreaker.Cosmos/, but managed to use your workaround with the DI container configuration ignoring the Cosmos component in the debug case:

#if DEBUG
            builder.Services.AddDbContext<IGamesRepository, GamesCosmosContext>(options =>
            {
                options.UseCosmos("AccountEndpoint = https://localhost:8081/;AccountKey=C2y6yDjf5/R+ob0N8A7Cgv30VRDJIWEHLM+4QDU5DE2nQ9nDuVTqobD4b8mGGyPMbIZnqyMsEcaGQy67XIw/Jw==", "codebreaker",
                 cosmosOptions => {
                    cosmosOptions.HttpClientFactory(() => new HttpClient(new HttpClientHandler()
                    {
                        ServerCertificateCustomValidationCallback = HttpClientHandler.DangerousAcceptAnyServerCertificateValidator
                    }));
                    cosmosOptions.ConnectionMode(ConnectionMode.Gateway);
                });
            });
#else
            builder.AddCosmosDbContext<GamesCosmosContext>("codebreaker", "codebreaker",
                configureDbContextOptions: static options =>
                {
                    options.UseQueryTrackingBehavior(QueryTrackingBehavior.NoTracking);
                });

            builder.Services.AddScoped<IGamesRepository, DataContextProxy<GamesCosmosContext>>();
#endif

Looking forward to updating this with preview 4.

One thing that I noted in some of my testing for my app, is that if I give the emulator time to fully start up (sometimes almost a whole minute) I will not get the SSL errors when connecting. If I don't give it time to connect, and try to use the my database context to call "EnsureCreated" I will still get the SSL issues.

I see similar problems with the cosmos emulator

@davidfowl are you seeing this on the main branch?

@christiannagel for preview 3 you will need to set the ignore flag for the certificate. But you still may see SSL errors. This is due to the time it takes for the emulator to start up. Even if the emulator output is saying it has started all the partitions it can still take some time for it to become responsive to some requests.

Try letting it run for about 40-60 seconds and see whether it starts being responsive. Could you let us know either way on this?

... if you are using preview 4 bits from main you don't need to set the ignore flag because the updated Cosmos client honours a setting on the connection string.

Reopening for now since this is still an active conversation and we just need to verify that it is actually working (if we wait long enough).

I've also seen SSL errors when the emulator is starting up.

However, the problem isn't caused by an invalid certificate. It's caused by the emulator returning a bad response as it starts. Ignoring invalid certificate won't fix it.

I've also seen SSL errors when the emulator is starting up.

However, the problem isn't caused by an invalid certificate. It's caused by the emulator returning a bad response as it starts. Ignoring invalid certificate won't fix it.

When waiting I do not get SSL errors. The other issue that I am noting is that I have no way (that I know of) beyond a GET request to check the status of the emulator. This seems like overkill. With Aspire, I would assume the startup and connection would be handled when adding these components by my AppHost, and I just "use" them.

I can write retry logic if I have health status information about the emulator, to wait for startup to complete, but I don't see anything in the docs about that. It is a little cumbersome to have to wait for 60 (sometimes more) seconds, to do local testing on cosmos changes. Its a first world problem I know, but just making a note of it.

I switched now to the daily build (aspire 8.0.0-preview.5.24154.1/8.0.100), having still issues with the Azure Cosmos DB emulator.

I've added a retry logic, doing "get" requests like @JamesLMiller. In the beginning I see "The SSL connection could not be established, see inner exception.", inner exception: "Received an unexpected EOF or 0 bytes from the transport stream.".
After about 55 seconds, a new inner exception: "The remote certificate is invalid because of errors in the certificate chain: UntrustedRoot".

The playground CosmosEndToEnd https://github.com/dotnet/aspire/tree/main/playground/CosmosEndToEnd has the same issues with the emulator, I couldn't run it successfully.

@christiannagel are you still facing issues after adding the work-around to check connectivity? (i.e. after you get remote cert invalid error)

@mitchdenny for Cosmos how about adding above work-around till emulator addresses the gap? (We can work on it next week)