> From: owner-openssl-us...@openssl.org On Behalf Of Yvonne Wambui > Sent: Friday, January 10, 2014 01:44
> thanks dave and martin. with all that information i think i should start the process again. > Do you have some materials that have step by step process of configuring two way connections I assume as before you mean two-way >authentication<, or client authentication. (The connection level in SSL/TLS is always two-way, regardless of authentication.) The details of authentication setup depend on the programs used at each end, which you haven't said except that at least one of them apparently uses openssl, and the Certificate Authority/ies = CA/s you use. In generic terms the process is: (ALMOST) ALWAYS DO >SERVER< AUTH 1. On server, generate a privatekey and obtain a cert for it. Usually this means generating a CSR and submitting it to a CA, which can be a public one (like Verisign, GoDaddy, etc.), a more private one like a corporation or government department, or a 'personal' CA you create yourself with openssl; in the first two cases you must also submit proof of your identity/legitimacy and usually payment; and get back your server cert, any chain certs needed, and maybe the root. Alternatively you can create a self-signed cert (no CA) but this is not usually a good idea. 2. Configure the server to use the server cert, any chain certs, and optionally the root (unless self-signed which has no root, or perhaps is its own root if you look at it that way). Method depends on the server program. 3. On client (each if more than one) trust the root for the server cert, or if the server cert is self-signed trust that individual cert. Some clients, including web browsers and Java apps and Windows 'MSXML' or dotnet apps and maybe more, come with a set of public CA roots already trusted, so if 1 used an established public CA, or a private one delegated from a public one, you don't need to do anything. Otherwise import/install/etc the server root (or self-signed cert) to the client(s). Method depends on the client program(s). Note if there is only one server ever, a self-signed server cert is no worse than a personal or nondelegated CA root. But in reality systems often need to be expanded or moved, and doing that is easier with a CA, even a personal one, than self-signed. ONLY IF & WHEN DOING CLIENT AUTH, ADD: 4. On (each) client generate a privatekey and obtain a cert for it; options are the same as 1 (except for a client cert from a real CA you usually need to prove less). 5. Like 1, configure client(s) to use the client cert, any chain certs, and optionally the root, or self-signed. (But for multiple clients self-signed is an even worse idea.) Method(s) depends on the client program(s). 6. Alternatively, if you are running a personal (or other) CA, and you have client(s) who are not technically adept especially if numerous, you can generate both privatekey and cert (and chain) for each client, and just have the client install them. This is simpler for the client(s) -- and thus easier for you to explain to them -- especially in most cases where you can package the key and certs in a single PKCS#12 (aka PFX) file. 7. On server trust the client root(s) (or self-signeds, but don't do that). If client(s) use a public CA(s), some servers already trust a set of public CAs, e.g. IIS on Windows and Tomcat/JSSE on Java. If I've guessed right your server uses openssl, the official distro doesn't include any truststore, but some packagings (e.g. some Linuxes) may, or your server package might. If it doesn't (or has one that is out of date or you otherwise don't want) http://curl.haxx.se/docs/caextract.html provides a converted copy of the current Mozilla/Firefox truststore, which is about as good as any conveniently available. For a personal or nondelegated CA, import/install/etc. root(s) depending on server program. Note these don't have to be strictly in the order described: 1 must precede 2 and 3, but 3 can precede 2; similarly 4 or 6 must precede 5 and 7, but needn't follow 1-3. Hope this helps. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
