Docker Community Forums

Share and learn in the Docker community.

Notary has to use a docker root CA cert?


(Frank) #1

I’m just trying to understand DTR and notary and am going through the install process. Have docker engine install, DTR, docker compose and now installed notary and am trying to configure it. I installed notary on he same VM as DTR for now.

I was following the directions from here: https://github.com/docker/notary
and when I did this step $mkdir -p ~/.notary && cp cmd/notary/config.json cmd/notary/root-ca.crt ~/.notary
I went what is this? so it copied the root ca cert to my home directory in a .notary directory. I looked at the cert and it had me concerned, at least WRT operating in my env. First I will be in a non internet connected env (thus no ability to receive CRLs). Second we generally do not use and or trust certificates issued by anyone other than ourselves for use to authenticate to a sever. So I have 2 questions:

  1. Does Notary allow for the use of customers generated certs/CA?
  2. Ok this is the root cert where is the server cert located? Questioning since notary is not ready fro production per documentation it maybe part of the SW distro/hard coded for now?

$ openssl x509 -noout -text -in root-ca.crt
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 14013006158795772747 (0xc27832db7a62134b)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=CA, L=San Francisco, O=Docker, CN=Notary Testing CA
Validity
Not Before: Jul 16 04:25:00 2015 GMT
Not After : Jul 13 04:25:00 2025 GMT
Subject: C=US, ST=CA, L=San Francisco, O=Docker, CN=Notary Testing CA
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Modulus:
00:cc:d4:ce:ad:8e:d3:bb:66:dc:0f:f8:7a:60:8d:
ff:6f:78:8d:40:67:35:e1:a5:33:84:e0:b0:1f:16:
f6:29:e0:c3:d0:94:ee:80:67:09:14:ca:f7:87:06:
0c:74:db:e6:87:dc:8f:d2:ad:e3:f7:52:2f:9d:ae:
26:99:19:b2:19:80:81:ae:1f:0c:38:6d:9e:d9:d4:
1d:a2:98:ce:3a:19:48:a6:6d:ab:ba:95:84:2d:43:
6a:1e:ec:df:37:ed:66:7e:0d:1e:24:5e:f3:69:68:
5c:7f:d6:d3:ff:f4:31:67:50:09:a2:dc:f0:4d:2b:
77:f6:a6:ad:de:84:3b:ee:52:53:01:78:75:74:a4:
9d:6a:28:de:8c:6d:38:49:db:d6:e4:1c:59:62:22:
c0:b4:66:77:5a:70:dc:f5:bf:6e:df:d2:1e:cb:03:
e5:d2:7e:ef:cf:e7:47:5a:82:1e:12:72:2d:5a:72:
94:c8:b2:5a:28:e4:30:a5:bb:99:b4:05:79:fb:82:
3a:c4:34:42:f1:86:dc:1a:d3:2e:ef:9f:56:cf:46:
60:dc:c7:0b:e2:f5:6d:24:1b:7e:db:38:9c:e4:a8:
75:c0:7f:92:58:5d:99:b8:15:5b:c9:ab:81:e1:f0:
c3:f8:e0:6f:65:89:5b:d6:37:44:53:69:fd:51:2e:
85:5a:c7:8b:3f:cd:5b:6a:84:de:73:cb:12:7b:b4:
bd:de:74:8d:82:17:6e:f0:66:7d:b8:42:a0:99:ed:
60:08:82:63:49:7c:bf:e3:ce:80:fd:c0:0a:db:12:
e3:5a:dc:9f:c5:72:0f:71:e8:e2:ee:35:f3:a9:22:
ef:5f:90:45:04:ec:52:4d:8c:5d:15:7a:00:a4:3d:
bb:80:a5:e1:dd:2d:57:5a:07:8d:5c:a2:28:3b:fc:
3c:d6:a4:36:b2:38:f0:a9:a7:17:d4:7d:c0:c8:33:
0c:72:28:05:54:19:ad:a5:53:c8:fc:16:f4:7b:d2:
f0:ad:cb:b2:6e:90:00:4e:e9:12:b8:9d:78:ec:81:
56:23:a2:8a:ab:d6:ee:b5:1a:2c:44:53:92:11:a2:
ad:7d:91:0a:1c:21:60:bb:58:22:3d:0b:8a:d8:33:
75:a4:f8:24:3d:49:c6:89:ea:37:7d:20:da:39:35:
fa:62:4a:30:47:96:04:c4:e3:16:ab:73:b9:03:d8:
1f:71:e4:1c:ac:68:35:fb:c4:b8:be:5f:b1:94:a6:
85:5f:e6:47:ec:96:95:27:b5:7f:ca:f5:aa:90:00:
0a:3f:ca:de:6a:26:7b:fc:fc:52:13:71:cc:45:bc:
4c:26:24:c1:a9:8b:90:03:c5:e3:ce:56:eb:82:88:
60:8d:6d
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:1
X509v3 Key Usage: critical
Non Repudiation, Certificate Sign, CRL Sign
X509v3 Subject Key Identifier:
75:0C:D5:4D:C4:E1:6C:8B:D6:7B:C5:77:E7:4F:63:C7:F8:3B:68:59
Signature Algorithm: sha256WithRSAEncryption
51:b6:eb:23:73:90:e5:73:bc:1c:7a:68:4f:05:6a:17:34:b3:
28:eb:92:4a:b7:0c:1a:bb:fa:ee:b9:fe:d8:7b:d5:25:87:f1:
b6:eb:19:05:2e:be:47:0e:d0:54:6d:dd:68:f4:be:a5:23:57:
34:cd:6a:ca:29:f7:06:3a:4d:47:69:48:ef:bd:72:c8:af:f2:
8e:33:47:f6:96:4f:47:ef:13:84:9f:3f:ef:ba:e8:2c:9b:9d:
4c:20:8f:b7:8f:4f:a1:88:12:41:0b:29:20:1e:f9:3e:5a:a7:
4d:65:70:71:c5:bd:a6:6d:b3:49:da:83:c4:57:99:a5:3a:70:
12:f8:32:5f:c3:0d:09:f6:1e:ca:7c:69:e7:e4:bc:d7:9f:77:
cf:c8:9a:bf:5e:ae:b7:62:37:f0:dc:85:24:ab:b1:8a:7f:73:
36:4c:64:a5:ff:da:f4:fa:ff:1a:4e:7a:83:0d:4e:7c:75:e9:
fa:c5:bf:e8:a2:33:c7:c7:e3:42:e2:fa:3f:c1:c4:a7:05:46:
cd:75:c0:f1:f3:17:f7:57:08:14:8e:3e:0d:37:3c:98:f8:ed:
62:f4:fa:fc:fc:c3:58:4f:ea:e8:56:59:9d:b1:c9:e7:43:60:
83:90:fc:b8:53:79:94:b8:19:14:db:5f:21:37:a8:36:34:e4:
da:4a:2a:f2:fb:d3:5b:c1:43:a4:c9:1b:e7:4c:ea:19:d0:68:
21:d0:ed:44:57:77:a2:8b:7e:30:48:3e:ea:66:da:f8:ab:6d:
c2:0d:39:68:9f:5a:48:82:31:8e:f5:38:34:7e:aa:39:70:52:
83:36:88:d6:13:2b:ec:34:c1:9d:a5:f1:30:40:62:68:d6:8f:
83:69:ea:8b:ab:a1:69:43:9c:57:0d:c5:d3:5c:81:7c:67:d7:
68:6b:0d:2c:aa:45:88:a1:58:41:f3:91:d4:cd:a1:a3:fe:c0:
2f:5f:46:61:00:f7:20:55:83:26:a9:34:fd:e4:0b:7c:54:7b:
e2:22:95:33:3e:a7:77:0b:7d:17:b0:3c:d3:1c:46:5c:6a:70:
d8:d2:50:4d:62:d0:ba:2e:16:ce:dd:f7:ab:9e:35:8a:1c:cb:
ec:40:ed:c9:b0:52:71:47:48:38:81:0e:db:49:87:af:67:33:
16:84:cb:f4:82:b1:ad:4d:02:93:90:4c:c8:c0:41:f8:33:a9:
a4:ff:93:78:a8:ee:b4:02:35:c9:15:6c:36:86:9b:3a:e2:b8:
a2:8f:c5:9a:ac:ac:81:0a:07:10:4f:a0:55:44:e1:ae:ba:44:
c1:5d:44:04:82:e4:5f:a3:b8:1a:23:2a:bb:5f:b1:f7:6f:f2:
0a:69:4a:12:0d:10:e8:c3


(Jeff Anderson) #2

Hello,

The instructions you mentioned are given under this section: https://github.com/docker/notary#getting-started-with-the-notary-cli

Specifically, they are given with the qualifier “To use the CLI against a local Notary server”, and appear alongside adding 127.0.0.1 notary-server to your /etc/hosts.

The whole idea of this section is to get folks up and running with a local notary server quickly for development. To facilitate this, it includes this certificate authority, and certificates in the fixtures directory that were generated with it. This is relatively safe since the certificates in question use non-fqdn CNs (like notary-server that require most users to set up an /etc/hosts entry to use it at all.

You certainly would not use that same certificate authority for a production deploy of notary.


(Frank) #3

Jeff,
Thanks and I think in a round about way you answered my question lol. Sounds like if i want to use my own certs there is another set of directions/and or it is possible to use my own certs/root CA?

Where I’m head just FYI is I want to use a token/Yubikey so I ultimately want notary setup and sign containers. Showing a demo where ones signed by my cert/CA run and where ones signed by anyone else are not run by the client/user.

Also another question WRT Notary. Looking at the documentation I was trying to understand the singing process. It looks like and please correct me if I’m wrong but it’s the notary server that actually signs the container and not the user/developer? i.e. ref page https://docs.docker.com/notary/service_architecture/

Now the developer/user is authenticated through he authorization service but does one use or could use a Yubikey for that authentication?

Also this section of that page has me concerned as private keys should not really leave a token such as Yubikey, kind of it’s purpose to protect the private keys.
"Notary signer retrieves the necessary encrypted private keys from its database if available, decrypts the keys, and uses them to sign the metadata. If successful, it sends the signatures back to Notary server. "


(Jeff Anderson) #4

So, there are several keys with different roles in a TUF repository.

The root key signs other keys. It is meant to be kept secure. That’s the private key that gets put on the yubikey right now†. It never gets transmitted up to notary.

The root key signs the keys that are generated for other purposes: targets, snapshots, and timestamps roles.

The targets and snapshots roles will get stored on your workstation as a developer. These private keys never leave your workstation either. Should they be compromised, you can recover by doing a key rotate using your still safe and secure root key on your yubikey. These keys essentially sign your content and metadata about your content.

The notary server has a private key that gets used for the timestamps role. The timestamps role just provides fresh signatures of all the other metadata.

As far as I know, the current token authorization service that v2 registry and notary does not have any integration with any yubikey features.

† There is work in progress to make other key roles be storable in the yubikey as well: https://github.com/docker/notary/pull/653


(Frank) #5

Jeff,
Is there any better documentation (that provides the details) on what you just described (that 7 step figure but with more details)? The explanation from here: https://docs.docker.com/notary/service_architecture/ lacks the details you described from what I see. I need to understand the entire process in detail. What keys (and how they are generated) are used when and where they are held and protected. Really need to understand this " key rotate " on compromise also.

Frank


(Jeff Anderson) #6

So notary is an opinionated implementation of TUF. Much of that terminology I used is from the TUF spec. See https://theupdateframework.github.io/, and https://github.com/theupdateframework/tuf/blob/develop/docs/tuf-spec.txt

For notary’s key rotate support, check out The “Rotate Keys” section in the Advanced Usage dog: https://github.com/docker/notary/blob/77bf588830a15870f93b65f4c6d73a5da72473b1/docs/advanced_usage.md#rotate-keys