1

A previous question, What is the use of cross signing certificates in X.509? described cross-signed certificates well.

I have a situation where the clients trust CA1 xor CA2, and both need to reach a single service. Logically, this means I need two end-entity certificates for the same hostname. From a single SSL key, I generated a single CSR and submitted to both CAs, and gotten the two separate end-entity certificates.

I configured Apache to serve both certificates together and all relevant intermediates in the chain.

What's gotten me stumped is the ability to get Apache mod_ssl crashes hard with [Tue Nov 25 15:28:35 2014] [error] Init: Multiple RSA server certificates not allowed'

OpenSSL's s_server reads multiple -cert, -dcert arguments, takes the first RSA certificate in the last argument.

Using GnuTLS either via mod_gnutls or directly, either takes just the last certificate or claims The provided X.509 certificate list is not sorted (in subject to issuer order)

I think, reading RFC4158, what I'm trying to do should be valid. Where have I gone wrong? Why does cross-signing only seem to be valid among intermediate and root certificates?

There is no way ahead of time to differentiate between the clients, so I can't cheat and run different vhosts on different IPs (the clients share DNS). I don't have control over getting both CAs into the clients either. The only working work-around I have so far is to push each group of clients to a unique hostname out-of-band.

Community
  • 1
robbat2
  • 149
  • 8

2 Answers2

2

I read the TLS1.2 spec to allow ONLY ONE CHAIN to be sent.:
https://www.rfc-editor.org/rfc/rfc5246#page-48

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.
Community
  • 1
StackzOfZtuff
  • 17,923
  • 1
  • 51
  • 86
  • 1
    Isn't this already ignored by instances where you have an intermediate CA certified by multiple roots? Per RFC4158, figure 8. – robbat2 Nov 27 '14 at 08:17
  • @robbat2: Well, you can have several paths. (That start with the same end-entity-certificate but end with different root CAs.) But AFAIK you only get to *SEND* one of them when establishing TLS/SSL. – StackzOfZtuff Nov 27 '14 at 08:49
2

openssl s_server -cert -dcert is only useful if the certs (and matching keys -key -dkey) are different algorithms. Then it will use e.g. the RSA key&cert for plain-RSA or DHE-RSA key exchange but the DSS key&cert for DHE-DSS. And similarly for ECDSA and ECDHE-ECDSA now that ECC is supported (since 1.0.0 except for RedHat).

Apache appears to be the same. http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatefile says

This directive can be used multiple times (referencing different filenames) to support multiple algorithms for server authentication - typically RSA, DSA, and ECC. ...

and #sslcertificatekeyfile says

The directive can be used multiple times (referencing different filenames) to support multiple algorithms for server authentication. For each SSLCertificateKeyFile directive, there must be a matching SSLCertificateFile directive.

This would only help if you can get your clients to enable/disable different keyexchanges based on which CA they want you to use, which is probably harder and more confusing than using different hostnames.

There actually is a standard extension defined for TLS1.0 by 3546 TLS1.1 by 4366 TLS1.2 by 6066 for the client to identify which CAs it trusts, and would like the server to use. But most extensions are optional and as far as I have seen no browser (or client at all) implements this one.

Community
  • 1
dave_thompson_085
  • 10,064
  • 1
  • 26
  • 29
  • Yes, that trusted_ca_keys extension does look like it would solve the problem; but sadly it seems that neither of these sets of clients nor OpenSSL support it. – robbat2 Nov 27 '14 at 08:11