SSL Certificate Works on WWW but Not Root Domain : Troubleshooting Guide

One of the most common SSL Certificate issues website owners encounter is when their SSL Certificate appears to work correctly on the www version of their domain but fails on the non-www version. Visitors accessing www.example.com see a secure connection, while those visiting example.com receive browser security warnings or connection errors. This situation often leads to confusion because the SSL Certificate itself is perfectly valid, yet the website appears insecure to some visitors.

Understanding why this happens requires knowledge of how web servers handle SSL Certificate connections and how domain configurations affect secure traffic.

Trustico® frequently assists customers with this issue, and this guide explains the causes, diagnostic steps and solutions for resolving SSL Certificate discrepancies between www and non-www domain versions.

Understanding the Problem

When a browser connects to a website using HTTPS, it establishes a connection on port 443, which is the standard port for secure web traffic. The web server must be configured to listen on port 443 and respond with the appropriate SSL Certificate for that specific domain. If the server is not configured to handle secure connections for a particular domain or subdomain, the connection will fail.

The www and non-www versions of a domain are technically different hostnames from a server's perspective. The www version is actually a subdomain, while the non-www version is the root domain or apex domain. Each hostname can have separate configurations on your web server, including separate SSL Certificate bindings. This means that even though your SSL Certificate may cover both versions of your domain, your server must be properly configured to serve that SSL Certificate for each hostname.

When visitors report that your SSL Certificate works on one version of your domain but not the other, the SSL Certificate itself is almost never the problem. The issue lies in how your server has been configured to handle secure connections for each hostname. Learn About Other Common SSL Certificate Errors 🔗

Common Causes of This Issue

Several server configuration problems can cause SSL Certificates to work on the www version but fail on the non-www version of a domain. Understanding these causes helps identify the specific issue affecting your website.

Missing Port 443 Listener for Root Domain

The most frequent cause is that your web server is simply not listening on port 443 for the root domain. When you configured your SSL Certificate, you may have only set it up for the www subdomain. The server accepts secure connections on www.example.com but refuses connections entirely on example.com because no HTTPS listener exists for that hostname.

In this scenario, browsers cannot establish any secure connection to the root domain because the server is not accepting HTTPS traffic for that hostname. The connection attempt times out or is refused outright, resulting in an error message rather than a security warning.

Incorrect SSL Certificate Binding

Another common cause is that the root domain has an SSL Certificate binding, but it is bound to the wrong SSL Certificate. This often occurs on servers hosting multiple websites where a default or self-signed SSL Certificate is returned instead of your actual SSL Certificate.

Windows servers running Internet Information Services (IIS) are particularly prone to this issue because SSL Certificate bindings are configured separately for each hostname. If the binding for your root domain points to a different SSL Certificate than the binding for your www subdomain, visitors will see different SSL Certificates depending on which version of your domain they access.

Server Name Indication (SNI) Configuration Issues

Modern web servers use Server Name Indication (SNI) to serve the correct SSL Certificate when multiple domains share the same IP address. Server Name Indication (SNI) allows the server to identify which hostname the browser is requesting before selecting which SSL Certificate to present.

If Server Name Indication (SNI) is not configured correctly for your root domain, the server may return a default SSL Certificate or the SSL Certificate for a different website hosted on the same server. This results in a name mismatch error where the SSL Certificate presented does not match the domain the visitor requested. Learn About Server Name Indication (SNI) 🔗

Virtual Host Configuration Errors

On Apache and Nginx web servers, virtual host configurations control how the server responds to requests for different domains. If you have configured an HTTPS virtual host for www.example.com but not for example.com, secure connections to the root domain will fail or return an unexpected response.

Virtual host configuration files must include entries for both the www and non-www versions of your domain if you want both to be accessible via HTTPS. Missing or incorrect virtual host entries are a common cause of SSL Certificate accessibility issues.

Load Balancer or Proxy Configuration

Websites using load balancers, reverse proxies or content delivery networks may experience this issue if the SSL Certificate is only configured for one version of the domain at the proxy level. The backend server may be configured correctly, but the load balancer or proxy handles the SSL Certificate termination and is missing the configuration for one hostname.

This is particularly common with cloud hosting platforms where SSL Certificate configuration occurs at multiple layers of the infrastructure. Learn About SSL Certificate Termination 🔗

How to Diagnose the Problem

Before attempting to fix the issue, you should confirm exactly what is happening when browsers connect to each version of your domain. Trustico® provides free diagnostic tools that help identify the specific problem affecting your server configuration.

Using the Trustico® SSL Certificate Chain Analyzer

The SSL Certificate Chain Analyzer at tools.trustico.com/chain 🔗 is an excellent tool for diagnosing this issue. Click the "Obtain from URL" option and enter your domain name to see exactly what SSL Certificate your server returns for that hostname.

Test both versions of your domain separately. Enter www.example.com first and note which SSL Certificate is returned. Then test example.com without the www prefix. Compare the results to identify the discrepancy.

If your SSL Certificate is configured correctly for the www version, the tool will display your SSL Certificate details including the domain name, issuer and expiry date. If the non-www version returns a different SSL Certificate, such as a self-signed SSL Certificate or an SSL Certificate for a different domain, you have confirmed that your server is returning the wrong SSL Certificate for that hostname.

If the tool cannot connect to the non-www version at all, your server is likely not listening on port 443 for that hostname. This indicates a missing HTTPS listener or virtual host configuration rather than an SSL Certificate binding issue.

Using OpenSSL to Test Connections

For more detailed diagnostics, you can use OpenSSL from the command line to test SSL Certificate connections to your server. The following command connects to your server and displays the SSL Certificate information that the server returns.

To test the www version of your domain, use the following command :

openssl s_client -connect www.example.com:443 -servername www.example.com

To test the non-www root domain version, use this command :

openssl s_client -connect example.com:443 -servername example.com

Replace example.com with your actual domain name in both commands. The -servername parameter ensures that Server Name Indication (SNI) is used, which is important when multiple domains share the same IP address. Compare the output from both commands to see if the server returns different SSL Certificates or fails to respond entirely for one hostname.

If OpenSSL reports a connection refused error for one hostname but connects successfully to the other, your server is not accepting secure connections for that hostname. If OpenSSL connects to both but returns different SSL Certificate information, you have an SSL Certificate binding or Server Name Indication (SNI) configuration issue. Explore Our OpenSSL Quick Reference Guide 🔗

Checking Browser Developer Tools

Browser developer tools provide another way to diagnose SSL Certificate issues. In Chrome, Firefox or Edge, press F12 to open developer tools, then navigate to the Security tab. Visit both versions of your domain and compare the SSL Certificate information displayed for each.

The Security tab shows which SSL Certificate the browser received, the connection protocol and any security warnings. If the browser displays different SSL Certificate information for www.example.com versus example.com, your server is presenting different SSL Certificates for each hostname.

Solutions for Common Scenarios

Once you have diagnosed the specific issue, you can implement the appropriate solution. The exact steps depend on your web server software and hosting environment.

Adding an HTTPS Listener for the Root Domain

If your server is not listening on port 443 for your root domain, you need to add an HTTPS configuration for that hostname. The process varies depending on your web server software.

On Apache servers, you need to create or modify a virtual host entry that listens on port 443 for your root domain. The virtual host should reference the same SSL Certificate files that your www configuration uses. Ensure the ServerName directive specifies your root domain without the www prefix.

On Nginx servers, add a server block that listens on port 443 with SSL enabled for your root domain. Reference the same SSL Certificate and Private Key files used by your www server block. The server_name directive should specify your root domain.

On Windows Internet Information Services (IIS), you need to add an HTTPS binding for your root domain in the site bindings configuration. Select your SSL Certificate and specify the hostname as your root domain without the www prefix.

Correcting SSL Certificate Bindings

If your server returns the wrong SSL Certificate for your root domain, you need to update the SSL Certificate binding for that hostname. This typically involves editing the configuration to point to the correct SSL Certificate file or selecting the correct SSL Certificate in your hosting control panel.

On shared hosting platforms, check your SSL Certificate configuration in the control panel. Ensure that the SSL Certificate is assigned to both the www and non-www versions of your domain. Some control panels require you to explicitly add the root domain to the SSL Certificate configuration.

On Windows Internet Information Services (IIS), open the site bindings dialog and check which SSL Certificate is assigned to each hostname. Select the correct SSL Certificate for your root domain binding. If Server Name Indication (SNI) is enabled, ensure the hostname field correctly specifies your root domain.

Configuring Server Name Indication (SNI) Correctly

If your server hosts multiple domains on the same IP address, ensure Server Name Indication (SNI) is properly configured for all hostnames. Each domain and subdomain that should serve HTTPS traffic needs its own configuration entry with the correct SSL Certificate specified.

Verify that your web server software supports Server Name Indication (SNI) and that it is enabled. Most modern web servers support Server Name Indication (SNI) by default, but older configurations may need to be updated.

Implementing a Redirect Strategy

If you prefer visitors to always use one version of your domain, implementing a redirect from one version to the other can simplify your SSL Certificate configuration. However, the redirect itself must be handled carefully to avoid security issues.

For HTTPS redirects to work properly, both versions of your domain must have valid SSL Certificate configurations. The server must accept the secure connection and present a valid SSL Certificate before it can redirect the visitor to the other version. You cannot redirect HTTPS traffic without first establishing a secure connection, which requires a properly configured SSL Certificate binding. Learn About HTTP to HTTPS Redirects 🔗

Verifying Your SSL Certificate Covers Both Domains

Before troubleshooting server configuration, confirm that your SSL Certificate actually covers both versions of your domain. Most SSL Certificates issued today include both the www and non-www versions, but this is not universal.

Checking Your SSL Certificate Coverage

Use the SSL Certificate Decoder at tools.trustico.com 🔗 to view your SSL Certificate details. Look at the Common Name (CN) and Subject Alternative Names (SAN) fields to see which domain names your SSL Certificate covers.

If your SSL Certificate lists www.example.com but not example.com, your SSL Certificate does not cover the root domain. In this case, you would need to reissue your SSL Certificate with the root domain included, or obtain a separate SSL Certificate for the root domain.

Most Domain Validation (DV) SSL Certificates from Trustico® automatically include both the www and non-www versions when you request an SSL Certificate for a standard domain name. However, if you specifically requested an SSL Certificate for only the www subdomain, only that hostname will be covered. Learn About Domain Validation (DV) SSL Certificates 🔗

Understanding Wildcard SSL Certificate Coverage

Wildcard SSL Certificates cover all subdomains at a single level but do not automatically cover the root domain. A Wildcard SSL Certificate for *.example.com covers www.example.com, mail.example.com and any other subdomain, but it does not cover example.com itself.

If you use a Wildcard SSL Certificate and need to secure your root domain, ensure your Wildcard SSL Certificate includes the root domain as a Subject Alternative Name (SAN), or obtain a separate SSL Certificate for the root domain. Learn About Wildcard SSL Certificates 🔗

Communicating with Your Technical Team

If you do not manage your own server, you will need to communicate the issue to your hosting provider or technical team. Here is how to explain the problem clearly.

Inform your technical team that your root domain is not responding on port 443 like your www version is. Explain that this is not an SSL Certificate problem but a server configuration issue. The server is not configured to listen on port 443 for the root domain, or it is returning the wrong SSL Certificate for that hostname.

Provide the results from your diagnostic testing. Share what the Trustico® SSL Certificate Chain Analyzer returned for each version of your domain. If the www version returns your correct SSL Certificate while the non-www version returns a self-signed SSL Certificate or fails to connect, share this information with your team.

Request that your technical team add an HTTPS binding or virtual host configuration for your root domain using the same SSL Certificate that is configured for your www subdomain. They should verify that port 443 is accepting connections for the root domain and that the correct SSL Certificate is bound to that hostname.

Preventing This Issue When Installing SSL Certificates

When installing a new SSL Certificate, take steps to ensure both versions of your domain are properly configured from the start.

Always test both the www and non-www versions of your domain after installing an SSL Certificate. Do not assume that configuring one version automatically configures the other. Each hostname may require its own configuration entry depending on your server software.

Consider using the Trustico® Premium Installation service if you are unsure about configuring SSL Certificates on your server. The Trustico® technical team handles the complete installation and ensures all domain versions are properly configured. Learn About Premium Installation Services 🔗

Summary

When an SSL Certificate works on the www version of a domain but not the non-www version, the problem is almost always a server configuration issue rather than an SSL Certificate issue. The server is either not listening on port 443 for the root domain, or it is returning the wrong SSL Certificate for that hostname.

Use the Trustico® SSL Certificate Chain Analyzer to diagnose the issue by testing both versions of your domain. Implement the appropriate solution based on your web server software, whether that involves adding an HTTPS listener, correcting SSL Certificate bindings or configuring Server Name Indication (SNI) properly.