RE: How does cipher selection and TLS protocol negotiation interact
To answer my own question, seems the code that generates the SSL_CIPHER_description() output does not make any difference between SSLv3, TLSv1.0 and TLSv1.1. Only TLSv1.2 is displayed as such. So in my case, I probably did have a TLSv1 connection. Confusing ... A followup question, is it correct that TLSv1 in the cipher string disables TLSv1.2 ciphers ? I didnt expect that. >-- Original Message -- >Date: Fri, 15 Jun 2012 14:34:27 -0700 >From: "Erik Forsberg" >Subject: How does cipher selection and TLS protocol negotiation interact >To: openssl-users@openssl.org >Reply-To: openssl-users@openssl.org > > >I have a weird case that I cannot properly explain. >Using OpenSSL 1.0.1c for both client and server, I was testing various >combinations of ciphers and protocol version requests. > >Basically, the server uses SSLv23_server_method(). >The client code uses SSLv23_client_method() and SSL_OP_NO_SSLv2 > >Then, if I have the following cipher list (which I have used for a long >time) >TLSv1+HIGH:!CAMELLIA:!SSLv2:RC4+MEDIUM:!MD5:!aNULL:!eNULL:@STRENGTH >(same for client and server side) > >I always get a SSLv3 connection, regardless what client asks for. > >Changing the cipher list to (removing the TLSv1) >HIGH:!CAMELLIA:!SSLv2:RC4+MEDIUM:!MD5:!aNULL:!eNULL:@STRENGTH > >I start getting TLS1.2 connections. Question is, in the first case, >why dont I get a TLSv1 connection ? Furthermore, high strength >ciphers from TLSv1 should still be usable for TLS 1.1 and 1.2, so >why dont I get a TLS1.2 connection in the first case ? > > >__ >OpenSSL Project http://www.openssl.org >User Support Mailing Listopenssl-users@openssl.org >Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
How does cipher selection and TLS protocol negotiation interact
I have a weird case that I cannot properly explain. Using OpenSSL 1.0.1c for both client and server, I was testing various combinations of ciphers and protocol version requests. Basically, the server uses SSLv23_server_method(). The client code uses SSLv23_client_method() and SSL_OP_NO_SSLv2 Then, if I have the following cipher list (which I have used for a long time) TLSv1+HIGH:!CAMELLIA:!SSLv2:RC4+MEDIUM:!MD5:!aNULL:!eNULL:@STRENGTH (same for client and server side) I always get a SSLv3 connection, regardless what client asks for. Changing the cipher list to (removing the TLSv1) HIGH:!CAMELLIA:!SSLv2:RC4+MEDIUM:!MD5:!aNULL:!eNULL:@STRENGTH I start getting TLS1.2 connections. Question is, in the first case, why dont I get a TLSv1 connection ? Furthermore, high strength ciphers from TLSv1 should still be usable for TLS 1.1 and 1.2, so why dont I get a TLS1.2 connection in the first case ? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
DES_ede3_cbc_encrypt Maximum Text Length?
I am interacting with DES encryption at a fairly superficial level, but it has been working for some time. Now I am trying to encrypt a slightly longer text string and am running into a problem. It works well until my text length exceeds about 8 KB and then it simply truncates the input and encrypts that. How can I handle this? I haven’t found much by Googling.
RE: Secure WebSocket Server (using OpenSSL) Failing Client Connection During Initial SSL Handshake
>From: owner-openssl-us...@openssl.org On Behalf Of Jack Trades
>Sent: Thursday, 14 June, 2012 16:18
>I have an asynchronous win32 websocket server (written in C/C++
>using MSVS 2010) application that I now want to support WSS -
>a WebSocket Secure connection. To accomplish this, I added
>openssl to my application. However, when the client tries to
>connect to my webserver, openssl is rejecting the client
>during the initial handshake with the following error:
>13500:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:
>unknown protocol:.\ssl\s23_clnt.c:683:
This is a client-side error and should never occur on a server.
Are you doing SSL_accept or SSL_set_accept_state on the SSL
object(s) you create for specific connections ?
>Here is some other info to help in uncovering the cause for this error:
>* openssl version - OpenSSL 1.0.0d 8 Feb 2011
>* I am testing locally using the latest Firefox/chrome browsers.
IP=127.0.0.1 Port=8181
Note at the app level (not SSL level) browsers like IE FF Chrome,
and some but not all other clients, want or require the host
in the URL to match the subjectDN (or SAN) in the cert.
>* I created my own certificates for testing
> >openssl dhparam -check -text -5 512 -out dh512.pem
> >openssl dhparam -check -text -5 1024 -out dh1024.pem
If you want/need actual security, don't use DH-512 except for
old export suites and don't use old export suites at all.
>* I setup the SSL_CTX for the server as follows:
> ctx = SSL_CTX_new (SSLv23_method ());
> if (ctx == NULL) {...
> // Load the trusted certificates from rootcert.pem
> if (SSL_CTX_load_verify_locations(ctx, CAFILE, CADIR) != 1) { ...
> // Load the built-in certificate stores.
> if (SSL_CTX_set_default_verify_paths(ctx) != 1) { ...
set_default_verify replaces the settings from load_verify,
so OpenSSL will use only the default store and unless you
have your root cert (or any other needed root(s)) there
the server won't verify your client(s). Generally you should
use set_default only if you have no app-specific truststore,
or you supposedly have one but it gets an error and you want
to proceed rather than demanding a fix.
> // Incorporate certificate information into the SSL_CTX by loading
> // a chain of certificates from the specified file name
> if (SSL_CTX_use_certificate_chain_file (ctx, SERVER_CERTFILE) != 1) { ...
The server cert you created above has no intermediate(s) and thus
doesn't need _use_cert_chain, only _use_cert. But _use_chain works
here, and also in other situations that do have real chains.
> // Set password required to decrypt an encrypted private key
> SSL_CTX_set_default_passwd_cb(ctx, passwd_cb);
> // Load in the application's private key
> if (SSL_CTX_use_PrivateKey_file (ctx, SERVER_CERTFILE, SSL_FILETYPE_PEM)
!= 1) { ...
> // Have the server request a certificate fom the client.
> // or if no certificate supplied.
> SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, verify_callback);
> // Set the maximum depth for verification.
> SSL_CTX_set_verify_depth(ctx, 4);
This setting >requests< client auth (cert plus proof), but
accepts connection if none is supplied. Is that what you want?
> // Enable all bug workarounds, disable SSL version 2, and recompute the
private
> // part of the DH exchange for each client connecting.
> SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2 |
SSL_OP_SINGLE_DH_USE);
> SSL_CTX_set_tmp_dh_callback(ctx, tmp_dh_callback);
I assume this callback uses the dh-param files you created above.
If you prohibit export suites, you could set DH-1024 statically.
> if (SSL_CTX_set_cipher_list(ctx, CIPHER_LIST) != 1) { ...
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
OCSP_basic_verify error: root ca not trusted
I made an error. I didn't actually add OCSPSigning extended key usage to the OCSP responder cert. My attempt(which I found at the mailing list archive) was bad: openssl x509 -in 03.crt -inform PEM -addtrust OCSPSigning -out ocsp_resp_cert.pem "-addtrust" is another command for another purposes. To add OCSPSigning extended key usage to the OCSP responder cert we must use "-extension" option during signing certificate request. OCSP verification works now. The problem is closed. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OCSP_basic_verify error: root ca not trusted
Hello. I could connect to OpenSSL OCSP responder only by IPv6. But I have another error: 3908:error:2706A067:OCSP routines:OCSP_CHECK_DELEGATED:missing ocspsigning usage:.\crypto\ocsp\ocsp_vfy.c:350: 3908:error:27069070:OCSP routines:OCSP_basic_verify:root ca not trusted:.\crypto\ocsp\ocsp_vfy.c:148: I made and adjusted the simple test Certification Authority. I have a root CA and three certs issued and certainly signed by the root CA: 01.crt, 02.crt, 03.crt. Now I want to test OpenSSL OCSP responder. I will test 01.crt for the revocation status and use 03.crt cert as the OCSP responder's certificate. I added OCSPSigning extended key usage to the 03.crt: openssl x509 -in 03.crt -inform PEM -addtrust OCSPSigning -out ocsp_resp_cert.pem I start OpenSSL OCSP responder: openssl ocsp -index index.txt -port -rkey cert3_pkey.pem -rsigner ocsp_resp_cert.pem -CA cacert.crt -text After that I try to verify 01.crt via OCSP and I get the above error. If I would use the root CA as the OCSP responder's cert all is ok: OCSP_basic_verify not failed and I get OCSP status "GOOD". I see docs on openssl.org: ocsp(1) section OCSP "Response verification": 1) "Otherwise the issuing CA certificate in the request is compared to the OCSP responder certificate: if there is a match then the OCSP verify succeeds." This rule works. This case is when certificate of the OCSP responder is a root CA. 2) "Otherwise the OCSP responder certificate's CA is checked against the issuing CA certificate in the request. If there is a match and the OCSPSigning extended key usage is present in the OCSP responder certificate then the OCSP verify succeeds. This rule doesn't work or I don't understand it or I made something wrong. Please, say what am I do wrong? Regards, Vladimir. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OCSP server listem only TCPv6 connections on Windows. Why?
Hello.
I start OCSP server for testing. I use command:
openssl ocsp -index index.txt -port -rkey ocsp_resp_pkey.pem -rsigner
ocsp_resp_cert.crt -CA cacert.crt –text
After I got the message “Waiting for OCSP client connections...” I see that
process openssl.exe listen only TCPv6 port
, no TCPv4.
That’s why when I try to connect to OCSP responder on 127.0.0.1:
BIO_do_connect returns errors:
2992:error:0200274D:system
library:connect:reason(1869):.\crypto\bio\bss_conn.c:269:host=127.0.0.1:
2992:error:20073067:BIO routines:CONN_STATE:connect
error:.\crypto\bio\bss_conn.c:273:
My code is:
conn = BIO_new_connect(host);
if (!conn)
{
result=-6;
goto l_fr;
}
int port_int=atoi(port);
BIO_set_conn_int_port(conn, &port_int);
if (BIO_do_connect(conn) <= 0)
{
result=-7;
ERR_print_errors(bf_log); //here we print errors
goto l_fr;
}
How to set up OCSP responder to handle IPv4-connections? Or the only way is to
use manually IPv6-connection to the
OpenSSL OCSP responder?
Regards,
Vladimir.
Re: OpenSSL and GOST engine issue (statically linked library )
Hello,
IIRC, when you do dynamic linkage, the conf file is parsed and engine
initiated as per conf file, not when you do static linkage. Hence your
issue.
More generally, it's a bad idea to link statically in the context of
GOST use: if at one point you need to use FSB certified GOST, you'll run
into trouble (there are chances, depending how you use it, that you'll
need to submit your code for certification).
Regards,
Alexandre
Le 15/06/2012 08:34, Abyss Lingvo a écrit :
Hi Vladimir,
I have inserted your code into my application between
OPENSSL_config("correct config file path");
SSL_library_init();
SSL_load_error_strings();
and
SSL_CTX_use_certificate_chain_file(ctx, CERTFILE)
The code was executed without errors but
SSL_CTX_use_certificate_chain_file(ctx, CERTFILE) function call cause
the same error: Unsupported algorithm.
As far as I understood the main idea of this code is to get engine and
initialize it by ENGINE_init(e).
What is the further use of this ENGINE* pointer? It seems that i can
"forget" about it.
Why ENGINE_init(e) call is not necessary for dynamic linkage?
I thought that everything should be the same because I pass correct
configuration file path to OPENSSL_config("correct config file path");
I read "Network security with openssl" book and CryptoKom
documentation http://www.cryptocom.ru/products/cryptopacket.html#docs
Unfortunately both sources doesn't contain information how to handle
with engines (especially in case of statically linkage).
*От:* Vladimir Belov
*Кому:* openssl-users@openssl.org
*Отправлено:* четверг, 14 июня 2012 18:01
*Тема:* Re: OpenSSL and GOST engine issue (statically linked library )
I made a mistake in code and it is possible not to load all engines
with ENGINE_load_builtin_engines :
What next code show you:
//testing loading GOST engine
ENGINE *e;
const char *engine_id = "gost";
ENGINE_load_openssl();
//ENGINE_load_builtin_engines();
ENGINE_load_gost();
e = ENGINE_by_id(engine_id);
if(!e)
{
/* the engine isn't available */
ERR_print_errors(bf_log);
return 1;
}
if(!ENGINE_init(e))
{
/* the engine couldn't initialise, release 'e' */
ERR_print_errors(bf_log);
ENGINE_free(e);
return 1;
}
From: Abyss Lingvo
Sent: Wednesday, June 13, 2012 5:21 PM
To: openssl-users@openssl.org
Subject: OpenSSL and GOST engine issue (statically linked library )
Hi all !
This is my first mail to openssl mailing list.
I have a problem with statically linked openSSL library and GOST
crypto engine. Openssl 1.0.0g
I have simple client/server application using GOST keys and
certificates. It works fine with GOST keys but only if I use
dynamically linked version of openSSL library. If I try to use
statically linked openSSL I got an error message.
This is how I initialized openSSL library:
OPENSSL_config("correct config file path");
SSL_library_init();
SSL_load_error_strings();
When I try to read certificate file I got an error.
SSL_CTX_use_certificate_chain_file(ctx, CERTFILE)
Return value here is not 1. So this is an error.
The human readable error message is:
3084809868:error:0609E09C:digital envelope
routines:PKEY_SET_TYPE:unsupported algorithm:p_lib.c:239:
3084809868:error:0B07706F:x509 certificate
routines:X509_PUBKEY_get:unsupported algorithm:x_pubkey.c:155:
3084809868:error:140BF10C:SSL routines:SSL_SET_CERT:x509
lib:ssl_rsa.c:402:
When I use the same code with dynamically linked openSSL library with
external GOST engine library everything works fine. So what is the
difference between static and dynamic version? The only idea that I
have at this time that my library initialization sequence is wrong.
I checked symbols in the compiled libcrypto.a library.
nm ./libcrypto.a | grep gost
This command gave me output with many GOST function which were
included to libcrypto.a library. So I think that library was compiled
properly and all GOST engine functions were included in the static
library.
"Unsupported algorithm" error message means that GOST functions was
not initialized properly. The question is: how properly initialize
engines with statically linked openSSL?
Is it possible to use engines and statically linked openssl library in
general?
Best Regards
Xidex
__
OpenSSL Project http://www.openssl.org
Automated List Manager majord...@openssl.org
RE: TLSv1.2 backward compatibility
I have a question on how this situation happens, exactly, when using TLS 1.1 or 1.2. From ticket 2771, I see that the length of the ClientHello is what causes the problem. But what needs to happen in order to make a ClientHello get too big? My OpenSSL application only supports around 25 cipher suites, so let's say all 25 are included in a ClientHello. Would that make a TLS 1.1 or 1.2 ClientHello long enough to cause this issue? I don't think my application does anything else to add length to a ClientHello. From the bug report, I see there are ways to reproduce the problem, like adding "-servername (very long string)" to a call to s_client, but again my application doesn't do anything to add length to the ClientHello, and will at most propose around 25 ciphers. Another question, which may be sort of related to this bug. If I'm using 1.0.1c and my application calls SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2); will a ClientHello still try to use TLS 1.2 first in the ClientHello? What about if it calls: SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2 | SSL_OP_NO_TLSv1); or: SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3); to eliminate TLS 1.0 or SSL 3.0, respectively? My understanding is that TLS 1.2/1.1 would still be used initially, unless I explicitely eliminate them with SSL_OP_NO_TLSv1_1 | SSL_OP_NO_TLSv1_2. Is that correct? Thanks. > Date: Thu, 14 Jun 2012 03:46:23 +0200 > From: st...@openssl.org > To: openssl-users@openssl.org > Subject: Re: TLSv1.2 backward compatibility > > On Wed, Jun 13, 2012, Garrison, Jim (ETW) wrote: > > > > -Original Message- > > > From: owner-openssl-us...@openssl.org [mailto:owner-openssl- > > > us...@openssl.org] On Behalf Of Dr. Stephen Henson > > > Sent: Wednesday, June 13, 2012 5:23 PM > > > To: openssl-users@openssl.org > > > Subject: Re: TLSv1.2 backward compatibility > > > > > > On Wed, Jun 13, 2012, Garrison, Jim (ETW) wrote: > > > > > > > Is anybody else having trouble with newer SSL clients (1.0.1c > > > specifically) causing older servers to hang? > > > > > > > > > > Yes, see PR#2771. > > > > > > > > > > > Reading the 1.0.1c release notes I see > > > > > > > > 3. If all else fails setting OPENSSL_NO_TLS1_2_CLIENT will > > > disable > > > > TLS 1.2 client support entirely. > > > > > > > > Is this something that can be set at runtime, or is it purely a > > > compile-time option? > > > > > > Yes you can set SSL_OP_NO_TLSv1_2 and possibly SSL_OP_NO_TLSv1_1 too. > > > > Sorry if I seem dense, but how do I set this at runtime? I tried > > creating an environment variable as in: > > > > export SSL_OP_NO_TLSv1_2=1 > > export SSL_OP_NO_TLSv1_1=1 > > openssl s_client -connect remoteserver:443 > > > > but this gets the same hang, both with s_client and the svn client, and > > Wireshark shows it's still sending a TLSv1.2 handshake. > > > > Ah I see, the application needs to support it for that to work. For example a > call to: > > SSL_CTX_set_options(ctx, SSL_OP_NO_TLSv1_1); > > after SSL_CTX_new. But that will need modification to the application (but not > OpenSSL itself). There isn't an environment variable to set this. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org
Re: OpenSSL and GOST engine issue (statically linked library )
As far as I understood the main idea of this code is to get engine and
initialize it by ENGINE_init(e).
My code was only for testing of loading and initialization of specific ENGINE.
What is the further use of this ENGINE* pointer? It seems that i can "forget"
about it
Variable with type ENGINE can be used directly in many cryptography functions, such as EVP_EncryptInit_ex and many
others.
The code was executed without errors but SSL_CTX_use_certificate_chain_file(ctx, CERTFILE) function call cause the
same error: Unsupported algorithm.
So, if "gost" engine is successfully loaded, then try this code:
SSL_load_error_strings();
ENGINE *e;
const char *engine_id = "gost";
ENGINE_load_openssl();
ENGINE_load_gost();
e = ENGINE_by_id(engine_id);
if(!e)
{
//the engine isn't available
ERR_print_errors(bf_log);
return 1;
}
ENGINE_register_complete(e);
OpenSSL_add_all_algorithms();
SSL_library_init();
//here is your code
//at the end of the program
ENGINE_free(e);
ENGINE_cleanup();
From: Abyss Lingvo
Sent: Friday, June 15, 2012 10:34 AM
To: openssl-users@openssl.org
Subject: OpenSSL and GOST engine issue (statically linked library )
Hi Vladimir,
I have inserted your code into my application between
OPENSSL_config("correct config file path");
SSL_library_init();
SSL_load_error_strings();
and
SSL_CTX_use_certificate_chain_file(ctx, CERTFILE)
The code was executed without errors but SSL_CTX_use_certificate_chain_file(ctx, CERTFILE) function call cause the same
error: Unsupported algorithm.
As far as I understood the main idea of this code is to get engine and
initialize it by ENGINE_init(e).
What is the further use of this ENGINE* pointer? It seems that i can "forget"
about it.
Why ENGINE_init(e) call is not necessary for dynamic linkage?
I thought that everything should be the same because I pass correct configuration file path to OPENSSL_config("correct
config file path");
I read "Network security with openssl" book and CryptoKom documentation
http://www.cryptocom.ru/products/cryptopacket.html#docs
Unfortunately both sources doesn't contain information how to handle with engines (especially in case of statically
linkage).
От: Vladimir Belov
Кому: openssl-users@openssl.org
Отправлено: четверг, 14 июня 2012 18:01
Тема: Re: OpenSSL and GOST engine issue (statically linked library )
I made a mistake in code and it is possible not to load all engines with
ENGINE_load_builtin_engines :
What next code show you:
//testing loading GOST engine
ENGINE *e;
const char *engine_id = "gost";
ENGINE_load_openssl();
//ENGINE_load_builtin_engines();
ENGINE_load_gost();
e = ENGINE_by_id(engine_id);
if(!e)
{
/* the engine isn't available */
ERR_print_errors(bf_log);
return 1;
}
if(!ENGINE_init(e))
{
/* the engine couldn't initialise, release 'e' */
ERR_print_errors(bf_log);
ENGINE_free(e);
return 1;
}
From: Abyss Lingvo
Sent: Wednesday, June 13, 2012 5:21 PM
To: openssl-users@openssl.org
Subject: OpenSSL and GOST engine issue (statically linked library )
Hi all !
This is my first mail to openssl mailing list.
I have a problem with statically linked openSSL library and GOST crypto engine.
Openssl 1.0.0g
I have simple client/server application using GOST keys and certificates. It works fine with GOST keys but only if I use
dynamically linked version of openSSL library. If I try to use statically linked openSSL I got an error message.
This is how I initialized openSSL library:
OPENSSL_config("correct config file path");
SSL_library_init();
SSL_load_error_strings();
When I try to read certificate file I got an error.
SSL_CTX_use_certificate_chain_file(ctx, CERTFILE)
Return value here is not 1. So this is an error.
The human readable error message is:
3084809868:error:0609E09C:digital envelope routines:PKEY_SET_TYPE:unsupported algorithm:p_lib.c:239:
3084809868:error:0B07706F:x509 certificate routines:X509_PUBKEY_get:unsupported algorithm:x_pubkey.c:155:
3084809868:error:140BF10C:SSL routines:SSL_SET_CERT:x509 lib:ssl_rsa.c:402:
When I use the same code with dynamically linked openSSL library with external GOST engine library everything works
fine. So what is the difference between static and dynamic version? The only idea that I have at this time that my
library initialization sequence is wrong.
I checked symbols in the compiled libcrypto.a library.
nm ./libcrypto.a | grep gost
This command gave me output with many GOST function which were included to libcrypto.a library. So I think that library
was compiled properly and all GOST engine functions were included in the static library.
"Unsupported algorithm" error message means that
Secure WebSocket Server (using OpenSSL) Failing Client Connection During Initial SSL Handshake
I have an asynchronous win32 websocket server (written in C/C++ using MSVS
2010) application that I now want to support WSS - a WebSocket Secure
connection. To accomplish this, I added openssl to my application.
However, when the client tries to connect to my webserver, openssl is
rejecting the client during the initial handshake with the following error:
13500:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown
protocol:.\ssl\s23_clnt.c:683:
Here is some other info to help in uncovering the cause for this error:
* openssl version - OpenSSL 1.0.0d 8 Feb 2011
* I am testing locally using the latest Firefox/chrome browsers.
IP=127.0.0.1 Port=8181
* I created my own certificates for testing
Create the root CA
>openssl req -newkey rsa:1024 -sha1 -keyout rootkey.pem -out
rootreq.pem
>openssl x509 -req -in rootreq.pem -sha1 -extensions v3_ca -signkey
rootkey.pem -out rootcert.pem
>cat rootcert.pem rootkey.pem > root.pem
Create the server's certificate and sign it with the root CA
>openssl req -newkey rsa:1024 -sha1 -keyout serverkey.pem -out
serverreq.pem
>openssl x509 -req -in serverreq.pem -sha1 -extensions usr_cert -CA
root.pem -CAkey root.pem -CAcreateserial -out servercert.pem
>cat servercert.pem serverkey.pem rootcert.pem > server.pem
Create the client certificate and sign it with the root CA
>openssl req -newkey rsa:1024 -sha1 -keyout clientkey.pem -out
clientreq.pem
>openssl x509 -req -in clientreq.pem -sha1 -extensions usr_cert -CA
root.pem -CAkey root.pem -CAcreateserial -out clientcert.pem
>cat clientcert.pem clientkey.pem rootcert.pem > client.pem
Create the dh512.pem dh1024.pem
>openssl dhparam -check -text -5 512 -out dh512.pem
>openssl dhparam -check -text -5 1024 -out dh1024.pem
* I setup the SSL_CTX for the server as follows:
SSL_CTX *setup_server_ctx (void)
{
// Performs the necessary actions to provide certificate data
// to the client.
//
SSL_CTX *ctx;
// Specify the SSL protocol for the server to use.
ctx = SSL_CTX_new (SSLv23_method ());
if (ctx == NULL) {
int_error("Error creating a new SSL_CTX object");
return (NULL);
}
// Load the trusted certificates from rootcert.pem
if (SSL_CTX_load_verify_locations(ctx, CAFILE, CADIR) != 1) {
int_error("Error loading CA file and/or directory");
SSL_CTX_free (ctx);
return (NULL);
}
// Load the built-in certificate stores.
if (SSL_CTX_set_default_verify_paths(ctx) != 1) {
int_error("Error loading default CA file and/or directory");
SSL_CTX_free (ctx);
return (NULL);
}
// Incorporate certificate information into the SSL_CTX by
loading
// a chain of certificates from the specified file name
if (SSL_CTX_use_certificate_chain_file (ctx, SERVER_CERTFILE)
!= 1) {
int_error ("Error loading certificate from file");
SSL_CTX_free (ctx);
return (NULL);
}
// Set password required to decrypt an encrypted private key
SSL_CTX_set_default_passwd_cb(ctx, passwd_cb);
// Load in the application's private key
if (SSL_CTX_use_PrivateKey_file (ctx, SERVER_CERTFILE,
SSL_FILETYPE_PEM) != 1) {
int_error ("Error loading private key from file");
SSL_CTX_free (ctx);
return (NULL);
}
// Have the server request a certificate fom the client.
// or if no certificate supplied.
SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, verify_callback);
// Set the maximum depth for verification.
SSL_CTX_set_verify_depth(ctx, 4);
// Enable all bug workarounds, disable SSL version 2, and
recompute the private
// part of the DH exchange for each client connecting.
SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2 |
SSL_OP_SINGLE_DH_USE);
SSL_CTX_set_tmp_dh_callback(ctx, tmp_dh_callback);
if (SSL_CTX_set_cipher_list(ctx, CIPHER_LIST) != 1) {
int_error("Error setting cipher list (no valid ciphers)");
SSL_CTX_free (ctx);
return (NULL);
}
return (ctx);
} // setup_server_ctx
* Since I am using a asynchronous winsock implementation (FD_READ,
FD_WRITE, etc) to handle TCP packets, I am using memory bios to process the
data. I based some of my code off of the following implementation:
http://funcptr.net/2012/04/08/openssl-as-a-filter-%28or-non-blocking-openssl%29/
Can anyone help me figure out what is happening? Any help would be
appreciated, espec
