We have started to issue certificates with the "new" more secure algorithms, SHA2 (or to be precise SHA256) - basically, it means that the hashing algorithm which is a part of the signature is more secure against attacks than the current SHA1 algorithm (which in turn is more secure than the older MD5).
But only to a lucky few, not to everybody. And even they get to keep their "traditional" SHA1 certificates alongside the SHA2 one if they wish.
Because the catch is that not everything supports SHA2. The large middleware providers have started worrying about supporting SHA2, but we only really know by testing it.
So what's the problem? A digital signature is basically a one-way hash of something, which is encrypted with your private key: S=E(H(message)). To verify the signature, you would re-hash the message, H(message), and also decrypt the signature with the public key (found in the certificate in the signer): D(S)=D(E(H(message)))=H(message) - and also check the validity of the certificate.
If someone has tampered with the message, the H would fail (with extremely high probability) to yield the same result, hence invalidate the signature, as D(S) would no longer be the same as H(tamper_message).
However, if you could attack the hash function and find a tamper_message which has the property that H(tamper_message)=H(message), then the signature is useless - and this is precisely the kind of problem people are worrying about today, for H being SHA1 signatures (and history repeats itself, since we went through the same stuff for MD5 some years ago.)
So we're now checking if it works. So far, we have started with PKCS#10 requests of a few lucky individuals; I'll do some SPKACs tomorrow. If you want one to play with, send us a mail via the usual channels (eg email or helpdesk.)
Eventually, we will start issuing renewals with SHA2, but only once we're sure that they work with all the middleware out there... we also take the opportunity to test a few modernisations of extensions in the certificates.
But only to a lucky few, not to everybody. And even they get to keep their "traditional" SHA1 certificates alongside the SHA2 one if they wish.
Because the catch is that not everything supports SHA2. The large middleware providers have started worrying about supporting SHA2, but we only really know by testing it.
So what's the problem? A digital signature is basically a one-way hash of something, which is encrypted with your private key: S=E(H(message)). To verify the signature, you would re-hash the message, H(message), and also decrypt the signature with the public key (found in the certificate in the signer): D(S)=D(E(H(message)))=H(message) - and also check the validity of the certificate.
If someone has tampered with the message, the H would fail (with extremely high probability) to yield the same result, hence invalidate the signature, as D(S) would no longer be the same as H(tamper_message).
However, if you could attack the hash function and find a tamper_message which has the property that H(tamper_message)=H(message), then the signature is useless - and this is precisely the kind of problem people are worrying about today, for H being SHA1 signatures (and history repeats itself, since we went through the same stuff for MD5 some years ago.)
So we're now checking if it works. So far, we have started with PKCS#10 requests of a few lucky individuals; I'll do some SPKACs tomorrow. If you want one to play with, send us a mail via the usual channels (eg email or helpdesk.)
Eventually, we will start issuing renewals with SHA2, but only once we're sure that they work with all the middleware out there... we also take the opportunity to test a few modernisations of extensions in the certificates.