Thank you for the reply. It is probably obvious that I am new to SSL programming, and I am modifying some existing code. I will read over your information and write back if I am still having issues.
Thanks Derek On Wed, Oct 10, 2012 at 4:30 AM, Dave Thompson <[email protected]>wrote: > >From: [email protected] On Behalf Of Derek Cole > >Sent: Tuesday, 09 October, 2012 21:12 > > >I am trying to write a server that will accept an incoming SSL connection. > > >In psuedo, I have the following chain of function calls > > > SSL_CTX_load_verify_locations(ctx, root_cert_file, root_cert_dir) > > SSL_CTX_use_certificate_chain_file(chain file) > > SSK_CTX_use_PrivateKey_file(chain file) > > SSL_CTX_set_verify (sets SSL_VERIFY_PEER) > > SSL_CTS_set_verify_depth(to a depth of 4) > > I assume you are checking all calls that can return an error > indication; you suggest this below "everything goes fine". > If not, do so. But not all errors are (or can be) caught, > so lack of error indication doesn't prove lack of error. > > When you request client auth (aka client cert), it's usually > best to specify the CAs you like, so if the client has multiple > certs it can pick right. OpenSSL does NOT do this automatically. > If root_cert_file (or another file) has all CA(s) you trust, you > can use SSL_load_client_CA_file and SSL_[CTX_]set_client_CA_list . > Otherwise, e.g. if you have CA(s) present only in root_cert_dir, > it's a little more complicated. > > Note SSL_VERIFY_PEER requests client auth but doesn't require it. > To require it add SSL_VERIFY_FAIL_IF_NO_PEER_CERT . > > And if you want to allow clients to use certs from a public CA, > depth 4 doesn't leave much margin. Practically all public CAs > today chain either 2 or 3 within the CA itself, and often 1 or 2 > more when one CA "buys" trust from another (usually older) one. > If you require clients use certs you issue with your own CA > (see below) you can control the depth. > > > The chain file has 3 things in it - > > private key of the server CA > > a signed certificate request signed by my server CA > > the public key of the server CA > > 0. A CA doesn't sign requests (CSRs), it signs certs. > A cert is *derived from* a CSR, but it isn't a signed CSR. > If you have a cert issued from a CSR for your server, > it is a cert for your server, or just your server cert. > > 1. A cert chain consists of certs, not publickeys. > > 2. If your server cert is signed by the CA root key+cert, > you don't need any chain. Just load the server privatekey > and the server cert. If your server cert is signed by an > intermediate CA key+cert, and that possibly by another etc., > you must either (1) send chain or (2) have client(s) trust > anyway, depending on client. There are several suboptions: > (1A) give the server cert and chain cert(s) in chain_file > (1B) give the server cert and have chain cert(s) in server > truststore (your root_cert_file and/or root_cert_dir). > OpenSSL automatically fills the chain from truststore. > (2A) have client trust the first (non-sent) intermediate > cert as an anchor. OpenSSL doesn't but other clients may. > (2B) have all non-sent chain certs in and used from client > truststore. OpenSSL does (automatically). > 2A and 2B depend on the client(s), and so are suitable only > if your clients are known and reasonably few. > > 3. In all cases, the/each client's truststore must contain > the CA root for the server cert. Does "my" server CA mean one > you own and operate, or a public one you chose to use? > > 3A. If the server CA is a public one like Verisign, the client > may already trust its root, depending on the client. Windows > and common web browsers, and some utilities like curl, and > Java, come with truststores containing some dozens of public > established CA roots. OpenSSL does not. If you use s_client > or similar, you need to get at least the root used, and > optionally others you like, and put in client truststore. > > 3B. If the server CA is one you created (and not delegated > as a CA under an established CA, which AIUI is difficult and > costly to obtain so probably not), no typical client will > have its root already; for all clients, you must add it. > > >When I create a new SSL structure everything goes fine, but when > >I call SSL_accept() on it, I get a return of zero, which when > >I read the error queue says "sslv3 alert bad certificate" > > >What does this error mean exactly? Is it a problem with my server > >certificate itself, the client certificate returned on the verify, > >or what? > > "alert" means client said it didn't like your (server) auth. > Either the client is mistaken, usually because it doesn't have > the root in its truststore as above (though bugs are possible), > or the cert/chain you sent is in fact bad. This occurs at a > point the in protocol before client-auth, so no attempt was > made to verify any client cert. If a client cert is received > and doesn't verify, that's a different error. > > The client may have displayed a more specific error. If not, > try another client. If no better client is available, and > you have or can get openssl on (any) client system, use s_client > with a suitable truststore as above; it will be more specific. > > Or just examine your files and calls based on the rules above. > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List [email protected] > Automated List Manager [email protected] >
