Normally with a virtual host an ssl is setup with the following directives:

Listen 443 

SSLCertificateFile /home/web/certs/domain1.public.crt
SSLCertificateKeyFile /home/web/certs/domain1.private.key
SSLCertificateChainFile /home/web/certs/domain1.intermediate.crt

From: For enabling SSL for a single domain on a server with muliple vhosts, will this configuration work?

What is the difference between SSLCertificateFile and SSLCertificateChainFile ? The client has purchased a CA key from GoDaddy. It looks like GoDaddy only provides a SSLCertificateFile (.crt file), and a SSLCertificateKeyFile (.key file) and not at SSLCertificateChainFile.

Will my ssl still work without a SSLCertificateChainFile path specified ?

Also, is there a canonical path where these files should be placed?

  • 1
    The most commonly places I see people putting the cert files is in /etc/ssl, /usr/local/etc/ssl, or in a ssl subdirectory specific to the website (eg /home/www/example.com/data has the website then home/www/example.com/ssl has the certs).
    – Chris S
    Apr 24, 2012 at 17:51

4 Answers 4


Strictly speaking, you don't ever need the chain for SSL to function.

What you always need is an SSLCertificateFile with a SSLCertificateKeyFile containing the correct key for that certificate.

The trouble is, that if all you give Apache is the certificate, then all it has to give to connecting clients is the certificate - which doesn't tell the whole story about that SSL cert. It's saying, "I'm signed by someone, but I'm not going to tell you about them".

This usually works fine, as most client systems have a large store of CA certificates (both root and intermediate) which it can check through for a matching signing relationship to establish trust. However, sometimes this doesn't work; most often the issue you'll run into is a client that doesn't hold the cert for an intermediate CA that's signed your certificate.

That's where the chain comes in; it lets Apache show the client exactly what the trust relationship looks like, which can help a client fill in the blanks between your cert, a root they trust, and the intermediate that they don't know about. The chain can be included in your configuration in one of two ways:

  • Embedded in the same file as you've set for your SSLCertificateFile, on new lines after the server certificate in order (the root should be at the bottom). If you set it up like this, you'll want SSLCertificateChainFile pointed to the exact same file as SSLCertificateFile.
  • In a separate file configured in the SSLCertificateChainFile directive; the CA certificate that issued the server's certificate should be first in the file, followed by any others up the the root.

Check the certificate file that you have now - I'm betting that it doesn't have the chain data included. Which usually works fine, but will eventually cause an issue with some browser or other.

  • 2
    I think "usually works fine" doesn't really apply anymore to GoDaddy certs, if the intermediate isn't included. I'm not even sure if it applies anymore to guys like Verisign and Thawte, actually, since they've moved to make the site certs more distant from the base ones that are included in the browser. I imagine it makes revocation easier, since it's simpler to kill the intermediates.
    – cjc
    Apr 24, 2012 at 15:56
  • "Embedded in the SSLCertificateFile": I wished this worked, but it doesn't seem to, and isn't mentioned in the docs. Your chain has to be put in SSLCertificateChainFile. Sep 27, 2012 at 18:59
  • @SteveKehlet You're right that it's not documented, but I've had it work successfully in the past - how did you format the all-in-one file? Sep 28, 2012 at 7:04
  • 1
    @SteveKehlet Actually, you're right, I remembered wrong; the way I had it set up for a single file was to have both SSLCertificateFile and SSLCertificateChainFile pointed to the same combined file, which works - edited my answer to correct that. Sep 29, 2012 at 20:14
  • @ShaneMadden Beautiful! It works! Thanks so much for figuring that out. Oct 1, 2012 at 21:32

Here is a pretty good explanation of the differences as well as the observable impacts between choosing one vs the other:



Actually, GoDaddy does give you a intermediate chain:


Here's some more discussion.


The email from GoDaddy telling you how to download your new certificate will also have information on the intermediate certificate file. It's somewhere towards the bottom, perhaps after your eyes glaze over from the verbiage and upsell.

In terms of what will happen if you don't include the proper SSLCertificateChainFile directive: you will see a big red warning in your browser because your SSL site will not validate in browsers, as they can't follow the chain of certificates from your site's cert to one owned by a certificate authority the browser knows about.


I'd like to add to the previous good answers about the SSLCertificateChainFile that the order of the certificates in that file is important too. OpenSSL-based clients will sort out the order themselves but gnutls based clients will fail on a chain with the incorrect order.

Test the ordering with gnutls-cli, like

gnutls-cli --x509cafile /etc/ssl/certs/ca-certificates.crt -p https wwwsec.cs.uu.nl

where /etc/ssl/certs/ca-certificates.crt is the location your distro puts the combined certificates.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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