{"id":4568,"date":"2026-08-15T03:51:14","date_gmt":"2026-08-15T03:51:14","guid":{"rendered":"https:\/\/ownwebservers.com\/kb\/?p=4568"},"modified":"2026-08-15T03:51:16","modified_gmt":"2026-08-15T03:51:16","slug":"www-non-www-domains-ssl-certificate-redirect","status":"publish","type":"post","link":"https:\/\/ownwebservers.com\/kb\/www-non-www-domains-ssl-certificate-redirect\/","title":{"rendered":"Using www and non-www domains with an SSL certificate"},"content":{"rendered":"\n

Deciding whether your website lives at example.com<\/code> or www.example.com<\/code> is one of the oldest dilemmas on the web. While it might seem like a trivial preference, the choice carries significant technical and SEO implications once you introduce SSL certificates into the mix. Modern browsers display an explicit “Not Secure” warning for any page lacking a valid HTTPS connection, and if you aren’t careful, managing traffic between your www and non-www variants can inadvertently trigger those warnings.<\/p>\n\n\n\n

The challenge lies in the fact that search engines and web browsers treat the www<\/code> and non-www<\/code> versions of your domain as entirely separate entities. If both resolve to your server but only one is secured, or if they are not properly linked together, visitors might hit a security error wall before they ever see your homepage.<\/p>\n\n\n\n

In this guide, we will walk through the proper way to configure www non-www SSL setups, establish a 301 redirect canonical path, and ensure your visitors\u2014whether they type the prefix or not\u2014arrive safely at a single, encrypted destination.<\/p>\n\n\n\n

Understanding www vs non-www and SSL Certificate Coverage<\/h2>\n\n\n\n

From a DNS perspective, the root domain (example.com<\/code>) and the www subdomain (www.example.com<\/code>) are distinct records pointing at your server. To secure both, you cannot rely on a single-factor certificate. You must install an SSL certificate that explicitly covers both hostnames. <\/p>\n\n\n\n

The Role of SAN and Let’s Encrypt<\/h3>\n\n\n\n

Historically, securing multiple hostnames required complex configurations. Today, this is handled using a Subject Alternative Name (SAN) certificate. A SAN allows a single certificate to secure multiple domains or subdomains. <\/p>\n\n\n\n

For most small business owners, the easiest way to achieve this is through Let’s Encrypt, which issues free SSL certificates. A standard Let’s Encrypt SAN certificate auto-provisions both the root domain and the www variant by default. By utilizing Let’s Encrypt, you ensure that regardless of which version a user types into their browser, a valid SSL\/TLS handshake can be established.<\/p>\n\n\n\n

Preventing Mixed Content Warnings and Security Errors<\/h3>\n\n\n\n

If your non-preferred hostname resolves but lacks SSL coverage, any visitor arriving via HTTPS on that specific variant will be greeted with a browser security error. Furthermore, if traffic is incorrectly forwarded over HTTPS to HTTP content, browsers will block elements on the page, resulting in mixed content warnings. Properly securing both variants is mandatory to establish trust, prevent malicious attacks like SSL stripping, and maintain a professional user experience.<\/p>\n\n\n\n

Configuring Permanent 301 Redirects for Canonical Hostnames<\/h2>\n\n\n\n

Once both variants are secured with an SSL certificates<\/a><\/strong>, your next step is to choose a canonical (primary) hostname. To prevent duplicate content SEO penalties, you must implement a permanent 301 redirect from your non-preferred hostname to your canonical preferred hostname.<\/p>\n\n\n\n

This is essential for consolidating page ranking signals. Search engines like Google allocate ranking signals (like backlinks) to specific URLs. If users link to both example.com<\/code> and www.example.com<\/code>, splitting your traffic means splitting your authority. A 301 redirect consolidates all of that ranking power onto a single domain.<\/p>\n\n\n\n

Implementing Canonical Redirects on Apache and Nginx<\/h2>\n\n\n\n

Apache RewriteEngine Rules for .htaccess and Server Configs<\/h3>\n\n\n\n

In Apache environments, canonical redirects are efficiently handled using RewriteEngine rules in your .htaccess file or central server configuration. If your canonical domain is the non-www version, you would add the following to force all www traffic to the root domain:<\/p>\n\n\n\n

RewriteEngine On\nRewriteCond %{HTTPS} off [OR]\nRewriteCond %{HTTP_HOST} ^www.example.com [NC]\nRewriteRule ^(.*)$ https:\/\/example.com\/$1 [L,R=301]\n<\/code><\/pre>\n\n\n\n
This rule checks if HTTPS is off or if the request included the www prefix, then issues a 301 redirect to the secure, non-www version. A similar rule can be inverted if you prefer the www variant as your primary.<\/p>\n\n\n\n
Nginx Server Blocks for 301 Redirects to the Canonical Host<\/h3>\n\n\n\n
Nginx administrators should configure separate server blocks for the non-primary hostname that return a 301 redirect to the canonical server block. This is highly efficient and processes incredibly fast. If your primary site is www.example.com<\/code>, your Nginx configuration would look like this:<\/p>\n\n\n\n
server {\n    listen 443 ssl;\n    server_name example.com;\n    ssl_certificate \/path\/to\/fullchain.pem;\n    ssl_certificate_key \/path\/to\/privkey.pem;\n    return 301 https:\/\/www.example.com$request_uri;\n}\n<\/code><\/pre>\n\n\n\n
Note that even the non-canonical block must include the SSL certificate paths. If SSL is not configured on the redirecting block, browsers will throw a security error before the redirect can even execute.<\/p>\n\n\n\n
Leveraging CDNs and Edge Redirects for SSL Termination<\/h2>\n\n\n\n
If you are utilizing a Content Delivery Network like Cloudflare, you can manage www versus non-www redirects before traffic ever hits your origin server. CDNs allow seamless SSL termination at the edge, meaning you can enforce Strict HTTPS and manage edge redirects natively from their dashboard.<\/p>\n\n\n\n
This setup significantly minimizes origin SSL CPU overhead on hosting options like shared hosting or a Managed VPS. The CDN handles the cryptographic math required for HTTPS handshakes for millions of visitors, passing only standard HTTP requests back to your origin server behind the scenes.<\/p>\n\n\n\n
Managing SSL AutoSSL in Hosting Control Panels<\/h2>\n\n\n\n
If you operate your business through control panels like cPanel or DirectAdmin, these platforms include an AutoSSL feature that handles certificates automatically. However, when migrating between preferred domains on managed infrastructure, you must verify that autoSSL generation covers the (sub)domain aliases you intend to redirect.<\/p>\n\n\n\n
If you set up a redirect but delete the DNS record or disable the alias in cPanel before AutoSSL renews the certificate, the redirect destination will break at renewal time. Always verify that both root domains and mapped subdomains are listed in the AutoSSL queue to prevent automated certificate renewal failures.<\/p>\n\n\n\n
Configuring Reverse Proxies and Load Balancers for HTTPS Traffic<\/h2>\n\n\n\n
For dedicated servers and private cloud deployments utilizing reverse proxies like HAProxy or load balancers, offloading SSL to the proxy introduces a new challenge: the backend application needs to know if the original request was encrypted.<\/p>\n\n\n\n
Passing the X-Forwarded-Proto Header<\/h3>\n\n\n\n
You must ensure the X-Forwarded-Proto<\/code> header is passed to the backend application. If your load balancer communicates with your application server over HTTP (port 80), but the original user connected over HTTPS (port 443), the backend might assume HTTP is being used. Without this header, frameworks like WordPress or Laravel will attempt to loop the 301 redirect indefinitely, resulting in an “ERR_TOO_MANY_REDIRECTS” error in the browser.<\/p>\n\n\n\n
# HAProxy example for forwarding proto\nhttp-request set-header X-Forwarded-Proto https if { ssl_fc }\n<\/code><\/pre>\n\n\n\n
Best Practices<\/h2>\n\n\n\n