Authorization Issues between Blazor Web App and SQL Server API on Windows 10

Other Questions API
1

I’m working on a project using Windows 10, IIS 10, and SQL Server installed locally with standard Windows authentication configurations, along with Visual Studio 2022. I developed an ASP.NET Core Web API that interfaces with my SQL Database using this connection string:

Server=localhost;Database=Shipwrecks;User id=apilogin;Password=xxxxx;TrustServerCertificate=true;MultipleActiveResultSets=true;

I’ve successfully published and accessed the API via https://localhost:8081/api/Expeditions/1001. In my Blazor web project developed in Visual Studio, everything works fine in debug mode, but after deploying it to the local IIS, I encounter a connection error.

I would like to understand why the API behaves differently when it is accessed through a web page compared to a direct entry in the browser. Any insights would be appreciated!

Here’s the error message I’m receiving:

System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception.
---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid because of errors in the certificate chain: UntrustedRoot...

I’ve tried various configurations for the API’s connection string, including using the IP address, localhost, and the computer’s name.

2

I’ve faced a similar issue in the past where SSL/TLS connection problems arose due to self-signed or locally trusted root certificates when accessing services through IIS. One potential workaround that might help you is to manually add the certificate used by your local IIS to the trusted root certificate authorities on your machine. This can sometimes resolve issues related to ‘UntrustedRoot’ errors. Make sure that your API and Blazor app are both configured to accept and verify the same certificate. Also, double-check your IIS setup to ensure that the SSL binding is properly configured. Another thing to try is bypassing SSL verification temporarily for debugging purposes, though consider using this cautiously as it’s not a production solution. Sometimes, such deployment issues revert to how certificates are handled in local environments versus dev/debug setups.