On first glance, it's rather stupid, but Apache (partly due to baggage from the underlying OpenSSL, but this baggage was unavoidable) requires the end-entity certificate (the certificate which contains the public key for which you have the private key) to be loaded separately from the chain that leads to the trust anchor.
However, it becomes a bit clearer why this is the case when you consider that an X.509 certificate has absolutely nothing within itself to identify how deep its trust structure is. This is intentional, as a CA Alpha could become trusted by another CA Beta. CA Beta has a huge trust base, while CA Alpha has a very small one. If the end-entity certificate EEAlpha were issued by an intermediate A' issued by Alpha, A' would know that it was 1 step down, and EEAlpha would know that it was 2 steps down. However, because of the cross-certificate potential (Beta certifies Alpha), EEAlpha could potentially be either 3 or 4 steps away from a widely-used trust anchor (depending on how you count it). What the SSLCertificateChainFile directive is is the list of intermediate certificates between the end-entity and a widely-used trust anchor. (You're right, it doesn't have 'CA' in it. It's confusing enough to those of us who know it.) The 'trust anchor' is, technically, the CA public key that's embedded in the client software. You need to get something signed by the CA root private key which states that it's authorized to act as an intermediate CA, that in turn signs something that may be the end-entity certificate or may be another intermediate CA, and you need every one of those intermediate certificates including the one that signed your end-entity certificate (the one in the Issuer field, the one identified by the Authority Key Identifier extension). I consider it a bug in the TLS protocol that multiple peer identities (either server or client) cannot be proffered simultaneously, and that there is the potential to rely on the CA Key extension (which has the potential to lead to a very difficult-to-troubleshoot situation absent custom tools) to form the basis for a multiply-identified server which owner was trying to manage its risks by having EE certs from more than a single provider. -Kyle H On Thu, Aug 12, 2010 at 3:07 PM, Bill Moseley <mose...@hank.org> wrote:
On Thu, Aug 12, 2010 at 1:56 PM, <aerow...@gmail.com> wrote:You're looking at a couple of issues here. (First, please be aware that this is the OpenSSL users list, not necessary a mod_ssl support list; however, since they're intertwined, we do have some knowledge of mod_ssl.)Plus, single-to-noise ration is quite good here. ;)What you need to do is change that from 'SSLCACertificateFile' to 'SSLCACertificateChainFile'.So you mean combine my certificate and the intermediate certificate? cat my_site.crt intermediate.crt > bundle.crt SSLCACertificateChainFile /etc/apache2/ssl/bundle.crt Invalid command 'SSLCACertificateChainFile', perhaps mis-spelled or defined by a module not included in the server configuration There's SSLCertificateChainFile, but if I set that w/o SSLCertificateFile I get: [error] Server should be SSL-aware but has no certificate configured [Hint: SSLCertificateFile] And with SSLCertificateFile and SSLCertificateChainFile set I still have the same issue that some browsers report: The certificate is not trusted because the issuer certificate is unknown. (Error code: sec_error_unknown_issuer) In Firefox, but Chrome accepts it fine. Again, I am not using client authentication. Thanks, -- Bill Moseley mose...@hank.org
smime.p7s
Description: S/MIME Cryptographic Signature
