How to fix 'HTTP 403 (Forbidden)' with a self-signed certificate in IIS?

Ensure correct HTTPS binding with the self-signed certificate in IIS and verify SSL Settings, setting Client certificates to Ignore unless mutual TLS is required. 2. Install and trust the self-signed certificate by exporting it from IIS and importing it into the Trusted Root Certification Authorities store on the client or server. 3. Check IIS Request Filtering and IP/Domain Restrictions to ensure no rules are blocking access and allow unlisted IP addresses or add specific allow rules. 4. Confirm host headers and SNI are properly configured in the HTTPS binding, use the exact domain name matching the certificate, and update the hosts file if necessary. 5. Verify NTFS permissions by granting Read & Execute access to IIS_IUSRS or the app pool user and ensure Anonymous Authentication is enabled in IIS. 6. Review URL Rewrite rules and custom HTTP errors in web.config that may interfere with requests. 7. Test access from different clients, browsers, or tools like curl with the -k flag to isolate trust issues from authorization errors. The 403 error with a self-signed certificate in IIS is typically caused by configuration issues such as SSL settings, request filtering, or permissions, not the certificate itself, and resolving these settings resolves the error.

The HTTP 403 error with a self-signed certificate in IIS usually occurs not because of the certificate being self-signed, but due to misconfigurations in SSL settings, certificate trust, or request filtering. A 403 Forbidden error means the server understood the request but refuses to authorize it. Here’s how to fix it step by step:

1. Verify SSL Settings in IIS

Even with a self-signed certificate, IIS must be properly configured to allow HTTPS traffic.

• Open IIS Manager.
• Select your site and click Bindings under the Actions pane.
• Ensure there’s an HTTPS binding on port 443 (or custom port) with the correct self-signed certificate selected.
• If the certificate is missing, you may need to assign it again via the binding settings.

Also check:

• SSL Settings for the site:
  • Double-click SSL Settings.
  • Make sure Require SSL is set appropriately.
  • If Require SSL is enabled but Accept or Require client certificates is checked, and no valid client cert is presented, a 403.7 or 403.16 may occur.
  • For testing, try setting Client certificates: Ignore unless you're using mutual TLS.

⚠️ Common mistake: Enabling "Require client certificate" without providing one causes 403.7.

2. Install and Trust the Self-Signed Certificate

A self-signed certificate isn’t trusted by default, which can cause browser-level blocks — but not a 403. However, some internal applications or filters might reject untrusted certs and trigger access denial.

To fix trust issues:

• Export the self-signed certificate from the Server Certificates section in IIS.
• Import it into the Trusted Root Certification Authorities store on the client machine (or server, if accessing locally):
  • Run certlm.msc (for local machine) or certmgr.msc (for current user).
  • Go to Trusted Root Certification Authorities > Certificates.
  • Import the exported .cer file.

This prevents SSL warnings and avoids potential filter rules that block untrusted SSL.

3. Check IIS Request Filtering and IP/Domain Restrictions

IIS may block requests based on host headers, IP, or URL filtering.

• In IIS Manager, select your site.

• Open IP Address and Domain Restrictions:

  • Ensure no rules are denying access (e.g., default deny all without allow rules).
  • If the feature is enabled, make sure Allow unlisted IP addresses is set or add explicit allow entries.

• Open Request Filtering:

  • Check if certain file types, URLs, or verbs are blocked.
  • Look for any rules that might block the requested path.

4. Host Headers and SNI Conflicts

If multiple sites use HTTPS on the same IP, SNI (Server Name Indication) must be enabled and properly configured.

• In the site’s HTTPS binding, ensure Host Name matches the URL you’re using (e.g., test.local).
• Check that SNI is enabled in the binding if you’re hosting multiple SSL sites on the same IP.
• Access the site using the exact host header name (e.g., don’t use https://localhost if the cert is for https://myapp.local).

Tip: Add an entry in your hosts file (C:\Windows\System32\drivers\etc\hosts) if using a custom domain:

127.0.0.1  myapp.local

5. Check NTFS and IIS Permissions

A 403 error can also stem from file system or authentication issues.

• Ensure the application pool identity has read access to the site’s folder.
  • Right-click the site folder → Properties → Security.
  • Grant Read & Execute to IIS_IUSRS or the app pool user.
• In IIS, check Authentication:
  • Enable Anonymous Authentication (usually uses app pool identity).
  • Disable or configure Windows Authentication as needed.
  • Make sure no authentication module is blocking access.

6. Check for Custom HTTP Errors or URL Rewrite Rules

Sometimes, a rewrite rule or custom error page can mask the real issue.

• Open URL Rewrite module for the site.
• Temporarily disable rules to see if one is redirecting or blocking HTTPS requests.
• Check web.config for any <httpErrors> or <rewrite> sections that might interfere.

7. Test with Different Clients and Browsers

• Try accessing the site from:
  • Another machine (to rule out local trust issues).
  • curl or Postman, which can show more detailed error responses.
  • Example with curl:

    curl -k https://your-site.local

    The -k flag ignores certificate errors. If this works, the issue is certificate trust, not 403.

    ---

    Summary of Key Fixes:

    • ✅ Correct HTTPS binding with self-signed cert in IIS.
    • ✅ SSL Settings: Disable "Require client certificate" unless needed.
    • ✅ Install self-signed cert in Trusted Root on client/server.
    • ✅ Verify host headers, SNI, and bindings match the request.
    • ✅ Check IP/domain restrictions and request filtering.
    • ✅ Ensure NTFS and IIS authentication permissions are set.
    • ✅ Rule out rewrite rules or custom errors masking the issue.

    The 403 error with a self-signed cert is rarely about the certificate itself — it's usually a configuration mismatch in IIS access rules or SSL settings. Fix the binding and permissions first, then validate trust separately.

    Basically, it's not the self-signed cert causing 403 — it's what you do with it.

    The above is the detailed content of How to fix 'HTTP 403 (Forbidden)' with a self-signed certificate in IIS?. For more information, please follow other related articles on the PHP Chinese website!