Windows Azure Storage certificate expired?
social.msdn.microsoft.com
social.msdn.microsoft.com
Amazon likes to downplay their AWS issues as well (their console is always green), but at least they provide a very detailed postmortem, and issue credits proactively.
Have not seen that from MS yet, and it's been two days.
I took a screenshot of the status console once it got updated with the outage info (several hours into the outage):
https://mobile.twitter.com/iTrendTV/status/30395990016434176...
Pretty unhappy about the whole experience. Luckily, we have our own colo in addition to Azure.
If you want to see people's reactions as this event unraveled:
http://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted...
Right now everything is down.
http://www.wired.com/wiredenterprise/2012/02/azure_outage/
I'm pretty tolerant of mistakes (I make them all the time), but I have little patience for repeating mistakes.
The only similarity is that both involved certificates. (The invalid date was used internally as an expiration date for a certificate.)
I see you've been busy since you left MS. Somehow I missed all the news about Site44!
On the bright side, after this you know they're not going to make the same mistake twice.
Why do you think Azure is not?
Unless you run your own DC, you are still outsourcing part of your infrastructure to a colo facility, which will not be immune to power and connectivity issues, and of course, issues with your setup.
Saying "<cloud provider> is down" certainly isn't very comforting, but if the aggregate downtime is less than if you were running your own setup, I'm not sure that being powerless in the event of downtime is reason enough to not use them.
Runs on a daily cron job and emails if any of the certs it's monitoring are within 30 days of expiration.
currentDateEpoch=$(date +%s)
expirationDate=$(openssl x509 -in $my_cert -enddate -noout | sed 's/notAfter=//' | date -f -)
expirationDateEpoch=$(date -d "$expirationDate" +%s)
diff=$((expirationDateEpoch - currentDateEpoch))
oneMonthInSeconds=$((30 * 24 * 3600))
oneWeekInSeconds=$((7 * 24 * 3600))
if [ "$diff" -lt $oneWeekInSeconds ]; then
printf "Certificate $my_cert needs to be renewed! Expires on $(date -d "$expirationDate" +"%B %_d, %Y")\n" >&2
exit 3
fi
if [ "$diff" -lt $oneMonthInSeconds ]; then
printf "Certificate $my_cert expires in less than a month! Expires on $(date -d "$expirationDate" +"%B %_d, %Y")\n" >&2
else
printf "Note: certificate $my_cert expires on $(date -d "$expirationDate" +"%B %_d, %Y")\n" >&2
fiCouldn't find it but I know they've had other embarrassing domain or certs expire over the years. You would think they'd fix it before they lose microsoft.com!
Edit: Maybe not such a great idea. It looks like this relies on Storage under the hood as well. Now my instances are recycling.
Later: It appears doing so actually corrupted the instance and required a redeploy, which is of course not currently possible. Awesome.
http://checkmyssl.com/
https://sslcheck.globalsign.com/en_US
Email notifications: https://www.sslshopper.com/ssl-checker
http://www.serverexec.com/ (does domain expiration too)
Script to run yourself, does email notification: http://www.prefetch.net/articles/checkcertificate.html
Any others to recommend?We do a number of things to keep our platform and your apps more available. For instance we set up reminders before our certificates expire...
I think it's worth noticing that a bunch of services (including a worker) is included on the free plan. The $10/month to run a full app with custom hostnames is actually pretty cheap when you take that into consideration.
If your app/blog is focused on the .NET/Windows developer ecosystem you can apply for inclusion in the community application program (https://appharbor.com/page/community-application-program). If included we'll pay for your app.
I don't think it was related to the page weight (unless you're on a very slow connection), nor the platform for that matter. I hope we were able to figure out a solution or give you advice on how to resolve it :-)
Furthermore, private keys can be cracked, given enough time. Expiry dates reduce this risk with (a) less time to do it; (b) key is invalidated even if you don't know that it's been compromised, so every compromise ends sooner or later, and (c) renewed certificates can be made with longer keys as hardware gets more powerful.
Since then, in addition to service monitoring, I've taken to calendaring certificate expiration dates ~14 days before they expire. Low tech but I've never forgotten since.
Example: http://exchange.nagios.org/directory/Plugins/Network-Protoco...
http://www.theregister.co.uk/2003/11/06/microsoft_forgets_to...
http://www.wired.com/wiredenterprise/2012/03/azure-leap-year...
You don't have a backup plan?
Do you just sit on your hands when that happens? Do you have a failure plan?
That being said, there unfortunately is always a level 'sitting on hands' in events like this. If you're in dev you rely on your operations people (and vicea versa). You put your best people on it and continue to go on the best you can.
All that being said, a fired rill just for the sake of doing something may cause more harm than good. If a rollover plan takes 2 hours (switch DNS, migrate data, test, stabilize, etc.) a) often times that'll take longer than the original issue requires to be resolved and b) you'll run into new issues in your new location (maybe environmental, maybe not)
Anyone else is welcome to pitch in here, I'm new to native cloud applications and find myself just waiting in this case.
I like Azure, but I don't think I am ready to use it in production for anything critical without another standby infrastructure in place.
Seems like a really good general rule for any service :)