Fixed?

<gerrit-wm> New patchset: Dzahn; "add SSLCACertificate file to gerrit apache

site" [operations/puppet] (production) -
https://gerrit.wikimedia.org/r/4334

<mutante> !log manganese (gerrit) now sends SSL CA certificate on https, (curl

-vvv says verify ok), should resolve [[RT:2777]] and [[BZ:35709]]

This solution seems to be using a config option which is for client authentication w/ client certs, not for certs coming from a server.

http://httpd.apache.org/docs/2.0/ssl/ssl_howto.html#allclients

Serving a CA cert in the certificate chain is only appropriate for intermediate certs not root CA certs AIUI. Example of appropriate serving of certificate chain: bug 23631

See also https://jira.toolserver.org/browse/TS-1351.

IMO, this (change 4334) clearly should be reverted.

I have commented in gerrit:

1. To achieve the change as envisioned by submitter - "SSLCertificateChainFile" option should be used, not "SSLCACertificateFile". This is a good thing so probably gerrit change 4334 could be amended and not reverted.

2. This change will have no effect on toolserver.org client - libcurl is checking certificates by default (and so does git), and the only proper fix is adding the root certificate as trusted per https://jira.toolserver.org/browse/TS-1351.

(In reply to comment #4)

1. To achieve the change as envisioned by submitter - "SSLCertificateChainFile"

option should be used, not "SSLCACertificateFile". This is a good thing so
probably Gerrit change #4334 could be amended and not reverted.

I'm not certain it's a good thing and I still think it should be reverted. I don't care so much for the case of gerrit but in general (and certainly for a higher usage domain like a content wiki; note the same root CA is used for both bugzilla.wikimedia.org and www.wikimedia.org and probably others) I think we probably should not serve the root CA cert in a cert chain unless we actually expect it to make a difference for a client. (so, either because the CA told us to or because someone found a UA that behaves differently whether or not we serve the root cert in a chain)

The only reason I know of for a widely accepted root CA cert to also be an intermediate cert signed by some other root CA is if it's a new cert that wants to get into browsers earlier than it would otherwise. (or to get in retroactively for an already released or frozen root store)

That is a state that a root would be in only at the beginning of it's life cycle; it won't get to be an intermediate later after already being an accepted root. This particular root seems to have been first generated in 1998.

I'm no expert on PKI genealogy or SSL / TLS service configuration or protocols. However, my guess is that in all cases where serving a chain would make a difference for conforming clients, the issuing CA would instruct the new cert holder to serve a chain and would provide copies of all the intermediate CA certs to be served. We could ask Equifax explicitly (or I could myself) but I doubt this root doubles as an intermediary for a modern (last ~8 years?) store that doesn't also store it directly. (that's mostly a guess but I did do some quick and dirty [[WP:OR]] that makes me think it's been in mozilla's store either >10 yrs or at least >9.8 yrs)

A root certificate received via TLS Server Certificate exchange does not make it into the list of browser's trusted root certificates. I've never heard about the process of sneaking-in as you describe. You also cannot use root certificate as intermediate, since root certificate by definition has issuer == subject. An intermediate would need to have issuer set to something else.

RFC 5246, section 7.4.2 says:

certificate_list

This is a sequence (chain) of certificates.  The sender's
certificate MUST come first in the list.  Each following
certificate MUST directly certify the one preceding it.  Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate that specifies the root
certificate authority MAY be omitted from the chain, under the
assumption that the remote end must already possess it in order to
validate it in any case.

Including root certificate might have the advantage for clients not having it stored locally, i.e. in theory OCSP or CRL information from extended v3 attributes could be used to verify validity of the whole chain.

Path validation process (RFC 3280 section 6) describes a whole validation
as coming from the top (CA) to the bottom (host certificate). If you don't
have the issuer name (and most importantly, public key) you can't really
verify the chain. Please note, that even if you don't trust the trust anchor
(root CA) you can do certain validation - like expiration dates, names
and making sure the whole chain is really working. So even without trust anchor set some basic validation is still possible.

By the way, https://en.wikipedia.org/ servers a whole CA path including the root and the intermediate CA as well:

depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance CA-3
verify return:1
depth=0 C = US, ST = California, L = San Francisco, O = "Wikimedia Foundation, Inc.", CN = *.wikipedia.org
verify return:1

Please note, it's also a different root. (Because this is the so-called EV certificate).

Equifax / GeoTrust Root CA certificates for import on toolserver:

http://www.geotrust.com/resources/root-certificates/index.html

the gerrit cert is signed by Equifax

See also https://jira.toolserver.org/browse/TS-1369

Yay!

krinkle@willow:~/externals/wikimedia-gerrit$ git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git mediawiki-core
Cloning into mediawiki-core...
remote: Counting objects: 362166, done
remote: Finding sources: 9% (34435/362166)

this is going to take a while :D