Mutual Authentication in IIS

Hey Everyone! 

So today, let’s chat about something super important but often misunderstood — Mutual Authentication in IIS. If you've ever heard terms like two-way SSL, client certificates, or mutual TLS and felt a little overwhelmed — don’t worry. I'm going to break it all down for you, just like I would if we were sitting across from each other and looking at a server setup together.

Before you proceed read my previous blogs Setup SSL on IIS and TLS/SSL Handshake 

Ready? Let’s go!

What is Mutual Authentication?

You know how, in most secure web connections, your browser checks the server’s certificate to make sure it’s talking to the right website? That’s one-way SSL. Now imagine flipping that around — the server also wants to verify that the client (you) is who they claim to be. That’s mutual authentication — both sides validate each other before they shake hands and start talking securely.

So instead of just saying:

"You’re The website? Okay cool, here’s my data."

Now we’re saying:

"You’re The website? Okay, prove it.
I'm a valid client? Here's my certificate — you verify it too."

Mutual authentication = trust on both sides 

Where Is Mutual Authentication Used?

It’s not something you’ll see every time you browse Website or order food. This is more of a high-security feature used when it really matters, like:

• Banking apps or APIs
• Healthcare platforms
• Internal corporate tools with sensitive data
• VPN connections to internal systems
• Server-to-server communications (backend services)

If you’re dealing with anything highly sensitive or regulated — mutual TLS (mTLS) is your best friend.

What You’ll Need to Get Started (Before Setting It Up in IIS)

Before we dive into mutual authentication setup in IIS, let’s make sure your toolbox is ready. Here's what you absolutely need in place:

1. SSL Certificates on Both Ends

• Server Certificate: This goes on your IIS server. It authenticates the server to the client.
• Client Certificate(s): Each client needs its own certificate to prove its identity to the server.

Think of this like both sides showing their ID cards before entering a secure building.

2. Trusted Certificate Authority (CA)

• All certificates should be issued by a trusted CA (public or internal).
• If you're using self-signed certs, make sure the full trust chain is manually imported on both client and server.

If the cert isn’t trusted, the handshake breaks right there—no second chances.

3. IIS Configured with HTTPS

• IIS must be up and running with HTTPS bindings properly set up.
• Make sure the server cert is already installed and bound to the right site.

4. Port 443 Open

• Your firewall should allow inbound and outbound traffic on port 443.
• No HTTPS = No TLS = No handshake.

5. Clients That Support Certificates

• Not all browsers or systems send client certificates by default.
• Make sure your client device, browser, or app supports and presents certificates when requested.

Chrome and Edge usually prompt for a certificate; some browsers need extra setup.

Step-by-Step: How to Configure Mutual Authentication in IIS

Let’s walk through this like I’m helping you set it up from scratch.

Step 1: Install and Bind the Server Certificate

• Open IIS Manager → Go to Server Certificates
• Install the certificate (issued to your domain name)
• Go to your site → Bindings → Add or Edit binding for https and choose the certificate

Step 2: Generate and Distribute Client Certificates

• Create client certificates via your internal CA or a trusted 3rd-party CA
• Export them securely (with private key) and import them into clients under:
  • Current User > Personal > Certificates

Step 3: Configure SSL Settings in IIS

• In IIS Manager, select your site
• Go to SSL Settings
• Check Require SSL
• Under Client Certificates, choose Require

That’s the key switch — when you hit "Require", IIS won’t just accept any request — it will demand a client certificate. If the client doesn’t provide one, it’s goodbye.

Step 4: Configure Authorization (Optional but Important)

• Go to IIS > Feature View > Authorization Rules
• You can allow or deny based on specific certificates or mapped Windows users (via Client Certificate Mapping)

Step 5: Enable Client Certificate Mapping via IIS Config Editor

Let’s go into the config editor and turn it on.

1. Open IIS Manager.
2. Select your website.
3. In the Features View, double-click Configuration Editor.
4. In the Section dropdown at the top, navigate to:
   
   

   system.webServer/security/authentication/iisClientCertificateMappingAuthentication

   
   
   
5. Set:

• • enabled: True
  • oneToOneCertificateMappingsEnabled: True (if using one-to-one mappings)
  • manyToOneCertificateMappingsEnabled: True (if using many-to-one mappings)

 

 

     6. Click Apply on the right pane.

     7. Do an IIS Reset (run iisreset in CMD) to apply changes.

Choose Your Mapping Method: One-to-One vs Many-to-One

One-to-One Mapping: Precision Control

This is tight control: each client certificate is matched to one specific Windows user.

Use this when: You want specific user-level access for each certificate.

Steps to Set Up One-to-One Mapping:

1. Go to IIS > Client Certificate Mapping Authentication.
2. On the Actions pane (right), click “Edit Feature Settings…”:
   • Ensure “Enable” is checked.
3. Click “One-to-One Mappings…” in the right pane.
4. In the One-to-One dialog:
   • Click Add.
   • Browse and select the client certificate file (usually a .cer file).
   • Provide the Windows account to map this cert to.
     • Can be local (.\username) or domain (DOMAIN\username).
   • Enter the password if needed.

Done! That specific certificate now logs in as that mapped user.

Many-to-One Mapping: Broad Grouping

This is looser control: match multiple client certs using rules (e.g., same issuer) to a single Windows user.

Use this when: You want to group multiple clients under a single identity, like a shared role.

Steps to Set Up Many-to-One Mapping:

1. In IIS Manager, select your site.
2. Go to IIS > Client Certificate Mapping Authentication.
3. Click “Many-to-One Mappings…” in the right pane.
4. In the Many-to-One dialog:
   • 1. In the editor, click Add (adds a new mapping item).
     2. Configure the following properties:
        • enabled: True
        • name: A friendly name for this rule (e.g., FinanceCertRule)
        • permissions: Usually leave default (Read)
        • userName: The Windows account this cert maps to (e.g., DOMAIN\financeuser)
        • password: Password for the account
        • rules: Click (…) to open the Rules collection

     Step-by-Step Inside rules → Add a Certificate Field Match Rule

     Now you’re defining what to match from the certificate.

     1. In the rules collection editor, click Add.
     2. Now configure the following fields:

     Property	Example Value	Description
     certificateField	Subject or Issuer	Which X.509 field to inspect. Common ones: Subject, Issuer, SerialNumber, SubjectAltName
     certificateSubField	CN (Common Name), O, etc.	Specific sub-field. For Subject: CN, OU, O, etc.
     matchCriteria	FinanceUser001	The value to compare to (e.g., subject CN)
     compareCaseSensitive	True or False	Should the match be case-sensitive?

     
     Example: Match on Subject → CN → FinanceUser001

     That means if a client presents a certificate with:

     Subject: CN=FinanceUser001, OU=Finance, O=ExampleCorp

     then the client will be mapped to the Windows user DOMAIN\financeuser.

      

   •  

• Click OK on the rules editor.
• Click OK on the mappings editor.
• Click Apply back in the Configuration Editor.

Testing the Setup

Try accessing your site from a browser with a valid client certificate. You’ll either:

• Be prompted to choose a certificate (browser pops up a dialog)
• Get in successfully
• Or get a 403 Forbidden error if the cert isn’t valid

Let’s Open NetMon: What Does Mutual Authentication Look Like on the Wire?

Now comes the fun part — network tracing. If you want to see mutual authentication in action, here's how you do it in Microsoft Network Monitor (NetMon) or Wireshark.

Sample Mutual Auth Flow (2-Way SSL)

Here’s what you’ll see in a successful mutual authentication session:

Key Things to Notice:

Frame 2: Server Hello + Certificate Request

• This is the giveaway that mutual auth is happening.
• The Certificate Request from server is not present in normal one-way SSL.
• It tells the client: "Hey — now you give me your certificate too."

Frame 3: Client Certificate & Verification

• The client responds with its certificate
• Followed by:
  • Client Key Exchange (sends Pre-Master Secret)
  • Certificate Verify (proves ownership of private key)
  • Change Cipher Spec (switch to encrypted mode)

Frame 4: Server Finished

• Server finishes handshake and both sides can now securely talk.

If Something Fails:

Check if:

• Frame 2 is missing Certificate Request → server isn’t asking for client cert.
• Frame 3 doesn’t have Certificate → client didn’t send it (wrong browser, cert missing, not trusted)
• You get a TLS Alert packet (e.g., “bad certificate”) → cert mismatch, expired, or not mapped.

Where Are Certificates Stored?

Here’s a quick cheat sheet:

You can open them using:

run -> certmgr.msc   or
Use MMC Console → Add/Remove Snap-In → Certificates

Logs to Check If It’s Not Working

Trust me, when mutual TLS fails, you’ll want all the logs. Start here:

IIS Logs:

• Found at C:\inetpub\logs\LogFiles\W3SVCx
• Check for status codes like 403.7 (Client certificate required)

Event Viewer:

• Windows Logs → System or Application
• Look for Schannel errors — they give hints like "certificate expired" or "unable to find revocation list"

Wireshark or NetMon Captures:

Browser Debug:

• Open dev tools → Security tab
• You’ll often see messages like “No client certificate presented” or “Invalid certificate”

Wrapping It Up

Mutual authentication in IIS is one of those things that sounds scary but is actually really straightforward when you break it down. It's like upgrading from just checking someone's ID to both of you checking each other's passports before sitting down to talk.

By:

• Installing proper certificates
• Configuring IIS to require client certs
• Verifying handshake using NetMon
• Checking logs when things go wrong

You can set up a super secure environment that ensures only trusted clients can talk to your servers.

Need Help?

Drop a question below and I’ll help help answer it for you!
Happy learning