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