EID Authentication on IIS

[Cyril Colin]

Hello,

Sorry if the question has been asked before but it's my first time trying to use mutual TLS authentication.

Long story short, I've been tasked to create a POC of an API that would authenticate external users with their eID. As far I know (from this google Group and the github), there is no way to directly read the card in a web context. However, as the PIN code is required to select the certificat, we believe that getting the certificate, combined with a custom login process would be good enough for the POC.

Because we're using Windows VMs and IIS to deploy our applications, I've been trying to do that though mTLS. However I'm stuck on a HTTP 403.13 Error sent directly by the IIS. Which means that it cannot validate the certificate and proceed to the API behind. In this case it looks like a revocation error (which doesn't make sense to me).

With one of the System Engineers, I fixed a firewall misconfiguration that prevented OCSP revocation checks. I found that error while looking in the VM's Event Viewer.

As of right now, everything seems alright:

So I'm a bit lost as to what could still cause this 403 error. Has anyone tried to do something similar and could give me some pointers ?

I have installed all Belgium ROOT CAs in the server's Trusted Root CA store:

As well as the Citizen CA comming from my own eID card (because that's the one I use for testing) in the server's intermediate CA store:

My API has a valid SSL certificate installed on the server and binded through the IIS:

And I believe the IIS' SSL Settings to be correctly configured:

I've been directed here by BOSA, however please tell me if this is not the right place to ask for such support and I'll remove the post. 

Thanks in advance,

Cyril.

[Wouter Verhelst]

Hi Cyril,

I'm not familiar with how IIS does this, but from what I see the configuration you set up should be sufficient; you installed the root certificates as well as the intermediat one for your card, and you do get a successful TLS handshake. So I'm not sure either.

Just to be 100% sure, can you try if your card validates in the eID viewer? Just go to the "certificates" tab page and hit the "validate now" button there. If it doesn't validate there either, then the certificate is in fact revoked and you'll have to get that resolved first.

If that does succeed, then it may be that IIS tries to access the CRL, which are also listed in the certificates, and that this is blocked by your firewall too. Could you rule out that possibility as well?

Beyond that, I'm not sure what else could be wrong. If you can enable more detailed logging somewhere, that might give us a clue.

Cyril Colin schreef op wo 16-04-2025 om 07:53 [-0700]:

[Cyril Colin]

Hello,

Thanks for your answer. I used RDP (with port sharing) to read my eID from the server, and it seems able to validate the certifcates:

As far as OCSP and CRL validation goes, the server seems to have access to the URLs, as I can download them with both Chrome and Edge on the server:

By enabling "FailedRequestLogging" and setting a local webserver to properly display the xml and "freb.xsl" file that were created, I can see the following:

It seems that the server indeed has trouble with the CRL. But I do not know why it may believes the revocation server to be offline when it is freely accessible from the browser.

Thanks for your help,

Cyril.

[Cyril Colin]

Hello again,

I forgot to add the picture to the last message, but I also used the "certutil" command to validate that my certificate is valid from the server:

And as far as that command goes, it was able to validate the certificate and it's revocation checks.

Please have a nice day,

Cyril.

[Cyril Colin]

Hello,

Because I could not find an answer, I also made a post on Microsoft Learn.

While the answer wasn't what I expected, the post linked by the answer did guide me to the solution.

Long story short, the problem was that the account used by IIS could not get through our company's firewall.

I do not really know why my user account could reach the OCSP and CLR but the user account of the IIS could not.

What I did to check that was 

• Create a batch-only Service Account on our active directory
• Link it to the Application Pool in the IIS
• Confirm that the exact same error still occurs
• Temporarily allow the SA to log interactively 
• Log into the server with the SA.
• Try to access the OCSP and CLR URLs from Edge
• Get the nice following error:
  
  

With this proof I could go back to the System Engineers and ask them to add a rule that would allow the server's main IP (the additionnal IPs on the network card that are used to bind each IIS Website to a specific IP do not count) to communicate with "*.eidpki.belgium.be".

Again, I do not know why my regular user could do it without a special firewall config, but allowing that url in the firewall did fix the problems for me.

Regards,

Cyril.