> From: owner-openssl-us...@openssl.org On Behalf Of Ariel
> Sent: Friday, 22 October, 2010 13:04
> On Thu, Oct 21, 2010 at 7:52 PM, Dave Thompson
<dthomp...@prinpay.com> wrote:
<snip>
> Do as sandeep said. Create your own private CA with OpenSSL.
You issue
> certs to clients (who request them) and set your server(s)
to trust your
> private root and thus the certs presented by the clients.
Your server
> presents the cert issued to it under a real CA which the
clients trust.
> This means I need to create my own self-signed CA cert, right?
> And this is what I'm trying to avoid "Because there is no established
> trust hierarchy leading to a self-signed certificate, it is impossible
> to verify that a self-signed certificate is genuine." [1]
> [1]
http://publib.boulder.ibm.com/infocenter/zos/v1r10/index.jsp?topic=/com.ibm.
zos.r10.ikya100/intermed.htm
'verify' in this context means automatic. As that page continues:
"Accordingly, any person or application that wishes to process certificates
issued by a root authority must explicitly trust the authenticity of the
self-signed CA certificate."
If you use your own CA to issue the *server* cert, then each of your
clients must be configured to trust your CA. Sometimes for some clients
that's okay, but in general it's a hassle or worse, which is why in general
it's disrecommended. Since you got a Godaddy cert usable for your server,
you're fine on this front.
> I was reading here [2] because this is what I'm trying to do:
> SSL Client Authentication; but my problem is in how to setup or get
> a valid ca.crt that can use to sign and issue new client certificates
> and that will also validate properly.
> [2]
http://www.symantec.com/connect/articles/apache-2-ssltls-step-step-part-3
Aside: that page, and part-2, are completely screwed up in my IE7.
FF(3.5) is okay, except that the code (and data) <pre> blocks are
run together, apparently wrong in page source according to FF.
Those two pages are saying almost the same thing sandeep and I are,
but with (mostly right) detail. part-2 method 3 says how to set up
a 'local' CA using OpenSSL and use it to issue (and possibly revoke)
your server cert, and have your clients trust it. part-3 says how to
use it to issue and revoke client certs, and have your server trust.
I'm saying *don't* use it for the server cert, so your clients don't
need to trust it; *just* use it for the clients, only your server(s)
need to trust it, which should be easier and friendlier.
(part-3 doesn't mention it is also possible to have your clients
get certs from real CA(s) and have Apache trust those, but since
lots of other people besides your clients have certs from real CAs
you would need additional checks probably based on Distinguished Name
values, which is theoretically secure but could get complicated,
especially since different CAs don't enforce the same rules on DNs,
rather than just assuming any valid cert means a valid client.)
(part-3 also doesn't mention there are other ways to generate client
key and CSR, and resulting .p12, besides openssl. But since you have
and are using openssl anyway, it's convenient to use for these.
Plus on-topic!)
Having gone through it, some quibbles:
- in part-2 the Distinguished Name in the (garbled) code examples
is not the same as 'table 3' says they will use.
- for CA at least and perhaps entities I recommend RSA 2048 not 1024.
Bleeding-edge factoring is now close to 800bits and appears likely to
reach 1024 within a decade or so. AFAIK most authorities now recommend
2048 or at least 1536; for one major example, the US government
is officially 'required' by NIST not to use RSA 1024 after this year
(2010) although like most bureaucratic mandates it's already been
slipped some and will get waived or ignored more.
- AFAICS FF does not have passwords on its keystore entries as IE can.
I don't know about other browsers. So don't assume this is two-factor.
- I don't believe you will get the error shown if a client cert
is revoked. You should get some error, just not that one.
- the numbers for brute-forcing session (symmetric) keys are off.
40bit (if anyone is silly enough to use it) is now probably minutes,
and 56 on the order of days depending on how much hardware (or
equivalently money) you have to spend. 128 (and even 'tripleDES'
which is really 112 given soon-feasible storage) is still billions
or trillions of years even using all the computers on the planet.
And 'supercomputer' is a red-herring. Brute-forcing symmetric
is totally parallel; all that matters is total compute cycles,
and a few thousand (botted?) PCs, or cellphones, is just fine.
On the other hand factoring (and thus breaking) RSA does still
partly need the high connectivity of a supercomputer.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
