Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →SelfSSL can create a private certificate authority (CA) and issue a TLS certificate for an IIS site. It is suited to development, staging, internal applications, and restricted networks where you control the clients. The certificate can encrypt traffic immediately, but browsers and other clients will still show a warning until they trust SelfSSL’s root CA. TechYorker’s 2026 guide describes this private-trust model and its use cases.
When SelfSSL is the right choice
SelfSSL is most useful when a service is internal and you can install its root CA on every client that needs to connect. That makes it a practical fit for a lab server, staging site, internal dashboard, or air-gapped network. It does not make a certificate publicly trusted: an Internet-facing site generally needs a certificate chain trusted by mainstream clients, while an organization managing many Windows devices may be better served by enterprise PKI. The choice depends on who controls client trust, how certificates will be issued and renewed, hostname coverage, and the complexity of IIS bindings. TechYorker discusses these distinctions.
What you need before creating a certificate
- The exact DNS name: Choose the hostname clients will enter, such as
app01.internal.example.com. The certificate name and the URL must match; do not substitutelocalhostor an unrelated alias when testing. - Administrative access: Install the SelfSSL package or IIS 6.0 Resource Kit tools, then run the utility from an elevated Administrator shell. The documented SharePoint procedure also calls for installing the Resource Kit as Administrator and opening SelfSSL with elevated permissions. Al’s Tech Tips
- A plan for client trust: Decide how you will distribute the SelfSSL root CA. For a Windows domain, Group Policy is a practical way to deploy it; otherwise, install it on each controlled client.
Create the certificate and configure IIS
- Install the tools. Install SelfSSL or the IIS 6.0 Resource Kit tools, and open an elevated Administrator shell. The procedure documented for SharePoint uses the Resource Kit and elevated access. Al’s Tech Tips
- Issue a certificate for the site name. Generate the certificate for the DNS hostname clients will use and store it in the local computer’s Personal certificate store. A historical example in Al’s Tech Tips uses
selfssl.exe /s:512363676 /t /v:7 /n:cn=contoso.com; it reports the certificate in Personal. Treat that command as an example from the documented procedure, not a universal command: replace the site-specific values as appropriate and verify the options supported by the SelfSSL version installed. - Confirm the certificate is usable by IIS. In the local computer’s Personal store, check that the certificate has its private key. IIS cannot use a certificate without the private key.
- Set the HTTPS binding. In IIS Manager, select the site and open Bindings. Edit or add the HTTPS binding, set the host name to the exact DNS name, and select the generated certificate. SelfSSL may create a binding without completing the hostname and certificate selection, so verify these fields rather than assuming the binding is ready. For multiple sites sharing port 443, check host-name and SNI settings to ensure IIS presents the intended certificate.
- Test using the site’s real hostname. Connect to the same DNS name configured in the certificate and IIS binding. A test with another name may trigger a name-mismatch warning even if the site responds.
- Distribute the root CA to clients. Export the SelfSSL root CA and add it to the trust store of each client that should trust certificates it issued. In a domain, use Group Policy where practical; on other controlled clients, install the root CA individually.
Why the browser still warns
SelfSSL’s certificate is privately trusted, not automatically trusted by browsers. A warning from a client that has not been configured to trust the SelfSSL root CA is expected; Al’s Tech Tips documents this occurring when another server connects without the corresponding trust configuration. Al’s Tech Tips
Once the root is trusted, a warning can still point to a different problem. Check the hostname in the address bar against the certificate’s subject or SAN and the IIS binding. Then confirm that IIS has the certificate with its private key and that the correct site binding is selected. On port 443, incorrect host-name or SNI configuration can cause IIS to return a different site’s certificate.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →#1 Best Overall
Keep the certificate working over time
Private certificates expire. Record the expiry date, set a renewal reminder, and plan a binding rotation: issue the replacement certificate, confirm it has a private key and the right hostname, update the IIS HTTPS binding, and test before retiring the old certificate. This avoids leaving renewal until clients begin receiving expiry warnings. SelfSSL’s suitability depends in part on whether you can maintain this issuance and renewal work. TechYorker
Quick Recap
Rank #4
Rank #3
Choose the trust model that fits the site
- SelfSSL: Choose it for controlled internal, development, staging, lab, or air-gapped environments when you can distribute and maintain trust on clients.
- Publicly trusted CA: Prefer this for an Internet-facing site whose visitors’ devices are not under your control.
- Enterprise PKI: Consider this for an organization-managed Windows fleet where centralized issuance and trust distribution are needed.
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.
