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
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
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
There are many places where a PKI breaks - hash collisions are far down the
list.
What he said.
4KRSA -SHA-256 is fine for a CA. Most likely operational issues will cause you
problems. Invest in an HSM.
--
Principal Security Engineer, Akamai Technologies
IM: rs...@jabber.me Twitter:
Out of general interest,
Assuming a low e (such as e=65537) RSA public key, how big is the
cost of going from a 2048 bit to a 4096 bit modulus for an
intermediary CA, given that verifications will significantly
outnumber signings for a CA key?
On 29/09/2014 09:26, Kyle Hamilton wrote:
On 30/09/14 03:30, Michael Sierchio wrote:
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
JH On 30/09/14 03:30, Michael Sierchio wrote:
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
