IIS SSL/TLS Certificate
Installation and Renewal Guide
Safe process for installing, testing, updating, and validating certificates on IIS
PurposeThis document explains how to install a new SSL/TLS certificate on IIS, test it without affecting the current production binding, and later update the live binding when ready. It also includes practical tips for common shared or managed hosting environments. |
Important principleInstalling a certificate into the Windows certificate store does not automatically replace the certificate used by a website. The live site only changes when the HTTPS binding is edited to use the new certificate. |
Table of Contents
1. Certificate concepts
2. Before you start
3. Validate the certificate before installation
4. Fresh installation on IIS without overriding the current certificate
5. Test the new certificate safely on an alternate binding
6. Update the live IIS binding when ready
7. Troubleshooting
8. Tips for usual hosting providers
9. Final checklist
10. Command reference
1. Certificate concepts
A certificate installation is easier to manage when the key parts are understood:
| Item | Meaning | Why it matters |
| Certificate file | Usually .crt, .cer, or .pem. | Contains the public certificate. It proves the site identity but may not include the private key. |
| Private key | The secret key created when the CSR was generated. | IIS needs the matching private key to use the certificate for HTTPS. |
| PFX file | Usually .pfx or .p12. | Contains the certificate and private key, and often the intermediate chain. This is usually the easiest format for IIS. |
| Intermediate certificate | Certificate chain provided by the certificate authority. | Helps browsers trust the server certificate. |
| CSR | Certificate Signing Request. | Generated from the server or hosting panel. The matching private key stays where the CSR was created. |
| IIS binding | Website + protocol + IP + port + host name + certificate. | The live certificate changes only when the HTTPS binding is changed. |
Key rule If the CSR was created on the same IIS server, use Complete Certificate Request. If the CSR was created somewhere else, use a PFX export from that original location or reissue/rekey the certificate using a new CSR from this IIS server. |
2. Before you start
· Confirm the exact hostname or wildcard domain the certificate must cover.
· Confirm whether the certificate includes the root domain and all required subject alternative names.
· Confirm whether you have the private key or a PFX file.
· Do not delete the old certificate before the new one is tested and production is confirmed working.
· Schedule the final live binding change during a low-risk maintenance window.
· Have administrator access to the IIS server.
3. Validate the certificate before installation
3.1 Check expiration and identity
| $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\<folder to cert>\certificate.crt") $cert | Select-Object Subject, Issuer, NotBefore, NotAfter, Thumbprint |
3.2 Check the certificate details with certutil
| certutil -dump "C:\<folder to cert>\certificate.crt" |
In the output, review these sections:
· Subject: the main certificate name.
· Subject Alternative Name: all DNS names covered by the certificate.
· NotBefore and NotAfter: the validity period.
· Enhanced Key Usage: should include Server Authentication for IIS HTTPS use.
3.3 Check whether an installed certificate has a private key
| Get-ChildItem Cert:\LocalMachine\My | Where-Object Subject -like "*your-domain*" | Select-Object Subject, FriendlyName, NotAfter, HasPrivateKey, Thumbprint |
Expected result For IIS HTTPS binding, HasPrivateKey must be True. If it is False, IIS may show the certificate but it cannot properly use it for HTTPS. |
4. Fresh installation on IIS without overriding the current certificate
4.1 Back up the existing IIS configuration
| New-Item -ItemType Directory -Path C:\Temp\IIS-Cert-Backup -Force & "$env:windir\system32\inetsrv\appcmd.exe" list site /config /xml > C:\Temp\IIS-Cert-Backup\iis-sites-bindings-backup.xml netsh http show sslcert > C:\Temp\IIS-Cert-Backup\netsh-sslcert-backup.txt |
4.2 Record the current live bindings
| Import-Module WebAdministration Get-ChildItem IIS:\SslBindings | Format-Table -AutoSize |
4.3 Install the new certificate
Option A - CSR was created on this IIS server
1. Open IIS Manager.
2. Click the server name, not a specific website.
3. Open Server Certificates.
4. Click Complete Certificate Request.
5. Select the certificate file received from the certificate authority.
6. Use a clear friendly name, such as DO NOT USE YET - Wildcard Certificate - Renewal Year.
7. Store it in Personal.
8. Click OK.
Why this is safe Completing the certificate request installs the certificate into the certificate store. It does not replace the live website certificate unless you edit the website's HTTPS binding. |
Option B - CSR was not created on this IIS server
1. Do not rely on the .crt file alone.
2. Obtain a PFX file from the system where the CSR/private key was created, or reissue the certificate using a new CSR from this IIS server.
3. Import the PFX into Local Computer > Personal.
4. Confirm HasPrivateKey is True before using it in IIS.
4.4 Install the intermediate certificate
1. Open the intermediate certificate file provided by the certificate authority.
2. Choose Install Certificate.
3. Select Local Machine.
4. Choose Place all certificates in the following store.
5. Select Intermediate Certification Authorities.
6. Finish the wizard.
5. Test the new certificate safely on an alternate binding
Safe testing approach Use a separate HTTPS binding on a non-production port, such as 4443, or use a temporary test hostname. This allows validation without touching the current live 443 binding. |
5.1 Add a temporary test binding
1. In IIS Manager, open Sites.
2. Select the site to test.
3. Click Bindings.
4. Click Add.
5. Use Type: https.
6. Use Port: 4443, or another approved test port.
7. Use the same hostname or a dedicated test hostname.
8. Enable Require Server Name Indication if the server hosts multiple HTTPS sites on the same IP.
9. Select the new certificate.
10. Click OK.
| Setting | Example value | Purpose |
| Type | https | Creates an SSL/TLS binding. |
| IP address | All Unassigned or specific server IP | Usually safe to keep as the current site uses, unless there is a specific IP requirement. |
| Port | 4443 | Avoids changing production port 443. |
| Host name | test-hostname.example.com | Used by IIS to match the request to the correct binding. |
| SNI | Checked | Recommended when multiple HTTPS sites share the same IP. |
| SSL certificate | New certificate friendly name | The certificate being validated. |
5.2 Test locally from the server
| curl.exe -vk --resolve test-hostname.example.com:4443:127.0.0.1 https://test-hostname.example.com:4443/ |
The web page may show a 404 or application-level error if the port is not configured for the application route. That is acceptable for certificate testing. The important part is whether the browser or curl output shows the new certificate.
5.3 Browser validation
· Open the test URL using the alternate port.
· Click the browser security/certificate icon.
· Confirm the certificate subject, issuer, and expiration date.
· Confirm the certificate shown is the new one, not the current production certificate.
Firewall note An alternate test port may be blocked from the public internet. This is normal and often desirable. If blocked, test locally from the server or from a trusted network where that port is allowed. |
6. Update the live IIS binding when ready
Moment of change The live certificate is changed only when the existing production HTTPS binding, usually port 443, is edited to use the new certificate. |
1. Open IIS Manager.
2. Go to Sites and select the production site.
3. Click Bindings.
4. Select the existing https binding on port 443.
5. Click Edit.
6. Change only the SSL certificate field to the new certificate.
7. Keep the same IP address, host name, port, and SNI setting unless a planned binding change is required.
8. Click OK.
9. Test the public URL immediately.
6.1 Confirm the live site is using the new certificate
| curl.exe -vk https://your-production-hostname/ |
· Check the certificate dates shown by the browser.
· Confirm the application loads correctly.
· Confirm no certificate warning appears.
· Test from an external network if the site is public.
6.2 Cleanup after the switch
· Keep the old certificate installed for a short rollback period.
· Remove the temporary 4443 binding after testing is complete.
· Remove the old certificate only after the new certificate is confirmed stable.
· Document the new expiration date and renewal owner.
7. Troubleshooting
| Issue | Likely cause | Recommended check |
| Certificate appears in IIS but cannot be selected for binding | Missing private key or wrong certificate store. | Confirm it is in Local Computer > Personal and HasPrivateKey is True. |
| Browser still shows old certificate after binding change | Binding not saved, browser cache, another server, proxy, or load balancer. | Check IIS binding, test with curl, verify DNS points to the expected server. |
| Certificate warning about name mismatch | Hostname is not covered by Subject Alternative Name. | Check SAN values using certutil -dump. |
| Certificate chain warning | Intermediate certificate missing. | Install the intermediate certificate into Intermediate Certification Authorities. |
| Local test works, public test does not | Firewall, NAT, reverse proxy, or load balancer not passing traffic to this server/port. | Test from the server, then from outside. Check network path and public DNS. |
| Application shows 404 on test port | The application route is not configured for that port or host header. | For certificate validation, this is acceptable if the certificate is served correctly. |
| Multiple sites on same IP show wrong certificate | SNI or host header binding issue. | Enable SNI and confirm hostnames are unique across bindings. |
8. Tips for usual hosting providers
Many hosting providers do not expose IIS Manager directly. The process is conceptually the same, but the actions are performed through a hosting control panel or support request.
8.1 Common hosting panel workflow
1. Open the hosting control panel.
2. Find the SSL/TLS or Security section.
3. Generate a CSR if the provider will host the certificate.
4. Use that CSR to issue or reissue the certificate with the certificate authority.
5. Upload the certificate file, private key, and CA bundle/intermediate chain if requested.
6. Apply the certificate to the correct domain or subdomain.
7. Test the public URL in a browser and with an SSL checker if allowed by policy.
8.2 If the provider manages the server
· Ask whether they need a PFX file or separate certificate/private key/CA bundle files.
· Ask whether they can test on a temporary port or staging hostname before changing production.
· Ask them to confirm the private key is present after installation.
· Ask them to confirm the exact binding/domain where the certificate was applied.
· Ask for the certificate expiration date visible from the public endpoint after completion.
8.3 If the provider offers automatic SSL
· Automatic SSL is convenient for standard websites, but confirm whether it supports wildcard certificates.
· Confirm whether DNS validation is required.
· Confirm whether automatic renewal will update the live binding automatically.
· For business-critical sites, still document expiration dates and renewal ownership.
8.4 If a CDN, proxy, or load balancer is involved
· The public certificate may be served by the edge/proxy, not by IIS directly.
· You may need to update both the edge certificate and the origin/IIS certificate.
· Test from the server directly and from the public internet to confirm both layers.
· If public traffic still shows the old certificate, verify DNS and proxy configuration before changing IIS again.
8.5 Information to provide to hosting support
| Provide | Example/description |
| Target hostname(s) | The exact domain, subdomain, or wildcard that must be covered. |
| Certificate files | Certificate, intermediate/CA bundle, and private key or PFX. |
| Requested behavior | Install first, test safely, then switch production only after confirmation. |
| Production binding | Current HTTPS hostname and port, usually 443. |
| Test preference | Temporary port, staging hostname, or local-only validation. |
| Rollback expectation | Keep the previous certificate available until the new one is confirmed. |
9. Final checklist
| Check | Completed |
| Existing IIS bindings backed up | ☐ |
| Current production certificate thumbprint documented | ☐ |
| New certificate expiration date confirmed | ☐ |
| Subject Alternative Name covers all required hostnames | ☐ |
| Server Authentication usage confirmed | ☐ |
| New certificate installed in Local Computer > Personal | ☐ |
| Private key confirmed with HasPrivateKey = True | ☐ |
| Intermediate certificate installed | ☐ |
| Temporary test binding created without touching port 443 | ☐ |
| New certificate validated on test binding | ☐ |
| Production binding updated only during approved window | ☐ |
| Public URL confirmed after final switch | ☐ |
| Temporary test binding removed | ☐ |
| Old certificate retained for rollback period | ☐ |
10. Command reference
View installed certificates for a domain
| Get-ChildItem Cert:\LocalMachine\My | Where-Object Subject -like "*your-domain*" | Select-Object Subject, FriendlyName, NotAfter, HasPrivateKey, Thumbprint |
View IIS SSL bindings
| Import-Module WebAdministration Get-ChildItem IIS:\SslBindings | Format-Table -AutoSize |
View HTTP.sys SSL bindings
| netsh http show sslcert |
Dump certificate details
| certutil -dump "C:\Temp\certificate.crt" |
Test a local alternate-port binding
| curl.exe -vk --resolve test-hostname.example.com:4443:127.0.0.1 https://test-hostname.example.com:4443/ |
Suggested customer-facing update after safe test
| Hello, The new certificate has been installed and tested on a temporary HTTPS binding using a non-production port, so the existing production certificate was not replaced during the test. The test page may return an application-level error, such as 404, because the alternate port is only being used to validate the certificate. The important result is that the server presented the new certificate correctly. The production HTTPS binding can be updated to the new certificate during the approved maintenance window. |
Comments
0 comments
Please sign in to leave a comment.