On Sun, Sep 28, 2014 at 11:59 PM, Jason Haar <jason_h...@trimble.com> wrote:
> ... > If I just "click through" the defaults of "openssl ca", I'd probably end > up with a 2048bit RSA, SHA-2 (256) cert. So my question is, should I > future proof that by making it 4096bit and maybe SHA-2 (512)? (ie I want > the CA to be viable for 10 years, not 5 years). What is the performance > impact of increasing these values of the CA cert itself? I'd expect to > still only sign 2048-bit, SHA-256 server/client certs - but is there a > real performance downside to making the CA cert itself stronger? I don't > care if the CA takes 30 seconds longer to sign a cert - but I'd really > care if it made a web browser hang when talking to the resultant server > cert ;-) There are many places where a PKI breaks - hash collisions are far down the list. Most internal CA implementations offer no more effective security or trust than just using self-signed certs - the objective seeming to be to make browsers not complain about the SSL connection. Without subsidiary CAs, good discipline about their use, a CRL distribution point baked into certs (or OCSP), you can only verify that a cert was valid when it was signed, but have no way of dealing with private key compromise, etc. which happens all the time. Spend some time thinking about revocation, cert lifespan, etc.if you want to make a CA "stronger." - M ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
