> From: owner-openssl-us...@openssl.org On Behalf Of Wojciech Kocjan > Sent: Wednesday, 11 January, 2012 14:47
> I am working on reworking existing code that uses several OpenSSL APIs > from using files to store keys, certificates and CAs to passing this > directly from memory (so that it can be retrieved from memory, read > from encrypted storage among other things). > > This is my first post here, so if this is not the correct group and/or > anything below seems obvious/completely incorrect, please feel free to > correct me. > > Our code currently uses the following APIs: > > - SSL_CTX_use_certificate_file and SSL_CTX_use_PrivateKey_file > > This part seems easier. From what I understand, I can use BIO_s_mem > and pass it key/certificate data from memory. I could then use PEM to > get EVP_PKEY or X509. > For PEM files yes. For DER files (which OpenSSL also supports here) use d2i_*_bio on BIO_s_mem or d2i_* directly on memory. > Then I could just invoke SSL_CTX_use_certificate() and > SSL_CTX_use_PrivateKey() directly. > > In practice it may be a bit more complex, but at least I know > the solution. > > - SSL_CTX_load_verify_locations and SSL_CTX_set_client_CA_lis > > This part is the harder one. I was not able to find any APIs > to do this. > _set_client_CA_list already takes STACK_OF(X509). Instead of getting that stack from SSL_load_client_CA_file, construct it yourself with sk_X509_new etc. Or use SSL_add_client_CA instead. _load_verify_ is the hard one. The builtin X509_STORE/X509_LOOKUP mechanism only does PEM files. It *is* pluggable -- you can substitute your own LOOKUP's -- but it appears to me you have to reimplement quite a bit, and I haven't made the attempt. > Another alternative I was wondering about is whether I can provide > another way for OpenSSL to access the keys - i.e. so that I can tell > that filename is something like mystorage://key1.pem and OpenSSL would > use my BIO (or create BIO_s_mem and preload it with data) instead of > BIO_s_file. > AFAIK not at the OpenSSL level for _load_verify_. If your OS has any kind of virtual files or filesystems, you could use those. Most(?) nowadays have at least something for remote files, like NFS or NetBIOS/SMB, that you can use/fake with enough effort. AIUI at least Windows and Linux have ways to install your own driver, which could do this sort of thing, but those aren't simple to write. This is dependent on your OS of course, and often requires 'root' or 'admin' which an SSL (and OpenSSL) app doesn't otherwise need. Similarly, your C library's "fopen" *could* have a capability like this. But I haven't seen it in any commonly used ones. I've heard a rumor Plan9 does, but I doubt you (or your users) use Plan9. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
