On Fri, Jan 14, 2011 at 8:03 AM, Dave Thompson <dthomp...@prinpay.com>wrote:
> > From: owner-openssl-us...@openssl.org On Behalf Of Karthik > Ravikanti > > Sent: Thursday, 13 January, 2011 05:12 > > > Thanks a LOT for the detailed reply. I was more interested in the > > SSL connection part. Please find my responses inline. Just to add some > > context, I'm trying to implement SSL sockets on the iPhone and am just > > using Java as a reference. > > > On Wed, Jan 12, 2011 at 9:47 AM, Dave Thompson > <dthomp...@prinpay.com> wrote: > > > For an SSL connection, OpenSSL can directly use a PEM file > containing > > all trusted CAcerts, or a directory containing for each > CAcert a file > > with the filename, or usually better a symbolic link, being > the hash > > of the CA name for lookup; ... > > > So, the filesystem based certificate store (of PEM files) seems to > be > > the easiest method. I looked at the PEM*() functions before, they don't > seem > > to support augmenting an existing PEM file. if I have to add new > certificates > > to the store is maintaining a folder of PEM files a better option? > > The PEM* routines can use a C filepointer or a BIO > and C fopen() can append to an existing file on output. > Replacing or deleting an entry would be harder. > > Separate file (in dir) is simple, and easy to replace > or delete, but unless you use hash *names* make sure > hash links are created/updated as necessary. > > > Also, if I add a certificate to an X509_STORE, will it be reflected > > in the file system store? > > Not automatically. > > > I suppose I can avoid bundling any CA certs by using a native > > verification API when verification fails. That should guarantee > > that the certificate is alsways verified against the device's default > > list of CA certificates. > > Should work, although I haven't tried it. > > > I suppose there is no concept of a key store, though. What I mean > > is I can't just put all my private keys in a folder and call something > > like SSL_CTX_load_verify_locations(). I'd have to fetch the exact > > certificate and private key for the peer (near end). I may have to > > decide on a file name scheme for that. > > Yes. If there is a choice, i.e. you have multiple key/certs > for your device, often called 'identities', your code > must give the right one for a session to SSL_[CTX_]use* . > OpenSSL won't pick the right one out of a set -- even if > the server specifies a desired CA (or list) which would > be sufficient to select e.g. 'me-retail' vs 'me-internal'. > (Except for different PK *algorithms*; you can set one > privkey/cert for RSA and one for DSA and one for ECDSA, and > OpenSSL will use the one for the ciphersuite negotiated. > But doing e.g. RSA for one identity and DSA for a different > identity will generally produce different security results > depending on server features you can't control and most > users don't understand, causing errors and confusion.) > > Using filename(s) for that is easy, although > I can think of other methods like an index file. > > Of course this is assuming you use/need (SSL) client auth. > Many Internet applications don't. > > > Or I probably can just use the native key store, with the overhead > > of converting between the native certificate and key objects to OpenSSL > objects. > > Should work, if the native keystore lets you get the actual > privkey out as PKCS#1. (And the cert as X.509, but no one > has a good reason to restrict certs or use other than X.509.) > I'd be unpleasantly surprised if the overhead of converting a key > is significant compared to the overhead of an SSL connection -- > but I have had some unpleasant surprises in my life. For certs > I'd be surprised to see anyone use something besides X.509 -- > nothing else has significant public acceptance. > > > I found a X509_TRUST_*() class of functions in the code. > > What do these do? Can they simplify any of this? > > I don't know exactly; I don't use them. I think they add some > finer trust settings to an X.509 cert, kind of like keyUsage > or extendedKeyUsage but not set/confirmed/signed by the CA. > Firefox does a similar thing: you can change some (simple) > options for a cert in its truststore without changing the cert. > > > Alternatively I understand you can write your own > X509_STORE > 'subclass' > > which gets certs (and CRLs) anyhow you wish (e.g. a > database) but it's > > more work. ... > > > I'm planning to override just the 'verify' method in my > application's > > SSL_CTX's X509_STORE. There I can call the native certification > verification > > methods. Will that work? From what I've seen in the code, all the other > > callbacks get called only from within verify(). > > When I've needed to trace though cert verify logic (with default > STORE and LOOKUPs, using a pre-read file or a hashlinked directory) > it reminded me forcefully of the Gordian knot. Just replacing > one method may work, but I'm not at all certain. On more thought, > to just use your own store it's probably enough to change > the X509_LOOKUP(s) in the X509_STORE, not the entire STORE. > > Or to replace the whole verify logic with native (or other) > SSL_CTX_set_cert_verify_callback looks good; I haven't tried. > As opposed to using OpenSSL *logic* with a different supply > of *data*, STORE/LOOKUP are clearly designed for that. > SSL_CTX_set_cert_verify_callback sets 'verify_cb', which gets called only after the verification. Where as 'verify' by default points to 'internal_verify' which seems to do all the hard work. That's why I'm thinking of overriding just it. I'm already doing that in the code (which is not working yet , btw). I'll let you know how it goes. Yes, using LOOKUP is also a good option, probably cleaner too. I'll see if that works for me and let you know. > > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org >
