Wednesday, June 16, 2021

403.16 error : "Root certificate which is not trusted by the trust provider. (0x800b0109)"

A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider. (0x800b0109)

 

Client Certificate is a digital certificate which confirms to the X.509 system. It is used by client machines/users to prove their identity to the remote server.

 

We normally get 403 errors if the client certificate authentication is not configured properly. In this article, we will talk about the error “403 – Access denied” while browsing a site hosted on IIS (internet information services).

 

“403 – Access denied” might be a custom error message thrown from the application code. Hence, we need to get the exact status code and sub-status code from the IIS logs stored in the location C:\inetpub\logs\LogFiles\W3SVC{site_id}

 

In this scenario, IIS logs had the error code 403.16.

 

HTTP 403.16 indicates that the Client certificate is untrusted or invalid : If IIS is not configured to use a CTL, SSL client certificate authentication will fail with the 403.16 error condition. This error occurs because SChannel.dll wrongly considers the client certificate to be untrusted

 

As a troubleshooting step, we can enable CAPI2 logging to get more details on 403.16 error. Below are the steps to enable it.

 

  • In the Event Viewer, go to Application and Services Logs -> Microsoft -> Windows -> CAPI 2 to get the CAPI 2 channel.
  • Right-click on "Operational" and select “Enable Log”. This will enable CAPI2 Diagnostics logging.

 

CAPI2 logging has generated below event log for 403.16 error.

 

Malathi_Pai_1-1623823606576.png

 

Above highlighted error message would occur when there is a non-self-signed certificate present in Trusted root Certification authorities certificate store on the MMC console. We can resolve 403.16 error by removing the non-self-signed certificate from the Trusted root Certification authority. Please refer the article for more details.

                                                     

Please note that this is a probable solution for this issue. We need to find the exact error/issue details by enabling appropriate logging.

 

Note:

We can make use of below command to list the non-self-signed certificate exists on the trusted root authority.

Get-Childitem cert:\LocalMachine\root -Recurse | Where-Object {$_.Issuer -ne $_.Subject} | Format-List * | Out-File "c:\computer_filtered.txt

  

Hope this helps !!

Posted at https://sl.advdat.com/2TAFlIu