Self-signed certificates generated locally often fail on other intranet machines because they are not trusted by the client operating systems. The primary cause is that the certificate's Subject Alternative Name (SAN) does not match the hostname used in the browser URL, or the issuing CA is missing from the Trusted Root Certification Authorities store on the client PCs.
Understanding Certificate Trust Chains
When a web server presents a self-signed certificate, the client browser performs a validation check. Unlike public certificates signed by well-known Certificate Authorities (CAs), self-signed certificates lack a pre-existing trust anchor in the global root store. For an intranet environment to accept these certificates without security warnings, two conditions must be met: the certificate must accurately identify the server, and the client must explicitly trust the issuer. If either condition fails, the browser will block access or display a prominent warning, effectively rendering the certificate "not working" for practical purposes.
The Role of Subject Alternative Names
One of the most common pitfalls when configuring IIS with self-signed certificates is neglecting the Subject Alternative Name (SAN) field. Modern browsers enforce strict hostname matching based on RFC 6125. If your certificate was issued for the IP address
192.168.1.10 but users access the site via
intranet.company.local, the certificate will appear invalid even if it is technically correct for that IP. You must ensure that the SAN includes every possible way users might reach the server, including the FQDN, short hostname, and IP addresses.
Client-Side Trust Configuration
Even with a perfectly configured certificate, clients will reject it if they do not recognize the issuer. Since self-signed certificates act as their own root authority, you must manually distribute the certificate file to every client machine. This involves importing the certificate into the
Trusted Root Certification Authorities store. Without this step, the operating system treats the certificate as untrusted, leading to connection failures similar to those seen in public internet scenarios with expired or revoked certs.
Diagnostics and Troubleshooting Steps
To resolve the issue, follow a systematic diagnostic approach starting with the server configuration and moving to client trust.
Verify IIS Binding Configuration
First, inspect the bindings in Internet Information Services Manager. Open
IIS Manager and navigate to the specific site. Check the
Edit Site Bindings dialog. Ensure that the SSL binding uses the correct certificate. Click
Show to view details. Verify that the certificate name matches what you expect. Look at the
Subject and
Issuer fields. If the subject contains only an IP address, update the certificate to include DNS names.
Check Certificate Details in Browser
Access the site from a client machine where the issue occurs. Note the error message. Usually, it states that the certificate name is incorrect or that the issuer is not trusted. Right-click the page and select
Certificate Error, then
View Certificates. Compare the details shown here with the expected values. Pay close attention to the
Alternative Names tab. If the hostname used in the URL is not listed here, the certificate is misconfigured for that specific access method.
Distribute and Install the Certificate
If the certificate details are correct, the problem is likely trust. Export the self-signed certificate from the server. You can do this via the
certlm.msc snap-in or PowerShell. Save the file as a .cer or .pfx file. Copy this file to the client machine. On the client, double-click the certificate file. Choose
Install Certificate. Select
Local Machine as the store location. Place the certificate in the
Trusted Root Certification Authorities store. This action tells Windows to trust any certificate signed by this key.
Automating Distribution with Group Policy
Manually installing certificates on dozens of machines is inefficient. For larger intranets, use Active Directory Group Policy Objects (GPO). Create a new GPO linked to the organizational unit containing your client computers. Navigate to
Computer Configuration >
Windows Settings >
Security Settings >
Public Key Policies. Right-click
Trusted Root Certification Authorities and select
Import. Upload the self-signed certificate file. When clients refresh their group policy, typically within 90 minutes or after a reboot, the certificate will be installed automatically. This ensures consistency across the network.
Testing the Fix
After applying the changes, clear the browser cache on a test client. Restart the browser to ensure no cached errors persist. Reload the intranet site. If configured correctly, the lock icon should appear green or gray, indicating a secure connection. No warnings should appear. If warnings persist, verify that the GPO has propagated successfully by running
gpupdate /force on the client and checking the event viewer for certificate installation logs.
For more information on accessing local resources, see
Access my locally hosted website from another computer using IIS and
Access my locally hosted website from another computer outside my network without a domain name.
Frequently Asked Questions
Why does the certificate work on the server but not on clients?
The server trusts its own self-signed certificate because it resides in the local personal store. Clients do not have this certificate in their trusted root store, so they reject it as untrusted. You must explicitly add the certificate to the client's trusted authorities.
Can I use an IP address instead of a hostname in the certificate?
Yes, but you must include the IP address in the Subject Alternative Name (SAN) field. Browsers prefer DNS names, so using an IP-only certificate may trigger warnings in some modern browsers. Always include both the IP and the FQDN in the SAN for maximum compatibility.
How do I export a self-signed certificate from IIS?
Open the Certificates snap-in for the local computer. Locate the certificate under Personal > Certificates. Right-click the certificate, select All Tasks, and choose Export. Follow the wizard to save it as a .cer file. Do not export the private key unless you need to reinstall the cert on another server.
What is the difference between User and Computer stores in GPO?
Computer store applies the certificate to all users on the machine, which is ideal for shared intranet sites. User store applies it only to the logged-in user. For corporate intranets, always use the Computer store to ensure consistent behavior regardless of who logs in.
Will clearing browser cache fix certificate errors?
Sometimes, yes. Browsers cache SSL state and errors. If you install the certificate correctly but still see warnings, clear the TLS/SSL state in Internet Options or clear the browser cache. This forces the browser to re-evaluate the certificate chain on the next request.