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: > > From: owner-openssl-us...@openssl.org On Behalf Of Karthik > Ravikanti > > Sent: Tuesday, 11 January, 2011 00:44 > > > Does OpenSSL provide any API for managing a trust store and a key > store like Java? > > Not in the same way at least. > > OpenSSL most easily uses certs and keys (and related things) stored in > files, > either as DER or PEM (which is actually just labelled base64ed DER, > but sometimes using different encryption where applicable i.e. > privatekeys). > (PEM is the format Java keytool -exportcert calls ambiguously 'rfc'.) > > You can read or write a file containing a cert with the X509* or PEM*X509 > routines. Similarly you can read or write a file containing a privatekey. > These routines can also use data from or to another store e.g. a database. > You can generate (and write) keypairs (and parameters separately where > applicable) and symmetric keys (useful only for lowlevel, see below, > like Java). You can create a CSR for a key; issue a cert from a CSR > (or IIRC directly from a key) if you act as a CA; create a selfsigned cert > for a key; create CRLs if you act as a CA; etc. Unlike Java, you can > have multiple certs for one key or no cert for a key if you want, > although situations where this is actually useful are fairly rare. > > 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; there is a perl script c_rehash to > (re)create hashlinks or you can build on commandline x509 (or crl). > (Aside: if you need to work with existing/old OpenSSL installations, > be aware the hash algorithm used here is different 0.9.8 vs 1.0.0.) > The OpenSSL distro itself does not include any 'recommended' CAcerts, > although I believe (some?) packagers may add that. You can easily > script exporting the CAcerts in a Java distro's (or installation's) > jre/lib/security/[jsse]cacerts into a file or directory for OpenSSL. > I don't know any equally easy way with IE or FF, but there may be one. > And of course you can add any CAcert(s) you choose to. > > 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? Also, if I add a certificate to an X509_STORE, will it be reflected in the file system store? 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. 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. 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. I found a X509_TRUST_*() class of functions in the code. What do these do? Can they simplify any of this? > 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. For a peer's own cert (or chain) and privatekey (possibly > for each of RSA, DSA, ECDSA), OpenSSL can directly read a file, or can > be passed the data (DER) which you can store and obtain anyhow you wish. > In PEM format 'wrong type' data is skipped, so you can put a peer's > privatekey and cert together in one file, but you aren't required to. > > 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(). > In particular, OpenSSL supports PKCS12 files, which Java (more exactly, > the default Suncle provider) supports as a keystore type, but OpenSSL > can't use them directly for SSL connections. Your app could easily > use PKCS12_* to read such a file and decrypt the privatekey(s), > and pass the (selected?) cert(s) and privatekey(s) to SSL_[CTX_]* . > Getting CAcerts from a PKCS12 used for verification would be harder. > I believe, but haven't tested, that within some limitations > you could use the same PKCS12 file (for a peer) from both Java > and OpenSSL, and (thus) maintain it with Java keytool etc. > > A PKCS12 is integrity-protected (MACed). Privatekey files in 1.0.0 are > usually in PKCS8 format, which I'm sure is MACed; before that they are > often in PEM-encrypted format, which I think is but would have to check. > But the *set* of files (keys, certs, etc.) in a directory is protected > against add, substitute, damage, delete only by OS/filesystem protection. > > For OpenSSL's lower-level crypto API, it's all up to the app. You can read > a file(s); keep in a database; or use carrier pigeons (if you have them). > (Similarly in JCE you can use keys etc. from a store but can just as easily > use key data from anywhere you like run through an appropriate Factory.) > > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org > Thanks, Karthik
