* Renaming and reordering to help users navigate the Networks section. * Split of pages between bootstrapped, existing and dynamic compatibility zones. Reintegrates Mike H content about creating a dynamic zone. * Address review feedback except BNO point. * Documents BNO app. * Better docs of networkServices config option. Better comments of NetworkParameters fields. * Documents additional network map protocol endpoint. * Address review feedback. * Addresses Kostas review feedback. * Update protocol due to bug. * Addresses Kostas's review feedback. * Addresses Kostas's review feedback.
3.4 KiB
Joining an existing compatibility zone
To connect to a compatibility zone you need to register with its certificate signing authority (or doorman) by submitting a certificate signing request (CSR) to obtain a valid identity for the zone. This process is only necessary when the node connects to the network for the first time, or when the certificate expires. You could do this out of band, for instance via email or a web form, but there's also a simple request/response utility built into the node.
Before using this utility, you must first have received the trust store file containing the root certificate from the zone operator. For high security zones, this might be delivered physically. Then run the following command:
java -jar corda.jar --initial-registration --network-root-truststore-password <trust store password>
By default, the utility expects the trust store file to be in the location certificates/network-root-truststore.jks
. This can be overridden using the additional --network-root-truststore
flag.
The utility performs the following steps:
- It creates a certificate signing request based on the following information from the node's configuration file (see
corda-configuration-file
):- myLegalName Your company's legal name as an X.500 string. X.500 allows differentiation between entities with the same name, as the legal name needs to be unique on the network. If another node has already been permissioned with this name then the permissioning server will automatically reject the request. The request will also be rejected if it violates legal name rules, see
node_naming
for more information. You can use the X.500 schema to disambiguate entities that have the same or similar brand names - emailAddress e.g. "admin@company.com"
- devMode must be set to false
- compatibilityZoneURL or networkServices The address(es) used to register with the compatibility zone and retrieve the network map. These should be provided to you by the operator of the zone. This must be either:
- compatibilityZoneURL The root address of the network management service. Use this if both the doorman and the network map service are operating on the same URL endpoint
- networkServices The root addresses of the doorman and the network map service. Use this if the doorman and the network map service are operating on the same URL endpoint, where:
- doormanURL is the root address of the doorman. This is the address used for initial registration
- networkMapURL is the root address of the network map service
- myLegalName Your company's legal name as an X.500 string. X.500 allows differentiation between entities with the same name, as the legal name needs to be unique on the network. If another node has already been permissioned with this name then the permissioning server will automatically reject the request. The request will also be rejected if it violates legal name rules, see
- It generates a new private/public keypair to sign the certificate signing request
- It submits the request to the doorman server and polls periodically to retrieve the corresponding certificates
- It creates the node's keystore and trust store using the received certificates
- It creates and stores the node's TLS keys and legal identity key along with their corresponding certificate-chains
Note
You can exit the utility at any time if the approval process is taking longer than expected. The request process will resume on restart as long as the --initial-registration
flag is specified.