by sign-in prompt, a notice that “ACM has verified that its servers are not impacted by the Heartbleed OpenSSL vulnerability.”

this only fixes heartbleed, each developer-customer needs to do the rest of the clean-up steps, after 2014-04-08

The certs generated with CAcert are fine, but the systems used to log into CAcert may have been compromised. Note that while the blog post is dated the 8th, the list of fixed systems is made in an undated update to the original post; we know the update was in place by the 10th.

CeroWRT is a router OS distribution, and certain remote services (VPN) are exposed and affected. You need to upgrade the OS to avoid being vulnerable

With Cisco many of the product offerings use the affected OpenSSL 1.0.1. Cisco's web system itself is potentially unaffected, but not mentioned in the article.

Comodo avoid mentioning whether or not their own systems, through which certificates are ordered, were vulnerable, thus the lack of a ‘safe’ status. Also beware the “no-charge reissue policy” claim, as they do not claim no-charge for revoking the old certificate, which remains necessary and one reseller has reported problems trying to persuade Comodo to waive the fees for that.

Quick update on #heartbleed: We’ve patched all of our user-facing services & will continue to work to make sure your stuff is always safe.

“Evernote does not use, and has not used, OpenSSL”

F5 sell loadbalancers, which go in front of servers and act as the server-side end-point for TLS (HTTPS); F5 have strong market share; some models, in some versions, are vulnerable.

no mention of revocation of old certs, but otherwise a near ideal response

Certificate Vendor; portal vulnerability, if you purchased your certificate from GoDaddy, then you should re-key, even if your own systems were unaffected.

most consumer services you're likely to use were fixed by that safe-date; see the blogpost for more details. You probably need to also cycle "Application-specific passwords".

Note that this status only describes safety of services provided by Heroku for customer, not Heroku.com's own SSL certs for changing your passwords. Timestamp for that still unknown.

Passwords should be reset based on the email that was sent.

Correct response: clearly communicated that OpenSSL was fixed, that new keys were generated and old certs were revoked. This is how everyone should do it.

Passwords should be reset based on the email that was sent. "Airspace" is potentially effected.

blog post tracks what they saw from one of their providers, but they haven't communicated to their own customers the status of changing keys

Passwords and API keys should be reset based on the email that was sent.

Help center suggests users reset their passwords. However the post makes no mention of certs being revoked, or even rotated.

RapidSSL avoid mentioning whether or not their own systems, through which certificates are ordered, were vulnerable, thus the lack of a ‘safe’ status. Much like Comodo, RapidSSL carefully claim “Replacements are free for the lifetime of the certificate” but do not make this free claim for the cost of revoking the old certificate.

Twitter assert that they were never affected by this

Unlike various certificate authorities, VMware is being honest. However almost all of the recent product offerings use the affected OpenSSL 1.0.1 that are in the current offering. VMware's web system itself is potentially unaffected, but not mentioned in the article.