Skip to content

rebased/mergable copy of "Add https cert and key options to docker"#2996

Closed
discordianfish wants to merge 3 commits intomoby:masterfrom
discordianfish:1745_HTTPS_Remote_client_api
Closed

rebased/mergable copy of "Add https cert and key options to docker"#2996
discordianfish wants to merge 3 commits intomoby:masterfrom
discordianfish:1745_HTTPS_Remote_client_api

Conversation

@discordianfish
Copy link
Contributor

This is a mergable copy of #2186

@crosbymichael
Copy link
Contributor

something is not merge-able with this code ;)

@discordianfish
Copy link
Contributor Author

@crosbymichael: Ha, this thing moves so fast. Rebased again!

@vieux
Copy link
Contributor

vieux commented Dec 2, 2013

LGTM

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is kind of misleading. We may want to change the line above to:

sudo docker -d -sslkey=privkey.pem -sslcert=cacert.pem -H=tcp://0.0.0.0 -H unix:///var/run/docker.sock

So that the client still works while the API is being served of https at the same time.

@discordianfish
Copy link
Contributor Author

@crosbymichael Good catch, I've changed it

@crosbymichael
Copy link
Contributor

@discordianfish After more testing the client does not work with the unix socket because we are still serving https over the unix socket and the client gets malformed responses.

I think we should update the client to work with https also no matter the protocol.

@discordianfish
Copy link
Contributor Author

@crosbymichael I'm working in another branch on https client which fixes this problem as well. Maybe it's easier to just close this "https server" PR and I'll open a new PR with both client and server changes. Guess this PR here alone doesn't make much sense anyway.

@discordianfish
Copy link
Contributor Author

As discussed in IRC: Will close this in favor of a new PR including https support for client and server.

@ghost
Copy link

ghost commented Dec 5, 2013

@discordianfish and/or @crosbymichael...

so just to level-set on what i believe to be true right now --> there is no way to use the docker CLI to push images to a private registry which is using SSL correct?

what i have is a private docker registry being fronted by nginx. nginx is in turn setup to use self-signed certificates for SSL. i cannot get a docker push <private_ssl_repo_tag> to work with 0.7.0 docker. when i do the push i get an error like this from the docker CLI:

[debug] registry.go:130 Registry https://MY_IP:443/v1/ does not work (Get https://MY_IP:443/v       1/_ping: x509: cannot validate certificate for MY_IP because it doesn't contain any IP SANs), falling        back to http

my cert does in fact contain valid SAN IP and DNS -- i double checked by dumping it to text with openssl -text.... moreover i tested with curl --cacert ... and it works when i can specify the client side cert.

IMHO it seems like the docker CLI should support:

  • ability to pass in an option to not validate the server cert. most tools support this with an option like -insecure or similar.
  • ability to specify the cert to use from the docker client... for example docker -cert /path/to/certfile push yadda

i was hoping i could use unix sockets with socat to hack around this issue short term, but it appears a docker push does not use the -H option (i.e. client CLI example here: http://jpetazzo.github.io/2013/10/20/secure-connection-docker-api/)

thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants