Once the request has been approved and the certificates downloaded from the server, the node will create the keystore and trust store using the certificates and the generated private key.
The legal name is the unique identifier in the Corda network, so constraints have been set out to prevent encoding attacks and visual spoofing.
The legal name validator (see ``LegalNameValidator.kt``) is used to enforce rules on Corda's legal names, it is intended to be used by the network operator and Corda node during the node registration process.
It has two functions, a function to normalize legal names, and a function to validate legal names.
The normalize function performs the following transformations:
* Remove leading and trailing whitespaces.
* Replace multiple whitespaces with a single space.
* Normalize the string according to `NFKC normalization form <https://en.wikipedia.org/wiki/Unicode_equivalence#Normalization>`_.
The validation function will validate the input string using the following rules:
* No blacklisted words like "node", "server".
* Restrict names to Latin scripts for now to avoid right-to-left issues, debugging issues when we can't pronounce names over the phone, and character confusability attacks.
* Should start with a capital letter.
* No commas or equals signs.
* No dollars or quote marks, although we may relax the quote mark constraint in future to handle Irish company names.
A ``certificates`` folder containing the keystore and trust store will be created in the base directory when the process is completed.
..warning:: The keystore is protected by the keystore password from the node configuration file. The password should kept safe to protect the private key and certificate.
..note:: This section is intended for developers who want to implement their own doorman service.
The certificate signing protocol:
* Generate a keypair, save it to disk.
* Generate a CSR using Bouncy Castle or the java crypto APIs containing myLegalName from the config file. We should also have an admin email address in the config file and CSR so we know who to email if anything goes wrong. Sign it with the private key.
* HTTPS POST the CSR to the doorman. It creates the server-side records of this request, allocates an ID for it, and then sends back an HTTP redirect to another URL that contains that request ID (which should be sufficiently large that it's not predictable or brute forceable).
* Store that URL to disk.
* Server goes into a slow polling loop, in which every 10 minutes or so it fetches the URL it was given in the redirect. Mostly it will get 204 No Content. Eventually it will get 200 OK and download the signed certificate in binary form, which it can then stash in its local keystore file.
The initial registration process uses the following web api to communicate with the doorman service:
| POST | /api/certificate | Create new certificate request record and stored for further approval process, server will response with a request ID if the request has been accepted.|
| GET | /api/certificate/{requestId} | Retrieve certificates for requestId, the server will return HTTP 204 if request is not yet approved or HTTP 401 if it has been rejected. |
See ``NetworkRegistrationHelper`` and ``X509Utilities`` for examples of certificate signing request creation and certificate signing using Bouncy Castle.
