23 Aug 2026
Microsoft Internet Information Services, commonly known as IIS, is widely used to host websites, web applications, APIs, and enterprise applications on Windows Server.
When IIS handles customer or employee traffic, HTTPS is essential for protecting information exchanged between the browser and server. An SSL Certificate for IIS enables encrypted HTTPS communication and helps authenticate the identity of the website or application.
Although people still commonly refer to these as SSL certificates, modern websites use TLS to establish secure HTTPS connections.
Installing an SSL certificate on IIS involves more than importing a certificate into Windows. You need to generate or obtain the certificate, install it correctly, configure the HTTPS binding, associate the certificate with the correct website, and plan for renewal.
This guide explains how to install an IIS SSL Certificate, configure HTTPS, troubleshoot common certificate problems, and manage certificates efficiently across IIS environments.
IIS can serve websites over HTTP, but HTTPS should be used whenever a website or application handles credentials, personal information, payment data, API requests, business information, or authenticated sessions.
An SSL/TLS certificate provides:
For organizations running IIS on Windows Server, SSL certificates are commonly configured through IIS Manager and the Windows certificate store.
IIS can host:
When these applications are exposed over the internet, HTTPS helps protect communication between clients and the IIS server.
Internal applications can also require HTTPS.
Employee portals, HR systems, customer portals, APIs, and administrative applications may exchange sensitive information even when they are not publicly accessible.
For internal environments, organizations may use certificates issued by an internal PKI rather than publicly trusted certificate authorities.
The appropriate certificate depends on the domains, subdomains, applications, and infrastructure you need to secure.
A single-domain certificate protects one domain name.
For example:
www.example.com
This can be suitable when a single IIS website operates under one primary domain.
A wildcard certificate can protect multiple first-level subdomains.
For example:
*.example.com
It can cover:
However, a wildcard certificate does not automatically cover deeper levels such as:
dev.portal.example.com
A multi-domain certificate can secure several explicitly specified domain names.
This can be useful when a single IIS server hosts multiple applications or websites under different domains.
Certificates can also be selected based on their validation level.
For many public websites, DV may be sufficient. Organizations with additional identity or compliance requirements may choose OV or EV certificates depending on their needs.
Before installing an SSL certificate on IIS, prepare the domain name, certificate files, private key, and certificate chain.
You may need:
The exact files depend on how the certificate was generated and issued.
A Certificate Signing Request contains information required by the certificate authority to issue your certificate.
In IIS Manager, you can generate a CSR through:
Server Certificates → Create Certificate Request
You generally provide:
The certificate authority then uses the CSR to issue your certificate.
The private key is generated when the CSR is created and is associated with the certificate request.
It should never be publicly shared.
If the certificate is being transferred between servers, use an appropriate exportable certificate format such as PFX when required, and protect the PFX file with a strong password.
Installing an SSL certificate on IIS generally involves importing the certificate into the Windows certificate store and then binding it to the appropriate IIS website.
On your Windows Server:
This is where certificates available to IIS can be managed.
If you generated the CSR through IIS, use:
Complete Certificate Request
Select the certificate file provided by your certificate authority.
Provide a friendly name so that the certificate can be easily identified later.
For example:
example.com-2026
If you already have a PFX file containing the certificate and private key, you can import it into the appropriate Windows certificate store.
A PFX file typically contains:
Protect the PFX password and avoid transferring the file through insecure channels.
In IIS Manager:
Configure:
Select the certificate you installed earlier.
Make sure the certificate matches the domain configured in the binding.
For example:
Host name: www.example.com
Port: 443
Certificate: www.example.com
Open:
https://www.example.com
Check that:
An IIS HTTPS binding connects a website to an IP address, port, hostname, and certificate.
A basic HTTPS binding uses:
Type: HTTPS
IP Address: All Unassigned
Port: 443
Host Name: www.example.com
SSL Certificate: Example Certificate
Server Name Indication, or SNI, allows multiple HTTPS websites to use the same IP address and port while presenting different certificates based on the requested hostname.
For example, one IIS server can host:
www.example.com
www.example.net
portal.example.org
Each website can have its own HTTPS binding and certificate.
When configuring the binding in IIS, the Require Server Name Indication option can be enabled when the hosting environment requires it.
SNI is particularly useful when:
If the wrong certificate is displayed, check:
Incorrect bindings are one of the first things to investigate when IIS presents the wrong SSL certificate.
SSL problems on IIS can originate from the certificate, private key, certificate chain, Windows certificate store, or IIS binding.
IIS may not be able to use a certificate if its corresponding private key is unavailable.
This can happen when a certificate is imported incorrectly or when only the public certificate is transferred to another server.
A PFX file is commonly used when the private key needs to be transferred with the certificate.
A certificate may show as untrusted when the required certificate chain is missing or when the certificate was issued by an authority that the client does not trust.
Check the certificate chain and ensure the required intermediate certificates are installed correctly.
Suppose your IIS website is:
www.example.com
but the certificate does not include www.example.com in its valid names.
The browser may display a hostname mismatch warning.
Check the certificate’s SAN entries and make sure the hostname used by the IIS binding is covered.
An expired certificate can cause browsers and API clients to reject HTTPS connections.
Check the certificate’s:
Certificate expiration should be monitored before the expiration date rather than discovered through user complaints.
If IIS displays an unexpected certificate, review the HTTPS bindings.
Check whether multiple websites are using:
SNI configuration should also be reviewed when multiple websites share the same IP address.
If IIS cannot complete a certificate request, verify that the certificate is being installed on the same server where the original CSR and private key were generated.
A certificate issued from a CSR on another server may not have the matching private key available locally.
Certificate renewal should be planned before the current certificate expires.
A typical IIS certificate renewal process includes:
Not always.
If the renewed certificate is installed correctly, you may need to update the HTTPS binding so that IIS uses the new certificate.
The exact process depends on how the certificate was renewed and installed.
After renewal, verify:
Do not consider the renewal complete until the live website has been tested.
Managing certificates manually can become difficult when an organization operates multiple IIS servers and applications.
The risk increases when certificates are spread across:
Certificate automation can help with:
A complete certificate lifecycle process should cover discovery, issuance, renewal, deployment, monitoring, and retirement.
Instead of maintaining spreadsheets and manually checking certificates, organizations can use centralized certificate lifecycle management to maintain visibility across their IIS infrastructure.
This becomes especially valuable when certificates are managed by different application, infrastructure, security, and DevOps teams.
The objective of automation is not simply to renew certificates.
The workflow should ensure that a renewed certificate reaches the correct IIS server, is associated with the correct website, and is validated after deployment.
A properly installed certificate is only one part of secure HTTPS configuration.
Use modern TLS protocols and avoid obsolete protocols unless there is a documented compatibility requirement.
Windows Server and IIS TLS configuration can depend on the underlying Windows version, Schannel configuration, and application requirements.
Private keys should be protected using appropriate Windows permissions and certificate store controls.
Do not place private keys in publicly accessible folders or source repositories.
Maintain an inventory containing:
Do not rely on calendar reminders alone.
Automated monitoring can identify certificates approaching expiration and help infrastructure teams take action before an outage occurs.
Old certificates should be reviewed before removal.
Confirm that no active IIS binding or application depends on the certificate before deleting it from the server.
When an IIS website has an HTTPS problem, work through the certificate and binding configuration systematically.
Open the certificate and verify:
Open:
IIS Manager → Sites → Website → Bindings
Check the HTTPS binding.
Confirm:
Type: HTTPS
Port: 443
Host name: Correct domain
Certificate: Correct certificate
If multiple sites share an IP address, verify SNI.
Use the Windows certificate management tools to confirm that the certificate is installed in the correct store and that the private key is available.
Do not rely only on what appears inside IIS Manager.
Check the certificate presented by the live website using a browser or TLS inspection tool.
This can reveal situations where the correct certificate has been installed but the wrong certificate is still associated with the active binding.
Windows Event Viewer can provide useful information when troubleshooting TLS and Schannel-related problems.
Review relevant Windows and IIS logs when the certificate appears correct but HTTPS connections continue to fail.
Managing certificates on one IIS server is relatively simple.
The operational challenge increases when an organization has dozens or hundreds of Windows servers.
Certificates may be deployed across:
A centralized certificate lifecycle management platform can provide visibility into certificates across these environments.
Teams can track certificate ownership, expiration, deployment status, renewal activity, and compliance requirements from a centralized location.
This helps reduce dependency on manual spreadsheets and individual server administrators.
Managing an SSL certificate on a single IIS website is straightforward. Managing certificates across multiple Windows servers, domains, applications, and environments requires a more structured approach.
Flying Stars can help organizations with SSL certificate selection, installation, renewal, monitoring, and certificate lifecycle management for IIS and broader enterprise infrastructure.
If your team is dealing with certificate expiration, manual renewals, multiple IIS servers, or difficulty tracking certificate ownership, centralized certificate management can help reduce operational risk.
Talk to an SSL certificate specialist about selecting, installing, and managing certificates for your IIS environment.
Monitor, renew, and manage IIS certificates centrally to reduce certificate expiry and deployment risks.
Install the certificate in IIS or the Windows certificate store, then open the website’s Bindings section and create or edit an HTTPS binding on port 443. Select the appropriate certificate and test the website over HTTPS.
IIS commonly works with certificates in formats such as PFX/P12 when the certificate needs to include the private key. A PFX file can contain the certificate, private key, and certificate chain depending on how it was created.
The certificate may not be installed in the appropriate Windows certificate store, may not have its private key, or may have been imported incorrectly. Check the certificate installation and confirm that the private key is available.
Check the HTTPS binding for the website. Verify the IP address, port, hostname, selected certificate, and SNI setting. Multiple IIS websites sharing port 443 can require SNI to ensure the correct certificate is presented.
In IIS Manager, select the website, choose Bindings, click Add, select https, specify port 443 and the hostname, then select the SSL certificate you want IIS to use.
SNI allows multiple HTTPS websites to share the same IP address and port while using different certificates. IIS uses the requested hostname to determine which certificate should be presented.
Not necessarily. You can use a single-domain certificate for one domain, a wildcard certificate for multiple subdomains, or a multi-domain certificate for several specified domains. The best option depends on your domain structure and security requirements.
The hostname requested by the browser may not be included in the certificate’s valid domain names. Check the certificate’s Subject Alternative Name entries and make sure they cover the hostname configured in the IIS HTTPS binding.
The certificate chain may be incomplete, the issuing authority may not be trusted by the client, or an intermediate certificate may be missing. Review the certificate’s certification path and verify that the required chain is available.
Obtain the renewed certificate, install it on the IIS server, and update the relevant HTTPS binding to use the renewed certificate if necessary. Then test the live website and confirm that the new expiration date is being served.
Yes. Certificate renewal and deployment can be automated using appropriate certificate management and automation tools. The workflow should also verify deployment and ensure that IIS uses the renewed certificate.
Open the installed certificate and check its validity dates. For multiple IIS servers, centralized certificate monitoring is more efficient because it can track expiration dates across the environment.
Yes. IIS can host multiple HTTPS websites with different certificates. SNI allows multiple websites to share the same IP address and port while presenting the appropriate certificate based on the hostname.
Browsers and other clients may display certificate warnings or reject the HTTPS connection. Applications and APIs that validate certificates can also stop communicating successfully. Certificate expiration should therefore be monitored and addressed before the expiration date.
Yes. IIS can use wildcard certificates such as *.example.com. They can protect multiple first-level subdomains, which can be useful when several IIS applications use the same domain namespace.
A full IIS restart is not always necessary. After changing an HTTPS binding or certificate, verify the configuration and test the website. The exact behavior can depend on the certificate installation and IIS configuration.
If the private key needs to be transferred, export the certificate with its private key, typically as a password-protected PFX file, and import it on the destination server. Protect the PFX file during transfer and storage.
Use automated certificate discovery, expiration monitoring, renewal, and deployment. Organizations with multiple IIS servers should maintain a centralized certificate inventory instead of relying only on manual reminders.
Yes. Internal applications can use certificates issued by an organization’s internal PKI when the client devices and applications trust the internal certificate authority.
