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. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
