Comment 4 for bug 1484489

Most OpenStack charms, including openstack-dashboard that this was originally filed against, are affected by this issue because they use the apache2 template from charm-helpers (charmhelpers/contrib/openstack/templates/openstack_https_frontend). Targeting the bug to charm-helpers but other charms would then need to sync charmhelpers and re-release to fix the issue.

Ante's comment is incorrect, this feature was introduced in Apache2 in 2.4.8, as documented here:
http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatechainfile

This has become more of a problem in the last few years, as all public CAs started issuing certificates with chained roots instead of directly from a root certificate. Only a few years ago it was still common to get SSLs issue direct from the root where these chains weren't necessary which is why it is more of a problem now.

Trusty ships with 2.4.7 and I have confirmed both with the charm setup and with a manual setup that it does not send the certificate chain even if all the chain certificates are in the system SSL library (/etc/ssl) and even if all the chain certificates are in the SSLCertificateFile. The only way to make it work on trusty is to setup SSLCertificateChainFile. If you are testing this yourself, note that Google Chrome ships a copy of most intermediate certificates and generally will not complain but most other tools including firefox, wget, python https libraries, etc all require the full trust chain to be sent in order to validate the certificate.

On Xenial, it works fine if you simply chain all certificates into the single certificate file as described by Ante.

For this reason I am proposing a patch which sets SSLCertificateChainFile to the same certificate file as SSLCertificateFile. Though the ChainFile is not required to have the actual SSL Certificate in it, it does not seem to hurt or impact it in any way and this allows the same charm configuration to work on both Trusty and Xenial. The certificate file SHOULD be constructed from leaf to root in that order (simply concatenated into the same file) however in practice it seems to work in any order.

We could have instead used ssl_ca setting and done it separately to ssl_cert, but there are two problems with that
 (a) It would require extra charm code in all of the charms to support passing in the CA certificate, rendering/syncing out the /etc/apache2/ssl/ca_* files on all nodes, etc. This logic is already quite complicated.
 (b) The ssl_ca setting is currently used in some charms (e.g. keystone) to load this CA into the system SSL store in /etc/ssl on all related charms which is probably OK but may not actually be desired or expected. i.e. this lets an otherwise non-trusted and likely self-signed CA become trusted if you are using a private CA, but is overkill for a simple certificate chain.

Thus the simple approach to configure SSLCertificateChainFile as the same file is a single one-line patch, requires no extra logic, is equally compatible on Trusty and Xenial and has the least possible effect on the general SSL configuration of the system.

It should then fix all charms using the charm-helpers code once synced, a non-exhaustive list o those appears to be:
 - ceilometer
 - cinder
 - glance
 - heat
 - keystone
 - neutron-api
 - nova-cloud-controller
 - swift-proxy