3 ms·

index.docker.io was serving an expired certificate

45 points by jsprogrammer 12y ago

shad42 12y ago
http://status.docker.com/ http://status.docker.com/
- philip1209 12y ago
  While the issue is frustrating, I commend them on having an up-to-date status page.
  - jsprogrammer 12y ago
    It wasn't up to date for a while, ~45min.
Sxw1212 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      well 15 days, isnt that bad.
- justinsb 12y ago
  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.
- agwa 12y ago
  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/ https://sslmate.com/, is doing.
  - homakov 12y ago
    you should put cert checker on top, seems like a great feature
namecast 12y ago
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 :)
jlgaddis 12y ago
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&latest https://www.ssllabs.com/ssltest/analyze.html?d=docker.io&lat...
WestCoastJustin 12y ago
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-Protocols/HTTP/check_ssl_certificate/details http://exchange.nagios.org/directory/Plugins/Network-Protoco... [2] http://exchange.nagios.org/directory/Plugins/Network-Protocols/HTTP/check_ssl_cert/details http://exchange.nagios.org/directory/Plugins/Network-Protoco... [3] https://github.com/sensu/sensu-community-plugins/tree/master/plugins/ssl https://github.com/sensu/sensu-community-plugins/tree/master... [4] http://exchange.nagios.org/directory/Plugins/Internet-Domains-and-WHOIS/check_domain/details http://exchange.nagios.org/directory/Plugins/Internet-Domain... [5] https://github.com/sensu/sensu-community-plugins/tree/master/plugins/whois https://github.com/sensu/sensu-community-plugins/tree/master...
- ams6110 12y ago
  Every CA I've ever used sends reminder emails. The problem is they are probably going to some un-read administrative email address.
  - deleted 12y ago
    [deleted]
  - RKearney 12y ago
    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.
- DougN7 12y ago
  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 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.
justizin 12y ago
Frustratingly, the --tlsverify=false option doesn't bypass this somehow?
- regecks 12y ago
  Only applies to the TLS connection between the client (or swarm) and the Docker daemon.
nickdavies 12y ago
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"
neeravkumar 12y ago
It seems be back.
robdimsdale 12y ago
Looks like it's functional again: Sending build context to Docker daemon Step 0 : FROM ubuntu:trusty 511136ea3c5a: Pull complete
heavenlyhash 12y ago
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 12y ago
  I'm not sure what this has to do with, for example, being able to query the docker hub search API?
  - heavenlyhash 12y ago
    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.

45 points by jsprogrammer 12y ago

shad42 12y ago

http://status.docker.com/ http://status.docker.com/

philip1209 12y ago
While the issue is frustrating, I commend them on having an up-to-date status page.
- jsprogrammer 12y ago
  It wasn't up to date for a while, ~45min.

Sxw1212 12y ago

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 12y ago
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 12y ago
  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 12y ago
    well 15 days, isnt that bad.
justinsb 12y ago
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.
agwa 12y ago
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/ https://sslmate.com/, is doing.
- homakov 12y ago
  you should put cert checker on top, seems like a great feature

namecast 12y ago

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 :)

jlgaddis 12y ago

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

WestCoastJustin 12y ago

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-Protocols/HTTP/check_ssl_certificate/details http://exchange.nagios.org/directory/Plugins/Network-Protoco... [2] http://exchange.nagios.org/directory/Plugins/Network-Protocols/HTTP/check_ssl_cert/details http://exchange.nagios.org/directory/Plugins/Network-Protoco... [3] https://github.com/sensu/sensu-community-plugins/tree/master/plugins/ssl https://github.com/sensu/sensu-community-plugins/tree/master... [4] http://exchange.nagios.org/directory/Plugins/Internet-Domains-and-WHOIS/check_domain/details http://exchange.nagios.org/directory/Plugins/Internet-Domain... [5] https://github.com/sensu/sensu-community-plugins/tree/master/plugins/whois https://github.com/sensu/sensu-community-plugins/tree/master...

ams6110 12y ago
Every CA I've ever used sends reminder emails. The problem is they are probably going to some un-read administrative email address.
- deleted 12y ago
  [deleted]
- RKearney 12y ago
  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.
DougN7 12y ago
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 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.

justizin 12y ago

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

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

nickdavies 12y ago

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"

neeravkumar 12y ago

It seems be back.

robdimsdale 12y ago

Looks like it's functional again: Sending build context to Docker daemon Step 0 : FROM ubuntu:trusty 511136ea3c5a: Pull complete

heavenlyhash 12y ago

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 12y ago
I'm not sure what this has to do with, for example, being able to query the docker hub search API?
- heavenlyhash 12y ago
  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.