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
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
