4 ms·

Loading an https://APPNAME.herokuapp.com https://APPNAME.herokuapp.com page, I'm seeing a certificate (sn:"0E:3E:94:7F:C0:64:D7:4A:52:B1:38:D7:71:90:88:1F") wit

by gojomo 13y ago

Loading an https://APPNAME.herokuapp.com https://APPNAME.herokuapp.com page, I'm seeing a certificate (sn:"0E:3E:94:7F:C0:64:D7:4A:52:B1:38:D7:71:90:88:1F") with an "Issued Date" of "1/20/14"... which doesn't sound like it's been regenerated in the last 24 hours. Am I interpreting the certificate info wrong? [edit per official answer below: YES] (Are fresh certificates sometimes given much older start times? [edit: YES]) This blogpost doesn't clearly address *.herokuapp.com HTTPS service, as opposed to the custom-domains "ssl:endpoint" service.

dpritchett 13y ago
I'm pretty sure if you're using herokuapp.com then you're not using your own cert and Heroku will update it for you. If you're using ssl:endpoint then you will have had to submit your own cert, and that will need replacing.
- gojomo 13y ago
  Indeed, that's my expectation with herokuapp.com. However, this blogpost says, "As of Tuesday, April 8 at 15:55 UTC, all Heroku certificates and infrastructure have been updated and are no longer vulnerable"... while the certificate still superficially looks like it's almost 3 months old. Something isn't as it seems, I hope it's just the certificate age.
praseodym 13y ago
Several certificate vendors reissue certificates with the same "not valid before"/"issued" date as the original one.
- munger 13y ago
  Yep, I was just hassling our billing SaaS provider about this, but then I looked into their SSL vendor heartbleed post, and their customers mention this in the comments: http://blog.digicert.com/2014/04/heartbleed-openssl-fix/ http://blog.digicert.com/2014/04/heartbleed-openssl-fix/ Excerpt: "Also, Busy IT Guy is right; it's a little disheartening to be listed as Unsafe after having done all the right things, just because the issue date didn’t get updated."
dpiddy 13y ago
Hi, Heroku engineer here. We rekeyed our certificates, including the one for *.herokuapp.com, meaning we resent our original certificate requests (CSR) to our CA but signed with new private keys. This is why the dates didn't change. Our CA will eventually revoke the previous incarnations of our certificates, signed with the old private keys, making them invalid.
- gojomo 13y ago
  Thanks! It might be reassuring to others who see the same mixed-signals if the official blogpost made specific mention of APPNAME.herokuapp.com HTTPS, and that the certificates may look older but really are fresh.
  - craigkerstiens 13y ago
    Thanks for the feedback, we have updated the blog post to include some information regarding this.
- smw 13y ago
  Am I missing something, or doesn't the browser have to explicitly check for key revocation? I know the checkbox was off in my version of Chrome. Maybe I set it, but I'm not sure. This [1] Seems to suggest that Firefox, for instance, only checks for EV certs? [1] http://news.netcraft.com/archives/2013/05/13/how-certificate-revocation-doesnt-work-in-practice.html http://news.netcraft.com/archives/2013/05/13/how-certificate...
- orblivion 13y ago
  So is there a simple way to check if an arbitrary site updated their certs?
- grittygrease 13y ago
  This is completely the wrong approach. Your private key might have been compromised and you're generating another certificate for the same compromised private key? What is that supposed to do?

by gojomo 13y ago

dpritchett 13y ago

I'm pretty sure if you're using herokuapp.com then you're not using your own cert and Heroku will update it for you. If you're using ssl:endpoint then you will have had to submit your own cert, and that will need replacing.

gojomo 13y ago
Indeed, that's my expectation with herokuapp.com. However, this blogpost says, "As of Tuesday, April 8 at 15:55 UTC, all Heroku certificates and infrastructure have been updated and are no longer vulnerable"... while the certificate still superficially looks like it's almost 3 months old. Something isn't as it seems, I hope it's just the certificate age.

praseodym 13y ago

Several certificate vendors reissue certificates with the same "not valid before"/"issued" date as the original one.

munger 13y ago
Yep, I was just hassling our billing SaaS provider about this, but then I looked into their SSL vendor heartbleed post, and their customers mention this in the comments: http://blog.digicert.com/2014/04/heartbleed-openssl-fix/ http://blog.digicert.com/2014/04/heartbleed-openssl-fix/ Excerpt: "Also, Busy IT Guy is right; it's a little disheartening to be listed as Unsafe after having done all the right things, just because the issue date didn’t get updated."

dpiddy 13y ago

Hi, Heroku engineer here. We rekeyed our certificates, including the one for *.herokuapp.com, meaning we resent our original certificate requests (CSR) to our CA but signed with new private keys. This is why the dates didn't change. Our CA will eventually revoke the previous incarnations of our certificates, signed with the old private keys, making them invalid.

gojomo 13y ago
Thanks! It might be reassuring to others who see the same mixed-signals if the official blogpost made specific mention of APPNAME.herokuapp.com HTTPS, and that the certificates may look older but really are fresh.
- craigkerstiens 13y ago
  Thanks for the feedback, we have updated the blog post to include some information regarding this.
smw 13y ago
Am I missing something, or doesn't the browser have to explicitly check for key revocation? I know the checkbox was off in my version of Chrome. Maybe I set it, but I'm not sure. This [1] Seems to suggest that Firefox, for instance, only checks for EV certs? [1] http://news.netcraft.com/archives/2013/05/13/how-certificate-revocation-doesnt-work-in-practice.html http://news.netcraft.com/archives/2013/05/13/how-certificate...
orblivion 13y ago
So is there a simple way to check if an arbitrary site updated their certs?
grittygrease 13y ago
This is completely the wrong approach. Your private key might have been compromised and you're generating another certificate for the same compromised private key? What is that supposed to do?