After some IRC conversations I believe we decided on adding a new key/value to the sslmulticert.config file which specifies the type of dialog for each cert.
ssl_key_pass_dialog=[builtin|exec:/path/to/program] Method used to provide a pass phrase for encrypted private keys. Two options are supported: builtin and exec builtin - Requests passphrase via stdin/stdout. Useful for debugging. exec: - Executes a program and uses the stdout output for the pass phrase. Example: ssl_cert_name=foo.pem ssl_key_pass_dialog="exec:/usr/bin/mypass foo" Yes? -Ron On 1/15/14, 4:23 PM, "Ron Barber" <rbar...@yahoo-inc.com> wrote: >Oops for got a comment on #2 > >On 1/15/14, 4:17 PM, "Ron Barber" <rbar...@yahoo-inc.com> wrote: > >>James, Thanks for the quick feedback... >> >>On 1/15/14, 3:08 PM, "James Peach" <jpe...@apache.org> wrote: >> >>>On Jan 15, 2014, at 10:46 AM, Ron Barber <rbar...@yahoo-inc.com> wrote: >>> >>>> All, >>>> >>>> I have been asked to address TS-612 >>>> (https://issues.apache.org/jira/browse/TS-612) by Œthe man¹. I made a >>>> proposal on the ticket regarding configuration and would like some >>>> feedback at your leisure (well pretty quick since I am on it now). >>> >>>1. The 'builtin' dialog may be a problem, since traffic_server would be >>>the one running the dialog, and it's a couple of processes down the fork >>>chain. >> >>Was going to include it primarily for completeness (and for my testing >>it’s useful). Certainly I can remove it if it’s problematic (maybe it >>will create more questions), but just like it’s helpful for me, it may be >>useful to the person trying to implement/test his own exec or pipe >>solution. >>> >>>2. Compatibility with the Apache http dialog would be a good thing. >>>However, there's no ATS requirement to specify a dest_ip >>>(servername:portnumber in the httpd documentation), so I don't know that >>>it makes sense. > >You are correct, thank you for pointing that out. In looking at the docs >(https://trafficserver.readthedocs.org/en/latest/reference/configuration/s >s >l_multicert.config.en.html#std:configfile-ssl_multicert.config) the only >required field is ssl_cert_name, so I will make that first and provide the >other 2 if provided. >>> >>>Are you planning to implement the httpd prompt-minimization logic? >>> >>>It's difficult for me to see how a program could select a passphrase >>>using the http logic. It doesn't seem like there's a way for the program >>>to really know which key it is being prompted for. If the dialog was >>>specified in ssl_multicert.config, then it would be possible. >> >>Short answer: No. I thought that was a really cool feature in httpd so I >>looked at the implementation. Httpd tries each password that it has seen >>previously before asking for another password..in order to do that it >>would take refactoring of the SSL config code which is beyond what I have >>time for. >> >>> >>>While you are at it, consider whether we can consolidate the number of >>>places in our code that calls fork+exec into a libts API that looks a >>>lot >>>like posix_spawn. >> >>Will look at that. >> >>> >>>While this is useful from a compatibility point of view, I'd like the >>>provisioning and protection of private keys to go much further. The >>>linux >>>kernel keychain looks like the most promising infrastructure for key >>>management, and I'd like us to support that. Additionally, I think that >>>using a privileged helper (eg. traffic_manager?) is the right way to go >>>for accessing keys that are read-only for root, or protected in some >>>other fashion. >> >>I agree with the idea (not sure keychain capability is available in all >>supported OSs) but is outside of my time horizon (and knowledge base >>atm). >> >>> >>>J >> >
