On 13/08/17 16:42, Rainer Jung wrote: > Hi, > > OpenSSl has an API named SSL_CONF_cmd. Te API allows application using > OpenSSL to no longer implement an application specific configuration > option per OpenSSL config feature the app wants to support, but instead > use a more generic approach. The API can be seen here (it was added in > 1.0.2, but also exists in 1.1.0): > > https://www.openssl.org/docs/man1.0.2/ssl/SSL_CONF_cmd.html > > mod_ssl in httpd already supports that API: > > http://httpd.apache.org/docs/2.4/en/mod/mod_ssl.html#sslopensslconfcmd > > The API can be fed with pairs of command names and values. If we would > like to support this, we would have to find an appropriate approach of > supporting name/value pairs in our config. I'd say server.xml (and every > xml based file) isn't appropriate. > > Is there any interest in supporting SSL_CONF_cmd? > > If so, should we > > a) create a new file, e.g. conf/openssl.properties > or > b) pack new properties into catalina.properties, probably with a common > prefix "openssl.conf.cmd."? > > And if catalina.properties, should we add the properties also to java > system properties or filter them? > > Or maybe the other way round: extract all system properties named > openssl.conf.cmd.* and use them? > > If we would want to support different setting per connector or > SSLHostConfig, we would instead need a properties file per connector or > SSLHostConfig, so probably an xml attribute opensslConfCmdFile="..." and > read the properties form there. > > Any opinion?
I like the idea of not having to replicate openssl setters and gettes in Java and C. I think the configuration needs to be per SSLHostConfig. I was thinking of something along the line of IntrosepctionUtils that was passed the attribute name and value from the XML and then called the appropriate API. If the attributes had a common prefix (openssl.cmd...) then ID'ing the name/value pairs should be fairly easy. Haven't thought about how this might integrate with the current code. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
