Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I've got a wildcard SSL certificate installed on a domain hosted with Media Temples Dedicated Virtual 4.0. Here's a simple example page that I'm trying to serve over SSL: https://ssltest.bblhosted.com/

Now, other people I've asked (about 4 or 5) say the site works fine on their computers, in a variety of browsers, with no security warning. However, I'm getting inconsistent results on my computer.

Here are my results. I'm running the latest OSX, with Windows 7 running through Parallels, and the latest versions of all browsers:

OSX / Firefox: Padlock shows, no problems. Windows 7 / Firefox: Warning - 'This connection is untrusted'

OSX / Chrome: Warning - 'This site's security is not trusted!' Windows 7 / Chrome: Green Padlock - 'Identity verified by RappidSSL CA'.

OSX / Opera: Warning - 'This server's certificate chain is incomplete, and the signer(s) are not registered. Accept?' Windows 7 / Opera: Padlock shows, 'securely connected, clean security record'.

OSX / Safari: Warning - 'Safari can't verify the identity of the website'

Windows 7 / IE: Padlock shows, 'This connection to the server is encrypted'.

My question is, can anyone provide any insight into what might be causing the issue here, or how to go about fixing it? Could it be just a problem on my computer, and if so, what? What's particularly strange is that I get opposite results on OSX vs. Windows 7, for the same browsers.

Even if you can just comment what browser / OS you're using, and whether or not it worked for you, that'd be great! Thanks.


The initial email from Rapid SSL gave me one Certificate and one CA certificate. I've updated it to include the two CA certificates here, that Christopher Perrin linked to.

I've tested ssltest.bblhosted.com with Rapid SSL's tool and it says everything is set up correctly (although that tool gave a success before I changed the CA certificate, too).

This tool gives an error - and says it's most likely an intermediate certificate issue.

I'm updating the certificate through Plesk, and I do get the warning "Warning: the CA certificate does not sign the certificate.", though according to this, you can generally ignore that warning.

SSL works fine for https://www.bblhosted.com/, https://bblhosted.com/ and https://anythinggoeshere.bblhosted.com/ - it only doesn't work for subdomains which have been explicitly set up.

in var/log/httpd/error_log, I have a bunch of errors like: "RSA server certificate wildcard CommonName (CN) `*.bblhosted.com' does NOT match server name!?"

and in ssl_error_log, I have a bunch of errors like: "[warn] RSA server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)"

I'm not experienced enough to know what they mean. I'll continue the battle tomorrow!

share|improve this question
The opera error This server's certificate chain is incomplete is the most likely one to lead you to the correct fix. –  Zoredache Jan 4 '13 at 7:08
PC is not an operating system –  Eric DANNIELOU Jan 4 '13 at 10:42
Sorry, I mentioned I'm running the latest OSX, with Windows 7 running through Parallels, so people will probably figure out what I'm referring to by PC. Anyway, I've now changed PC to Windows 7. –  joshua.paling Jan 4 '13 at 10:45
add comment

3 Answers

It is possible that your certificate chain is not complete. You might need to add the RapidSSL CA Bundle. to your certificate.

In Apache you have the option SSLCertificateChainFile. Set this to the path where you saved the RapidSSL CA Bundle.

Another option is to add the chain certificates to your own by appending them to your certificate like this

cat mycert.pem RapidSSL_CA_bundle.pem >> mychainedcert.pem

This should solve the problem.


You obviously bought your certificate at RapidSSL. RapidSSL though is not one of the CAs that your browsers trust. This is no problem because your browser trusts GeoTrust and GeoTrust trusts RapidSSL. You just have to show the browser the certificate that proves this. That is why you need to include the chain file.

share|improve this answer
this is likely the correct answer. –  ItsGC Jan 4 '13 at 7:23
add comment

I recently configured exactly this scenario. I would have to verify further, BUT:

When checking your certificate details, you get:

Nome DNS: *.bblhosted.com Nome DNS: bblhosted.com

You got bblhosted.com as AltDNSName.

I got around the behaviour you're experiencing by having one certificate for the root domain and one wildcard cert for every othersubdomain.

That way the pattern mask of the certificate will match the given url in all the possible ways a browser should check for it.

TL;DR: get two new certificate, one with just "bblhosted.com" as altDnsName/CN and one with "*.bblhosted.com".

EDIT: You could check if that is the issue by running some free certs by the guys at http://www.cacert.org . I didn't bother with a commercial cert and i have those as my main ssl certificates. The only hassle is most OS do not ship their Root certificate, so you'll have to install it on your own.

share|improve this answer
add comment
up vote 1 down vote accepted

OK so Christopher Perrin put me on the right track with SSLCertificateChainFile - thanks. Here are the specifics, in case they help someone else. I'm using Plesk 11, and obviously the paths I refer to will be different for others.

When I create the subdomain ssltest.bblhosted.com, Plesk creates a file at /var/www/vhosts/ssltest.bblhosted.com/conf/13558069200.18494000_httpd.include (or similar). This file effectively serves the purpose of a vhost.conf file (or vhost_ssl.conf), except that it's automatically generated by plesk, and will be automatically overriden each time you change settings through Plesk.

The file contains the line:

SSLCertificateFile /usr/local/psa/var/certificates/cert-Eq8jue

which shows where to find my SSL certificate. What it doesn't contain is a line indicating where to find the CA certificate. So it should contain the line:

SSLCertificateChainFile /usr/local/psa/var/certificates/cert-t8ReAO

(Obviously the path should point to your own CA Certificate). As far as I can tell, the fact that this line is not included is a bug in Plesk. You could add the line to that file, directly below the SSLCertificateFile line, and then restart Apache, and it would work - HOWEVER, if you do that, the file will get overriden next time you change the settings for that domain in Plesk, and you'll lose your changes. At the top of the file, Plesk gives this warning:



So, I created /var/www/vhosts/ssltest.bblhosted.com/conf/vhost_ssl.conf and added the single line to it:

SSLCertificateChainFile /usr/local/psa/var/certificates/cert-t8ReAO

You don't need to add anything else but that single line. From what I know, all other settings will still get taken from the default httpd.include file generated by Plesk.

Now, you have to tell Plesk to look for the vhost_ssl.conf file, because it won't by default - even though you've created it! Do this by logging in via SSH and executing this command:

/usr/local/psa/admin/bin/httpdmng --reconfigure-all

That will tell Plesk to look for vhost.conf (and vhost_ssl.conf) for all domains. You can also do it for just a single domain if need be.

Last, restart Apache, and the SSL works!

Note that if you add another subdomain, you need to go through the whole process again, including executing the terminal command to make Plesk look for vhost.conf and vhost_ssl.conf for your new domain or subdomain.

share|improve this answer
wouldn't work if you merged the certificate and then chain certs in one file. Then you wouldn't need the SSLCertificateChainFile directive AFAIK. –  Christopher Perrin Jan 6 '13 at 4:56
I tried merging the certificate and CA certificate in one file, and disabling the SSLCertificateChainFile directive. It didn't work for me. –  joshua.paling Jan 6 '13 at 22:40
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.