1
0
Fork 0
mirror of https://github.com/moby/moby.git synced 2022-11-09 12:21:53 -05:00
Commit graph

5 commits

Author SHA1 Message Date
Wei-Ting Kuo
2f69da2a5e Update certificates.md
`openssl req -new -x509 -text -key client.key -out client.cert` creates a self-sign certificate but not a certificate request.

Signed-off-by: Wei-Ting Kuo <waitingkuo0527@gmail.com>
2015-02-09 04:36:00 +08:00
Dan Walsh
69fe3e1a34 On Red Hat Registry Servers we return 404 on certification errors.
We do this to prevent leakage of information, we don't want people
to be able to probe for existing content.

According to RFC 2616, "This status code (404) is commonly used when the server does not
wish to reveal exactly why the request has been refused, or when no other response i
is applicable."

https://www.ietf.org/rfc/rfc2616.txt

10.4.4 403 Forbidden

   The server understood the request, but is refusing to fulfill it.
   Authorization will not help and the request SHOULD NOT be repeated.
   If the request method was not HEAD and the server wishes to make
   public why the request has not been fulfilled, it SHOULD describe the
   reason for the refusal in the entity.  If the server does not wish to
   make this information available to the client, the status code 404
   (Not Found) can be used instead.

10.4.5 404 Not Found

   The server has not found anything matching the Request-URI. No
   indication is given of whether the condition is temporary or
   permanent. The 410 (Gone) status code SHOULD be used if the server
   knows, through some internally configurable mechanism, that an old
   resource is permanently unavailable and has no forwarding address.
   This status code is commonly used when the server does not wish to
   reveal exactly why the request has been refused, or when no other
   response is applicable.

When docker is running through its certificates, it should continue
trying with a new certificate even if it gets back a 404 error code.

Docker-DCO-1.1-Signed-off-by: Dan Walsh <dwalsh@redhat.com> (github: rhatdan)
2014-10-20 13:20:48 -04:00
O.S. Tezer
7df5493071 Docs: articles/certificates.md rewrite.
This commit contains a re-structured re-write of the original
certificated.md file, containing the amendments proposed with
PR #7120 (commit ID bd28595e31) by @timthelion.

Related to: https://github.com/dotcloud/docker/pull/7120

2014-07-30: Update/rebase/squash based on the comments from @jamtur01 and @fredlf.
2014-08-12: Update/rebase/squash based on the comments from @fredlf (of 2014-08-12).

Docker-DCO-1.1-Signed-off-by: O.S. Tezer <ostezer@gmail.com> (github: ostezer)
2014-08-12 14:49:08 +03:00
Timothy
fae72c83be Apply @jamtur01's copy edit's to certificates.md
Docker-DCO-1.1-Signed-off-by: Timothy <timothyhobbs@seznam.cz> (github: timthelion)
2014-07-30 16:23:56 +03:00
Alexander Larsson
05243104fc Add support for client certificates for registries
This lets you specify custom client TLS certificates and CA root for a
specific registry hostname. Docker will then verify the registry
against the CA and present the client cert when talking to that
registry.  This allows the registry to verify that the client has a
proper key, indicating that the client is allowed to access the
images.

A custom cert is configured by creating a directory in
/etc/docker/certs.d with the same name as the registry hostname. Inside
this directory all *.crt files are added as CA Roots (if none exists,
the system default is used) and pair of files <filename>.key and
<filename>.cert indicate a custom certificate to present to the registry.

If there are multiple certificates each one will be tried in
alphabetical order, proceeding to the next if we get a 403 of 5xx
response.

So, an example setup would be:
/etc/docker/certs.d/
└── localhost
    ├── client.cert
    ├── client.key
    └── localhost.crt

A simple way to test this setup is to use an apache server to host a
registry. Just copy a registry tree into the apache root, here is an
example one containing the busybox image:
  http://people.gnome.org/~alexl/v1.tar.gz

Then add this conf file as /etc/httpd/conf.d/registry.conf:

 # This must be in the root context, otherwise it causes a re-negotiation
 # which is not supported by the tls implementation in go
 SSLVerifyClient optional_no_ca

 <Location /v1>
 Action cert-protected /cgi-bin/cert.cgi
 SetHandler cert-protected

 Header set x-docker-registry-version "0.6.2"
 SetEnvIf Host (.*) custom_host=$1
 Header set X-Docker-Endpoints "%{custom_host}e"
 </Location>

And this as /var/www/cgi-bin/cert.cgi

 #!/bin/bash
 if [ "$HTTPS" != "on" ]; then
     echo "Status: 403 Not using SSL"
     echo "x-docker-registry-version: 0.6.2"
     echo
     exit 0
 fi
 if [ "$SSL_CLIENT_VERIFY" == "NONE" ]; then
     echo "Status: 403 Client certificate invalid"
     echo "x-docker-registry-version: 0.6.2"
     echo
     exit 0
 fi
 echo "Content-length: $(stat --printf='%s' $PATH_TRANSLATED)"
 echo "x-docker-registry-version: 0.6.2"
 echo "X-Docker-Endpoints: $SERVER_NAME"
 echo "X-Docker-Size: 0"
 echo

 cat $PATH_TRANSLATED

This will return 403 for all accessed to /v1 unless *any* client cert
is presented. Obviously a real implementation would verify more details
about the certificate.

Example client certs can be generated with:

openssl genrsa -out client.key 1024
openssl req -new -x509 -text -key client.key -out client.cert

Docker-DCO-1.1-Signed-off-by: Alexander Larsson <alexl@redhat.com> (github: alexlarsson)
2014-06-13 11:13:18 +02:00