> 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
