SelfSSL lets a Windows administrator create a private certificate authority (CA) and issue a TLS certificate for an IIS site. It is best suited to internal, staging, lab, or restricted-network services where you control the clients. The connection can be encrypted immediately, but browsers will still show a trust warning until those clients trust SelfSSL’s root CA. For an Internet-facing site, use a certificate chain trusted by mainstream clients or an enterprise PKI deployed to the clients that need access.
Before you start: confirm SelfSSL fits the site
SelfSSL is a private-trust workflow, not a way to make a certificate automatically trusted by the public web. It is useful when administrators can install the root CA on every relevant client, including through Group Policy for a managed Windows domain. A current overview describes SelfSSL’s fit for internal apps, staging environments, and lab setups where the server and clients are controlled: TechYorker’s SelfSSL guide (2026).
As an Amazon Associate I earn from qualifying purchases.
- Lab, staging, or internal service: SelfSSL can work when you control the clients and can distribute trust.
- Air-gapped or restricted network: A private CA can issue certificates without relying on public certificate services, provided clients can be configured to trust it.
- Public Internet site: Prefer a publicly trusted certificate chain. SelfSSL alone will cause trust warnings for clients that do not have its root CA installed.
- Large managed Windows fleet: Enterprise PKI may be a better fit when centralized issuance and trust distribution are needed.
There are no established adoption, failure-rate, or security-outcome statistics for SelfSSL in the available sources, so the choice should be based on trust management, hostname coverage, issuance and renewal effort, and IIS binding needs—not an assumed success rate.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Create and bind a SelfSSL certificate in IIS
1. Choose the exact hostname
Decide the DNS name users will enter, such as app01.internal.example.com. The certificate’s subject or Subject Alternative Name (SAN), the URL clients use, and the IIS binding hostname must match. Do not issue for one name and expect it to validate for a different alias or for localhost.
#1 Best Overall
2. Install and run SelfSSL with administrator privileges
Install the SelfSSL package or the IIS 6.0 Resource Kit tools, then open an elevated administrator shell. The historical SharePoint instructions specifically call for installing the Resource Kit as Administrator and running SelfSSL elevated; see Al’s Tech Tips’ SharePoint procedure (2015).
3. Generate the certificate for the intended site
Use SelfSSL to issue a certificate for the chosen hostname or IIS site and ensure it is placed in the local computer’s Personal certificate store with its private key. The historical example uses selfssl.exe /s:512363676 /t /v:7 /n:cn=contoso.com and reports that the certificate is stored in Personal. Treat that command as an example from the documented environment, not a universal IIS site identifier or a current recommendation for every installation.
4. Complete the HTTPS binding in IIS Manager
- Open IIS Manager and select the intended site.
- Open Bindings and add or edit the HTTPS binding on port 443.
- Set the binding hostname to the exact DNS name clients will request.
- Select the SelfSSL certificate that was just issued, then save the binding.
The historical SharePoint procedure notes that SelfSSL may create a binding while leaving the administrator to complete the hostname and certificate selection. If several sites share port 443, verify host-name and SNI settings so IIS presents the certificate for the right site.
5. Verify the certificate and test the hostname
Confirm the certificate appears in the local computer’s Personal store and has an associated private key; IIS cannot use a certificate without that private key. Then test with the exact hostname in the browser or client. Testing only with an IP address, localhost, or a different alias can produce a name mismatch even when the intended binding is correct.
Rank #3
6. Distribute trust to clients
Export the SelfSSL root CA certificate and install it in the appropriate trusted root store on each controlled client. In a Windows domain, Group Policy is a practical distribution route; on unmanaged systems, install the root CA on each client that needs to trust the site. Distribute only the root certificate, never the CA’s private key.
Why a browser can still show a certificate warning
The client does not trust SelfSSL’s root CA
Encryption and trust are separate: a TLS session can be encrypted while the browser warns that the issuing CA is not trusted. Every client that connects must trust the SelfSSL root CA. Al’s 2015 SharePoint example records a warning when another server in the domain had not been configured to trust it.
Rank #4
The hostname does not match
Compare the hostname in the address bar with the certificate’s SAN or subject and the IIS binding hostname. Correct the certificate or binding so all three refer to the same DNS name; do not rely on a certificate for one name to validate another.
Recommended Free Tools
IIS is presenting the wrong certificate
When multiple IIS sites use port 443, inspect each HTTPS binding’s hostname and SNI configuration. An incorrect or incomplete binding can cause IIS to return a different site’s certificate.
The certificate lacks a usable private key
Check the certificate in the local computer’s Personal store and verify it has its private key. Without that key, the server cannot use the certificate for its HTTPS binding.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Plan for certificate expiration and renewal
Self-issued server certificates expire. Keep a renewal reminder and define a safe binding-rotation procedure: issue the replacement for the same required hostname, verify its private key and trust chain, update the IIS binding, and test the site before retiring the old certificate. If the root CA itself changes, clients may also need the replacement root distributed before they can trust certificates issued under it.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Free tools Windows power users keep installed
One-click scans. No signup required.
