On 8/31/2011 11:07 AM, Erwann ABALEA wrote:
Bonjour,
Hodie III Kal. Sep. MMXI, Jakob Bohm scripsit:
[...]
1) The CA has changed/improved the attributes, e.g. by extending the
expiry date or adding a CRL
location for detecting future root cert revocation (a good
precaution for CA's to take, coupled with
a pre-generated key compromise CRL stored somewhere off-site but secure).
The relying party won't automatically update its trust store when
receiving such a certificate, even if the key is reused. So it won't
trust this new certificate, and won't use it to build a valid
certification path. But you can of course manually grab it for this:
2) My browser lacks the CA cert, in which case having it at hand
eliminates one of the two steps
in securely adding it (the other step is to compare the cert hash
("fingerprint") with a known published
value).
Is that really useful? Always sending a useless certificate in case
someone would need it and use "openssl s_client -connect ...
-showcerts" to update its database, instead of providing a link to
this certificate somewhere?
Higher level user interfaces (such as web browsers) tend to make this
option available directly from the user interface that reports the CA
problem.
It is mostly a matter of answering yes and no in the right places.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
