[openssl-users] sign sub CA issue

2015-12-07 Thread Mohammad Jebran
I have to sign a sub-CA through my current root CA using openSSLeverything I have configured as per instructions but still getting an error that "stateorProvanceName field needed to be the same" As mentioned below. *root@machine:~/ImportantCACerts/intermediate# openssl ca -configopenssl.cnf

Re: [openssl-users] explicitly including other ciphers.

2015-12-07 Thread Ron Croonenberg
Yes I think that probably would be the case. on EDR HTTPS vs HTTP I loose about 15-20GB/s, almost half that is why am trying to do HTTPS for the authentication only On 12/03/2015 07:10 PM, Jakob Bohm wrote: On 04/12/2015 03:03, Michael Wojcik wrote: From: openssl-users

Re: [openssl-users] explicitly including other ciphers.

2015-12-07 Thread Ron Croonenberg
if the proxy is another host, I'd probably loose too much bandwith On 12/03/2015 07:03 PM, Michael Wojcik wrote: From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Ron Croonenberg Sent: Thursday, December 03, 2015 18:35 To: openssl-users@openssl.org Subject: Re:

Re: [openssl-users] explicitly including other ciphers.

2015-12-07 Thread Ron Croonenberg
That is something we have been considering, but someone is going to bring up the fact that passwords would be in the clear. It would be an option to have some sort of encrypted authentication 'thing' over HTTP No it is strictly for having users, on front ends authenticate so they will only

Re: [openssl-users] explicitly including other ciphers.

2015-12-07 Thread Michael Wojcik
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Ron Croonenberg > Sent: Monday, December 07, 2015 14:24 > To: openssl-users@openssl.org > Subject: Re: [openssl-users] explicitly including other ciphers. > > if the proxy is another host, I'd probably loose too much

Re: [openssl-users] explicitly including other ciphers.

2015-12-07 Thread Ron Croonenberg
well... the performance loss would be high, I know that from other applications. Also, each server (there are 50) would need it's own 'proxy' that probably is a little impractical. We're moving a lot of data... machines that cache run out of memory to actually cache in no time. caching

[openssl-users] Question about TLS record length limitations

2015-12-07 Thread Software Engineer 979
Hello, I'm currently developing an data transfer application using OpenSSL. The application is required to securely transfer large amounts of data over a low latency/high bandwidth network. The data being transferred lives in a 3rd part application that uses 1 MB buffer to transfer data to my

Re: [openssl-users] Question about TLS record length limitations

2015-12-07 Thread Salz, Rich
I suggest you ask on the TLS mailing list, t...@ietf.org /r$ -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz ___ openssl-users mailing list To unsubscribe:

Re: [openssl-users] Question about TLS record length limitations

2015-12-07 Thread Benjamin Kaduk
On 12/07/2015 02:43 PM, Software Engineer 979 wrote: > Hello, > > I'm currently developing an data transfer application using OpenSSL. > The application is required to securely transfer large amounts of data > over a low latency/high bandwidth network. The data being transferred > lives in a 3rd

[openssl-users] Failed TLSv1.2 handshake

2015-12-07 Thread Nounou Dadoun
Hi folks, running into a failed handshake problem - Although we upgraded to openssl 1.0.2d last summer, we had never changed our context setup from accepting any version other than TLSv1, i.e. (in boost) m_context(pIoService->GetNative(), boost::asio::ssl::context::tlsv1) When we recently

Re: [openssl-users] Failed TLSv1.2 handshake

2015-12-07 Thread Viktor Dukhovni
On Mon, Dec 07, 2015 at 10:46:26PM +, Nounou Dadoun wrote: > The cipher setting on the server is: > SSL_CTX_set_cipher_list(pSslContext->GetNativeRef().impl(), > "ALL:SEED:!EXPORT:!LOW:!DES:!RC4"); Note, your cipher setting is likely not what you intend it to be, instead try: