Getting 403 Forbidden: Access denied error when sending client certificate on some clients - iis-7.5

We have an ASP.NET MVC web application where we use digital signatures for both authorization and signing purposes. So in the SSL Settings of the website I've chosen to Require client certificates. I've also chosen to require SSL. But with some clients I have a problem with 403 Forbidden: Access denied error. If I choose to Ignore the Client Certificates the error goes away. Again, this error occurs only with couple of clients, the rest can connect OK.
The IIS version is 7.5
You might wonder the set up of those problematic and the rest clients in the network: There are two routers, A and B. Some clients connect to A and some to B. The above problem occurs on both cases. So nothing like the problematic clients are connected to router A or B.

Had this error for awhile not to long ago, unfortunately it could be anything in the setup. I'll take a shot in the dark and the client is using the machine name? and not the pre made user used for the service.

Related

What does HTTP 403 with substatus 72 mean on Azure and how to fix it?

I have an App Service that's protected by a TLS certificate. It worked fine with small payloads, however, it started failing with larger payloads.
According to an article, I enabled certificate negotiation for my API Management Service:
https://notetoself.tech/2019/06/13/api-call-with-client-certificate-policy-failing-to-execute-due-to-message-size-on-azure-api-management/
However, it still randomly fails with certificate negotiation error, as seen below:
Important - I do not want to use client authentication between browser <-> API management. I'm using it only between API management <-> App Service.
I could not find any information on this substatus 72 code. What does it mean and can it be fixed? Is Azure client certificate authentication broken and won't work with large payloads?
The Negotiate Client Certificate checkbox will not help here as this is for the mutual auth between the client and your apim service where your problem is between apim and app service. Your app service should force apim to exchange the client certificate during the initial SSL handshake rather than waiting until it is needed.
This problem is not related specifically to azure, see this
https://techcommunity.microsoft.com/t5/networking-blog/https-client-certificate-request-freezes-when-the-server-is/ba-p/339672
The issue description to me or at least to how I understood it does not match with the error code as the 17 substatus code means that the client certificate has expired or is not yet valid.
See this https://www.google.com/search?q=403.17+http+code&oq=403.17+http+code&aqs=chrome..69i57.9265j0j7&client=ms-android-samsung-gn-rev1&sourceid=chrome-mobile&ie=UTF-8
And this https://techcommunity.microsoft.com/t5/iis-support-blog/client-certificate-revisited-how-to-troubleshoot-client/ba-p/348053

HTTPS React app inside intranet still shows as untrusted

We have a Node.js application with React frontend for warehouse management. One of the features of the app is a real-time QR code reader (Which requires webcam access that is only available if the website is running under a secured connection).
This application is accessible only inside the intranet network (eg.: 192.168.157.12:80) and has no domain. I know after some research that the way is to obtain a self-signed certificate and I already did that successfully.
The problem is that it shows on the client-side as an "untrusted" certificate and require the user to confirm/bypass a bunch of warning to access the app - this is a no-go for us because a lot of the users are not tech-savvy and it presents a significant issue.
Is there any way to show the self-signed certificate as fully valid inside the local network on Windows PC and Android tablet with chrome browser and not bother the user with any warnings and alerts?
If not, can you please suggest any other method how to handle this?
Thank You.

Azure - WebApp - authenticate requests by certificate

I would like to use certificate authentication for requests on my website. But when I set clientCertEnabled to true (through https://resources.azure.com/) I am getting 403 forbidden error when I try to reach my site through https.
Through browser I get blue screen Error 403 - This web app is stopped but I can still access web site through http. When I switch clientCertEnabled back to false https is working.
Through fiddler I get 403 as well (client certificate is included in request) with no additional info.
I followed this https://azure.microsoft.com/en-us/documentation/articles/app-service-web-configure-tls-mutual-auth/ but there is nothing else mentioned to be required to make this work.
Do I have to upload client certificates somewhere?
Eventually I found out that problem was in my client certificate which I was using for testing.
Certificate generated in a way described in this very useful blog post worked properly:
https://dotnetcodr.com/2016/01/14/using-client-certificates-in-net-part-2-creating-self-signed-client-certificates/

Protecting mobile app from man-in-the-middle attack

We are working on a mobile app that communicates with the backend through REST API over SSL. Mobile device executes cert validation on the API call (using standard libraries in mobile frameworks).
If we try to connect the mobile device through proxy (such as Charles), we see all the traffic, but it is encrypted - as expected.
However, if I enable SSL proxy, generate root certificate and install that cert on my device, I will see all the data in clear text through Charles - again, as expected.
The question is, how to prevent this?
The main target, of course, is to expose data ONLY if device calls allowed server with a valid certificate for that server.
Off hand the only way to prevent such a thing if the attacker has that level of access to the device would be to use SSL thumb printing. You would initiate a connection to the server. Retrieve the SSL certificate and compare this to a hard coded value within the app code. If this does not match abort the connection and don't send the data.
The issue with this however is the overhead if the SSL updates. You would need to release an update to the app with a fresh thumbprint value. This would also stop people using the app until they updated to the latest version.
The only way to prevent this is through certificate pinning, but if the attacker is able to install a root certificate before you connect for the first time to your API, you can still be MiM'ed.

MVC Application call a web service with client certificate

I have a MVC 4.0 application with a web service as reference. The web service is installed on third party remote server will SSL. Also the web service requires client certificate authentication. I installed the certificate that issued by the 3rd party to our test server on Personal store, Trusted Root Certificate Authorities and Third-Party Root Certificate Authorities. Same to my local computer. The application is able to access the remote server and get response on my local development server, but always failed on our test server. Our test server is win 2003 and IIS 6.0. The error I got is "Client Certificate Required". It looks like the remote server either reject or cannot take the certificate we pass.
Here is my code:
var svc = new webservcie();
svc.ClientCertificates.Add(X509Certificate.CreateFromCertFile("c:\clientcert.cer"));
svc.Credentials = new NetworkCredential(username, password);
svc.url = "https://www.thirdparty.com/WMServices";
svc.givemedata()
I have tried many ways to fix this issue, but cannot. I think the issue is that our test server is not able to access the client certification. I read an article about grant Networkservice access to the certificate, but not sure if it is right or not.
Could someone please help me out? Thanks!
I found more detail error from server application event log:
Failed auto update retrieval of third-party root list sequence number from: http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootseq.txt with error: This network connection does not exist.
Thanks!

Resources