Re: Client verify failing - continued
Check out the code for the OpenSSL s_client application, available in apps/s_client.c, about how one may go about loading a client cert into the client and attaching it to an SSL session. Ger On Tue, Nov 25, 2008 at 10:58 AM, vinni rathore [EMAIL PROTECTED] wrote: yes its true that server does not request certificate automatically everything is done by using APIs .. so nothing to say on it.. here the problem is not of server but from client side as the server is not able to get the client certificate.. -- Met vriendelijke groeten / Best regards, Ger Hobbelt -- web:http://www.hobbelt.com/ http://www.hebbut.net/ mail: [EMAIL PROTECTED] mobile: +31-6-11 120 978 -- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Client verify failing - continued
hi, This Error tells that your server is demanding a certificate from client side that means authentication needed.. but client is not sending any certificate.. so please check your code where your client is sending certificate to Server.. hope u'll get something from there.. On Tue, Nov 25, 2008 at 3:13 PM, joshi chandran [EMAIL PROTECTED]wrote: Hi I am new to openssl and now i face the problem SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificat errror .While searching in google , i have found you too had the same problem and also you was able to rectify the problem. Can you please help me to solve this problem . Thanks Joshi Chandran On Mon, Nov 24, 2008 at 3:57 AM, Michael Simms [EMAIL PROTECTED]wrote: Well, thanks to Dave Thompson, this silly bug was fixed, his hint to examine the certificate lead me to the path that ended up with me finding that actually the CA in the clients side was being set AFTER its test to see if it had a CA and setting the values if it did, so it never ran the SSL_CTX_load_verify_locations, believing it had no CTX The logic was all fine, just one line setting the CA done at the wrong place. So, hooray, all of the SSL functionality now works! Thanks -- Michael Simms __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] -- Regards Joshi Chandran -- regards, Vineeta Kumari Software engg Mobera Systems Chandigarh
Re: Client verify failing - continued
I am new to openssl and now i face the problem SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificat errror .While searching in google i have found you too had the same problem and also you was able to rectify the problem. Can you please help me to solve this problem . The server doesn't automatically request a certificate from the client. Use something like SSL_CTX_set_verify(ctx,SSL_VERIFY_PEER,NULL); SSL_CTX_set_verify_depth(ctx,10); Thanks -- Michael Simms __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Client verify failing - continued
yes its true that server does not request certificate automatically everything is done by using APIs .. so nothing to say on it.. here the problem is not of server but from client side as the server is not able to get the client certificate.. On Tue, Nov 25, 2008 at 3:21 PM, Michael Simms [EMAIL PROTECTED]wrote: I am new to openssl and now i face the problem SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificat errror .While searching in google i have found you too had the same problem and also you was able to rectify the problem. Can you please help me to solve this problem . The server doesn't automatically request a certificate from the client. Use something like SSL_CTX_set_verify(ctx,SSL_VERIFY_PEER,NULL); SSL_CTX_set_verify_depth(ctx,10); Thanks -- Michael Simms __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] -- regards, Vineeta Kumari Software engg Mobera Systems Chandigarh
Re: Client verify failing - continued
Hi I am new to openssl and now i face the problem SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificat errror .While searching in google , i have found you too had the same problem and also you was able to rectify the problem. Can you please help me to solve this problem . Thanks Joshi Chandran On Mon, Nov 24, 2008 at 3:57 AM, Michael Simms [EMAIL PROTECTED]wrote: Well, thanks to Dave Thompson, this silly bug was fixed, his hint to examine the certificate lead me to the path that ended up with me finding that actually the CA in the clients side was being set AFTER its test to see if it had a CA and setting the values if it did, so it never ran the SSL_CTX_load_verify_locations, believing it had no CTX The logic was all fine, just one line setting the CA done at the wrong place. So, hooray, all of the SSL functionality now works! Thanks -- Michael Simms __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] -- Regards Joshi Chandran
RE: Client verify failing - continued
From: [EMAIL PROTECTED] On Behalf Of vinni rathore
Sent: Tuesday, 25 November, 2008 04:58
To: openssl-users@openssl.org
Subject: Re: Client verify failing - continued
yes its true that server does not request certificate automatically
everything is done by using APIs .. so nothing to say on it..
here the problem is not of server but from client side as the server is
not able to get the client certificate..
If you do want the client to authenticate (send a cert) either:
- preset (before connecting) its cert and corresponding privatekey with
SSL_[CTX_]use_{certificate,PrivateKey}*
(after setting password callback routine and/or data if needed, i.e. if the
privatekey is encrypted
and you don't want the user to just be prompted to enter it in the default
fashion)
- set a client_cert_cb callback which is invoked during connection to
(select and) provide the cert privatekey
Either way make sure the client's cert is issued (signed) by a CA the server
trusts.
If you don't want the client to authenticate, change the server to not
demand it.
On Tue, Nov 25, 2008 at 3:21 PM, Michael Simms [EMAIL PROTECTED]
wrote:
I am new to openssl and now i face the problem
SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificat errror
.While
searching in google
i have found you too had the same problem and also you was able to
rectify the
problem. Can you please help me to solve this problem .
The server doesn't automatically request a certificate from the
client.
Use something like
SSL_CTX_set_verify(ctx,SSL_VERIFY_PEER,NULL);
SSL_CTX_set_verify_depth(ctx,10);
Re: Client verify failing - continued
Well, thanks to Dave Thompson, this silly bug was fixed, his hint to examine the certificate lead me to the path that ended up with me finding that actually the CA in the clients side was being set AFTER its test to see if it had a CA and setting the values if it did, so it never ran the SSL_CTX_load_verify_locations, believing it had no CTX The logic was all fine, just one line setting the CA done at the wrong place. So, hooray, all of the SSL functionality now works! Thanks -- Michael Simms __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Client verify failing - continued
Dave Thompson wrote:
As a note: The certificates are *fine* I have used them successfully
with s_client and s_server tests. They verify perfectly well.
The one you've attached, yes; the one you are generating in code,
maybe not, because s_client (and s_server) never does that.
Right, although I dont want to verify the generated one, which would
be pointless cos it isnt signed by a ca. The autogenerated one is just
there for encryption and does not provide any verification, it isnt
designed to.
So, the conversation goes as follows.
It seems overwhelmingly likely, but just to be absolutely clear,
I presume private_key and public_key are buffers containing
the servercert.pem and serverkey.pem files you posted.
You could read the files directly with _use_certificate_file
and _use_PrivateKey_file, which is usually more convenient.
Also, you don't show BIO_free for second bio (mem leak).
The bio free was omitted accidentally, it is done in the code. Its
done this way as this is all part of a library, which needs to accept
keys from memory, to allow greatest flexibility.
Ive just run a test changing the code to use a file, and no change.
SERVER: SSL_accept(sssl) //Keep on doing this until WANT_READ
stops
Server didn't do (SSL_CTX|SSL)_set_verify ? If so (as previously noted)
it shouldn't be requesting client to authenticate at all.
The server doesnt request the client verify. It would fail if it did
as the keys arent signed by a ca, just auto generated.
CLIENT: len=i2d_RSAPublicKey(rsakey,correct_sized_buf)
//Move correct_sized_buf back to its start
CLIENT: pubrsa=d2i_RSAPublicKey(NULL,correct_sized_buf,len)
Aside: I THINK you don't actually need this i2d-d2i conversion,
if you just set a (tagged) RSA* that happens to be a privatekey
it can be encoded as a publickey (because of how RSA works).
Right, this is one of those things I got after many hours trawling
through websites.
CLIENT: X509_set_version(ccert,3);
Aside: I'm pretty sure that should be 2. X.509 version 3 is
the version of the standard but the certs actually have a
version field value of 2. In fact you apparently aren't using
extensions, so a value of 0 meaning version 1 would work.
Fair enough
CLIENT: X509_set_notBefore(ccert,timebound);
CLIENT: X509_set_notAfter(ccert,timebound);
Aside: the same time? Normally you want notBefore=some_time
and notAfter=some_later_time (typically +3mo/2yr/10yr, etc.)
Yeah, I do set those values to proper times (yesterday/yext year), I
just didnt think it was worth mentioning, as its all for the generated
key
CLIENT: SSL_CTX_use_PrivateKey(cctx,ckey);
CLIENT: SSL_CTX_use_certificate(cctx,ckey)
I hope that's a typo and you meant ccert there.
Yeah, I did. Sorry
So your client has created its own selfsigned cert, using (and for)
a key the server knows nothing about. If this was actually used
for authentication it should fail, because the server has no reason
to trust it. But per above the server is probably not requesting it,
and per below you are getting an error before client auth anyway.
Yeah, the server doesnt need to know who the client is in this
instance. The generated keys are for encryption only.
CLIENT: SSL_connect(cssl);//Keep on doing this until WANT_READ
stops
**HERE** We get the error on SSL_connect after a few WANT_READS
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate
verify failed
So, thats the routine used. The exact reverse, where the client uses
the same keys and the server has the same ca, works just fine.
I'm not sure what you mean by client uses 'same keys' since you show
client generating a different, and probably useless, key on each run.
Yes, I mean, if the process is reversed. Giving the verifiable keys to
the client and having the server generate random keys. The library is
designed to work with both, either, or none of the parties having
verifiable keys.
But if server has use_privatekey/certificate of serverkey/cert.pem
and client has load_verify_locations of rootcert.pem, it should pass
this step = server authentication. (I suspect you will still have
a problem with client authentication, but that's a different matter.)
You could try writing a verify callback used in the client that logs
or displays some convenient bits of the received cert/chain and check
they are as they should be, or just debug it and look at the same.
Maybe you have a bug in your multithreading, but those tend to be erratic;
could you perhaps configure one process to run only the client thread
and a different one to run only the server thread?
Same happens on different processes.
Thanks, I'll go look at how on earth to write a verify callback, which
I have no idea how to do, but the oreilly and the source code should
be able to give me a clue. Only problem is, Im not really sure what Im
looking for {:-)
Thanks
--
Michael Simms
RE: Client verify failing - continued
From: [EMAIL PROTECTED] On Behalf Of Michael Simms Sent: Wednesday, 19 November, 2008 11:05 OK, as requested, I'm going to give a detailed breakdown of what the client and server does with this error As a note: The certificates are *fine* I have used them successfully with s_client and s_server tests. They verify perfectly well. The one you've attached, yes; the one you are generating in code, maybe not, because s_client (and s_server) never does that. So, the conversation goes as follows. I am abbreviating some of it, but only the unimportant bits (like the low level socket negotiation, and the values we pass into the generated keys which arent being verified). SERVER: SERVER: socket() // Create socket SERVER: fcntl() // Nonblocking fcntl SERVER: bind()// Bind to port SERVER: listen() // Listen on port SERVER: SSL_library_init() SERVER: SSL_load_error_strings() SERVER: ssl_meth=SSLv23_server_method() SERVER: sctx=SSL_CTX_new(ssl_meth) SERVER: bio = memory_buf_BIO(private_key, -1) SERVER: if (private_key_password) SERVER: key=PEM_read_bio_PrivateKey(bio,NULL, ssl_key_password_callback, private_key_password) SERVER: else SERVER: key=PEM_read_bio_PrivateKey(bio,NULL,NULL,NULL,NULL) SERVER: BIO_free(bio) SERVER: bio = memory_buf_BIO(public_key, -1) SERVER: cert=PEM_read_bio_X509(bio,NULL,NULL,NULL) SERVER: SSL_CTX_use_PrivateKey(sctx,key) SERVER: SSL_CTX_use_certificate(sctx,cert) SERVER: SSL_CTX_check_private_key(sctx)// PASSES It seems overwhelmingly likely, but just to be absolutely clear, I presume private_key and public_key are buffers containing the servercert.pem and serverkey.pem files you posted. You could read the files directly with _use_certificate_file and _use_PrivateKey_file, which is usually more convenient. Also, you don't show BIO_free for second bio (mem leak). CLIENT: socket() CLIENT: fcntl() // Nonblocking fcntl CLIENT: connect() //WAIT for connect to succeed SERVER: accept() SERVER: fcntl() // Nonblocking fcntl on new socket SERVER: sssl=SSL_new(sctx) SERVER: SSL_set_fd(sssl,newly_accepted_fd) SERVER: SSL_accept(sssl) //Keep on doing this until WANT_READ stops Server didn't do (SSL_CTX|SSL)_set_verify ? If so (as previously noted) it shouldn't be requesting client to authenticate at all. //CLIENT DOES **NOT** run SSL_library_init, as this is a unit test //run with the server and client in one process, and so it does not //initialise twice. CLIENT: ssl_meth=SSLv23_client_method() CLIENT: cctx = SSL_CTX_new(ssl_meth) CLIENT: SSL_CTX_load_verify_locations(cctx, ca_filename,NULL) CLIENT: SSL_CTX_set_verify(cctx,SSL_VERIFY_PEER,NULL) CLIENT: SSL_CTX_set_verify_depth(cctx,10); //THIS SECTION is all just generating a new keypair CLIENT: rsakey=RSA_generate_key(1024,RSA_F4,NULL,NULL) CLIENT: ckey = EVP_PKEY_new() CLIENT: EVP_PKEY_assign_RSA(ckey, rsakey) CLIENT: required_size = i2d_RSAPublicKey(rsakey,NULL) CLIENT: len=i2d_RSAPublicKey(rsakey,correct_sized_buf) //Move correct_sized_buf back to its start CLIENT: pubrsa=d2i_RSAPublicKey(NULL,correct_sized_buf,len) CLIENT: tmp_pkey = EVP_PKEY_new(); CLIENT: EVP_PKEY_assign_RSA(tmp_pkey, pubrsa); Aside: I THINK you don't actually need this i2d-d2i conversion, if you just set a (tagged) RSA* that happens to be a privatekey it can be encoded as a publickey (because of how RSA works). CLIENT: ccert=X509_new(); CLIENT: X509_set_pubkey(ccert,tmp_pkey); CLIENT: X509_set_version(ccert,3); Aside: I'm pretty sure that should be 2. X.509 version 3 is the version of the standard but the certs actually have a version field value of 2. In fact you apparently aren't using extensions, so a value of 0 meaning version 1 would work. CLIENT: X509_set_serialNumber(ccert, serial); CLIENT: X509_set_notBefore(ccert,timebound); CLIENT: X509_set_notAfter(ccert,timebound); Aside: the same time? Normally you want notBefore=some_time and notAfter=some_later_time (typically +3mo/2yr/10yr, etc.) CLIENT: X509_set_subject_name(ccert,subject); CLIENT: X509_set_issuer_name(ccert,subject); CLIENT: X509_sign(ccert, ckey, EVP_md5()); //THIS FINISHES the creation CLIENT: SSL_CTX_use_PrivateKey(cctx,ckey); CLIENT: SSL_CTX_use_certificate(cctx,ckey) I hope that's a typo and you meant ccert there. So your client has created its own selfsigned cert, using (and for) a key the server knows nothing about. If this was actually used for authentication it should fail, because the server has no reason to trust it. But per above the server is probably not requesting it, and per below you are getting an error before client auth anyway. CLIENT: SSL_CTX_check_private_key(cctx)//PASS CLIENT: cssl=SSL_new(cctx); CLIENT:
