Putting HTTPS on IIS is a three-part job: a certificate, a site binding that uses it, and a redirect that pushes HTTP traffic to the secure endpoint. Each step has its own pitfalls — a certificate name mismatch, a missing private key, or a redirect loop can waste an afternoon. This guide walks through bindings, certificate installation, and HTTP→HTTPS redirects the way they work in practice, and finishes with the failure modes to watch for.
Before You Start: What You Need
- A domain name pointing at your server’s public IP — HTTPS on a raw IP is technically possible but impractical for production.
- A certificate whose name matches the hostname you will bind. Let’s Encrypt via win-acme is free and automates renewal; commercial certificates add warranty and multi-year options; self-signed is only for testing.
- Ports 80 and 443 reachable — open in the Windows Firewall and in the provider’s firewall.
- The URL Rewrite module if you want clean HTTP→HTTPS redirects (installable via the Web Platform Installer or the IIS Manager).
Step 1: Install the Certificate into the Computer Store
Certificates live in the Local Machine store, not the Current User store — IIS runs as a service and cannot read your personal store. Import your .pfx with certlm.msc (Local Machine → Personal → Certificates → right-click → All Tasks → Import). When prompted, mark the key as exportable only if you need to move it later. The import must include the private key; a certificate without a key will not appear in the IIS binding dropdown. If your issuer provides intermediate certificates, install those into the Intermediate Certification Authorities store as well — missing intermediates cause chain errors in browsers even though the leaf certificate looks fine.
Step 2: Create the HTTPS Binding
In IIS Manager, open your site and click Bindings → Add. Set Type to https, Port to 443, enter the host name (for example www.example.com), and select the certificate from the dropdown. Check Require Server Name Indication (SNI) whenever you host more than one HTTPS site on a single IP — without SNI, IIS can only serve one certificate per IP:port pair and every other HTTPS site on the box breaks.
| Binding field | Value to use | Why it matters |
|---|---|---|
| Type | https | Defines the protocol and certificate handling |
| Host name | Your domain, e.g. www.example.com | Must match the certificate CN/SAN or browsers reject the site |
| Port | 443 | Standard HTTPS port; keep it unless you have a reason |
| IP address | All Unassigned (typical) | Leave default unless you run multiple IPs |
| SSL certificate | The certificate whose name matches the host | Only certificates with a private key appear here |
| Require SNI | Checked for multi-site servers | Enables multiple HTTPS sites per IP |
Test immediately: browse to https://www.example.com and confirm the padlock. If the browser shows a name mismatch, either the host name in the binding differs from the certificate’s names, or the certificate was issued for a different domain.
Step 3: Redirect HTTP to HTTPS
Once HTTPS works, make HTTP bounce to it with a permanent redirect. Install the URL Rewrite module, open your site, and add a rule: match pattern (.*), add a condition where {HTTPS} is off, and set the action to Redirect to https://{HTTP_HOST}/{R:1} with status code 301 (Permanent). The equivalent web.config rule looks like this:
<rewrite>
<rules>
<rule name="HTTPS Redirect" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{HTTPS}" pattern="off" ignoreCase="true" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" />
</rule>
</rules>
</rewrite>Use 301 for real sites so search engines and clients cache the secure URL. Use 302 only during testing. On IIS 10+, the built-in HTTP Redirect feature is a simpler alternative if you do not need URL Rewrite for anything else. Once redirects work, consider adding HSTS headers so browsers refuse to connect over HTTP at all after the first visit.
Common Pitfalls and Their Fixes
- Certificate name mismatch (NET::ERR_CERT_COMMON_NAME_INVALID): the binding host name does not match any CN/SAN on the certificate. Fix the binding or reissue the certificate.
- Certificate missing from the binding dropdown: the .pfx was imported without its private key, or into the Current User store. Re-import into Local Machine → Personal with the key.
- “The specified login session does not exist” / cannot access the private key: the app pool identity lacks read access to the certificate’s private key. In
certlm.msc, right-click the certificate → All Tasks → Manage Private Keys, and grant the app pool identity read access. - HTTPS times out while HTTP works: port 443 is blocked in the Windows Firewall or the provider’s firewall. Check both layers.
- Chain errors despite a valid leaf certificate: intermediate certificates were not installed. Add them to Intermediate Certification Authorities.
- Redirect loop: the rewrite rule targets a host that itself redirects, or an HTTP-only binding still exists on port 80 with the same host. Ensure the HTTPS binding host matches
{HTTP_HOST}. - Mixed content warnings: the page loads over HTTPS but references scripts, images, or API calls over HTTP. Fix the absolute URLs in your application.
Verify, Then Automate Renewal
After the redirect is live, check three things: the padlock on https://, the 301 on http://, and the certificate chain with a tool such as SSL Labs or openssl s_client -connect yourdomain:443. Then automate renewal — a certificate that expires quietly is the most common “HTTPS down” incident on IIS. win-acme (Let’s Encrypt) or your CA’s agent can renew and re-bind automatically; verify the renewal pipeline once in staging so you are not debugging it in production. For the hosting foundation underneath all of this, compare the features you get with a Windows VPS, and if you are still choosing a provider, review the options that include automated certificate tooling.
Want a server to host your HTTPS site on? Deploy a Windows VPS on Vultr and follow this guide from the first binding.
