Commit 206ae7d5 authored by pfandzelter's avatar pfandzelter
Browse files

make it clear that CN of a certificate should be node ID

parent 600562cf
Pipeline #64220 passed with stages
in 17 minutes and 25 seconds
......@@ -81,7 +81,7 @@ $ State or Province Name (full name) []:Berlin
$ Locality Name (eg, city) []:Berlin
$ Organization Name (eg, company) []:MCC
$ Organizational Unit Name (eg, section) []:FRED
$ Common Name (eg, fully qualified host name) []:etcd
$ Common Name (eg, fully qualified host name) []:
$ Email Address []:
......@@ -93,14 +93,16 @@ However, you must keep the private key `ca.key` private at all times!
With your CA private key in hand you may now generate certificates for `etcd`, `fred`, storage server, client, and any other software components.
Use the included `` script like this: ` {NAME} {IP}`, where `{NAME}` is the name for your certificate and `{IP}` is the IP address of your service.
The name you assign to the certificate for a FReD node should be the ID of the node.
It is the common name (CN) of this certificate.
Although not strictly required, it is recommended to generate unique certificates for every software component.
In this example case, the following commands are required:
./ etcdnase
./ frednode
./ fredclient
./ fredNodeA
./ fredClient
#### Network
......@@ -148,35 +150,36 @@ Running the `fred` software is similar to running `etcd`, but the image has to b
docker build -t fred .
docker run -d \
-v $(pwd)/frednode.crt:/cert/frednode.crt \
-v $(pwd)/frednode.key:/cert/frednode.key \
-v $(pwd)/fredNodeA.crt:/cert/fredNodeA.crt \
-v $(pwd)/fredNodeA.key:/cert/fredNodeA.key \
-v $(pwd)/ca.crt:/cert/ca.crt \
--network=fredwork \
--ip= \
fred \
fred --log-level info \
--handler dev \
--nodeID fred \
--nodeID fredNodeA \
--host \
--peer-host \
--adaptor badgerdb \
--badgerdb-path ./db \
--nase-host \
--nase-cert /cert/frednode.crt \
--nase-key /cert/frednode.key \
--nase-cert /cert/fredNodeA.crt \
--nase-key /cert/fredNodeA.key \
--nase-ca /cert/ca.crt \
--trigger-cert /cert/frednode.crt \
--trigger-key /cert/frednode.key \
--trigger-cert /cert/fredNodeA.crt \
--trigger-key /cert/fredNodeA.key \
--trigger-ca /cert/ca.crt \
--peer-cert /cert/frednode.crt \
--peer-key /cert/frednode.key \
--peer-cert /cert/fredNodeA.crt \
--peer-key /cert/fredNodeA.key \
--peer-ca /cert/ca.crt \
--cert /cert/frednode.crt \
--key /cert/frednode.key \
--cert /cert/fredNodeA.crt \
--key /cert/fredNodeA.key \
--ca-file /cert/ca.crt
This starts an instance of the `fred` software with the `info` log level using the `dev` log handler.
The ID of this node is `fredNodeA`.
It also uses an embedded BadgerDB database as a storage backend.
#### Using FReD
......@@ -187,8 +190,8 @@ If you want to try it out, use the `client.proto` in `./proto` to build a client
docker build -t grpcc -f grpcc.Dockerfile .
docker run \
-v $(pwd)/fredclient.crt:/cert/fredclient.crt \
-v $(pwd)/fredclient.key:/cert/fredclient.key \
-v $(pwd)/fredClient.crt:/cert/fredClient.crt \
-v $(pwd)/fredClient.key:/cert/fredClient.key \
-v $(pwd)/ca.crt:/cert/ca.crt \
-v $(pwd)/proto/client/client.proto:/client.proto \
--network=fredwork \
......@@ -198,8 +201,8 @@ grpcc \
grpcc -p client.proto \
-a \
--root_cert /cert/ca.crt \
--private_key /cert/fredclient.key \
--cert_chain /cert/fredclient.crt
--private_key /cert/fredClient.key \
--cert_chain /cert/fredClient.crt
This uses the direct client interface of FReD instead of the recommended ALExANDRA middleware.
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment