New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for intermediate certificates #683

Closed
rxbynerd opened this Issue Jul 8, 2015 · 7 comments

Comments

Projects
None yet
3 participants
@rxbynerd
Copy link
Contributor

rxbynerd commented Jul 8, 2015

TLS certificates from Gandi need two intermediate certificates for them to actually work, without them, you get an error like this:

v2 ping attempt failed with error: Get https://deployment.rubynerd.net/v2/: x509: certificate signed by unknown authority

from the result of docker login https://deployment.rubynerd.net.

I don't have any experience with TLS in Go, but from my reading last night, it seems that I need to include the intermediate certificates Gandi have supplied me in this array.

I don't imagine I'm the first person to see this, nor will I be the last. The deployment guide states You can buy a certificate for as cheap as 10$ a year. These cheap 10$ certificates almost always depend on some sort of intermediate certificate, so end users following this "highly recommended" solution will find themselves trapped with a 10$ certificate they cannot use.

I consider this a necessary feature to deploy Docker Distribution, and I would like to discuss how this feature should be implemented. If nobody else feels up to the task, I am more than happy to roll up my sleeves and do it myself. However, this is my first time dealing with Go and this codebase, so I want to make sure I'm doing it the right way first.

In terms of proposed solutions, we could take inspiration from nginx, which allows you to concatenate your certificate with its intermediates into one file, which nginx then loads into the SSL context for you. Alternatively, we can specify a path of certificates to load, similarly to how a $PATH variable works in a shell.

I'm eager to hear your thoughts on how this can be resolved - I would like to get this docker registry off the ground as soon as possible as it's blocking other projects!

@taxilian

This comment has been minimized.

Copy link

taxilian commented Jul 9, 2015

Here is how I started my registry instance:

docker run -d -p 5000:5000 \
       -v /data/ssd/config/certs:/certs \
       -v /data/gradecam/registry:/var/lib/registry \
   -e REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY=/var/lib/registry \
   -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/combined.crt \
   -e REGISTRY_HTTP_TLS_KEY=/certs/STAR_zzt_net.key \
   --restart=always --name=registry registry:2

Previous to this I did:

cat  STAR_zzt.net.crt cacertfiles.cabundle > combined.crt
@stevvooe

This comment has been minimized.

Copy link
Contributor

stevvooe commented Jul 9, 2015

Here was the first attempt, I believe: #453.

I think we can close this when we have documentation showing how to join intermediate certificates for server cert.

@stevvooe

This comment has been minimized.

Copy link
Contributor

stevvooe commented Jul 9, 2015

@taxilian Do you have the command to combine the certs appropriately?

@taxilian

This comment has been minimized.

Copy link

taxilian commented Jul 9, 2015

Just updated my comment to have that

@taxilian

This comment has been minimized.

Copy link

taxilian commented Jul 9, 2015

The basic syntax for the .crt file should be something like:

----BEGIN CERTIFICATE-----
(your certificate here)
-----END CERTIFICATE-----
----BEGIN CERTIFICATE-----
(Chain cert 1 here)
-----END CERTIFICATE-----
----BEGIN CERTIFICATE-----
(Chain cert 2 here)
-----END CERTIFICATE-----
----BEGIN CERTIFICATE-----
(Chain cert 3 here)
-----END CERTIFICATE-----

Incidentally this is very similar to how nginx expects certificates come

@rxbynerd

This comment has been minimized.

Copy link
Contributor

rxbynerd commented Jul 9, 2015

Yup, turns out this feature all works as expected with nginx, I must have fudged up a cat command when I was first trying to get this deployed!

To confirm, concatenating the certificates together with a command like cat server.crt GandiStandardSSLCA2.pem > server.with-intermediate.crt creates a certificate bundle which can be handled by Go's TLS LoadX509KeyPair, which distribution uses to load certificate files.

I'll make a PR for some improved documentation about intermediate certs. Thanks @taxilian!

@stevvooe

This comment has been minimized.

Copy link
Contributor

stevvooe commented Jul 9, 2015

@rxbynerd Re-opening until we merge #686.

@stevvooe stevvooe reopened this Jul 9, 2015

dave-tucker added a commit to dave-tucker/distribution that referenced this issue Jul 21, 2015

Include configuration explanation for intermediate TLS certificates
Intermediate certificates are issued by TLS providers who themselves are
an intermediate of a certificate in the trust store. Therefore, to prove
the chain of trust is valid, you need to include their certificate as
well as yours when you send your certificate to the client.

Contrary to what I said in issue docker#683, distribution can handle these
certificate bundles like nginx. As discussed in #docker-distribution,
I have updated the deployment documentation (which recommends the use of
a TLS certificate from a provider) to include instructions on how to
handle the intermediate certificate when a user is configuring
distribution.

Signed-off-by: Luke Carpenter <x@rubynerd.net>

RichardScothern added a commit that referenced this issue Nov 6, 2015

Include configuration explanation for intermediate TLS certificates
Intermediate certificates are issued by TLS providers who themselves are
an intermediate of a certificate in the trust store. Therefore, to prove
the chain of trust is valid, you need to include their certificate as
well as yours when you send your certificate to the client.

Contrary to what I said in issue #683, distribution can handle these
certificate bundles like nginx. As discussed in #docker-distribution,
I have updated the deployment documentation (which recommends the use of
a TLS certificate from a provider) to include instructions on how to
handle the intermediate certificate when a user is configuring
distribution.

Signed-off-by: Luke Carpenter <x@rubynerd.net>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment