Openssl error 19: “Self signed certificate in certificate chain” when keyed by GoDaddy

Question

Can someone help me understand how to verify that my SSL cert is installed properly (or troubleshoot why it isn't)?

I installed GoDaddy SSL certificate on my Apache server. Some users are still reporting issues (Some versions of IE say "This page cannot be displayed" with no further explanation), and openssl says that there is a 'self signed' certificate in the chain. Please note, this is not a self-signed cert. It is signed by GoDaddy. This article has a related answer that did not work: https://stackoverflow.com/a/4106224/1723405

Here are the steps I have taken:

Step 1: Generate a private key

openssl req -out CSR.csr -new -newkey rsa:2048 -nodes -keyout privateKey.key

Step 2: Go to GoDaddy and re-key by pasting CSR.csr.

Step 3: Install the crt and bundle file in Apache and restart.

// In <VirtualHost>
SSLEngine on
SSLProtocol -ALL +SSLv3 +TLSv1
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP
SSLVerifyClient none
SSLCertificateFile      /path/to/allthingsinsurance.net.crt
SSLCertificateKeyFile   /path/to/privateKey.key
SSLCertificateChainFile /path/to/gd_bundle-g2.cr

% apachectl restart

Step 4: Go to any one of several machines and fail to verify using openssl.

% openssl s_client -connect allthingsinsurance.net:443 -showcerts -CApath /etc/ssl/certs

...lots of output, shows certs I installed...
Verify return code: 19 (self signed certificate in certificate chain)

Step 5: Go to online SSL validation services and receive mixed reports:

• whynopadlock.com: self-signed error
• ssltest.net: self-signed error
• ssllabs.com: ok
• crossbrowsertesting.com: similar error

Answer 1

If whynopadlock.com and ssltest.net complain about the certificate while ssllabs.com say that things are fine, check your virtual hosts configuration. SSLLabs.com supports SNI while whynopadlock.com, ssltest.net and older versions of IE do not.

When SNI is not supported by the client, no server name will be available to the webserver which will then fallback to the first matching virtualhost. Perhaps you have another virtualhost for testing purposes that takes precedence over your main website.

The solution is to change this order or use a dedicated IP address for this host.