Docker Community Forums

Share and learn in the Docker community.

Docker UCP Content Trust, not working, notary

I have following problem with Docker Content Trust Registry, if i use following commands.

Push signed Image

UCP

docker pull docker/trusttest

docker tag docker/trusttest :5000/test/trusttest:latest

export DOCKER_CONTENT_TRUST=1

docker push :5000/test/trusttest:latest

Error Log

docker push :5000/test/trusttest:latest

If i want to pull the image, i get following error:

Error response from daemon: required at least one valid signer, none found

Debug Log

The Debug-log of the ucp-controller are:

{“level”:“debug”,“msg”:“notary.Middleware: Parsed image name: /trust/admintrust, and using tag: ‘latest’”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“entered ValidateRoot with dns: /trust/admintrust”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“found the following root keys: [38c2a311c39c97b854510461747f5c72e3c89e015ea4bcdeeb0bdce1bd5a55e1]”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“found 1 valid leaf certificates for /trust/admintrust: 38c2a311c39c97b854510461747f5c72e3c99e015ea2bcdeeb0bdce1bd5a55e1”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“found 1 leaf certs, of which 1 are valid leaf certs for /trust/admintrust”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“checking root against trust_pinning config%!(EXTRA string=/trust/admintrust)”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“checking trust-pinning for cert: 38c2a311c39c97b854510461747f5c72e3c99e015ea4bcdeeb0bdce1bd5a55e1”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:" role has key IDs: 38c2a311c39c97b854510461747f5c72e3c99e015ea4bcdeeb0bdce1bd5a55e1",“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“verifying signature for key ID: 38c2a311c39c97b854510461747f5c72e3c99e015ea4bcdeeb0bdce1bd5a55e1”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“root validation succeeded for /trust/admintrust”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“entered ValidateRoot with dns: /trust/admintrust”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“found the following root keys: [38c2a311c39c97b854510461747f5c72e3c99e015ea4bcdeeb0bdce1bd5a55e1]”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“found 1 valid leaf certificates for /trust/admintrust: 38c2a311c39c97b854510461747f5c72e3c99e015ea4bcdeeb0bdce1bd5a55e1”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“found 1 leaf certs, of which 1 are valid leaf certs for /trust/admintrust”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“checking root against trust_pinning config%!(EXTRA string=/trust/admintrust)”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“checking trust-pinning for cert: 38c2a311c39c97b854510461747f5c72e3c99e015ea4bcdeeb0bdce1bd5c55e1”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:" role has key IDs: 38c2a311c39c97b854510461747f5c72e3c99e015ea4bcdeeb0bdce1bd5a55a1",“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“verifying signature for key ID: 38c2a311c39c97b854510461747f5c72e3c99e015ea4bcdeeb0bdce1bd5a55a1”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“root validation succeeded for /trust/admintrust”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“updating TUF client”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“Loading timestamp…”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“200 when retrieving metadata for timestamp”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“timestamp role has key IDs: 92880a681c8c306a0aabb7cc69862f541b540a591dc9a0374de0c00276febe9e”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“verifying signature for key ID: 92880a681c8c306a0aabb7cc69862f541b540a591dc9a0374de0c00276febe9e”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“timestamp role has key IDs: 92880a681c8c306a0aabb7cc69862f541b540a591dc9a0374de0c00276febe9e”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“verifying signature for key ID: 92880a681c8c306a0aabb7cc69862f541b540a591dc9a0374de0c00276febe9e”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“successfully verified downloaded timestamp”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“Loading snapshot…”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“no snapshot in cache, must download”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“200 when retrieving metadata for snapshot.8436c3c695b0b6b876f4958420705761c490e3578e02a752f6580215c3dff24b”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“snapshot role has key IDs: 41655f5d5addd0a59f9954eca13b737185fb1497f4fa628d488776b974dc10fb”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“verifying signature for key ID: 41655f5d5addd0a59f9954eca13b737185fb1497f4fa628d488776b974dc10fb”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“successfully verified downloaded snapshot.8436c3c695b0b6b876f4958420705761c490e3578e02a752f6580215c3dff24b”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“Loading targets…”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“no targets in cache, must download”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“200 when retrieving metadata for targets.17db7f2e7c2a88d6eeadc4803f07e1d30581b1b638e7058f8e78be6fec56a250”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“targets role has key IDs: e401bd753770e99211e26b50433b1b5a369f67ed0bd6b49d60b5b6feec57ec11”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“verifying signature for key ID: e401bd753770e99211e26b50433b1b5a369f67ed0bd6b49d60b5b6feec57ec11”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“successfully verified downloaded targets.17db7f2e7c2a88d6eeadc4803f07e1d30581b1b638e7058f8e78be6fec56a250”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“notary.Middleware: found 1 entries for target”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“notary.Middleware: found 0 potential signers”,“time”:“2017-01-18T11:06:10Z”}

{“level”:“debug”,“msg”:“notary.Middleware: found 0 valid signers”,“time”:“2017-01-18T11:06:10Z”}

For the purposes of UCP Signing Policy, configured via the “Content Trust” section of the Admin Settings, it’s necessary that we can identify the image was signed by a member of the UCP organization. We do that by making use of client bundles that you can download for your user account from UCP. Client Bundles contain a “cert.pem” file which is an x509 certificate signed by the UCP Certificate Authority, and a “key.pem” file which is the private key matched with the certificate.

You need to create the “targets/releases” delegation and one other delegation, e.g. “targets/my_user” and add the “cert.pem” as the public signing key to both. When another service then inspects the trust data, they can determine that the certificate belongs to a member of the UCP organization and their signatures should be trusted. You then need to import the key.pem so it is available for signing when you push.

The documentation provides more information and specific commands to run, specifically the “Initialize a Repo” section.

I’ve taken a look at the primary documentation and consider it insufficiently clear on the steps necessary to use content trust in UCP. I apologize for this and will work with the docs team to get it into shape.