Mark, On 5/27/15 4:56 AM, Mark Thomas wrote: > On 26/05/2015 08:28, Mark Thomas wrote: >> On 25/05/2015 15:18, Rainer Jung wrote: >> >> <snip/> >> >>>> Mark has been doing a whole lot of work recently to both unify the TLS >>>> configuration across all connectors (OpenSSL and JSSE) as well as >>>> support SNI. Since it's all changing, this would be a good time to >>>> either add some new configuration attributes (-0 for me) or to change >>>> the format of the "certificate" (or whatever) value to support multiple >>>> values. I'm +1 for something like comma-separated multi-valued, like >>>> this: >>>> >>>> <SSLHostConfig ... >>>> certificateFile="/path/to/rsa.pem, , /path/to/ec.pem" >>>> >>>> Note the double-comma, indicating that there is no DSA certificate in >>>> this example. >>> >>> Actually only the first certificate has a special meaning. AFAIK the one >>> with the RSA key has to come first, DSA (very rarely used) and EC(DSA) >>> (should become more popular) can come after without any special ordering >>> and without any problem if one or both are missing. New server key types >>> can turn up in the future and then the number could grow. >> >> Presumably this doesn't just affect the certificate. It also affects the >> key and the certificate chain. >> >> Allowing all of these to be multi-valued is going to create >> configuration complexity - particularly since order is going to have to >> be maintained across multiple attributes. >> >> In future we may also need to know the type of certificate. >> >> I'm leaning towards a nested <Certificate .../> element under SSLHostConfig. >> >> Does Java support this sort of thing? I need to check but I suspect not. > > It doesn't but... > > We could easily extend the hack we used for SNI as follows: > > 1. When parsing the client hello, remember the cipher suites the client > asked for (currently we just skip over them). > > 2. Filter the server supported cipher suites for each SSLHostConfig > based on which certificate types are available. > > 3. When doing selecting the SSLHostConfig and more than one certificate > is present identify the preferred cipher suite (if server order: first > cipher in server list that client supports; if client order: first > cipher in client list that server supports) and from that select the > appropriate certificate. > > And bingo, we can support RSA, DSA, ECC and whatever is next type certs > in parallel. > > I'll add an enhancement for Tomcat 9 to support this.
+1 This is the way to go IMO. -chris
signature.asc
Description: OpenPGP digital signature
