On 2014-10-10 at 20:51 -0700, Charles Polisher wrote: > Not to keep beating a dead horse, but here's a related thing > that puzzles me. I wonder if anyone else gets a different > result. I've got 2 very different certs claiming to be the > Google Internet Authority G2. Same subject, same auth key ID, > same subject key id, same public key. Different certs. Huh?
Important point: signatures are made by private keys, not by
certificates. The certificate conveys the public key corresponding to
the private key.
So a certificate path of "A (root) -> B (intermediate) -> C (server)"
has a certificate for C issued using the _key_ of B; the _certificate_
of B can be replaced and as long as the same key is portrayed, it's very
possible for the old signatures to still be valid.
There may be differences in constraints, so it's still possible to break
the verification path, but an important issue coming up for all sysadmin
to be aware of is the need to audit and replace your intermediate
certificates. Since this ties into why you can have two different
certs, I'll expand upon it because this is germane to LOPSA folks.
The use of SHA1 in a certificate chain is being deprecated more
aggressively than some CAs had been assuming; they'd held for "well, we
can keep issuing right up to the deadline", but Chrome, followed closely
after by Mozilla, said "well no, SHA1 is already deprecated by NIST for
use, we shouldn't be accepting new certs issued using SHA1, here is our
schedule for how we're going to sunset support, in stages, so that this
_will_ be gone by the deadline". Browsers will start complaining, based
upon the expiry time of certificates. Cue much wailing and gnashing of
teeth by CAs.
The signature in each certificate is, like ~any public key crypto
signature, made by taking a cryptographic hash of the data to be
affirmed, then making a message using the private key, so that anyone
with the public key can confirm that the private key was used to make
the message, and when they use the same hash function over the same
data, they can protect against tampering.
For X.509 trust chains, the hash algorithm used in the "root"
certificate doesn't matter, if that certificate is in your trust store:
the presence of the certificate in the trust store is what provides the
trust linkage, not a signature. Every link _after_ that in a trust
chain needs to migrate away from SHA1 and towards, in practice,
SHA2-256. There are still some client browser constraints to catch you
here, if you're still running unsupported releases of some OSes.
If you have an end-site (end-user) certificate issued in the past year
or two, it really should have been issued using
`sha256WithRSAEncryption` (assumption: sticking with the mainstream and
not using ECC certs). If it was issued with `sha1WithRSAEncryption`
then you need to chase with the CA vendor getting your certificate
reissued using modern crypto.
You should not be paying for this reissue. This is not a mishap on your
side (such as Heartbleed affecting you) where the CA can charge for
work; this is a case where if the CA wants to avoid later nasty legal
class actions then they reissue using the algorithms they should have
been using in the first place. This new certificate will be for the
same key and probably the same CSR (Certificate Signing Request: the
thing you sent to the CA with the public key, after you generated a
private key, because of course you didn't let the CA generate a private
key for you). Some CAs with weirdly broken tooling will use the hash
algorithm in the CSR to select the hash algorithm in the certificate and
push work back onto you. If you encounter this, I recommend regarding
it as a sign that the CA's internal systems are effectively not
undergoing feature maintenance, that they're not ready to react to a
major crypto incident and thus as a warning sign that you should start
evaluating their competitors and planning your escape strategy.
When you start using the new certificate, you'll likely end up with a
chain which looks like:
server cert you purchased (sha256/RSA by intermediate)
by: intermediate (sha1/RSA by root)
by: root (sha1/RSA on self) (or even MD5 :( )
Which leads back around to the original issue: the CA should have
multiple versions of the intermediate certificate available. Same key
is represented, but there should be a version which is signed by the
same root but using `sha256WithRSAEncryption`.
If you replace the intermediate certificate in your trust chain with the
new one, you should end up with a chain which uses the same _keys_ at
each step, but certificates where all below the root are using SHA2-256
in the parent's signature.
Test thoroughly. Aim to try to get this migration finished THIS year.
http://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html
https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/
https://community.qualys.com/blogs/securitylabs/2014/09/09/sha1-deprecation-what-you-need-to-know
(Why is it that Google's online security blog is the only one of those
which force-redirects _away_ from HTTPS? Because irony is delicious?)
-Phil
signature.asc
Description: Digital signature
_______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
