While SNI (Server Name Indication) is typically associated with shared hosting environments, I recently encountered a puzzling case where a Plesk-managed LAMPP server was exhibiting SNI-like behavior despite using dedicated IP addresses. The symptom: Internet Explorer 9 on Windows Vista (Trident/5.0) received a Parallels Panel self-signed certificate instead of the valid RapidSSL certificate that modern browsers received.

Multiple SSL checkers revealed the dual-certificate scenario:

# Valid certificate seen by most clients:
Common Name: www.menswearireland.com
SANs: www.menswearireland.com, menswearireland.com
Issuer: RapidSSL CA

# Invalid certificate seen by legacy clients:
Common Name: Parallels Panel
Issuer: Parallels Panel (self-signed)

The root cause was Plesk's default behavior of maintaining two certificate chains:

1. The intended commercial certificate (RapidSSL in this case)
2. A fallback self-signed certificate for panel administration

Legacy clients without SNI support (like IE9 on older Windows) would receive the fallback certificate. The solution required modifying Plesk's SSL configuration:

# SSH into server and navigate to Plesk's SSL dir
cd /usr/local/psa/admin/conf/httpsd/

# Backup original configuration
cp ssl.conf ssl.conf.bak

# Edit the virtual host configuration
nano ssl.conf

Add these directives to ensure single-certificate delivery:

<VirtualHost [dedicated_ip]:443>
    ServerName menswearireland.com
    ServerAlias www.menswearireland.com
    SSLEngine on
    SSLProtocol all -SSLv2 -SSLv3
    SSLCertificateFile /path/to/rapidssl.crt
    SSLCertificateKeyFile /path/to/private.key
    SSLCertificateChainFile /path/to/intermediate.crt
    SSLHonorCipherOrder on
    Header always set Strict-Transport-Security "max-age=63072000"
</VirtualHost>

Use OpenSSL to verify certificate delivery:

# Check certificate for modern clients
openssl s_client -connect menswearireland.com:443 -servername menswearireland.com

# Check certificate for legacy clients
openssl s_client -connect menswearireland.com:443

Both commands should now return the RapidSSL certificate chain. For comprehensive testing, use SSL Labs' advanced tester:

curl https://api.ssllabs.com/api/v3/analyze?host=menswearireland.com

The described HTTP/HTTPS redirect issue requires modifying .htaccess:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} ^/account [NC]
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

RewriteCond %{HTTPS} on
RewriteCond %{REQUEST_URI} !^/account [NC]
RewriteRule ^ http://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

When your server delivers different SSL certificates to different browsers, you're typically dealing with one of these scenarios:

// Common certificate delivery patterns
1. SNI-capable browsers → Valid domain certificate
2. Non-SNI clients → Default/fallback certificate
3. IE-specific cases → Certificate chain issues

The key findings from the diagnostic data reveal:

• Modern browsers receive: RapidSSL cert for www.menswearireland.com
• Legacy clients receive: Parallels Panel self-signed cert
• Server environment: Plesk-managed LAMPP stack

To verify the certificate presentation behavior:

# Check certificate for SNI-enabled clients
openssl s_client -connect menswearireland.com:443 -servername menswearireland.com

# Check certificate for non-SNI clients  
openssl s_client -connect menswearireland.com:443

The solution involves correcting Plesk's SSL configuration:

# Sample apache configuration for proper cert handling
<VirtualHost *:443>
    SSLEngine on
    SSLCertificateFile /path/to/domain_cert.pem
    SSLCertificateKeyFile /path/to/domain_key.key
    SSLCertificateChainFile /path/to/intermediate.crt
    ServerName menswearireland.com
    ServerAlias www.menswearireland.com
</VirtualHost>

Post-configuration verification steps:

1. Clear all browser caches
2. Test with SSL Labs' analyzer
3. Verify certificate consistency across:

curl -vk https://menswearireland.com
curl -vk https://www.menswearireland.com