On Thu January 12 2012, Dave Thompson wrote: > > 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. >
If using gnu/binutils ld to build your application for the custom OS (or native ld on HP-UX or Solaris) you can use the linker's: --wrap=symbol command option to provide your own "fopen" as required. Ref: http://okmij.org/ftp/syscall-interpose.html http://linux.die.net/man/1/ld Mike > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
