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. >>> Furthermore if we want to support all three (RSA, DSA, EC) at the same >>> time, it would require the use of a new tcnative version, because it has >>> a fixed array length of 2 for the certificates. >> >> Do you mean a new major version of tcnative? Presumably, we'd need a new >> version to wire those certificates all the way down to OpenSSL... or >> does tcnative /currently/ have the capability to offer /two/ different >> types, just not /three/? >> >> In any case, it makes sense to me to start improving tcnative with an >> eye towards supporting these use cases in the future, even if we aren't >> ready at the Tomcat level. > > tcnative already supports up to two certificates if the Java API > provides an index when handing over the certificate. Tomcat always sets > the index to 0. > > So if we are goint to improve Tomcat to handle multiple certificates, > tcnative must be able to handle the incoming indexes. The biggest > allowed index currently is 1. Short term mitigation would be to simply > allow max 2 (0, 1, 2) in tcnative, but actually it would be better to > allocate them dynamically. That would simply be a new minor version of > tcnative, because the API stays compatible. > > Then we would require that new tcnative version in all Tomcat versions, > handing over more than one certificate. If we wouldn't require it, a new > Tomcat could pass an index > 1 to an old tcnative version that leads in > overwriting parts of memory. I'd have no issue with bumping the minimum required version. As an aside, we probably should rethink our versioning scheme for tc-native (more along the lines of semantic versioning). Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
