[openssl-users] "shutdown while in init" error from SSL_read
What might cause the following error as a result of a call to SSL_read: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init I'm seeing this error reported well after the initial handshake should have been completed, and before any call to SSL_shutdown on the SSL object given to SSL_read. So, externally, there is no intention or knowledge of SSL being actively shutdown or initialized at the time of the read call. No other errors were reported before this one. Occurrences of the error are uncommon, and I have not found a way to reliably reproduce it. What could possibly be the cause of this error, and how could it be prevented? For additional context: Using OpenSLL version 1.0.2l. This error is seen on the client side, using TLS 1.0 (TLSv1_client_method). Only memory BIO objects (BIO_s_mem) are set into the SSL object. Looking at the code, this error (SSL_R_SHUTDOWN_WHILE_IN_INIT) is only reported in SSL_shutdown, but I have not yet found how SSL_shutdown might be called from SSL_read. Additionally, the program in which this error occurs may be using multiple SSL objects at a time, potentially with SSL objects on different threads, but no SSL objects are shared between threads. The SSL objects are created (via SSL_new) using the same shared context object (SSL_CTX). Is there any chance the states or errors from different SSL objects are interfering with each other? - Jeffrey -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Problem with using EC private keys
Hi, I am confused about the two different ways I can generate an EC private key and why this is causing me problems with the test s_client s_server applications So, I am using the command below to generate a private key, then using this to create a certificate to work with openssl s_client s_server. openssl ecparam -name secp384r1 -genkey -out privkey.pem (1) I then create the .csr with the following two commands, openssl req -key privkey.pem -out pub.csr -new (2) openssl x509 -req -in pub.csr -signkey privkey.pem -out pub.crt (3) This works with s_server/s_client. But, when I generate a key like this: openssl genpkey -algorithm ec -pkeyopt ec_paramgen_curve:secp384r1 -out privkey.pem (4) If I now create a signed .crt with (2) and (3) above, then use this pair with openssl s_server it does not negotiate a cipher suite and it doesn't work. Client: CONNECTED(0154) 2546392219:error:14004410:SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 alert handshake failure:ssl_pkt.c:1205:SSL alert number 40 2546392219:error:140040E5:SSL routines:CONNECT_CR_SRVR_HELLO:ssl handshake failure:ssl_pkt.c:585: ... Server: ... ERROR 2867046282:error:140270C1:SSL routines:ACCEPT_SR_CLNT_HELLO_C:no shared cipher:ssl_srvr.c:1024: shutting down SSL CONNECTION CLOSED Using this url (https://wiki.openssl.org/index.php/Command_Line_Elliptic_Curve_Operations) It turns out, if I take the key generated by (4) above, and convert it to pk8 with openssl pkcs8 -topk8 -nocrypt -in privkey_ec.pem -out privkey.pem If I now use this key to create the .crt and use this key pair with openssl s_server it works. My question is why does the format of the private key make any difference. Surely openssl can decode the key in any supported format, after all it created it, and all the required information must be in it, as it is able to convert to pk8 format that works. Note: I am running openssl server/client like this.. openssl.exe s_server -tls1_2 -key privkey.pem -cert pub.crt -debug and openssl.exe s_client -tls1_2 Thanks! -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0
On 11/01/2017 09:52 AM, Dave Coombs wrote: >>> It would be nice, though, if the API provided a way to get the signer's >>> certificate. There is OCSP_resp_get0_signature(), but that only returns >>> the bit string. Comparable functions in other modules (eg: >>> X509_get0_signature(), X509_REQ_get0_signature(), >>> X509_CRL_get0_signature(), CMS_SignerInfo_get0_algs()) provide a way to get >>> any combination of bit string, algorithm, and signer cert. >> Kind of like https://github.com/openssl/openssl/pull/4573 ? > Quite a lot like that, yes. Neat. Is there any chance this might be > included in the 1.1.0 series? > Since there have been no reviews yet, it's easy enough for me to add the "1.1.0" label and see if a reviewer is persuaded that it is relevant there. -Ben -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OCSP_BASICRESP_verify() in 1.1.0
>> It would be nice, though, if the API provided a way to get the signer's >> certificate. There is OCSP_resp_get0_signature(), but that only returns the >> bit string. Comparable functions in other modules (eg: >> X509_get0_signature(), X509_REQ_get0_signature(), X509_CRL_get0_signature(), >> CMS_SignerInfo_get0_algs()) provide a way to get any combination of bit >> string, algorithm, and signer cert. > > Kind of like https://github.com/openssl/openssl/pull/4573 ? Quite a lot like that, yes. Neat. Is there any chance this might be included in the 1.1.0 series? Thanks, -Dave -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
