TL;DR
- The bootstrap identity is defined by the username:password used in -b argument to fabric-ca-server start
- The bootstrap identity is special and does not need a registration step. This is because it is automatically registered when the server starts
- All other identities will first need to be registered by fabric-ca-client before they can be enrolled
- If an identity that is not registered is tried to enroll, the enrollment will fail with following message on the fabric-ca server: “Failed to get user: : scode: 404, code: 63, msg: Failed to get User: sql: no rows in result set”. This gives us a clue as to what registration really does
- fabric-ca-client assumes the identity of whatever is in $FABRIC_CA_HOME/msp
- by default FABRIC_CA_HOME is set to /etc/hyperledger/fabric-ca-server
- If TLS is enabled then:
- we need to connect using https not http
- we need to pass –tls.certfiles X to fabric-ca-client where X = the cert of the CA who issued cert to the server
When I read hyperledger docs and specifically the section on Enrolling Bootstrap Identity, I noticed it does not register a user before enrolling. This led me to think that a user can be enrolled without registering but that is not true. If one tries to enroll a user who has not been registered, the request will fail with following error message in fabric-ca server logs:
"Failed to get user: : scode: 404, code: 63, msg: Failed to get User: sql: no rows in result set"
So how come the bootstrap identity can be enrolled without registering? The answer is that when enrolling the bootstrap identity, the username and password must match the username and password given when fabric-ca-server was started. When the server is started, it automatically registers an identity with given username and password i.e., it stores a row in sql database with given username and password – that is what registration is about. When fabric-ca-client tries to enroll a user the server will check the sql database to first verify that the user exists and fail with above message otherwise. So all users except the bootstrap identity need to be registered first before enrolling.
we illustrate this below with some actual commands. Create a docker-compose.yaml file with following contents:
now run it
$ docker-compose up
It should spin up a docker container named my-container. Log into the container:
$ docker exec -it my-container /bin/bash
since we have enabled TLS we need to connect using https instead of http. Also we need to add localhost to FABRIC_CA_SERVER_CSR_HOSTS otherwise will get an error saying
x509: certificate is valid for rca-ord, not localhost
run
root@1e046d83410d:/# fabric-ca-client enroll -u https://user:userpw@localhost:7054
2018/12/28 18:07:26 [INFO] TLS Enabled
Error: Failed to get client TLS config: No trusted root certificates for TLS were provided
what happened? we enabled TLS. so when the client tried to connect to the server, the server give it a cert but the client cannot verify authenticity of the certificate. The client needs to have the CA that issued cert to server in its trusted CA list. So to fix it run:
root@1e046d83410d:/# fabric-ca-client enroll -u https://user:userpw@localhost:7054 –tls.certfiles $FABRIC_CA_SERVER_HOME/tls-cert.pem
2018/12/28 17:32:28 [INFO] TLS Enabled
2018/12/28 17:32:28 [INFO] generating key: &{A:ecdsa S:256}
2018/12/28 17:32:28 [INFO] encoded CSR
Error: Response from server: Error Code: 20 – Authentication failure
on server:
my-container | 2018/12/28 17:32:28 [INFO] 127.0.0.1:58882 POST /enroll 401 23 “Failed to get user: : scode: 404, code: 63, msg: Failed to get User: sql: no rows in result set”
this is because user is not registered.
root@1e046d83410d:/# fabric-ca-client enroll -u https://admin:adminpw@localhost:7054 –tls.certfiles $FABRIC_CA_SERVER_HOME/tls-cert.pem
2018/12/28 17:25:38 [INFO] TLS Enabled
2018/12/28 17:25:38 [INFO] generating key: &{A:ecdsa S:256}
2018/12/28 17:25:38 [INFO] encoded CSR
2018/12/28 17:25:38 [INFO] Stored client certificate at /etc/hyperledger/fabric-ca-server/msp/signcerts/cert.pem
2018/12/28 17:25:38 [INFO] Stored root CA certificate at /etc/hyperledger/fabric-ca-server/msp/cacerts/localhost-7054.pem
2018/12/28 17:25:38 [INFO] Stored Issuer public key at /etc/hyperledger/fabric-ca-server/msp/IssuerPublicKey
2018/12/28 17:25:38 [INFO] Stored Issuer revocation public key at /etc/hyperledger/fabric-ca-server/msp/IssuerRevocationPublicKey
note we gave same username and password as the one used when starting the server. This is what defines the bootstrap identity – it is the user who started the server. And the command succeeds now. we can look at the cert of bootstrap identity as follows:
root@1e046d83410d:/# openssl x509 -in /etc/hyperledger/fabric-ca-server/msp/signcerts/cert.pem -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
29:dd:ac:fb:0a:83:19:4d:26:58:c0:56:37:79:6b:a6:42:a4:d1:b9
Signature Algorithm: ecdsa-with-SHA256
Issuer: C=US, ST=North Carolina, O=Hyperledger, OU=Fabric, CN=rca-ord
Validity
Not Before: Dec 28 17:21:00 2018 GMT
Not After : Dec 28 17:26:00 2019 GMT
Subject: C=US, ST=North Carolina, O=Hyperledger, OU=client, CN=admin
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:9a:77:1f:60:f1:0b:85:31:24:31:5f:c1:b2:5b:
6f:e4:32:1f:03:41:a5:d2:ce:f3:e5:bc:ba:12:d8:
98:65:04:52:72:d4:16:ed:32:f8:d5:d5:c5:e7:c2:
0f:c6:b8:a9:2f:89:5c:81:a2:36:28:f5:5b:35:1e:
75:61:dd:ea:ae
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
A9:7F:79:5E:83:8D:6E:F8:57:6D:B2:C5:FE:84:13:1C:A3:AD:5A:22
X509v3 Authority Key Identifier:
keyid:7F:16:BC:D0:A7:7E:4C:75:7C:73:52:8D:A5:17:45:5C:9E:B9:D7:10
X509v3 Subject Alternative Name:
DNS:1e046d83410d
Signature Algorithm: ecdsa-with-SHA256
30:45:02:21:00:cc:08:ff:bd:73:a4:c6:ec:7a:51:3d:43:f8:
a8:72:74:46:4b:f4:33:e7:58:76:00:79:94:a4:f7:69:d9:16:
7d:02:20:5a:9e:af:99:3c:60:dd:e8:46:12:e9:56:3d:90:0b:
d4:d5:28:94:b9:71:da:e7:4d:4f:71:2a:6a:2e:66:e2:45
Lets try to enroll the user defined in BOOTSTRAP_USER_PASS variable when we started the server
root@1e046d83410d:/# fabric-ca-client enroll -u https://rca-ord-admin:rca-ord-adminpw@localhost:7054 –tls.certfiles $FABRIC_CA_SERVER_HOME/tls-cert.pem
2018/12/28 17:36:03 [INFO] TLS Enabled
2018/12/28 17:36:03 [INFO] generating key: &{A:ecdsa S:256}
2018/12/28 17:36:03 [INFO] encoded CSR
Error: Response from server: Error Code: 20 – Authentication failure
my-container | 2018/12/28 17:36:03 [INFO] 127.0.0.1:58884 POST /enroll 401 23 “Failed to get user: : scode: 404, code: 63, msg: Failed to get User: sql: no rows in result set”
it does not work. Lets try to enroll a new user
root@1e046d83410d:/# fabric-ca-client register –id.name admin2 –id.affiliation org1.department1 –id.attrs ‘hf.Revoker=true,admin=true:ecert’ -u https://localhost:7054 –tls.certfiles $FABRIC_CA_SERVER_HOME/tls-cert.pem
2018/12/28 17:42:34 [INFO] Configuration file location: /etc/hyperledger/fabric-ca-server/fabric-ca-client-config.yaml
2018/12/28 17:42:34 [INFO] TLS Enabled
2018/12/28 17:42:34 [INFO] TLS Enabled
Password: mMNrwlSgLXqE
Things to note:
- Note that we enrolled bootstrap user earlier and above command ran under its identity. the fabric-ca-client will take identity from $FABRIC_CA_HOME/msp
- Since we did not specify any password the server generated one for us
Example showing password set at time of registration:
root@1e046d83410d:/# fabric-ca-client register –id.name test-user1 –id.secret test-user1pw –id.affiliation org1.department1 -u https://localhost:7054 –tls.certfiles $FABRIC_CA_SERVER_HOME/tls-cert.pem
2018/12/28 17:46:03 [INFO] Configuration file location: /etc/hyperledger/fabric-ca-server/fabric-ca-client-config.yaml
2018/12/28 17:46:03 [INFO] TLS Enabled
2018/12/28 17:46:03 [INFO] TLS Enabled
Password: test-user1pw
Also note what happens below:
root@1e046d83410d:/# mv /etc/hyperledger/fabric-ca-server/msp /etc/hyperledger/fabric-ca-server/msp1
root@1e046d83410d:/# fabric-ca-client register –id.name test-user2 –id.secret test-user2pw –id.affiliation org1.department1 -u https://localhost:7054 –tls.certfiles $FABRIC_CA_SERVER_HOME/tls-cert.pem
2018/12/28 19:38:00 [INFO] Configuration file location: /etc/hyperledger/fabric-ca-server/fabric-ca-client-config.yaml
2018/12/28 19:38:00 [INFO] TLS Enabled
2018/12/28 19:38:00 [ERROR] Enrollment check failed: Idemix enrollment information does not exist
Error: Enrollment information does not exist. Please execute enroll command first. Example: fabric-ca-client enroll -u http://user:userpw@serverAddr:serverPort
So it looks like fabric-ca-client is taking its identity from /etc/hyperledger/fabric-ca-server/msp which is same as $FABRIC_CA_HOME/msp
PS: I am not able to get wordpress to post code. I have tried wrapping code blocks in tags as explained here but every time i have more than one line in my code, wordpress would insert p and span tags and mess it up. I haven’t found a solution to this. When I try to google this problem i come across links saying to edit functions.php file but this file cannot be accessed from wordpress.com. I think the file can only be access if someone is running a self-hosted blog using the open source wordpress.org code. wordpress.com does not allow ftp. i cannot find functions.php under Admin -> Appearance -> … I hate wordpress.
