When working with SSL/TLS certificates, a common pain point emerges when you need to redirect traffic between www and non-www domains. The issue becomes particularly tricky when:

• Your certificate only covers www.site.com
• Users access https://site.com directly
• Browser security warnings must be avoided

Standard HTTP redirects via mod_rewrite or server configs won't work for HTTPS because the SSL handshake occurs before any redirects are processed. The browser sees:

1. Client requests https://site.com
2. Server must present valid cert for site.com (which you don't have)
3. Browser shows security warning before any redirect can execute

Here are three reliable approaches to solve this:

1. Cloudflare Flexible SSL

If you're using Cloudflare:

# In Cloudflare dashboard:
1. Enable "Always Use HTTPS"
2. Set up Page Rules:
   - URL: https://site.com/*
   - Setting: Forwarding URL
   - Destination: https://www.site.com/$1
   - Status code: 301

2. Server-Level Solution (Apache)

For Apache servers, create separate virtual hosts:

<VirtualHost *:443>
    ServerName site.com
    SSLEngine on
    # Use a wildcard cert or separate cert here
    SSLCertificateFile /path/to/cert.pem
    SSLCertificateKeyFile /path/to/key.pem
    Redirect 301 / https://www.site.com/
</VirtualHost>

<VirtualHost *:443>
    ServerName www.site.com
    SSLEngine on
    SSLCertificateFile /path/to/www_cert.pem
    SSLCertificateKeyFile /path/to/www_key.pem
    # Your actual website configuration
</VirtualHost>

3. DNS CNAME Record Solution

The most elegant solution is DNS-level redirection:

; DNS records
@        IN A     192.0.2.1   ; Main IP
www      IN CNAME example.com ; Points to same IP

Then configure your web server to handle both domains under the same SSL certificate.

• For permanent solutions, always get certificates covering both domains
• Let's Encrypt makes it easy to get multi-domain certificates
• Test redirects with curl: curl -vIk https://site.com

Remember that while these solutions work, the most professional approach is to properly certificate all domains you intend to serve content from.

Many developers face this common HTTPS redirection scenario: You have a valid SSL certificate for www.example.com, but not for the naked example.com domain. When users visit https://example.com, browsers show security warnings because the certificate doesn't match.

Traditional HTTP redirect methods (like .htaccess rules) don't work because the SSL handshake occurs before any HTTP traffic. The browser terminates the connection during certificate validation, preventing your server from issuing redirect instructions.

# This won't work for HTTPS:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^example.com [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [L,R=301]

The most reliable approach uses DNS configuration combined with cloud services:

1. Create a CNAME record pointing the naked domain to your www subdomain
2. Use a provider that offers SSL termination (Cloudflare, AWS, etc.)

Example Cloudflare configuration:

Type    Name       Content
CNAME   example.com  www.example.com

If you control the web server, these approaches work:

Apache Configuration

<VirtualHost *:443>
    ServerName example.com
    SSLEngine on
    # Use existing www cert
    SSLCertificateFile /path/to/www.example.com.crt
    SSLCertificateKeyFile /path/to/www.example.com.key
    # Force redirect
    Redirect permanent / https://www.example.com/
</VirtualHost>

Nginx Configuration

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /path/to/www.example.com.crt;
    ssl_certificate_key /path/to/www.example.com.key;
    return 301 https://www.example.com$request_uri;
}

• Always test redirects with curl -vI https://example.com before deployment
• Maintain consistent redirects (301 permanent) for SEO benefits
• Consider purchasing a certificate that covers both domains if traffic volume justifies it