am trying to deploying the nodes in different machine. its working fine. But i have many doubts. controller, Notary, customer1 and customer2 are in one MachineA and customer3 and customer4 are in MachineB. if i do any transaction between customer3 and customer4 in machineB, it will generate keys in certificates folder for all nodes.I placed my notary in machineA. Is that possible to update some changes using those keys in machineA without the knowledge of nodes in machineB?
The certificates that you are generated on all the nodes when you conduct a transaction between customer3 and customer4 are development certificates that are automatically generated to allow nodes to communicate.
In a real deployment, you'd turn off development mode on each node using a devMode=false flag in each node's node.conf file. See https://docs.corda.net/corda-configuration-file.html.
You'd then have to provision each node will proper certificates by following the instructions here: https://docs.corda.net/permissioning.html. If you do not provide the proper certificates, your nodes will fail to start with an error like the following:
java.lang.IllegalArgumentException: Identity certificate not found.
Please either copy your existing identity key and certificate from
another node, or if you don't have one yet, fill out the config file
and run corda.jar --initial-registration. Read more at:
https://docs.corda.net/permissioning.html at
net.corda.node.internal.AbstractNode.validateKeystore(AbstractNode.kt:460)
~[corda-node-2.0.0.jar:?] at
net.corda.node.internal.AbstractNode.start(AbstractNode.kt:179)
~[corda-node-2.0.0.jar:?] at
net.corda.node.internal.Node.start(Node.kt:312)
~[corda-node-2.0.0.jar:?] at
net.corda.node.internal.NodeStartup.startNode(NodeStartup.kt:95)
~[corda-node-2.0.0.jar:?] at
net.corda.node.internal.NodeStartup.run(NodeStartup.kt:74)
[corda-node-2.0.0.jar:?] at net.corda.node.Corda.main(Corda.kt:11)
[corda-node-2.0.0.jar:?]
Related
I have registered a node with an existing Corda network. When I then try to start the node, I get the following exception:
E 15:32:20+0530 [Network Map Updater Thread-1]
network.NetworkMapUpdater.exitOnParametersMismatch - Node is using
parameters with hash:
6C174011FD30DB2921E2595C927C49035C1287C313F557C69653A2019B04B803 but
network map is advertising:
12693BBBBF3BB89543FA7B08B31F0DC619DA4798DAF571659E2FBD2731415D61. Node
will shutdown now. Please update node to use correct network
parameters file. {}
How can I fix this error?
In my case, the node had an old network-parameters file lying around in its directory from another network.
I simply deleted the existing network-parameters file and restarted the node. It then downloaded the network parameters of the new network automatically and started normally.
Why does the Node need the network-root-truststore.jks file at initial registration? What's the relashionship between this file and the nodekeystore.jks?
EDIT: Actually, I was meant that I didn't see the relashionship between the CSR and the network-root-truststore.jks file. Is it not possible to generate the Certificate Signing Request without this file?
network-root-truststore.jks-> This is the network operator's root CA.
nodekeystore.jks -> This contains nodes identity key pairs and certificates.
As you can see in the diagram. The Root CA for Doorman and Network Map are same. The node assumes 3 level hierarchy as you can see in the picture above. ( This got fixed in version 3.3 so you can have a n-level certificate hierarchy)
For initial registration with the doorman, you'd need to create a CSR request and send it to the doorman, the doorman will then return you the requestId, Using the provided requestId you'll ask the doorman if the CSR has been signed by him or not once done, Doorman will hand you over the node certificate like below
Once you've the node certificate signed by the doorman, you want to validate it (for this you'd need the RootCA Certificate which is inside the network-root-truststore.jks now you don't need it to create the CSR, but the certificate received must be validated, as result, you need this. Also, this prevents man in the middle attack.)and generate the TLS key pair and certificates.
The above process is automatically done by the corda node for you at the time of initial registration when you start the node using this command -> java -jar corda.jar --initial-registration --network-root-truststore-password <trust store password>
One Important thing is you should remove or delete the network-root-truststore.jks file once you are done with the registration.
I have some questions about Corda Network Permission. In creating a root network CA's keystore and truststore section in https://docs.corda.net/releases/release-V3.1/permissioning.html#id6
Create a new keypair
This will be used as the root network CA’s keypair
Create a self-signed certificate for the keypair. The basic constraints extension must be set to true
This will be used as the root network CA’s certificate
Create a new keystore and store the root network CA’s keypair and certificate in it for later use
This keystore will be used by the root network CA to sign the doorman CA’s certificate
Create a new Java keystore named truststore.jks and store the root network CA’s certificate in it using the alias cordarootca
This keystore must then be provisioned to the individual nodes later so they can store it in their certificates folder.
I have three questions:
First question is that what is "The basic constraints extension" in your Step 2 means? Due to the code to generate the selfsignedCA is X509Utilities.createSelfSignedCACertificate(subject, caKey) and so I don't know where I can config this parameter.
Second one is that what is difference between " keystore" in Step 3 and "Java keystore" in Step 4? That means the first is "PEM" file and the second is "jks" file?
The last one is that I don't see any parameter about "alias" in Step 4.
By the way, you can give me some useful code to address those problems?
In our Network certificate hierarchy, A Corda network has three types of certificate authorities (CAs):
The root network CA
The doorman CA
Each node also serves as its own CA
The required key pairs and certificates take the form of the following Java-style keystores (this may change in future to support PKCS#12 keystores) in the node’s /certificates/ folder
You can refer to the diagram for hierarchical explanation,
Or you can find more information at: https://docs.corda.net/docs/corda-enterprise/4.4/network/permissioning.html#key-pair-and-certificate-formats
I want to create a new Node for my corda network. Can you help me with correct steps for generating a proper Certificate Key for a new node in non-dev Mode.
When adding a new node for an existing non-dev network, you need to register with the network's certificate signing authority (or doorman) to obtain a valid identity for the zone using the following command:
java -jar corda.jar --initial-registration --network-root-truststore-password <trust store password>
As part of this process, the node will automatically generate a new public/private keypair. You do not need to generate this keypair yourself.
Before you can register, you must first have received the trust store file containing the root certificate from the zone operator. By default the trust store file is expected to be in the location certificates/network-root-truststore.jks. This can be overridden with the additional --network-root-truststore flag.
Once Corda node failed, what is the appropriate process of recovery? Corda transactions are shared only with qualified nodes for specific business network, not with every nodes. Therefore, when recovering failure node, copying data from other node would not work well, recovering from backup is required. However, backup image is not completely same for other correct nodes, I would like to know how recover consistency of corda node.
Node data storage
A Corda node stores its vital information as follows:
The node's data is stored in a standard SQL database
By default, in an H2 database file called persistence.mv
The node's keys and certificates are stored in Java keystores in the certificates folder
Recovery from node crashes
If the node crashes:
The database and the contents of the certificates folder will not be affected
In-flight flows can be restarted from their most recent checkpoint
Artemis messages can be replayed
In other words, you can generate a new node, re-add the persistence.mv file, certificates folder and CorDapps, and the node will behave as if nothing happened when you start it up again.
Recovery from corruption/deletion of the node's files
Loss/corruption of data is non-fatal as long as you are able to recover:
The node's database
The contents of the node's certificates folder
It is the responsibility of the node's owner to ensure they protect and back-up these files using standard business procedures. If both of these can be recovered and re-added to a new node, the node should spin up as usual.
If the contents of the node's certificates folder cannot be recovered, you will no longer have your private key, and will not be able to spend your assets on the ledger.
If certain pieces of data cannot be recovered from the node's database, the node could attempt to re-request this data from other nodes where applicable (e.g. the transaction history). However, there is no way to force the counterparties to share this information.