ExternalVendorCode/corda
1
0
Fork 0
mirror of https://github.com/corda/corda.git synced 2025-02-20 09:26:41 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

More fixes

Browse Source
This commit is contained in:
Wawrzyniec Niewodniczański 2019-01-14 10:07:51 +00:00
parent b4b1d7d020
commit d55c527b3b
3 changed files with 55 additions and 59 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
docs/source/corda-network/index.md
View File

@ -62,17 +62,12 @@ CRL configuration
-----------------
The Corda Network provides an endpoint serving an empty certificate revocation list for the TLS-level certificates.
This is intended for deployments that do not provide a CRL infrastructure but still require a strict CRL mode checking.
In such a case use the following URL in `tlsCertCrlDistPoint` option configuration:
In order to use this, add the following to your configuration file:
.. sourcecode:: kotlin
.. parsed-literal::
"https://crl.cordaconnect.org/cordatls.crl"
Together with the above configuration `tlsCertCrlIssuer` option needs to be set to the following value:
.. sourcecode:: kotlin
"C=US, L=New York, O=R3 HoldCo LLC, OU=Corda, CN=Corda Root CA"
tlsCertCrlDistPoint = "https://crl.cordaconnect.org/cordatls.crl"
tlsCertCrlIssuer = "C=US, L=New York, O=R3 HoldCo LLC, OU=Corda, CN=Corda Root CA"
This set-up ensures that the TLS-level certificates are embedded with the CRL distribution point referencing the CRL issued by R3.
In cases where a proprietary CRL infrastructure is provided those values need to be changed accordingly.

97
docs/source/node-administration.rst
View File

@ -3,54 +3,6 @@ Node administration
.. _hiding-sensitive-data:
Hiding sensitive data
---------------------
A frequent requirement is that configuration files must not expose passwords to unauthorised readers. By leveraging environment variables, it is possible to hide passwords and other similar fields.
Take a simple node config that wishes to protect the node cryptographic stores:
.. parsed-literal::
myLegalName : "O=PasswordProtectedNode,OU=corda,L=London,C=GB"
keyStorePassword : ${KEY_PASS}
trustStorePassword : ${TRUST_PASS}
p2pAddress : "localhost:12345"
devMode : false
networkServices {
doormanURL = "https://cz.example.com"
networkMapURL = "https://cz.example.com"
}
By delegating to a password store, and using `command substitution` it is possible to ensure that sensitive passwords never appear in plain text.
The below examples are of loading Corda with the KEY_PASS and TRUST_PASS variables read from a program named ``corporatePasswordStore``.
Bash
~~~~
.. sourcecode:: shell
KEY_PASS=$(corporatePasswordStore --cordaKeyStorePassword) TRUST_PASS=$(corporatePasswordStore --cordaTrustStorePassword) java -jar corda.jar
.. warning:: If this approach is taken, the passwords will appear in the shell history.
Windows PowerShell
~~~~~~~~~~~~~~~~~~
.. sourcecode:: shell
$env:KEY_PASS=$(corporatePasswordStore --cordaKeyStorePassword); $env:TRUST_PASS=$(corporatePasswordStore --cordaTrustStorePassword); java -jar corda.jar
For launching on Windows without PowerShell, it is not possible to perform command substitution, and so the variables must be specified manually, for example:
.. sourcecode:: shell
SET KEY_PASS=mypassword & SET TRUST_PASS=mypassword & java -jar corda.jar
.. warning:: If this approach is taken, the passwords will appear in the windows command prompt history.
Logging
-------
@ -202,6 +154,55 @@ The example command above would give a 1 gigabyte Java heap.
.. note:: Unfortunately the JVM does not let you limit the total memory usage of Java program, just the heap size.
Hiding sensitive data
---------------------
A frequent requirement is that configuration files must not expose passwords to unauthorised readers. By leveraging environment variables, it is possible to hide passwords and other similar fields.
Take a simple node config that wishes to protect the node cryptographic stores:
.. parsed-literal::
myLegalName = "O=PasswordProtectedNode,OU=corda,L=London,C=GB"
keyStorePassword = ${KEY_PASS}
trustStorePassword = ${TRUST_PASS}
p2pAddress = "localhost:12345"
devMode = false
networkServices {
doormanURL = "https://cz.example.com"
networkMapURL = "https://cz.example.com"
}
By delegating to a password store, and using `command substitution` it is possible to ensure that sensitive passwords never appear in plain text.
The below examples are of loading Corda with the KEY_PASS and TRUST_PASS variables read from a program named ``corporatePasswordStore``.
Bash
~~~~
.. sourcecode:: shell
KEY_PASS=$(corporatePasswordStore --cordaKeyStorePassword) TRUST_PASS=$(corporatePasswordStore --cordaTrustStorePassword) java -jar corda.jar
.. warning:: If this approach is taken, the passwords will appear in the shell history.
Windows PowerShell
~~~~~~~~~~~~~~~~~~
.. sourcecode:: shell
$env:KEY_PASS=$(corporatePasswordStore --cordaKeyStorePassword); $env:TRUST_PASS=$(corporatePasswordStore --cordaTrustStorePassword); java -jar corda.jar
For launching on Windows without PowerShell, it is not possible to perform command substitution, and so the variables must be specified manually, for example:
.. sourcecode:: shell
SET KEY_PASS=mypassword & SET TRUST_PASS=mypassword & java -jar corda.jar
.. warning:: If this approach is taken, the passwords will appear in the windows command prompt history.
Backup recommendations
----------------------

4
docs/source/node-naming.rst
View File

@ -1,7 +1,7 @@
.. _node-naming:
Node naming
===========
Node identity
=============
A node's name must be a valid X.500 distinguished name. In order to be compatible with other implementations
(particularly TLS implementations), we constrain the allowed X.500 name attribute types to a subset of the minimum
supported set for X.509 certificates (specified in RFC 3280), plus the locality attribute: