Generally, a client doesn't bother checking a certificate that's in its local trust store. The idea is, if it's in its trusted store, there's no need to verify its integrity, because the administrator already performed that verification.
Where this might have an impact is if your new certificate is cross-certified by another organization's root. You'll have to judge for yourself how likely this scenario might be for your environment. -Kyle H On September 28, 2014 11:59:29 PM PDT, Jason Haar <jason_h...@trimble.com> wrote: >Hi there > >Due to the upcoming Google instigated phasing out of SHA-1, I'm looking >at creating a new enterprise CA (ie internal only) > >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 ;-) > >Thanks! > >-- >Cheers > >Jason Haar >Corporate Information Security Manager, Trimble Navigation Ltd. >Phone: +1 408 481 8171 >PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1 > >______________________________________________________________________ >OpenSSL Project http://www.openssl.org >User Support Mailing List openssl-users@openssl.org >Automated List Manager majord...@openssl.org -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
