Re: Reworking OpenSSL code from using files to reading keys from memory

2012-01-11 Thread Huaqing Wang
In similar way, you could generate your own BIO by BIO_new_mem_buf((void*)
cacert, len).
Then call PEM_X509_INFO_read_bio,
then e.g. for x509, use X509_STORE_add_cert for each one in
sk_x509_INFO_num().

Hope this helps
Huaqing

On Wed, Jan 11, 2012 at 2:47 PM, Wojciech Kocjan wojci...@kocjan.orgwrote:

 Hello,

 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.

 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.

 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.

 Thanks.

 --
 WK
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org




-- 
Thank you.
Best Regards,
Michael(Huaqing) Wang


Re: SSL_Connect call gives SSL_ERROR_WANT_READ for non blocking sockets

2011-11-15 Thread Huaqing Wang
Hi, Arjun,

For non-blocking case, you have to handle SSL_ERROR_WANT_READ  and
SSL_ERROR_WANT_WRITE
In that case you need to redo *SSL_connect.*
*
*
Huaqing

On Tue, Nov 15, 2011 at 5:51 AM, Arjun SM arjun...@gmail.com wrote:

 Hi all,
I am newbie to openssl any help is greatly appreciated.

 I have a requirement of fetching the Common name (domin name )  from the
 certificate that I request from any HTTPS websites. I followed the regular
 method of

 1. establish a connection with the ip address using *connect() *system
 call.
 2. Use *SSL_connect()* system call to perform handshake.
 3. Use *SSL_get_peer_certificate()* to get the certificate.

 The problem I faced was that, the connect() call would at times return a
 errno 4 (EINTR) error . So i changed code from blocking to non-blocking
 sockets and used select() call to have a valid connection and return an
 appropriate file descriptor.
 Now the ssl_connect() call returns SSL_ERROR_WANT_READ
 or SSL_ERROR_WANT_WRITE error. I am unable to make my code work by adding a
 select() even on ssl_connect() call.

 If any one can please help as to how I need to use the  ssl_connect() by
 polling that would be of great help. preferred language would be C/C++

 thanks,
 ~Arjun







-- 
Thank you.
Best Regards,
Michael(Huaqing) Wang


Openssl 1.0.0e: dtls segmentation fault after set SSL_OP_NO_QUERY_MTU

2011-09-21 Thread Huaqing Wang
Hi,

I don't know if any other person met this issue.
I use openssl1.0.0e, and working on dtls, in client side,  if I
set SSL_CTX_set_options(ssl_ctx, SSL_OP_NO_QUERY_MTU);
SSL_set_mtu(ss_ssl, 1500);
I met a segmentation fault on the client side, using gdb I saw the error
happens in:

memcpy()
dtls_do_write()
dtls_connect()


And if I remove  SSL_CTX_set_options(ssl_ctx, SSL_OP_NO_QUERY_MTU);
SSL_set_mtu(ssl, 1500);

It worked well.

For the same program if I run in Openssl 0.9.8e, it worked well
with set SSL_CTX_set_options(ssl_ctx, SSL_OP_NO_QUERY_MTU);
SSL_set_mtu(ss_ssl, 1500);

So I am thinking this may be a bug in Openssl 1.0.0e.

-- 
Thank you.
Best Regards,
Huaqing Wang