On Thu, Oct 10, 2013 at 4:44 PM, Dr Stephen Henson <shen...@opensslfoundation.com> wrote: > On 10/10/2013 23:18, Trevor Perrin wrote: >> >> How would you expect the code to track the Cert -> ServerInfo >> relationship between these points? > > AFAICS the certificate and key files both go through the function > ssl_cmd_check_aidx_max and store the filenames with an associated index. At > that > point you could save the last index used and store any associated ServerInfo > with the same index.
Sure. > I *think* you then have to delve into ssl_pphrase_Handle() [note the comment > on > the way in] and somehow link the ServerInfo index with something you can use > to > recognise it later. The algorithm type 'at' might be usable or perhaps turn > the > algorithm type into one of the SSL_AIDX_<ALGORITHM> values? I don't see a direct way to map ssl_algo_t to the SSL_AIX_* that's needed later. I suppose something could be kludged out of ssl_util_algotypestr() and ssl_asn1_keystr(). But maybe the easiest way to handle this is to create another hash table like tPublicCert (e.g. tServerInfoFile or tSSLConfCmd). This table could be populated in ssl_pphrase_Handle at the same time that the tPublicCert table is populated, and read in ssl_server_import_certs()? This would be easy to do as a directive, since only a ServerInfoFile string would be stored in the hash table, and no OpenSSL changes are needed. As an SSL_CONF_CMD, there's more work: - Add some indicator to distinguish per-cert vs global commands (?) - Serialize/deserialize SSL_CONF_CMD name/value lists into the hashtable - OpenSSL work: - Implement SSL_CONF_CMD for ServerInfoFile - Implement SSL_CONF_cmd_type(...) for relative path handling It seems like you guys are contemplating a larger redesign of cert/key handling based around SSL_CONF_CMD. Perhaps I could just do a directive for now, and let all this be swept into a big redesign later? (Yes, I'm trying to do the minimum work possible :-) Trevor
