Thank you for your advice. SSL_CTX_get_cert_store() was the right clue and X509_STORE_add_cert() did the trick.
> -----Original Message----- > From: owner-openssl-us...@openssl.org [mailto:owner-openssl- > us...@openssl.org] On Behalf Of Dave Thompson > Sent: 19 November 2013 00:07 > To: openssl-users@openssl.org > Subject: RE: Error 18: self signed certificate > > > From: owner-openssl-users On Behalf Of Mark Currie > > Sent: Monday, November 18, 2013 03:24 > > > I also managed to get self-signed certs to work like this but does > > anyone know how to use self-signed certs in a RAM-only environment > > i.e. no disk available? > > > Your OS or C runtime might provide a RAM filesystem in which case you can > use that, assuming you have the cert(s) to put in it. Otherwise as I said > earlier, build SSL_CTX cert_store by hand, ditto. > > Both these assume you have some permanent storage, maybe FLASH or even > ROM. Presumably the program comes from somewhere secure, so at worst > you can embed the cert data in your program, either as plain C data or as > something like a 'resource' in Windows or MacOS. > > > > -----Original Message----- > > > From: owner-openssl-us...@openssl.org [mailto:owner-openssl- > > > us...@openssl.org] On Behalf Of Manoj > > > Sent: 18 November 2013 10:09 > > > To: openssl-users@openssl.org > > > Subject: Re: Error 18: self signed certificate > > > > > > Thanks Guys for the help, I got it working by loading the location > > > using > > API > > > SSL_CTX_load_verify_locations(). The location where I have the > certificate > > > available. > > > > > > I have another question related to certification verification itself. > > > Can by any mean, I verify a peer certificate(self signed) without > > > having > > it in > > > the trust-store? > > > or > > > Let me put in other words , Server application verifiying clients > > > with > > each > > > client having its own self signed certificate, Does the server > > > require > any > > prior > > > information about certificates (i.e. having them as part of cert > > > trust > > store)? > > > > For OpenSSL to do the verification it must have cert in truststore, yes. > (To be exact it must have the root; for selfsigned the root is the cert.) > > You can override or replace OpenSSL's verification using the callback(s), but > what will you use instead? There's nothing in a selfsigned cert by itself > (without a truststore) that can't be faked. Instead of full certs you could > configure the peer=client publickey values and accept any cert using that > value -- assuming handshake succeeds through Finished which also proves > client possession of the privatekey. > That's what ssh does, with a shortcut for configuration on first use. > You could configure hashes of the publickeys -- even with MD5 and probably > SHA1 broken for collision AFAIK there's no 2nd-preimage. > You could configure hashes of the certs -- ditto -- although that would make > it harder to debug cases where a client created multiple certs for the same > key -- perhaps one by mistake and a corrected one -- and one of you has the > wrong one. > > If you have more than a few authenticated clients, it is usually easier to issue > them certs under a CA -- either your own ad-hoc CA, which can be done with > OpenSSL, or a 'real' public or organization CA -- and the server then only > needs that one cert. Note if you use a CA that issues EE certs under an > intermediate or "chain" cert -- which (all?) public ones do now -- according to > standard the client should be configured to send the chain certs. However > OpenSSL relier will fill in missing chain certs from its truststore, so it may be > easier to just configure them once on the server. > > > > Or > > > Is there any way possible of getting peer certificate without having > > > set > > the > > > SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, verify_callback); > > > > For *server* to get *client* cert, you must set SSL_VERIFY_PEER. It's your > choice whether to use a callback or not (you can set it null). For > *some* clients you may also need to call _set_client_CA_list to tell the client > which cert you want when it has more than one, but for simple OpenSSL > clients they just use the one (per kx) configured cert&key without checking if > it matches the server request. > > For *client* to get *server* cert you don't actually have to do anything; if > handshake selects a suite that uses certs, you get the cert, period. > If it selects a suite that doesn't use certs (either noncert auth like Kerberos, > or no authentication at all) you never get a cert no matter what you set. > > > > ______________________________________________________________ > ________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
