For anyone interested. If you are running Nagios/Sensu, then I highly suggest using one of the ssl check plugins [1, 2, 3], which will give you a heads up about these types of these before they happen. Then the onus is not on you to check some calendar/spreadsheet for expiring certs. Same goes for domains [4, 5]. When you are looking after tons of services, ssl certs, and domains, it is inevitable that things will slip through the cracks unless you have some type of monitoring keeping tabs on it for you.
I can't speak to what certificate was in place before, but now there seems to be a wildcard certificate installed that isn't expired.
If the old certificate was also a wildcard certificate, it stands to reason that even if the CA sent a reminder email, this particular front end could have been overlooked.
In addition, Chromium tells me that "Your connection to docker.io is encrypted with obsolete cryptography" (although that may just be a result of the expired certificate?).
How did no one responsible for this get notified prior to the certificate expiring? Presumably, that's something they (Docker) will shortly be adding to their monitoring system.
ETA: I'm no expert but after looking at the Qualys SSL Labs report [0], it would appear that the warning is simply due to the certificate having expired.
I've seen this happen to multiple sites and was wondering if there was a reason why some CAs don't let you issue a new cert until the day of the expiry. It doesn't seem like that would open up much of an attack surface.
Which CAs do that? I get alerts from our monitoring system 30d prior to expiration and have not had any problems generating new certs then (and they expire on the same day as the previous -- i.e., I don't "lose" three weeks if I renew three weeks early).
I'm using StartSSL for a personal site and it didn't let me generate a new one until it had almost expired. I'm using the free verification though, it might be different now or for their paid versions.
I've never heard of a CA doing that. By and large, the reason why this happens is human error - no one knows the cert is about to expire because it's not being monitored and/or the email from the CA (if they even send one) goes to a mailbox that's not being read.
But there's no reason why a rote task like renewing a certificate should be left to humans. It should be automated, which is what my startup, https://sslmate.com/, is doing.
If your CA doesn't let you renew your cert well in advance of expiry (which I find hard to believe), get a new cert on a different CA. You can have multiple certs valid for the same domain name, from different providers; the active cert is the one you serve.
SSL is the wrong security mechanism to be relying on here.
If you want immutable deploys, what you actually want is a hash over the content.
When you embed a hash over the content in your deploy script, you guarantee true immutable deploys: everything will be exactly what you ask for, forever. You're not beholden to SSL for security; you're not beholden to anyone maintaining the servers to "be a good citizen". You just have guarantees.
[1] http://exchange.nagios.org/directory/Plugins/Network-Protoco...
[2] http://exchange.nagios.org/directory/Plugins/Network-Protoco...
[3] https://github.com/sensu/sensu-community-plugins/tree/master...
[4] http://exchange.nagios.org/directory/Plugins/Internet-Domain...
[5] https://github.com/sensu/sensu-community-plugins/tree/master...