index.docker.io was serving an expired certificate | Hacker News Reader

index.docker.io was serving an expired certificate

index.docker.io

45 pointsjsprogrammer24 comments

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.

[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...

Every CA I've ever used sends reminder emails. The problem is they are probably going to some un-read administrative email address.

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.

On Windows (if you're not using Nagios), PA Server Monitor can do this for you.

http://www.poweradmin.com/help/sm_5_7/monitor_web_page.aspx

There really is no reason to be surprised by an expiring cert any more.

This in turn means that you can't pull any docker images if they're on the public index, e.g:

:~ $ sudo docker pull debian Pulling repository debian 2015/03/20 23:42:18 Get https://index.docker.io/v1/repositories/debian/images: x509: certificate has expired or is not yet valid

Thankfully it's a Friday night, so I'm taking this as a hint to start my weekend :)

Looks like it's functional again:

Sending build context to Docker daemon

Step 0 : FROM ubuntu:trusty

511136ea3c5a: Pull complete

http://status.docker.com/

While the issue is frustrating, I commend them on having an up-to-date status page.

It wasn't up to date for a while, ~45min.

Oops.

This is a wildcard cert for .docker.io.

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.

[0]: https://www.ssllabs.com/ssltest/analyze.html?d=docker.io&lat...

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.

well 15 days, isnt that bad.

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.

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.

you should put cert checker on top, seems like a great feature

horrid but working.... if you need to pull things just set your date back to yesterday

sudo date --set="Sat Mar 20 00:01:01 EDT 2015"

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.

Use a hash over your content.

I'm not sure what this has to do with, for example, being able to query the docker hub search API?

Very little.

It has everything, however, to do with all of the images served from that domain which people use to execute software on their machines.

It seems be back.

Frustratingly, the --tlsverify=false option doesn't bypass this somehow?

Only applies to the TLS connection between the client (or swarm) and the Docker daemon.

Reply on news.ycombinator.com