It's already here in fact. About a month ago, Comodo stopped issuing certificates from its old SHA-1 intermediaries. When we had ours reissued after Heartbleed, it was signed by a SHA-256 intermediate certificate.
We found out the impact of this the hard way -- not only with Windows older than XP Service Pack 3, but also with embedded systems and devices built with OpenSSL older than 0.9.8o.
These kinds of things really suck, when people you rely on supply you with things that breaks your stuff unexpectedly... Breaking stuff is okay, surprising the customers is not, imho...
What type of certificate did you get, and what was the intermediate certificate named?
I'm asking because I recently bought a Comodo PositiveSSL certificate, and it was still signed with SHA-1. The intermediate certificate was also signed with SHA-1 (the same one that they've been using for quite a while already). I guess they reserve SHA-256 to more expensive products for now?
Really? Openssl changelog implies all versions starting with 0.9.8 should handle sha256 signed certs.
It wasn't enabled by default until 0.9.8o. In earlier versions, if you wanted to use SHA-256 with SSL/TLS, you needed to call OpenSSL_add_all_algorithms() or specifically enable SHA-256. Not all software does this. I would guess that embedded systems shy away from it because it does add some overhead.
Your description is an inaccurate representation of the API then. OpenSSL has had SHA-256 support by default since the initial 0.9.8 release.
Use of the EVP lookup functions is dependent upon calling OpenSSL_add_all_algorithms() or populating the tables by other means. What (if any) algorithms are available without doing so is not defined anywhere in the API. There is no guarantee that SHA-1 or MD5 would be available either.
Edit: If you know of programs linked against early openssl 0.9.8 that are having problems you should file bugs, because they are reliant upon undefined behavior in the OpenSSL API. This is true even when linked against OpenSSL 1.0.1.
Edit 2: Not that this makes the problem any less real, but the problem is the broken applications, not the version of OpenSSL they linked to. Being version 0.9.8o is not necessary for SHA-256 certificate support for programs correctly using the OpenSSL API.
It is only needed for Server 2003. XP SP3 already have SHA256 support out of the box and it is not supported on XP SP2. AFAIK this hotfix is also in MS13-095/KB2868626 as they removed the GDR branch.
Comments
It's already here in fact. About a month ago, Comodo stopped issuing certificates from its old SHA-1 intermediaries. When we had ours reissued after Heartbleed, it was signed by a SHA-256 intermediate certificate.
We found out the impact of this the hard way -- not only with Windows older than XP Service Pack 3, but also with embedded systems and devices built with OpenSSL older than 0.9.8o.
These kinds of things really suck, when people you rely on supply you with things that breaks your stuff unexpectedly... Breaking stuff is okay, surprising the customers is not, imho...
What type of certificate did you get, and what was the intermediate certificate named?
I'm asking because I recently bought a Comodo PositiveSSL certificate, and it was still signed with SHA-1. The intermediate certificate was also signed with SHA-1 (the same one that they've been using for quite a while already). I guess they reserve SHA-256 to more expensive products for now?
Ours is Organization Validated - it's possible that they're still using SHA-1 intermediates for Domain Validated certificates.
Really? Openssl changelog implies all versions starting with 0.9.8 should handle sha256 signed certs.
RHEL5's openssl 0.9.8e and Debian "Lenny" 5.0's openssl 0.9.8g both work fine with the SHA-256 signed cert. Although they may have backports applied.
It wasn't enabled by default until 0.9.8o. In earlier versions, if you wanted to use SHA-256 with SSL/TLS, you needed to call OpenSSL_add_all_algorithms() or specifically enable SHA-256. Not all software does this. I would guess that embedded systems shy away from it because it does add some overhead.
Your description is an inaccurate representation of the API then. OpenSSL has had SHA-256 support by default since the initial 0.9.8 release.
Use of the EVP lookup functions is dependent upon calling OpenSSL_add_all_algorithms() or populating the tables by other means. What (if any) algorithms are available without doing so is not defined anywhere in the API. There is no guarantee that SHA-1 or MD5 would be available either.
Edit: If you know of programs linked against early openssl 0.9.8 that are having problems you should file bugs, because they are reliant upon undefined behavior in the OpenSSL API. This is true even when linked against OpenSSL 1.0.1.
Edit 2: Not that this makes the problem any less real, but the problem is the broken applications, not the version of OpenSSL they linked to. Being version 0.9.8o is not necessary for SHA-256 certificate support for programs correctly using the OpenSSL API.
Luckily there's a hotfix[1] that we have been telling our users to download if they're having this issue.
[1]: http://support.microsoft.com/kb/968730
It is only needed for Server 2003. XP SP3 already have SHA256 support out of the box and it is not supported on XP SP2. AFAIK this hotfix is also in MS13-095/KB2868626 as they removed the GDR branch.
Hacker News is already using it, probably because of this.