

index.docker.io was serving an expired certificate - jsprogrammer
https://index.docker.io/v1/_ping

======
WestCoastJustin
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...](http://exchange.nagios.org/directory/Plugins/Network-
Protocols/HTTP/check_ssl_certificate/details)

[2] [http://exchange.nagios.org/directory/Plugins/Network-
Protoco...](http://exchange.nagios.org/directory/Plugins/Network-
Protocols/HTTP/check_ssl_cert/details)

[3] [https://github.com/sensu/sensu-community-
plugins/tree/master...](https://github.com/sensu/sensu-community-
plugins/tree/master/plugins/ssl)

[4] [http://exchange.nagios.org/directory/Plugins/Internet-
Domain...](http://exchange.nagios.org/directory/Plugins/Internet-Domains-and-
WHOIS/check_domain/details)

[5] [https://github.com/sensu/sensu-community-
plugins/tree/master...](https://github.com/sensu/sensu-community-
plugins/tree/master/plugins/whois)

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

~~~
RKearney
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.

------
namecast
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](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 :)

------
robdimsdale
Looks like it's functional again:

Sending build context to Docker daemon

Step 0 : FROM ubuntu:trusty

511136ea3c5a: Pull complete

------
shad42
[http://status.docker.com/](http://status.docker.com/)

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

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

------
jlgaddis
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...](https://www.ssllabs.com/ssltest/analyze.html?d=docker.io&latest)

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

~~~
jlgaddis
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).

~~~
Sxw1212
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.

~~~
zobzu
well 15 days, isnt that bad.

------
nickdavies
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"

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

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

~~~
heavenlyhash
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.

------
neeravkumar
It seems be back.

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

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

