When dealing with Apache SSL certificate updates on CentOS 5.5 (Apache 2.2.3/mod_ssl), a particularly stubborn issue occurs where browsers continue to report certificate expiration despite proper installation of new certificates. This manifests even after:

• Correct configuration in ssl.conf
• Verification of certificate validity dates
• Multiple browser cache clears
• Apache service restarts

The critical configuration elements in /etc/httpd/conf.d/ssl.conf appear correct:

SSLCertificateFile /var/certs/gentlemanjoe.com/new2011/gentlemanjoe.com.crt
SSLCertificateKeyFile /var/certs/gentlemanjoe.com/new2011/gentlemanjoe.com.key
SSLCertificateChainFile /var/certs/gentlemanjoe.com/new2011/gd_bundle.crt

Yet Apache logs reveal a warning during restart:

[warn] RSA server certificate CommonName (CN) www.gentlemanjoe.com' does NOT match server name!?

To verify the actual certificate being served, use OpenSSL's client simulation:

openssl s_client -connect gentlemanjoe.com:443 -servername gentlemanjoe.com | openssl x509 -noout -dates

This bypasses browser cache and shows the raw certificate data. If this shows old dates, we've confirmed Apache isn't serving the new certificate despite the configuration.

On CentOS 5.5 with Apache 2.2.3, there's a known issue where mod_ssl may cache certificates in unexpected locations. Check these additional paths:

ls -la /etc/pki/tls/certs/
ls -la /etc/httpd/conf/ssl.crt/

Sometimes old certificates persist in these directories and get loaded preferentially.

When all else fails, completely reset the SSL environment:

# Stop Apache
service httpd stop

# Clear all SSL caches
rm -f /var/cache/mod_ssl/scache/*
rm -f /var/run/httpd/*ssl*

# Verify no Apache processes remain
ps aux | grep httpd

# Then start fresh
service httpd start

This forces Apache to rebuild all SSL contexts from scratch.

While the "Andromeda" server header seems suspicious, it's likely unrelated to the SSL issue. This could be from:

• Magento modifications
• A proxy layer not visible in the configuration
• Custom Apache modules

After implementing fixes, verify with:

# Check which certificate Apache is actually using
openssl s_client -connect localhost:443 -servername gentlemanjoe.com | openssl x509 -noout -text

# Check all virtual hosts are using the correct cert
apachectl -S

# Verify the certificate chain
openssl verify -CAfile /var/certs/gentlemanjoe.com/new2011/gd_bundle.crt /var/certs/gentlemanjoe.com/new2011/gentlemanjoe.com.crt

---

When Apache continues serving an expired SSL certificate despite proper installation of new certificates, it typically indicates one of these scenarios:

# Verify loaded modules
httpd -M | grep ssl
# Check virtual host configuration
apachectl -S
# View loaded certificates
openssl s_client -connect localhost:443 -showcerts

First, confirm the certificate chain is properly configured. For GoDaddy certificates, the intermediate CA must be correctly specified:

# Verify certificate chain order
cat /var/certs/gentlemanjoe.com/new2011/gentlemanjoe.com.crt \
    /var/certs/gentlemanjoe.com/new2011/gd_bundle.crt > combined.crt
openssl verify -CAfile combined.crt gentlemanjoe.com.crt

The configuration shows the VirtualHost is bound to 127.0.0.1:443, which suggests this might be a reverse proxy setup. Check for:

• Additional VirtualHost directives in other files (use grep -r "VirtualHost" /etc/httpd/)
• Proxy configurations that might be terminating SSL elsewhere
• Multiple Apache instances running simultaneously

Apache loads certificates differently based on configuration. Try forcing a full restart instead of graceful:

# Hard restart Apache
service httpd stop
sleep 5
service httpd start
# Verify PID to ensure complete restart
ps aux | grep httpd

The "Andromeda" server header suggests either:

1. Custom ServerTokens directive in httpd.conf
2. Reverse proxy or load balancer in front of Apache
3. Modified Apache source build

Check with:

# Search for ServerTokens modifications
grep -r "ServerTokens" /etc/httpd/
# Check network configuration
netstat -tulnp | grep 443

Create a test configuration that eliminates all variables:

Listen 8443
<VirtualHost *:8443>
    SSLEngine on
    SSLCertificateFile /path/to/new/cert.crt
    SSLCertificateKeyFile /path/to/new/key.key
    SSLCertificateChainFile /path/to/intermediate.crt
    DocumentRoot /tmp/test
</VirtualHost>

Then test with openssl s_client -connect localhost:8443

• Verify file permissions (certificates should be readable by Apache user)
• Check for SELinux context issues: ls -Z /var/certs/
• Confirm time synchronization: date; hwclock
• Inspect all enabled modules: ls /etc/httpd/conf.d/