diff --git a/content/en/platform/corda/1.2/cenm/_index.md b/content/en/platform/corda/1.2/cenm/_index.md index e3a5110a323..5134d7da3ea 100644 --- a/content/en/platform/corda/1.2/cenm/_index.md +++ b/content/en/platform/corda/1.2/cenm/_index.md @@ -45,7 +45,7 @@ Concepts and Overview * [The workflow]({{< relref "../../../../../en/platform/corda/1.2/cenm/workflow.md" >}}) * [Databases]({{< relref "../../../../../en/platform/corda/1.2/cenm/database-set-up.md" >}}) * [Public Key Infrastructure (PKI)]({{< relref "../../../../../en/platform/corda/1.2/cenm/pki-tool.md" >}}) -* [The node](../../../../../en/platform/corda/1.2/cenm/network-map.html#node-certificate-revocation-checking) +* [The node]({{< relref "../../../../../en/platform/corda/1.2/cenm/network-map.md#node-certificate-revocation-checking" >}}) * [Sub Zones]({{< relref "../../../../../en/platform/corda/1.2/cenm/sub-zones.md" >}}) * [Network Map overview]({{< relref "../../../../../en/platform/corda/1.2/cenm/network-map-overview.md" >}}) * [Certificate Revocation List]({{< relref "../../../../../en/platform/corda/1.2/cenm/certificate-revocation.md" >}}) diff --git a/content/en/platform/corda/1.2/cenm/certificate-revocation.md b/content/en/platform/corda/1.2/cenm/certificate-revocation.md index c0452f3abbc..8038437543e 100644 --- a/content/en/platform/corda/1.2/cenm/certificate-revocation.md +++ b/content/en/platform/corda/1.2/cenm/certificate-revocation.md @@ -23,7 +23,7 @@ It is used by nodes when they establish a TLS connection between each other and In order to add entries to the certificate revocation list there is the certificate revocation process that resembles the one from the certificate signing request (CSR). -For context on how the certificate revocation list fits into the wider context, please see [Certificate Hierarchy Guide](pki-guide.md). +For context on how the certificate revocation list fits into the wider context, please see [Certificate Hierarchy Guide]({{< relref "pki-guide.md" >}}). Note that, once added the entries cannot be removed from the certificate revocation list. @@ -171,6 +171,6 @@ an up-to-date CRL is distributed in the network before the previous one expires. lifecycle of 6 months and are manually signed every 3 months. Such a schedule gives plenty of time for any signing issues to be resolved. -See [Signing Services](signing-service.md) for details on building and signing CRLs, and especially the “updatePeriod” -configuration field which is used to determine the next update deadline. See also [CRL Endpoint Check Tool](crl-endpoint-check-tool.md) +See [Signing Services]({{< relref "signing-service.md" >}}) for details on building and signing CRLs, and especially the “updatePeriod” +configuration field which is used to determine the next update deadline. See also [CRL Endpoint Check Tool]({{< relref "crl-endpoint-check-tool.md" >}}) for more information how to check CRLs’ update deadlines. diff --git a/content/en/platform/corda/1.2/cenm/changelog.md b/content/en/platform/corda/1.2/cenm/changelog.md index 58ffcd66af7..5ba1456077a 100644 --- a/content/en/platform/corda/1.2/cenm/changelog.md +++ b/content/en/platform/corda/1.2/cenm/changelog.md @@ -18,7 +18,7 @@ title: Changelog # Changelog Here’s a summary of what’s changed in each Enterprise Network Manager release. For guidance on how to upgrade code from -the previous release, see [Upgrading Corda Enterprise Network Manager](upgrade-notes.md). +the previous release, see [Upgrading Corda Enterprise Network Manager]({{< relref "upgrade-notes.md" >}}). ## CENM 1.2 diff --git a/content/en/platform/corda/1.2/cenm/config-identity-manager-parameters.md b/content/en/platform/corda/1.2/cenm/config-identity-manager-parameters.md index af32fc8b74a..bbf60d340e8 100644 --- a/content/en/platform/corda/1.2/cenm/config-identity-manager-parameters.md +++ b/content/en/platform/corda/1.2/cenm/config-identity-manager-parameters.md @@ -28,11 +28,11 @@ The host and port on which the service runs * **database**: -See [CENM Database Configuration](config-database.md) +See [CENM Database Configuration]({{< relref "config-database.md" >}}) * **shell**: -*(Optional)* See [Shell Configuration Parameters](config-shell.md) +*(Optional)* See [Shell Configuration Parameters]({{< relref "config-shell.md" >}}) * **localSigner**: @@ -103,7 +103,7 @@ Whether a client should be attempt to reconnect if the connection is dropped. * **ssl**: -See [SSL Settings](config-ssl.md) +See [SSL Settings]({{< relref "config-ssl.md" >}}) diff --git a/content/en/platform/corda/1.2/cenm/config-network-map-parameters.md b/content/en/platform/corda/1.2/cenm/config-network-map-parameters.md index 82409af7b23..527986009f0 100644 --- a/content/en/platform/corda/1.2/cenm/config-network-map-parameters.md +++ b/content/en/platform/corda/1.2/cenm/config-network-map-parameters.md @@ -28,11 +28,11 @@ The host and port on which the service runs * **database**: -See [CENM Database Configuration](config-database.md) +See [CENM Database Configuration]({{< relref "config-database.md" >}}) * **shell**: -*(Optional)* See [Shell Configuration Parameters](config-shell.md) +*(Optional)* See [Shell Configuration Parameters]({{< relref "config-shell.md" >}}) * **enmListener**: @@ -52,7 +52,7 @@ Whether a client should be attempt to reconnect if the connection is dropped. * **ssl**: -See [SSL Settings](config-ssl.md) +See [SSL Settings]({{< relref "config-ssl.md" >}}) @@ -79,7 +79,7 @@ To which port it’s enmListener is bound * **ssl**: -See [SSL Settings](config-ssl.md) +See [SSL Settings]({{< relref "config-ssl.md" >}}) @@ -97,7 +97,7 @@ To which port it’s enmListener is bound * **ssl**: -See [SSL Settings](config-ssl.md) +See [SSL Settings]({{< relref "config-ssl.md" >}}) diff --git a/content/en/platform/corda/1.2/cenm/corda-networks.md b/content/en/platform/corda/1.2/cenm/corda-networks.md index ad13924d89a..8dce7c02ae5 100644 --- a/content/en/platform/corda/1.2/cenm/corda-networks.md +++ b/content/en/platform/corda/1.2/cenm/corda-networks.md @@ -37,7 +37,7 @@ not the recommended deployment model outside of a testing setup.{{< /note >}} this service should be deployed (for more details on this see the Signing Service documentation), in brief, it is the intention that, unlike the Identity Manager, the signer is completely isolated from external communication. It only addresses a data source it shares with the Identity Manager. This ensure no hostile entity can penetrate the system -and force the signing of a certificate. See [Signing Services](signing-service.md) +and force the signing of a certificate. See [Signing Services]({{< relref "signing-service.md" >}}) * The signed certificates are recognised by the Identity Manager and returned to the requesting node (Nodes poll the Identity Manager periodically to see if their signature request has been fulfilled). @@ -82,7 +82,7 @@ one sub zone {{< /important >}} -For more information, see [Sub Zones](sub-zones.md) +For more information, see [Sub Zones]({{< relref "sub-zones.md" >}}) ### Operating a Segregated Sub Zone diff --git a/content/en/platform/corda/1.2/cenm/database-set-up.md b/content/en/platform/corda/1.2/cenm/database-set-up.md index 13c6b8c586d..0d934729e12 100644 --- a/content/en/platform/corda/1.2/cenm/database-set-up.md +++ b/content/en/platform/corda/1.2/cenm/database-set-up.md @@ -378,7 +378,7 @@ database = { {{< note >}} -The [CENM Database Configuration](config-database.md) doc page contains a complete list of database specific properties.{{< /note >}} +The [CENM Database Configuration]({{< relref "config-database.md" >}}) doc page contains a complete list of database specific properties.{{< /note >}} * The restricted CENM service instance database user has no permissions to alter a database schema, so `runMigration` is set to `false`. * The CENM distribution does not include any JDBC drivers with the exception of the H2 driver. diff --git a/content/en/platform/corda/1.2/cenm/deployment-kubernetes-idman.md b/content/en/platform/corda/1.2/cenm/deployment-kubernetes-idman.md index 296a4eca4d2..270c6922dff 100644 --- a/content/en/platform/corda/1.2/cenm/deployment-kubernetes-idman.md +++ b/content/en/platform/corda/1.2/cenm/deployment-kubernetes-idman.md @@ -16,7 +16,7 @@ weight: 100 # CENM Identity Manager Helm chart -This Helm chart is to configure, deploy and run CENM [Identity Manager](identity-manager.md) service. +This Helm chart is to configure, deploy and run CENM [Identity Manager]({{< relref "identity-manager.md" >}}) service. ## Example usage @@ -62,4 +62,4 @@ helm install idman idman --set shell.password="superDifficultPassword" {{< /table >}} -For additional information on database connection details refer to the official documentation: [database documentation](config-database.md). +For additional information on database connection details refer to the official documentation: [database documentation]({{< relref "config-database.md" >}}). diff --git a/content/en/platform/corda/1.2/cenm/deployment-kubernetes-nmap.md b/content/en/platform/corda/1.2/cenm/deployment-kubernetes-nmap.md index b4aed88a8f3..56fba0090e4 100644 --- a/content/en/platform/corda/1.2/cenm/deployment-kubernetes-nmap.md +++ b/content/en/platform/corda/1.2/cenm/deployment-kubernetes-nmap.md @@ -16,7 +16,7 @@ weight: 300 # CENM Network Map Helm chart -This Helm chart is to configure, deploy and run CENM [Network Map](network-map.md) service. +This Helm chart is to configure, deploy and run CENM [Network Map]({{< relref "network-map.md" >}}) service. ## Example usage @@ -62,4 +62,4 @@ helm install nmap nmap --set shell.password="superDifficultPassword" {{< /table >}} -For additional information on database connection details refer to the official documentation: [database documentation](config-database.md). +For additional information on database connection details refer to the official documentation: [database documentation]({{< relref "config-database.md" >}}). diff --git a/content/en/platform/corda/1.2/cenm/deployment-kubernetes-signer.md b/content/en/platform/corda/1.2/cenm/deployment-kubernetes-signer.md index d38eb609b73..1ffe77dcbb0 100644 --- a/content/en/platform/corda/1.2/cenm/deployment-kubernetes-signer.md +++ b/content/en/platform/corda/1.2/cenm/deployment-kubernetes-signer.md @@ -16,15 +16,15 @@ weight: 200 # CENM Signer Helm chart -This Helm chart is to configure, deploy and run CENM [Signing](signing-service.md) service. +This Helm chart is to configure, deploy and run CENM [Signing]({{< relref "signing-service.md" >}}) service. As the initial step this chart runs automatically PKI tool which creates and stores certificates necessary for correct Corda Network operation. By default the certificates have sample X.500 subject names (e.g. Identity Manager certificate has the subject name “CN=Test Identity Manager Service Certificate, OU=HQ, O=HoldCo LLC, L=New York, C=US”). The subject name can be set by configuration options starting with `pki.certificates.` prefix. For more information about PKI Tool and Certificate Hierarchy refer to: -* [Certificate Hierarchy Guide](pki-guide.md) -* [PKI Tool](pki-tool.md) +* [Certificate Hierarchy Guide]({{< relref "pki-guide.md" >}}) +* [PKI Tool]({{< relref "pki-tool.md" >}}) ## Example usage diff --git a/content/en/platform/corda/1.2/cenm/deployment-kubernetes.md b/content/en/platform/corda/1.2/cenm/deployment-kubernetes.md index 35d6c1dbc85..12dbecdd8e8 100644 --- a/content/en/platform/corda/1.2/cenm/deployment-kubernetes.md +++ b/content/en/platform/corda/1.2/cenm/deployment-kubernetes.md @@ -64,10 +64,10 @@ Each CENM service has its own dedicated folder with more detailed documentation. | Helm Chart | | -------------------------------------------------- | -| [Identity Manager](deployment-kubernetes-idman.md) | -| [Signer](deployment-kubernetes-signer.md) | -| [Network Map](deployment-kubernetes-nmap.md) | -| [Corda Notary](deployment-kubernetes-notary.md) | +| [Identity Manager]({{< relref "deployment-kubernetes-idman.md" >}}) | +| [Signer]({{< relref "deployment-kubernetes-signer.md" >}}) | +| [Network Map]({{< relref "deployment-kubernetes-nmap.md" >}}) | +| [Corda Notary]({{< relref "deployment-kubernetes-notary.md" >}}) | The charts are currently developed and tested against [Azure Kubernetes Service (AKS)](https://azure.microsoft.com/en-gb/services/kubernetes-service/). @@ -86,7 +86,7 @@ X.500 subject names (e.g. Identity Manager certificate subject is “CN=Test Identity Manager Service Certificate, OU=HQ, O=HoldCo LLC, L=New York, C=US”). The subject names of the whole PKI Certificate Hierarchy can be configured in the Signer Helm chart. For more information about Signer helm chart refer to -[Signer](deployment-kubernetes-signer.md). +[Signer]({{< relref "deployment-kubernetes-signer.md" >}}). There are three ways of bootstrapping a new CENM environment: @@ -417,5 +417,5 @@ DATA/trust-stores/network-root-truststore.jks Visit CENM official documentation for more information about network parameters: -- [Updating Network Parameters](updating-network-parameters.md) -- [Network Parameters List](config-network-parameters.md) +- [Updating Network Parameters]({{< relref "updating-network-parameters.md" >}}) +- [Network Parameters List]({{< relref "config-network-parameters.md" >}}) diff --git a/content/en/platform/corda/1.2/cenm/enm-components.md b/content/en/platform/corda/1.2/cenm/enm-components.md index 37ed2ef1410..3327b019fea 100644 --- a/content/en/platform/corda/1.2/cenm/enm-components.md +++ b/content/en/platform/corda/1.2/cenm/enm-components.md @@ -102,7 +102,7 @@ environments: * Postgres * SQL Server -For details of supported versions and configuration, see [CENM Databases](database-set-up.md). +For details of supported versions and configuration, see [CENM Databases]({{< relref "database-set-up.md" >}}). # Public Key Infrastructure (PKI) @@ -114,7 +114,7 @@ By design, they only have the ability to talk *to* the other ENM components, the In addition, signing a CRR or CSR, and potentially the Network Parameters, *should* require a human to interact with the HSM via some manual authentication mechanism. -See [Certificate Hierarchy Guide](pki-guide.md) for a detailed guide to PKI. +See [Certificate Hierarchy Guide]({{< relref "pki-guide.md" >}}) for a detailed guide to PKI. # The Node diff --git a/content/en/platform/corda/1.2/cenm/enm-with-ssl.md b/content/en/platform/corda/1.2/cenm/enm-with-ssl.md index 57ba33cc6d1..f2d1abf720e 100644 --- a/content/en/platform/corda/1.2/cenm/enm-with-ssl.md +++ b/content/en/platform/corda/1.2/cenm/enm-with-ssl.md @@ -83,7 +83,7 @@ acting as clients of the network. ### SSL Certificate Configuring All components should be configured to use SSL with the following configuration block. More details can be found in -[Identity Manager Configuration Parameters](config-identity-manager-parameters.md) and [Network Map Configuration Parameters](config-network-map-parameters.md). +[Identity Manager Configuration Parameters]({{< relref "config-identity-manager-parameters.md" >}}) and [Network Map Configuration Parameters]({{< relref "config-network-map-parameters.md" >}}). ```docker ssl = { diff --git a/content/en/platform/corda/1.2/cenm/identity-manager.md b/content/en/platform/corda/1.2/cenm/identity-manager.md index b386ab14295..d71253925ee 100644 --- a/content/en/platform/corda/1.2/cenm/identity-manager.md +++ b/content/en/platform/corda/1.2/cenm/identity-manager.md @@ -81,7 +81,7 @@ The main elements that need to be configured for the Identity Manager are: {{< note >}} -See [Identity Manager Configuration Parameters](config-identity-manager-parameters.md) for a detailed explanation about each possible parameter. +See [Identity Manager Configuration Parameters]({{< relref "config-identity-manager-parameters.md" >}}) for a detailed explanation about each possible parameter. {{< /note >}} @@ -138,7 +138,7 @@ database { {{< note >}} Due to the way the migrations are defined, if the Identity Manager and Network Map Services are using the same DB instance then they *must* use separate DB schemas. For more information regarding the supported databases -along with the schema see [CENM Databases](database-set-up.md). +along with the schema see [CENM Databases]({{< relref "database-set-up.md" >}}). {{< /note >}} @@ -184,7 +184,7 @@ database { ### Embedded shell (optional) -See [Shell Configuration](shell.html#shell-configuration) for more information on how to configure the shell. +See [Shell Configuration]({{< relref "shell.md#shell-configuration" >}}) for more information on how to configure the shell. ### Issuance Workflow @@ -267,12 +267,12 @@ workflows { } ``` -See [Workflow](workflow.md) for more information. +See [Workflow]({{< relref "workflow.md" >}}) for more information. ###### Jira Project Configuration -See [Jira Set-Up](jira-setup.md) for more information about how to configure a Jira project for CSR approval. +See [Jira Set-Up]({{< relref "jira-setup.md" >}}) for more information about how to configure a Jira project for CSR approval. #### CSR Signing Mechanism @@ -290,11 +290,11 @@ approval mechanism above, this can be achieved via one of two mechanisms: The local Signing Service is recommended for testing and toy environments. Given a local key store containing the relevant signing keys, it provides the functionality to automatically sign all approved CSRs on a configured schedule. No human interaction is needed and the credentials for the key stores have to be provided upfront. The service is an -integrated signer that is a cut-down version of the standalone [Signing Services](signing-service.md) and provides no HSM integration or +integrated signer that is a cut-down version of the standalone [Signing Services]({{< relref "signing-service.md" >}}) and provides no HSM integration or ability to manually verify changes. It is strongly recommended against using this for production environments. In order for the local signer to function, it needs to be able to access Identity Manager’s certificate and keypair -which should have been previously generated (see [Certificate Hierarchy Guide](pki-guide.md) for more information). The local signer uses local +which should have been previously generated (see [Certificate Hierarchy Guide]({{< relref "pki-guide.md" >}}) for more information). The local signer uses local key stores which should include the necessary signing keys along with their full certificate chains. To enable the local signer, the top level `localSigner` configuration block should be added to the config file: @@ -317,7 +317,7 @@ signing any CSR requests along with the full certificate chain back to the root ##### External Signing Service -The production grade signing mechanism is the external [Signing Services](signing-service.md). This has all the functionality of the +The production grade signing mechanism is the external [Signing Services]({{< relref "signing-service.md" >}}). This has all the functionality of the integrated local signer as well as HSM integration and the ability for a user to interactively verify and sign incoming CSRs. It should be used in all production environments where maximum security and validation checks are required. @@ -357,7 +357,7 @@ This parameter can be omitted if desired, in which case it will default to port {{< /note >}} {{< note >}} -All inter-service communication can be configured with SSL support. See [Configuring the ENM services to use SSL](enm-with-ssl.md). +All inter-service communication can be configured with SSL support. See [Configuring the ENM services to use SSL]({{< relref "enm-with-ssl.md" >}}). {{< /note >}} @@ -479,7 +479,7 @@ workflows { } ``` -See [Workflow](workflow.md) for more information. +See [Workflow]({{< relref "workflow.md" >}}) for more information. #### CRR Signing Mechanism @@ -501,7 +501,7 @@ Identity Manager. That is, the same key used for signing approved CSRs will be u ##### External Signing Service -Also similarly to CSR signing, the production grade signing mechanism for CRRs is the external [Signing Services](signing-service.md). +Also similarly to CSR signing, the production grade signing mechanism for CRRs is the external [Signing Services]({{< relref "signing-service.md" >}}). This has all the functionality of the integrated local signer as well as HSM integration and the ability for a user to interactively verify and sign incoming CRRs. It should be used in all production environments where maximum security and validation checks are required. @@ -537,7 +537,7 @@ This parameter can be omitted if desired, in which case it will default to port {{< /note >}} {{< note >}} -All inter-service communication can be configured with SSL support. See [Configuring the ENM services to use SSL](enm-with-ssl.md). +All inter-service communication can be configured with SSL support. See [Configuring the ENM services to use SSL]({{< relref "enm-with-ssl.md" >}}). {{< /note >}} @@ -709,7 +709,7 @@ shell { Below is an example of a more production-like configuration of the Identity Manager. It is configured with a Issuance and Revocation workflow, using Jira workflows for CSR/CRR approvals, no local signer and also using SSL for secure communication between ENM services. In this scenario, all approved requests would be signed using an external signing -service (see [Signing Services](signing-service.md)). +service (see [Signing Services]({{< relref "signing-service.md" >}})). ```docker address = "localhost:10000" diff --git a/content/en/platform/corda/1.2/cenm/network-map-overview.md b/content/en/platform/corda/1.2/cenm/network-map-overview.md index 990291fb96d..399724e5c31 100644 --- a/content/en/platform/corda/1.2/cenm/network-map-overview.md +++ b/content/en/platform/corda/1.2/cenm/network-map-overview.md @@ -193,8 +193,8 @@ parameters change. * **whitelistedContractImplementations**: List of whitelisted versions of contract code. For each contract class there is a list of hashes of the approved CorDapp jar versions containing that contract. Read -more about *contract constraints* in the [contract constraints doc](https://docs.corda.net/api-contract-constraints.html). See -[Contract Whitelist Generation](contract-whitelisting.md) for how to configure this in the network parameters +more about *contract constraints* in the [contract constraints doc](https://docs.r3.com/api-contract-constraints.html). See +[Contract Whitelist Generation]({{< relref "contract-whitelisting.md" >}}) for how to configure this in the network parameters configuration file. diff --git a/content/en/platform/corda/1.2/cenm/network-map.md b/content/en/platform/corda/1.2/cenm/network-map.md index 8574fb278e3..2b50a42c023 100644 --- a/content/en/platform/corda/1.2/cenm/network-map.md +++ b/content/en/platform/corda/1.2/cenm/network-map.md @@ -24,7 +24,7 @@ title: Network Map Service The Network Map Service acts as a directory for all participants on the network. It is responsible for recording essential information of each participant such as connection address and available services. See -[Network Map Overview](network-map-overview.md) for an in-depth explanation. +[Network Map Overview]({{< relref "network-map-overview.md" >}}) for an in-depth explanation. ## Running The Network Map Service @@ -165,7 +165,7 @@ database { {{< note >}} Due to the way the migrations are defined, if the Identity Manager and Network Map Services are using the same DB instance then they *must* use separate DB schemas. For more information regarding the supported databases -along with the schema see [CENM Databases](database-set-up.md). +along with the schema see [CENM Databases]({{< relref "database-set-up.md" >}}). {{< /note >}} @@ -213,7 +213,7 @@ database { ### Embedded shell (optional) -See [Shell Configuration](shell.html#shell-configuration) for more information on how to configure the shell. +See [Shell Configuration]({{< relref "shell.md#shell-configuration" >}}) for more information on how to configure the shell. ### Network Data Signing Mechanism @@ -233,11 +233,11 @@ The local Signing Service is recommended for testing and toy environments. Given relevant signing keys, it provides the functionality to automatically sign all approved Network Map and Parameter updates on a configured schedule. No human interaction is needed and the credentials for the key stores have to be provided upfront. The service is an integrated signer that is a cut-down version of the standalone -[Signing Services](signing-service.md) and provides no HSM integration or ability to manually verify changes. It is strongly recommended +[Signing Services]({{< relref "signing-service.md" >}}) and provides no HSM integration or ability to manually verify changes. It is strongly recommended against using this for production environments. In order for the local signer to function, it needs to be able to access Network Map’s certificate and keypair -which should have been previously generated (see [Certificate Hierarchy Guide](pki-guide.md) for more information). The local signer uses local +which should have been previously generated (see [Certificate Hierarchy Guide]({{< relref "pki-guide.md" >}}) for more information). The local signer uses local key stores which should include the necessary signing keys along with their full certificate chains. To enable the local signer, the top level `localSigner` configuration block should be added to the config file: @@ -260,7 +260,7 @@ signing any network map or parameter changes along with the full certificate cha #### External Signing Service -The production grade signing mechanism is the external [Signing Services](signing-service.md). This has all the functionality of the +The production grade signing mechanism is the external [Signing Services]({{< relref "signing-service.md" >}}). This has all the functionality of the integrated local signer as well as HSM integration and the ability for a user to interactively verify and sign incoming network map or parameter changes. It should be used in all production environments where maximum security and validation checks are required. @@ -289,7 +289,7 @@ pollingInterval = 600000 ### Node Certificate Revocation Checking -In cases when the certificate revocation list infrastructure (See [Certificate Revocation List](certificate-revocation.md) for more information) +In cases when the certificate revocation list infrastructure (See [Certificate Revocation List]({{< relref "certificate-revocation.md" >}}) for more information) is provided, the additional validation for the node’s certificates can be enabled in the Network Map Service. This is achieved via the top-level `checkRevocation` flag set in the configuration file. This ensures that any node within the Network Map has a valid, trusted certificate. @@ -334,7 +334,7 @@ This parameter can be omitted if desired, in which case it will default to port {{< /note >}} {{< note >}} -All inter-service communication can be configured with SSL support. See [Configuring the ENM services to use SSL](enm-with-ssl.md). +All inter-service communication can be configured with SSL support. See [Configuring the ENM services to use SSL]({{< relref "enm-with-ssl.md" >}}). {{< /note >}} @@ -368,10 +368,10 @@ revocation { The `host` should correspond to the host part of the `address` value in the Identity Manager configuration. The `port` parameter for each service should correspond with the `port` value within the `enmListener` config block in -the service’s configuration. See [Network Map Configuration Parameters](config-network-map-parameters.md) for more information. +the service’s configuration. See [Network Map Configuration Parameters]({{< relref "config-network-map-parameters.md" >}}) for more information. {{< note >}} -All inter-service communication can be configured with SSL support. See [Configuring the ENM services to use SSL](enm-with-ssl.md) +All inter-service communication can be configured with SSL support. See [Configuring the ENM services to use SSL]({{< relref "enm-with-ssl.md" >}}) {{< /note >}} diff --git a/content/en/platform/corda/1.2/cenm/pki-guide.md b/content/en/platform/corda/1.2/cenm/pki-guide.md index f7aa91f36c3..17b92c72177 100644 --- a/content/en/platform/corda/1.2/cenm/pki-guide.md +++ b/content/en/platform/corda/1.2/cenm/pki-guide.md @@ -93,7 +93,7 @@ As such, in Corda, the certificate revocation list for the TLS level is signed b which is then added to node’s trust store (in a similar way as the Corda Root certificate - distributed with the `network-trust-store.jks`). During the certificate revocation list validation process the trust store is consulted for the presence of the TLS Signer certificate. -See [Certificate Revocation List](certificate-revocation.md) for instructions on revoking certificates, and [Signing Services](signing-service.md) for +See [Certificate Revocation List]({{< relref "certificate-revocation.md" >}}) for instructions on revoking certificates, and [Signing Services]({{< relref "signing-service.md" >}}) for configuration of the signer for CRLs (especially the “updatePeriod” option). @@ -237,6 +237,6 @@ is only required to provide only essential information to the tool. At the same defaults and have the configuration adjusted to the specific needs of different scenarios. {{< note >}} -To learn more about running the tool, see [Public Key Infrastructure (PKI) Tool](pki-tool.md). +To learn more about running the tool, see [Public Key Infrastructure (PKI) Tool]({{< relref "pki-tool.md" >}}). {{< /note >}} diff --git a/content/en/platform/corda/1.2/cenm/pki-specifications.md b/content/en/platform/corda/1.2/cenm/pki-specifications.md index 6cac5240c45..3b897c3b737 100644 --- a/content/en/platform/corda/1.2/cenm/pki-specifications.md +++ b/content/en/platform/corda/1.2/cenm/pki-specifications.md @@ -15,24 +15,24 @@ title: PKI Specifications # Public Key Infrastructure (PKI) Specifications -As described in the [Certificate Hierarchy Guide](pki-guide.md), Corda security relies heavily on the use of Public Key Infrastructure (PKI). Whether creating this hierarchy using the [PKI Tool](pki-tool.md) or setting up a Corda network on your own, your PKI must comply with existing Corda specifications. +As described in the [Certificate Hierarchy Guide]({{< relref "pki-guide.md" >}}), Corda security relies heavily on the use of Public Key Infrastructure (PKI). Whether creating this hierarchy using the [PKI Tool]({{< relref "pki-tool.md" >}}) or setting up a Corda network on your own, your PKI must comply with existing Corda specifications. Specifications and instructions are referenced here for the four scenarios below. Follow these guidelines to successfully create a Corda compliant hierarchy for your own use or to pass on to a third party service. ## Generating root, subordinate, and network certificates -For instructions on generating certificates, see the [PKI Tool](pki-tool.html#running-the-pki-tool) documentation. +For instructions on generating certificates, see the [PKI Tool]({{< relref "pki-tool.md#running-the-pki-tool" >}}) documentation. ## Setting up a network under an existing root -If you wish to set up a Corda network under an existing root and therefore are not using the PKI Tool, the certificate hierarchy you create should follow the guidelines specified in the [Certificate Hierarchy Guide](pki-guide.md). You may also find it helpful to reference the [Corda network policies](https://trust.corda.network/). +If you wish to set up a Corda network under an existing root and therefore are not using the PKI Tool, the certificate hierarchy you create should follow the guidelines specified in the [Certificate Hierarchy Guide]({{< relref "pki-guide.md" >}}). You may also find it helpful to reference the [Corda network policies](https://trust.corda.network/). ## Delegating network signing to a third party If you wish to delegate network signing to a third party software provider, this can be done partially (with the Certificate Authority only) or fully (with the Certificate Authority and the non-Certificate Authority). -Follow the specifications outlined in the [Signing and SMR Services](signing-service.html#developing-signing-plugins) documentation to delegate this task to a third party software provider. +Follow the specifications outlined in the [Signing and SMR Services]({{< relref "signing-service.md#developing-signing-plugins" >}}) documentation to delegate this task to a third party software provider. ## Using your own Certificate Authority software -To set up a Corda network using your own Certificate Authority software, use the Signable Material Retriever service. This service acts as a bridge between CENM services and one or more Signing Services. See the [Signable Material Retriever Service](signing-service.html#signable-material-retriever) documentation for instructions and specifications for using this service. +To set up a Corda network using your own Certificate Authority software, use the Signable Material Retriever service. This service acts as a bridge between CENM services and one or more Signing Services. See the [Signable Material Retriever Service]({{< relref "signing-service.md#signable-material-retriever" >}}) documentation for instructions and specifications for using this service. diff --git a/content/en/platform/corda/1.2/cenm/pki-tool.md b/content/en/platform/corda/1.2/cenm/pki-tool.md index 5f062b6a233..1d2f3e64600 100644 --- a/content/en/platform/corda/1.2/cenm/pki-tool.md +++ b/content/en/platform/corda/1.2/cenm/pki-tool.md @@ -22,7 +22,7 @@ title: Public Key Infrastructure (PKI) Tool ## Overview -As described in the [Certificate Hierarchy Guide](pki-guide.md), a certificate hierarchy with certain properties is required to run a Corda +As described in the [Certificate Hierarchy Guide]({{< relref "pki-guide.md" >}}), a certificate hierarchy with certain properties is required to run a Corda network. Specifically, the certificate hierarchy should include the two main CENM entities - the Identity Manager and the Network Map - and ensure that all entities map back to one common root of trust. The key pairs and certificates for these entities are used within the Signing Service to sign related network data such as approved CSRs, CRRs, Network Map @@ -120,7 +120,7 @@ are used by the tool for storing generated certificates. hierarchy. {{< note >}} -The full list of the configuration parameters can be found in [Public Key Infrastructure (PKI) Tool Configuration Parameters](config-pki-tool-parameters.md). +The full list of the configuration parameters can be found in [Public Key Infrastructure (PKI) Tool Configuration Parameters]({{< relref "config-pki-tool-parameters.md" >}}). {{< /note >}} @@ -128,7 +128,7 @@ The full list of the configuration parameters can be found in [Public Key Infras This configuration block defines all key stores that should be used by the PKI Tool. Each key store can be either local (backed by a Java key store file) or HSM (backed by a LAN HSM device). For HSM key stores, the available options and -authentication methods will depend on the HSM being used. See [Public Key Infrastructure (PKI) Tool Configuration Parameters](config-pki-tool-parameters.md) for more details. +authentication methods will depend on the HSM being used. See [Public Key Infrastructure (PKI) Tool Configuration Parameters]({{< relref "config-pki-tool-parameters.md" >}}) for more details. A mixture of key store types is allowed. That is, it is possible to generate some key pairs within a HSM device and others locally. Note that mixing key store types is not supported for a given entity. @@ -152,7 +152,7 @@ map from the user-defined alias to certificate configuration. The alias serves t reference the given entity throughout the rest of the PKI Tool config. Secondly, it also defines the alias for the generated (or existing) certificate entry in the corresponding certificate store. The certificate configuration defines the entity specific properties of both the X509 certificate and associated key pair. See -[Public Key Infrastructure (PKI) Tool Configuration Parameters](config-pki-tool-parameters.md) for more information. +[Public Key Infrastructure (PKI) Tool Configuration Parameters]({{< relref "config-pki-tool-parameters.md" >}}) for more information. If the desire is to use the resultant certificate hierarchy in a Corda network, this configuration block must define a set of certificates that meet some basic requirements. In addition to the hierarchy having to be under a single trust @@ -287,7 +287,7 @@ certificates = { ##### Free-form Certificates As an alternative to using the templates, each key pair and certificate can defined using the standard configuration -options. See the [Public Key Infrastructure (PKI) Tool Configuration Parameters](config-pki-tool-parameters.md) documentation for all possible parameters, and see below for examples +options. See the [Public Key Infrastructure (PKI) Tool Configuration Parameters]({{< relref "config-pki-tool-parameters.md" >}}) documentation for all possible parameters, and see below for examples that use this approach. Note that the templates only support local key stores - using a HSM requires the certificate hierarchy to be defined without templates. @@ -299,7 +299,7 @@ explicitly defines all necessary CRL file configurations or all CRL distribution generated without the `Certificate Revocation List Distribution Point` extension and will therefore be incompatible with any network using strict revocation checking. -As outlined in the [Public Key Infrastructure (PKI) Tool Configuration Parameters](config-pki-tool-parameters.md) doc, this extension is defined using the following logic: +As outlined in the [Public Key Infrastructure (PKI) Tool Configuration Parameters]({{< relref "config-pki-tool-parameters.md" >}}) doc, this extension is defined using the following logic: * If the certificate configuration has the `crlDistributionUrl` parameter set then use this. @@ -349,7 +349,7 @@ subordinate’s CRL file must be hosted, and available, on this endpoint. {{< note >}} Existing revocations can be added to the CRL file via the `crl.revocations` parameter. See -[Public Key Infrastructure (PKI) Tool Configuration Parameters](config-pki-tool-parameters.md) for more information. +[Public Key Infrastructure (PKI) Tool Configuration Parameters]({{< relref "config-pki-tool-parameters.md" >}}) for more information. {{< /note >}} For a given certificate, the exact crlDistributionPoint extension can be defined explicitly (rather than inheriting from @@ -376,7 +376,7 @@ certificates { As previously mentioned, it is up to the network operator to ensure that any configured CRL endpoints are available. The Identity Manager supports hosting of these CRL files (see the the “CRL Configuration” section of the -[Identity Manager Service](identity-manager.md) doc). +[Identity Manager Service]({{< relref "identity-manager.md" >}}) doc). ##### HSM Libraries @@ -458,7 +458,7 @@ This will create a jar called `azure-keyvault-with-deps.jar` which can be refere ##### Generating SSL Keys -As outlined in the [Configuring the ENM services to use SSL](enm-with-ssl.md) doc, all inter-service CENM communication can be configured to encrypt their +As outlined in the [Configuring the ENM services to use SSL]({{< relref "enm-with-ssl.md" >}}) doc, all inter-service CENM communication can be configured to encrypt their messages via SSL. This feature requires the operator to provide a set of SSL key pairs and certificates to each service, which can be generated using the PKI tool. @@ -485,7 +485,7 @@ certificates = { {{< note >}} HSM keys used by the Signing Service require an accompanying certificate store that contains all certificates in the chain, from the signing entity back to the root. This is because the full chains cannot be stored within the -HSMs. Refer to the [Signing Services](signing-service.md) documentation for more information. +HSMs. Refer to the [Signing Services]({{< relref "signing-service.md" >}}) documentation for more information. {{< /note >}} diff --git a/content/en/platform/corda/1.2/cenm/quick-start.md b/content/en/platform/corda/1.2/cenm/quick-start.md index 1a6331f9c12..0bb8c2f8fc2 100644 --- a/content/en/platform/corda/1.2/cenm/quick-start.md +++ b/content/en/platform/corda/1.2/cenm/quick-start.md @@ -51,7 +51,7 @@ value should be the external address of the machine along with any port defined Before starting any services, the PKI first needs to be generated. This involves creating the certificates and key pairs for all ENM services and determines what entities the nodes will trust. More information on the certificate hierarchy -is available in the [Certificate Hierarchy Guide](pki-guide.md) doc. +is available in the [Certificate Hierarchy Guide]({{< relref "pki-guide.md" >}}) doc. #### Example Configuration @@ -103,13 +103,13 @@ certificates = { {{< note >}} The passwords for the key stores are defaulted to “password” and the passwords for the trust stores are -defaulted to “trustpass”. These can be changed in the configuration (see [Public Key Infrastructure (PKI) Tool](pki-tool.md)). +defaulted to “trustpass”. These can be changed in the configuration (see [Public Key Infrastructure (PKI) Tool]({{< relref "pki-tool.md" >}})). {{< /note >}} #### Running The Tool -The required certificate stores and key pairs can be generated using the [Public Key Infrastructure (PKI) Tool](pki-tool.md). The PKI tool distribution zip +The required certificate stores and key pairs can be generated using the [Public Key Infrastructure (PKI) Tool]({{< relref "pki-tool.md" >}}). The PKI tool distribution zip archive should be extracted to a chosen location, after which it can be run via: ```bash @@ -184,7 +184,7 @@ workflows { {{< note >}} The example uses a local h2 database. You can modify this to point to an separate DB instance by modifying the -`database` section. See the “Database properties” section of [Identity Manager Service](identity-manager.md) for more +`database` section. See the “Database properties” section of [Identity Manager Service]({{< relref "identity-manager.md" >}}) for more information. {{< /note >}} @@ -280,7 +280,7 @@ The network parameters are a set of values that every node participating in the correctly communicate with each other. Therefore they need to be set before the Network Map Service can be started. They are set via running the Network Map jar in a special “set network parameters” mode which requires a parameter configuration file to be passed. Therefore this step requires both a Network Map Service configuration and a network -parameters configuration. See [Updating the network parameters](updating-network-parameters.md) for more information around the processing of setting +parameters configuration. See [Updating the network parameters]({{< relref "updating-network-parameters.md" >}}) for more information around the processing of setting and updating the parameters. @@ -324,7 +324,7 @@ checkRevocation = false {{< note >}} The example uses a local h2 database. You can modify this to point to an separate DB instance by modifying the -`database` section. See the “Database properties” section of [Network Map Service](network-map.md) for more information. +`database` section. See the “Database properties” section of [Network Map Service]({{< relref "network-map.md" >}}) for more information. {{< /note >}} @@ -420,11 +420,11 @@ The above guide also assumes the simplest possible settings for all services. Th more features, in particular: -* Certificate revocation support (“Revocation workflow ” section within [Identity Manager Service](identity-manager.md)) -* More advanced CSR approval workflows (“Certificate approval mechanism” section within [Identity Manager Service](identity-manager.md)) -* External signing of CSRs/Network Map updates including HSM integration ([Signing Services](signing-service.md)) +* Certificate revocation support (“Revocation workflow ” section within [Identity Manager Service]({{< relref "identity-manager.md" >}})) +* More advanced CSR approval workflows (“Certificate approval mechanism” section within [Identity Manager Service]({{< relref "identity-manager.md" >}})) +* External signing of CSRs/Network Map updates including HSM integration ([Signing Services]({{< relref "signing-service.md" >}})) -See the configuration sections within the [Identity Manager Service](identity-manager.md) and [Network Map Service](network-map.md) docs to learn more. +See the configuration sections within the [Identity Manager Service]({{< relref "identity-manager.md" >}}) and [Network Map Service]({{< relref "network-map.md" >}}) docs to learn more. ## Bundled Service alternative diff --git a/content/en/platform/corda/1.2/cenm/release-notes.md b/content/en/platform/corda/1.2/cenm/release-notes.md index 5b47d29a255..92ed37c2702 100644 --- a/content/en/platform/corda/1.2/cenm/release-notes.md +++ b/content/en/platform/corda/1.2/cenm/release-notes.md @@ -51,8 +51,8 @@ CENM 1.2.3 introduces fixes to known issues in CENM 1.2. ### Fixed issues -* We have fixed an issue where the maximum length of a certificate's serial number allowed by CENM was 28 digits (`NUMBER(28)` format in the database) - roughly about 93 bits of data. To extend the support (introduced in CENM 1.2) for third-party CAs such as [SwissPKI](https://www.swisspki.com/), the Identity Manager Service can now handle certificate serial numbers with sizes up to 20 octets/bytes (160 bits) to comply with [RFC 5280](https://tools.ietf.org/html/rfc5280). In addition, the [PKI Tool](pki-tool.md) now generates certificates with serial number sizes of up to 16 octets/bytes. -* We have fixed an issue where the [PKI Tool](pki-tool.md) would throw an error when using [securosys HSM](https://www.securosys.com/) with multiple partitions. +* We have fixed an issue where the maximum length of a certificate's serial number allowed by CENM was 28 digits (`NUMBER(28)` format in the database) - roughly about 93 bits of data. To extend the support (introduced in CENM 1.2) for third-party CAs such as [SwissPKI](https://www.swisspki.com/), the Identity Manager Service can now handle certificate serial numbers with sizes up to 20 octets/bytes (160 bits) to comply with [RFC 5280](https://tools.ietf.org/html/rfc5280). In addition, the [PKI Tool]({{< relref "pki-tool.md" >}}) now generates certificates with serial number sizes of up to 16 octets/bytes. +* We have fixed an issue where the [PKI Tool]({{< relref "pki-tool.md" >}}) would throw an error when using [securosys HSM](https://www.securosys.com/) with multiple partitions. ## Corda Enterprise Network Manager 1.2.2 @@ -73,7 +73,7 @@ We are expanding our support for Docker to Corda Enterprise Network Manager. Furthermore, we are introducing a first reference deployment with Helm and Kubernetes. Out of the box - you will be able to deploy in minutes an ephemeral representative test network to complement your development cycle. -See [Kubernetes deployment documentation](deployment-kubernetes.md) for more details. +See [Kubernetes deployment documentation]({{< relref "deployment-kubernetes.md" >}}) for more details. **Support for third party CAs** @@ -81,7 +81,7 @@ To satisfy clients who wish to use third party software or service providers to The new service (SMR) extracts signable material from the Identity Manager and Network Map Services, and then delegates signing to a plugin. Customers can implement their own plugins to integrate with external signing infrastructure and return signed material back to SMR to pass to the relevant CENM service. -See [Signing Services](signing-service.md) for more details. Also see [EJBCA Sample Plugin](ejbca-plugin.md) for a sample open source CA implementation. +See [Signing Services]({{< relref "signing-service.md" >}}) for more details. Also see [EJBCA Sample Plugin]({{< relref "ejbca-plugin.md" >}}) for a sample open source CA implementation. **CRL Endpoint Check tool** @@ -89,7 +89,7 @@ As a diagnostic aid in case of problems with TLS connections, CENM 1.2 introduce This stand alone tool checks CRL endpoint health of all certificates in a provided keystore, as a simpler alternative to manually extracting CRL endpoints individually from the certificate and then verifying them. -See [CRL Endpoint Check Tool](crl-endpoint-check-tool.md) for usage and further details. +See [CRL Endpoint Check Tool]({{< relref "crl-endpoint-check-tool.md" >}}) for usage and further details. ### Minor Features @@ -126,10 +126,10 @@ the logs files do not conflict. * Correct service healthcheck command when executed from the CRaSH shell. * Add new command to Network Map shell to view list of nodes that have accepted (or haven’t) a given parameters update (“view nodesAcceptedParametersUpdate accepted: , parametersHash: ”), -which can help to monitor the procedure of [Updating the network parameters](updating-network-parameters.md). +which can help to monitor the procedure of [Updating the network parameters]({{< relref "updating-network-parameters.md" >}}). * Add working directory argument for CENM services, which is a path prefix for config and certificate files. * Add `run networkParametersRegistration`, `run flagDay` and `run cancelUpdate` commands to the Network Map -service shell, to enable running flag days without restarting the service. See [Updating the network parameters](updating-network-parameters.md) for +service shell, to enable running flag days without restarting the service. See [Updating the network parameters]({{< relref "updating-network-parameters.md" >}}) for full details. * Add `view publicNetworkNodeInfos` command to Network Map Service shell, to see all public network participants’ node infos, including its’ platform version. @@ -186,7 +186,7 @@ configurations to be compatible with 1.1. **Oracle Database Support** Support has been added for Oracle DB versions 12cR2 and 11gR2 as a backend data store. -For full setup instructions see [CENM Databases](database-set-up.md). +For full setup instructions see [CENM Databases]({{< relref "database-set-up.md" >}}). **Configuration Migration Tool** @@ -205,7 +205,7 @@ as well as for Gemalto and Securosys HSMs in both the PKI Tool and Signing Servi * CENM now supports encryption of passwords in configuration files, using encryption keys derived from hardware attributes. An obfuscation tool ships with CENM, to process configuration files and encrypt -marked fields. For more details on usage see [Config Obfuscation Tool](config-obfuscation-tool.md). +marked fields. For more details on usage see [Config Obfuscation Tool]({{< relref "config-obfuscation-tool.md" >}}). * Fixed an internal error which occurred when using H2 versions below 1.4.198 due to use of unsupported lock types. * Added `run purgeAllStagedNodeInfos` and `run purgeStagedNodeInfo nodeInfoHash: ` commands @@ -246,18 +246,18 @@ fresh to the product but also those who are upgrading from pre-release versions. The Signing Service is a new addition to the suite of CENM services, sitting alongside the Identity Manager and Network Map. It provides a network operator with full control over the signing of node identity data (CSRs and CRRs) and global network data (Network Map and Network Parameters) and includes features such as HSM integration, signing scheduling and -support for multiple Network Map Services. See [Signing Services](signing-service.md) to learn more about this service. +support for multiple Network Map Services. See [Signing Services]({{< relref "signing-service.md" >}}) to learn more about this service. **Brand new PKI tooling** The PKI Tool enables a network operator to easily generate Corda-compliant certificate hierarchy (keys and certificates) as well as certificate revocation lists. The tool supports both local and HSM key stores and can be -customized with the configuration file. See [Public Key Infrastructure (PKI) Tool](pki-tool.md) to learn about all the features of the PKI Tool. +customized with the configuration file. See [Public Key Infrastructure (PKI) Tool]({{< relref "pki-tool.md" >}}) to learn about all the features of the PKI Tool. **Full End to End SSL communication** All CENM components now communicate over SSL with one another, this completes the removal of the “database as message -queue” of older versions. See [Configuring the ENM services to use SSL](enm-with-ssl.md) for more information. +queue” of older versions. See [Configuring the ENM services to use SSL]({{< relref "enm-with-ssl.md" >}}) for more information. **Security And Performance Fixes** @@ -282,13 +282,13 @@ versioned changes to the protocol without changing that which the Corda nodes de The Signing Service is a new addition to the suite of CENM services, sitting alongside the Identity Manager and Network Map. It provides a network operator with full control over the signing of node identity data (CSRs and CRRs) and global network data (Network Map and Network Parameters) and includes features such as HSM integration, signing scheduling and -support for multiple Network Map Services. See [Signing Services](signing-service.md) to learn more about this service. +support for multiple Network Map Services. See [Signing Services]({{< relref "signing-service.md" >}}) to learn more about this service. **Epoch Control** The PKI Tool enables a network operator to easily generate Corda-compliant certificate hierarchy (keys and certificates) as well as certificate revocation lists. The tool supports both local and HSM key stores and can be -customized with the configuration file. See [Public Key Infrastructure (PKI) Tool](pki-tool.md) to learn about all the features of the PKI Tool. +customized with the configuration file. See [Public Key Infrastructure (PKI) Tool]({{< relref "pki-tool.md" >}}) to learn about all the features of the PKI Tool. **Shell** @@ -312,7 +312,7 @@ sub-zones of nodes that operate in what appear to the nodes to be isolated netwo network parameters. Critically, however, their certificate governance remains under the jurisdiction of a global Doorman. This way, temporary benefits such as higher privacy, differential network parameters upgrade schedules or use of temporary private notaries can be delivered. Note that the ability to merge one sub-zone into another is not -currently supported. See the [Sub Zones](sub-zones.md) documentation for more information. +currently supported. See the [Sub Zones]({{< relref "sub-zones.md" >}}) documentation for more information. **Protocol Separation** @@ -326,12 +326,12 @@ The two top-level endpoints are now * `/network-map` * `/network-map-user` -see [Network Map Overview](network-map-overview.md) for more information. +see [Network Map Overview]({{< relref "network-map-overview.md" >}}) for more information. Another change that is introduced in the newest release is the ability to interact with the Doorman and Network Map services via a shell. The commands available currently mainly allow an operator to inspect the state of the service, for example by viewing the current set of nodes within the public network, or viewing the list of Certificate Signing -Requests that are awaiting approval. See the [Embedded Shell](shell.md) documentation for more information. +Requests that are awaiting approval. See the [Embedded Shell]({{< relref "shell.md" >}}) documentation for more information. Added support for overriding the default “increment previous value by 1” behaviour for epoch values during network parameter updates/initialisation. This allows a user to specify the epoch within the parameter config file and it diff --git a/content/en/platform/corda/1.2/cenm/setting-up-notary.md b/content/en/platform/corda/1.2/cenm/setting-up-notary.md index 3f81c27fb55..69cb5a09b7d 100644 --- a/content/en/platform/corda/1.2/cenm/setting-up-notary.md +++ b/content/en/platform/corda/1.2/cenm/setting-up-notary.md @@ -96,7 +96,7 @@ java -jar corda.jar --config-file --just-generate-node-info ### Setup Network Map Service -Follow instructions here [Network Map Service](network-map.md) +Follow instructions here [Network Map Service]({{< relref "network-map.md" >}}) ### Run The Notary diff --git a/content/en/platform/corda/1.2/cenm/signing-service.md b/content/en/platform/corda/1.2/cenm/signing-service.md index 1e52362431d..53858ed5bdd 100644 --- a/content/en/platform/corda/1.2/cenm/signing-service.md +++ b/content/en/platform/corda/1.2/cenm/signing-service.md @@ -27,7 +27,7 @@ Corda Enterprise Network Manager, alongside the Identity Operator and Network Ma a bridge between the main CENM services and PKI/HSM infrastructure, enabling a network operator to verify and sign incoming requests and changes to the network. -As mentioned in the CENM service documentation ([Identity Manager Service](identity-manager.md) and [Network Map Service](network-map.md)), the main CENM services +As mentioned in the CENM service documentation ([Identity Manager Service]({{< relref "identity-manager.md" >}}) and [Network Map Service]({{< relref "network-map.md" >}})), the main CENM services can be configured with an integrated *local signer* that will automatically sign all unsigned data using a provided key. While this is convenient, it is intended for use within for development and testing environments, and **should not** be used in production environments. Instead, large and important changes to the network should go through a series of checks before @@ -38,7 +38,7 @@ particular data to require authentication from multiple users. ## Signing Service -CENM’s Signing Service supports the following HSMs (see [CENM support matrix](cenm-support-matrix.md) for more information): +CENM’s Signing Service supports the following HSMs (see [CENM support matrix]({{< relref "cenm-support-matrix.md" >}}) for more information): * Utimaco @@ -76,7 +76,7 @@ for the configured signing keys. The overall flow of communication can be seen i ![Signing Service communication](/en/images/signing-service-communication.png "Signing Service communication") {{< note >}} All inter-service communication can be configured with SSL support to ensure the connection is encrypted. See -[Configuring the ENM services to use SSL](enm-with-ssl.md) +[Configuring the ENM services to use SSL]({{< relref "enm-with-ssl.md" >}}) {{< /note >}} {{< note >}} @@ -157,7 +157,7 @@ The configuration for the Signing Service consists of the following sections: The Signing Service is interacted with via the shell, which is configured at the top level of the config file. This shell is similar to the interactive shell available in other ENM services and is configured in a similar way. See -[Shell Configuration](shell.html#shell-configuration) for more information on how to configure the shell. +[Shell Configuration]({{< relref "shell.md#shell-configuration" >}}) for more information on how to configure the shell. #### HSM Libraries @@ -290,7 +290,7 @@ locations. {{< note >}} Communication with the configured service locations can be configured to use SSL for a secure, encrypted -connection. This is strongly recommended for production deployments. See [Configuring the ENM services to use SSL](enm-with-ssl.md) for more +connection. This is strongly recommended for production deployments. See [Configuring the ENM services to use SSL]({{< relref "enm-with-ssl.md" >}}) for more information. {{< /note >}} @@ -306,7 +306,7 @@ Material Retriever Service. {{< note >}} Communication with the configured SMR service location can be configured to use SSL for a secure, encrypted -connection. This is strongly recommended for production deployments. See [Configuring the ENM services to use SSL](enm-with-ssl.md) for more +connection. This is strongly recommended for production deployments. See [Configuring the ENM services to use SSL]({{< relref "enm-with-ssl.md" >}}) for more information. {{< /note >}} @@ -348,7 +348,7 @@ not be configured in production environments. Even though scheduled signing of CRLs should not be configured in production environment, they should be signed manually from time to time depending on its’ `nextUpdate` property. This is to ensure an up-to-date CRL is distributed in the network before the previous one expires. Conventionally they have a lifecycle of 6 months -and are manually signed every 3 months. See [CRL Endpoint Check Tool](crl-endpoint-check-tool.md) for more information how to check +and are manually signed every 3 months. See [CRL Endpoint Check Tool]({{< relref "crl-endpoint-check-tool.md" >}}) for more information how to check CRLs’ update deadlines. {{< /note >}} @@ -1436,7 +1436,7 @@ as a map of human-readable aliases (referenced by the material management task c {{< note >}} Communication with the configured SMR service location can be configured to use SSL for a secure, encrypted -connection. This is strongly recommended for production deployments. See [Configuring the ENM services to use SSL](enm-with-ssl.md) for more +connection. This is strongly recommended for production deployments. See [Configuring the ENM services to use SSL]({{< relref "enm-with-ssl.md" >}}) for more information. {{< /note >}} @@ -1977,4 +1977,4 @@ Non CA Plugin’s configuration file must be in the same directory as the servic ### Other Sample Plugins -See [EJBCA Sample Plugin](ejbca-plugin.md) for sample open source CA implementation. +See [EJBCA Sample Plugin]({{< relref "ejbca-plugin.md" >}}) for sample open source CA implementation. diff --git a/content/en/platform/corda/1.2/cenm/tool-config-migration.md b/content/en/platform/corda/1.2/cenm/tool-config-migration.md index ca963e19bc8..fb8dc1f7cd7 100644 --- a/content/en/platform/corda/1.2/cenm/tool-config-migration.md +++ b/content/en/platform/corda/1.2/cenm/tool-config-migration.md @@ -47,7 +47,7 @@ java -jar config-migration-tool-<>.jar --config-file <> [o {{< important >}} v0.2.2 deployments of CENM require the data to be migrated to the v0.3+ DB schema to function with -the v1.0 configs generated by this tool. See [Upgrading Corda Enterprise Network Manager](upgrade-notes.md). +the v1.0 configs generated by this tool. See [Upgrading Corda Enterprise Network Manager]({{< relref "upgrade-notes.md" >}}). {{< /important >}} diff --git a/content/en/platform/corda/1.2/cenm/tools-index.md b/content/en/platform/corda/1.2/cenm/tools-index.md index 8bae2e458a5..40283ac98af 100644 --- a/content/en/platform/corda/1.2/cenm/tools-index.md +++ b/content/en/platform/corda/1.2/cenm/tools-index.md @@ -23,7 +23,7 @@ A small number of tools are available to help with setting up, running and testi -* [Public Key Infrastructure (PKI) Tool](pki-tool.md) +* [Public Key Infrastructure (PKI) Tool]({{< relref "pki-tool.md" >}}) @@ -32,7 +32,7 @@ A small number of tools are available to help with setting up, running and testi -* [Certificate Revocation Request Submission Tool](tool-crr-submission.md) +* [Certificate Revocation Request Submission Tool]({{< relref "tool-crr-submission.md" >}}) @@ -41,5 +41,5 @@ A small number of tools are available to help with setting up, running and testi -* [Config Obfuscation Tool](config-obfuscation-tool.md) -* [CRL Endpoint Check Tool](crl-endpoint-check-tool.md) +* [Config Obfuscation Tool]({{< relref "config-obfuscation-tool.md" >}}) +* [CRL Endpoint Check Tool]({{< relref "crl-endpoint-check-tool.md" >}}) diff --git a/content/en/platform/corda/1.2/cenm/troubleshooting-common-issues.md b/content/en/platform/corda/1.2/cenm/troubleshooting-common-issues.md index bd1990276b2..f5c09535644 100644 --- a/content/en/platform/corda/1.2/cenm/troubleshooting-common-issues.md +++ b/content/en/platform/corda/1.2/cenm/troubleshooting-common-issues.md @@ -73,14 +73,14 @@ Identity Manager Service. To verify that issue 1 is not the culprit - verify that the Network Map signing process is still successfully running periodically. Unless the Network Map Service is configured for testing, it should have an external signing process -configured. See the “Signing Network Map and Network Parameters” section of [Signing Services](signing-service.md). If the service is +configured. See the “Signing Network Map and Network Parameters” section of [Signing Services]({{< relref "signing-service.md" >}}). If the service is configured to run with a local signer then verify that the configured sign interval is something fairly low to ensure that updates to the network map are persisted often (e.g. 1 minute). To verify that issue 2 is not the culprit - the logs of the Network Map Service should be checked. An error such as an invalid certificate is not recoverable and should be resolved out of band with the node operator and support. If there are any communication issues with the Identity Manager then the error will be logged and communication will be -retried after a short break. See the “Identity Manager Communication” section of [Network Map Service](network-map.md) to verify that the +retried after a short break. See the “Identity Manager Communication” section of [Network Map Service]({{< relref "network-map.md" >}}) to verify that the Identity Manager communication is correctly configured for the Network Map Service. @@ -140,7 +140,7 @@ IO. **Signing process is working as intended but timeout is configured too low** The timeout for a local signer can be configured via the service’s configuration file. See -[Identity Manager Configuration Parameters](config-identity-manager-parameters.md) and [Network Map Configuration Parameters](config-network-map-parameters.md) for more information. +[Identity Manager Configuration Parameters]({{< relref "config-identity-manager-parameters.md" >}}) and [Network Map Configuration Parameters]({{< relref "config-network-map-parameters.md" >}}) for more information. ### Explanation diff --git a/content/en/platform/corda/1.2/cenm/updating-network-parameters.md b/content/en/platform/corda/1.2/cenm/updating-network-parameters.md index ab776f39294..95079e6c869 100644 --- a/content/en/platform/corda/1.2/cenm/updating-network-parameters.md +++ b/content/en/platform/corda/1.2/cenm/updating-network-parameters.md @@ -32,7 +32,7 @@ Typical update process is as follows: * Stop the Network Map Service. * Run it with `--set-network-parameters` flag, along with the network truststore related flags. See the ‘Setting -the Network Parameters’ section within the [Network Map Service](network-map.md) doc for more information. The network parameters +the Network Parameters’ section within the [Network Map Service]({{< relref "network-map.md" >}}) doc for more information. The network parameters file must have `parametersUpdate` config block: ```guess diff --git a/content/en/platform/corda/1.2/cenm/upgrade-notes.md b/content/en/platform/corda/1.2/cenm/upgrade-notes.md index 1d8f7ce429e..746d0ece827 100644 --- a/content/en/platform/corda/1.2/cenm/upgrade-notes.md +++ b/content/en/platform/corda/1.2/cenm/upgrade-notes.md @@ -21,13 +21,13 @@ This document provides instructions for upgrading your network management suite Signing Service from previous versions to the newest version. Please consult the relevant release notes of the release in question. If not specified, you may assume the versions you are currently using are still in force. -We also strongly recommend cross referencing with the [Changelog](changelog.md) to confirm changes. +We also strongly recommend cross referencing with the [Changelog]({{< relref "changelog.md" >}}) to confirm changes. ## 1.2 to 1.2.1 **Identity Manager Service** - The release includes changes to database schemas (see [Changelog](changelog.md)) for Oracle databases; + The release includes changes to database schemas (see [Changelog]({{< relref "changelog.md" >}})) for Oracle databases; new columns are created automatically upon each service start-up. Ensure the Identity Manager Service is configured to perform this migration by setting the `runMigration` property to `true`. @@ -43,7 +43,7 @@ We also strongly recommend cross referencing with the [Changelog](changelog.md) ## 1.1 to 1.2 -The release includes changes to database schemas (see [Changelog](changelog.md)); new columns are created automatically +The release includes changes to database schemas (see [Changelog]({{< relref "changelog.md" >}})); new columns are created automatically upon each service startup. Ensure the Identity Manager and Network Map are configured to perform this migration by setting `runMigration` property to `true`. @@ -83,8 +83,8 @@ This step doesn’t relate to Signing Service as it doesn’t use a database.The Ensure to stop the services before replacing the JAR files. * **Dynamic loading of HSM Jars**CENM 1.1 now supports multiple HSMs, however due to to the proprietary nature of the HSM libraries, the release does not work out of the box with these HSMs. The relevant libraries need to be provided by the user and referenced in the -configuration of the relevant component (Signing Service or PKI Tool). See the relevant docs at [Signing Services](signing-service.md) -and [Public Key Infrastructure (PKI) Tool](pki-tool.md) for more information. +configuration of the relevant component (Signing Service or PKI Tool). See the relevant docs at [Signing Services]({{< relref "signing-service.md" >}}) +and [Public Key Infrastructure (PKI) Tool]({{< relref "pki-tool.md" >}}) for more information. ## 0.3+ to 1.0 @@ -133,7 +133,7 @@ database { * **Config Files**CENM 1.0 Identity Manager and Network Map Services are not backwards compatible with 0.x Doorman and Network Map -config files. 0.2.2 and 0.3 / 0.4 config files can be migrated to 1.0 using the [Config migration tool](tool-config-migration.md). +config files. 0.2.2 and 0.3 / 0.4 config files can be migrated to 1.0 using the [Config migration tool]({{< relref "tool-config-migration.md" >}}). Using the generated 1.0 configs, the services can be upgraded by: stopping the services, swapping out the JAR and config files and restarting the services. @@ -190,7 +190,7 @@ and Revocation services cannot be known by the upgrader. {{< warning >}} If you require private network functionality or node certificate revocation checking then the configuration should be updated to include the appropriate settings. See the *Doorman & Revocation Communication* section -of the [Network Map Service](network-map.md) doc for more information. +of the [Network Map Service]({{< relref "network-map.md" >}}) doc for more information. {{< /warning >}} @@ -201,20 +201,20 @@ of the [Network Map Service](network-map.md) doc for more information. The release modifies the Network Map Signing Service to request data through the Network Map Service rather than going directly to the database. Therefore the configuration needs to change to remove the redundant DB configuration and instead adding the service endpoint. As this information cannot be known by the config upgrader, this has to be added -manually. See [Signing Services](signing-service.md) for more information on how to configure this. +manually. See [Signing Services]({{< relref "signing-service.md" >}}) for more information on how to configure this. #### The Certificate Revocation Request service requires a configuration update to specify communication the Revocation service Similarly to above, the CRR Signing Service now pulls data through the Revocation service and therefore requires a -configuration modification. See [Signing Services](signing-service.md) for more information on how to configure this. +configuration modification. See [Signing Services]({{< relref "signing-service.md" >}}) for more information on how to configure this. #### Setting the network parameters requires passing the root certificate When setting network parameters, the Network Map Service cannot validate the proposed notary certificates using the Doorman DB. Hence the trusted root certificate now needs to be passed during setting of parameters. -See the “Setting the Network Parameters” section of the [Network Map Service](network-map.md) doc for more information. +See the “Setting the Network Parameters” section of the [Network Map Service]({{< relref "network-map.md" >}}) doc for more information. ## 0.1 to 0.2.1 diff --git a/content/en/platform/corda/1.3/cenm/_index.md b/content/en/platform/corda/1.3/cenm/_index.md index ff787af291d..40a4113a931 100644 --- a/content/en/platform/corda/1.3/cenm/_index.md +++ b/content/en/platform/corda/1.3/cenm/_index.md @@ -46,7 +46,7 @@ Concepts and overview * [The workflow]({{< relref "../../../../../en/platform/corda/1.3/cenm/workflow.md" >}}) * [Databases]({{< relref "../../../../../en/platform/corda/1.3/cenm/database-set-up.md" >}}) * [Public Key Infrastructure (PKI)]({{< relref "../../../../../en/platform/corda/1.3/cenm/pki-tool.md" >}}) -* [The node](../../../../../en/platform/corda/1.3/cenm/network-map.html#node-certificate-revocation-checking) +* [The node]({{< relref "../../../../../en/platform/corda/1.3/cenm/network-map.md#node-certificate-revocation-checking" >}}) * [Sub Zones]({{< relref "../../../../../en/platform/corda/1.3/cenm/sub-zones.md" >}}) * [Network Map overview]({{< relref "../../../../../en/platform/corda/1.3/cenm/network-map-overview.md" >}}) * [Certificate Revocation List]({{< relref "../../../../../en/platform/corda/1.3/cenm/certificate-revocation.md" >}}) diff --git a/content/en/platform/corda/1.3/cenm/angel-service.md b/content/en/platform/corda/1.3/cenm/angel-service.md index 9e70378137b..ed736537c30 100644 --- a/content/en/platform/corda/1.3/cenm/angel-service.md +++ b/content/en/platform/corda/1.3/cenm/angel-service.md @@ -71,7 +71,7 @@ The Angel Service is configured via the command-line and it downloads the config 3. It writes the new configuration. 4. It starts the managed service. -If the managed service is Network Map, the Zone Service can reply with a lifecycle event (Flag Day). This is because only the Network Map Service holds the network parameters that Flag Days update. In this case, the Angel Service will automatically perform the [required steps](updating-network-parameters.md) on the managed Network Map Service. +If the managed service is Network Map, the Zone Service can reply with a lifecycle event (Flag Day). This is because only the Network Map Service holds the network parameters that Flag Days update. In this case, the Angel Service will automatically perform the [required steps]({{< relref "updating-network-parameters.md" >}}) on the managed Network Map Service. ## Service health checking via API diff --git a/content/en/platform/corda/1.3/cenm/auth-service.md b/content/en/platform/corda/1.3/cenm/auth-service.md index 9dd9d886e71..9ae53c54da2 100644 --- a/content/en/platform/corda/1.3/cenm/auth-service.md +++ b/content/en/platform/corda/1.3/cenm/auth-service.md @@ -22,9 +22,9 @@ The Auth Service is the user authentication and authorization service for CENM. * Signing Service * Network map Service (and associated network configurations and node info). -Whenever you use the [User admin tool](user-admin.md) to create new users, groups or roles, the Auth Service is updated to authenticate those users and their permissions. If you use the [CENM Command Line Interface](cenm-cli-tool.md), the Auth Service verifies your security clearance to operate on the required context of the service. +Whenever you use the [User admin tool]({{< relref "user-admin.md" >}}) to create new users, groups or roles, the Auth Service is updated to authenticate those users and their permissions. If you use the [CENM Command Line Interface]({{< relref "cenm-cli-tool.md" >}}), the Auth Service verifies your security clearance to operate on the required context of the service. -When you use any front end interface for CENM, the Auth Service is activated and updated via a front-end gateway, called the [FARM Service](gateway-service.md). +When you use any front end interface for CENM, the Auth Service is activated and updated via a front-end gateway, called the [FARM Service]({{< relref "gateway-service.md" >}}). You do not need to interact directly with the Auth Service once it has been installed and configured. To protect the integrity of this secure service, there is no direct API contact with the Auth Service - all front-end communications go via the FARM Service. @@ -70,7 +70,7 @@ Before you can configure the Auth Service, you need to prepare SSL certificates, To do this: -1. Create a SSL certificate in a `.jks` file using the [CENM PKI tool](pki-tool.md). +1. Create a SSL certificate in a `.jks` file using the [CENM PKI tool]({{< relref "pki-tool.md" >}}). 2. Generate a `jwt` signing key (RSA keypair) in a jks file with the following command line command: `keytool -genkeypair -alias mytest -keyalg RSA -keypass mypass -keystore mytest.jks -storepass mypass`. @@ -81,14 +81,14 @@ To do this: To deploy the Auth Service, you need to create a configuration file. -When you create your config file, you establish its connection to your [FARM Service](gateway-service.md). Make sure you know: +When you create your config file, you establish its connection to your [FARM Service]({{< relref "gateway-service.md" >}}). Make sure you know: * Your FARM Service ID * Your FARM Service secret In the sample below, you can see the initial configuration process: -1. [Database configuration](database-set-up.md). Add the name, address and login credentials for the SQL database that supports the Auth Service. +1. [Database configuration]({{< relref "database-set-up.md" >}}). Add the name, address and login credentials for the SQL database that supports the Auth Service. 2. JSON Web Key configuration. Set the username, password, and location of the RSA keypair store for signing. The location must be the absolute path. diff --git a/content/en/platform/corda/1.3/cenm/cenm-cli-tool.md b/content/en/platform/corda/1.3/cenm/cenm-cli-tool.md index c036ef297e6..7ee7ecc6f0e 100644 --- a/content/en/platform/corda/1.3/cenm/cenm-cli-tool.md +++ b/content/en/platform/corda/1.3/cenm/cenm-cli-tool.md @@ -43,13 +43,13 @@ To install using Docker: You have installed the Docker image with CENM CLI tool. -To get the tool ready to use from within the Docker container, check the [Kubernetes deployment guide](deployment-kubernetes.html#network-operations). +To get the tool ready to use from within the Docker container, check the [Kubernetes deployment guide]({{< relref "deployment-kubernetes.md#network-operations" >}}). ## Set up the CENM CLI Tool In order to use the CLI, you must have permission to access the CENM services you plan to use. -You should have an account that has been set up by a user administrator using the [User Admin application](user-admin.md). This account gives you the credentials, roles, and permissions you need to access CENM services via the CLI. +You should have an account that has been set up by a user administrator using the [User Admin application]({{< relref "user-admin.md" >}}). This account gives you the credentials, roles, and permissions you need to access CENM services via the CLI. For the below example, the credentials of a sample CENM user are shown: @@ -75,7 +75,7 @@ To set up a new network with the CLI: `./cenm identity-manager config set-admin-address -a=identity-manager:5053` -3. Set the Identity Manager config. This command returns a **Zone token** which you should pass to your [Angel Service](angel-service.md): +3. Set the Identity Manager config. This command returns a **Zone token** which you should pass to your [Angel Service]({{< relref "angel-service.md" >}}): `./cenm identity-manager config set -f config/identitymanager.conf --zone-token` @@ -176,7 +176,7 @@ Your interaction with CENM services through the CLI is managed by the Front-end When you log in to each session, you specify the full endpoint address of the FARM Service instance you are accessing, for example: `http://10.230.41.12`. You do this using the argument `` in the command line. This endpoint forms the **context** for your session. -Setting a context means that your session can last for the full session duration set in your [Auth Service](auth-service.md) configuration, without being interrupted by any natural time-outs in your CENM service. It also means you can switch between servers, like staging and production servers, simply by switching from one context alias to another. +Setting a context means that your session can last for the full session duration set in your [Auth Service]({{< relref "auth-service.md" >}}) configuration, without being interrupted by any natural time-outs in your CENM service. It also means you can switch between servers, like staging and production servers, simply by switching from one context alias to another. In most commands in the CLI, you can specify the context you want to use with the command option: @@ -194,7 +194,7 @@ This command allows you to change the password you use to access your CENM servi {{< attention >}} -If you have been allocated a new password by an administrator using the [User admin tool](user-admin.md), you must change it to something only you know. You must do this before you continue to use CENM services. +If you have been allocated a new password by an administrator using the [User admin tool]({{< relref "user-admin.md" >}}), you must change it to something only you know. You must do this before you continue to use CENM services. {{< /attention >}} diff --git a/content/en/platform/corda/1.3/cenm/certificate-revocation.md b/content/en/platform/corda/1.3/cenm/certificate-revocation.md index 7cabdc68338..4e3d53f9381 100644 --- a/content/en/platform/corda/1.3/cenm/certificate-revocation.md +++ b/content/en/platform/corda/1.3/cenm/certificate-revocation.md @@ -21,7 +21,7 @@ It is used by nodes when they establish a TLS connection between each other and In order to add entries to the certificate revocation list there is the certificate revocation process that resembles the one from the certificate signing request (CSR). -Note: For context on how the certificate revocation list fits into the wider context, see [Certificate Hierarchy Guide](pki-guide.md). Once added, the entries cannot be removed from the certificate revocation list. +Note: For context on how the certificate revocation list fits into the wider context, see [Certificate Hierarchy Guide]({{< relref "pki-guide.md" >}}). Once added, the entries cannot be removed from the certificate revocation list. As with CSR, the approval workflow for revocation requests is integrated with the Jira tool by default, and the submitted requests follow the same lifecycle. To support the above functionality, there are two @@ -163,6 +163,6 @@ This does not use HTTP to avoid exposing any web vulnerabilities to the signing CRLs contain a field called "next update”, after which the CRL is no longer valid. This is to ensure that an up-to-date CRL is distributed in the network before the previous one expires. Conventionally, they have a lifecycle of 6 months and are manually signed every 3 months. This kind of scheduling allows plenty of time to resolve any signing issues. -{{< note >}} See [Signing Services](signing-service.md) for details on building and signing CRLs, and especially the “updatePeriod” -configuration field which is used to determine the next update deadline. See also [CRL Endpoint Check Tool](crl-endpoint-check-tool.md) +{{< note >}} See [Signing Services]({{< relref "signing-service.md" >}}) for details on building and signing CRLs, and especially the “updatePeriod” +configuration field which is used to determine the next update deadline. See also [CRL Endpoint Check Tool]({{< relref "crl-endpoint-check-tool.md" >}}) for more information how to check CRLs’ update deadlines. {{< /note >}} diff --git a/content/en/platform/corda/1.3/cenm/config-identity-manager-parameters.md b/content/en/platform/corda/1.3/cenm/config-identity-manager-parameters.md index 38385543197..ed06046c3f4 100644 --- a/content/en/platform/corda/1.3/cenm/config-identity-manager-parameters.md +++ b/content/en/platform/corda/1.3/cenm/config-identity-manager-parameters.md @@ -26,11 +26,11 @@ The host and port on which the service runs * **database**: -See [CENM Database Configuration](config-database.md) +See [CENM Database Configuration]({{< relref "config-database.md" >}}) * **shell**: - *(Optional)* See [Shell Configuration Parameters](config-shell.md) for more information. Note that + *(Optional)* See [Shell Configuration Parameters]({{< relref "config-shell.md" >}}) for more information. Note that we are planning to deprecate the shell and the recommended path for interacting with CENM services is the admin RPC interface detailed below. @@ -80,7 +80,7 @@ It is needed as this URL is encoded in certificates issued by the Identity Manag Determines if a client should attempt to reconnect if the connection is dropped. * **ssl**: - See [SSL Settings](config-ssl.md). + See [SSL Settings]({{< relref "config-ssl.md" >}}). * **plugin**: @@ -127,7 +127,7 @@ It is needed as this URL is encoded in certificates issued by the Identity Manag A list of CRLs hosted by the Identity Manager Service, in addition to the CRLs hosted by node operators. This allows the Identity Manager Service to host the CRLs for node operators that will not host their own CRL infrastructure, at the cost of not being able to revoke TLS certificates issued by the node. * **adminListener**: A configuration property you must define in order to use the RPC API in the Identity Manager Service. - You can add `port`, `reconnect`, and `verbose`. Also, this property has an SSL field - for more information, see [SSL Settings](config-ssl.md). + You can add `port`, `reconnect`, and `verbose`. Also, this property has an SSL field - for more information, see [SSL Settings]({{< relref "config-ssl.md" >}}). * **port**: Port number to listen to for Admin RPC connections. * **verbose**: @@ -135,7 +135,7 @@ A list of CRLs hosted by the Identity Manager Service, in addition to the CRLs h * **reconnect**: *(Optional)* Determines if a client should attempt to reconnect if the connection is dropped. Defaults to `true`. * **ssl**: - See [SSL Settings](config-ssl.md) for details. + See [SSL Settings]({{< relref "config-ssl.md" >}}) for details. {{% important %}} If the `adminListener` property is present in the configuration, this means that the service must only be used via Admin RPC. In this case, the `shell` configuration property will be disabled. The `shell` and `adminListener` properties cannot be used in the configuration at the same time. @@ -144,7 +144,7 @@ If the `adminListener` property is present in the configuration, this means that * **authServiceConfig**: The admin RPC interface requires an Auth Service to verify requests, which must be configured below in a `authServiceConfig` block. Typically - this is provided automatically by the [Zone Service](zone-service.md) (via an Angel Service), + this is provided automatically by the [Zone Service]({{< relref "zone-service.md" >}}) (via an Angel Service), however the parameters are detailed below for reference: * **host**: The hostname of the Auth Service. Required unless authentication is disabled. * **port**: The port number of the Auth Service. Required unless authentication is disabled. @@ -160,7 +160,7 @@ If the `adminListener` property is present in the configuration, this means that ## Obfuscated configuration files To view the latest changes to the obfuscated configuration files, -see [Obfuscation configuration file changes](obfuscated-config-file-changes.md). +see [Obfuscation configuration file changes]({{< relref "obfuscated-config-file-changes.md" >}}). ## Redirection forbidden diff --git a/content/en/platform/corda/1.3/cenm/config-network-map-parameters.md b/content/en/platform/corda/1.3/cenm/config-network-map-parameters.md index 20599fc96c0..be64f8c7465 100644 --- a/content/en/platform/corda/1.3/cenm/config-network-map-parameters.md +++ b/content/en/platform/corda/1.3/cenm/config-network-map-parameters.md @@ -24,9 +24,9 @@ Configuration reference for the Network Map Service * **address**: The host and port on which the service runs * **database**: -See [CENM Database Configuration](config-database.md) +See [CENM Database Configuration]({{< relref "config-database.md" >}}) * **shell**: -*(Optional)* See [Shell Configuration Parameters](config-shell.md) +*(Optional)* See [Shell Configuration Parameters]({{< relref "config-shell.md" >}}) * **enmListener** (optional in a simple test deployment): Details on how the service will communicate with the rest of the CENM deployment. * **port**: @@ -36,7 +36,7 @@ Details on how the service will communicate with the rest of the CENM deployment * **reconnect**: Informs whether a client should attempt to reconnect if the connection is dropped. * **ssl**: - See [SSL Settings](config-ssl.md) + See [SSL Settings]({{< relref "config-ssl.md" >}}) * **checkRevocation** (optional, defaults to `false` if omitted): If set to true, the Network Map will check with the Identity Manager’s revocation service to find out if the registering node is revoked. * **pollingInterval**: @@ -48,7 +48,7 @@ Details where the issuance service is on the network * **port**: The port that its `enmListener` is bound to. * **ssl**: - See [SSL Settings](config-ssl.md) for details. + See [SSL Settings]({{< relref "config-ssl.md" >}}) for details. * **revocation** (optional in a simple test deployment): Details where the revocation service is on the network * **host**: @@ -56,7 +56,7 @@ Details where the revocation service is on the network * **port**: The port that its `enmListener` is bound to. * **ssl**: - See [SSL Settings](config-ssl.md) for details. + See [SSL Settings]({{< relref "config-ssl.md" >}}) for details. * **localSigner**: *(Optional)* Configuration of the local signer for the Network Map Service. Useful for debugging, testing or when HSM support is not available. * **keyStore**: @@ -104,7 +104,7 @@ version of Corda that does not support the new PKI structure (arbitrary length c * **adminListener**: To use the RPC API in the Identity Manager Service, you must define a configuration property called `adminListener`. - You can add `port`, `reconnect`, and `verbose`. Also, this property has an SSL field - see [SSL Settings](config-ssl.md) for more information. + You can add `port`, `reconnect`, and `verbose`. Also, this property has an SSL field - see [SSL Settings]({{< relref "config-ssl.md" >}}) for more information. * **port**: Port number to listen to for Admin RPC connections. * **verbose**: @@ -112,7 +112,7 @@ version of Corda that does not support the new PKI structure (arbitrary length c * **reconnect**: *(Optional)* Determines if a client should attempt to reconnect if the connection is dropped. Defaults to `true`. * **ssl**: - See [SSL Settings](config-ssl.md) for details. + See [SSL Settings]({{< relref "config-ssl.md" >}}) for details. {{% important %}} If the `adminListener` property is present in the configuration, this means that the service must only be used via Admin RPC. In this case, the `shell` configuration property will be disabled. The `shell` and `adminListener` properties cannot be used in the configuration at the same time. @@ -121,7 +121,7 @@ If the `adminListener` property is present in the configuration, this means that * **authServiceConfig**: The admin RPC interface requires an Auth Service to verify requests, which must be configured below in a `authServiceConfig` block. Typically - this is provided automatically by the [Zone Service](zone-service.md) (via an Angel Service), + this is provided automatically by the [Zone Service]({{< relref "zone-service.md" >}}) (via an Angel Service), however the parameters are detailed below for reference: * **host**: The hostname of the Auth Service. Required unless authentication is disabled. * **port**: The port number of the Auth Service. Required unless authentication is disabled. diff --git a/content/en/platform/corda/1.3/cenm/corda-networks.md b/content/en/platform/corda/1.3/cenm/corda-networks.md index a0c796ddcaf..58ed87919c9 100644 --- a/content/en/platform/corda/1.3/cenm/corda-networks.md +++ b/content/en/platform/corda/1.3/cenm/corda-networks.md @@ -35,7 +35,7 @@ not the recommended deployment model outside of a testing setup.{{< /note >}} this service should be deployed (for more details on this see the Signing Service documentation), in brief, it is the intention that, unlike the Identity Manager, the signer is completely isolated from external communication. It only addresses a data source it shares with the Identity Manager. This ensure no hostile entity can penetrate the system -and force the signing of a certificate. See [Signing Services](signing-service.md) +and force the signing of a certificate. See [Signing Services]({{< relref "signing-service.md" >}}) * The signed certificates are recognised by the Identity Manager and returned to the requesting node (Nodes poll the Identity Manager periodically to see if their signature request has been fulfilled). @@ -80,7 +80,7 @@ one sub zone {{< /important >}} -For more information, see [Sub Zones](sub-zones.md) +For more information, see [Sub Zones]({{< relref "sub-zones.md" >}}) ### Operating a Segregated Sub Zone diff --git a/content/en/platform/corda/1.3/cenm/database-set-up.md b/content/en/platform/corda/1.3/cenm/database-set-up.md index 5b2332236e5..ecb5eba75b1 100644 --- a/content/en/platform/corda/1.3/cenm/database-set-up.md +++ b/content/en/platform/corda/1.3/cenm/database-set-up.md @@ -18,20 +18,20 @@ title: CENM Databases There are currently four types of CENM database schemas: -* The **Identity Manager** database schema is used by the [Identity Manager Service](identity-manager.md). It contains information relating to: +* The **Identity Manager** database schema is used by the [Identity Manager Service]({{< relref "identity-manager.md" >}}). It contains information relating to: * Certificate signing requests of nodes wanting to join the network. * Requests to revocation of nodes on the network. -* The **Network Map** database schema is used by the [Network Map Service](network-map.md). It contains information relating to: +* The **Network Map** database schema is used by the [Network Map Service]({{< relref "network-map.md" >}}). It contains information relating to: * The current participants on the network. * The current network parameters. * Any pending network parameter updates. -* The **Zone** database schema is used by the [Zone Service](zone-service.md). It contains information relating to: +* The **Zone** database schema is used by the [Zone Service]({{< relref "zone-service.md" >}}). It contains information relating to: * External addresses of services on the network. * Configurations of other services on the network. -* The **Auth** database schema is used by the [Auth Service](auth-service.md) to store RBAC data (users, permissions, groups). +* The **Auth** database schema is used by the [Auth Service]({{< relref "auth-service.md" >}}) to store RBAC data (users, permissions, groups). The services **must** use separate database schemas (either in the same database instance or in completely separate instances) due to the way the migrations are defined. If you try and run an Identity Manager Service, a Network Map Service, a Zone Service, or an Auth Service that shares the same database schema, it will result in errors. @@ -407,7 +407,7 @@ database = { } ``` -`runMigration` is set to `false` because the restricted CENM service instance database user does not have permissions to alter a database schema. See [CENM Database Configuration](config-database.md) for a complete list of database-specific properties. +`runMigration` is set to `false` because the restricted CENM service instance database user does not have permissions to alter a database schema. See [CENM Database Configuration]({{< relref "config-database.md" >}}) for a complete list of database-specific properties. {{< note >}} The CENM distribution does not include any JDBC drivers with the exception of the H2 driver. diff --git a/content/en/platform/corda/1.3/cenm/deployment-kubernetes-auth.md b/content/en/platform/corda/1.3/cenm/deployment-kubernetes-auth.md index 30dfc74c92c..653a33dc1cd 100644 --- a/content/en/platform/corda/1.3/cenm/deployment-kubernetes-auth.md +++ b/content/en/platform/corda/1.3/cenm/deployment-kubernetes-auth.md @@ -12,7 +12,7 @@ weight: 20 # CENM Auth Service Helm Chart -This Helm chart is to configure, deploy, and run the [CENM Auth Service](auth-service.md) on Kubernetes. +This Helm chart is to configure, deploy, and run the [CENM Auth Service]({{< relref "auth-service.md" >}}) on Kubernetes. ## Example usage @@ -49,4 +49,4 @@ helm install cenm-auth auth --set prefix=cenm --set acceptLicense=Y --set volume | `sleepTimeAfterError` | Sleep time (in seconds) after an error occurred | `120` | | `logsContainersEnabled` | Enable container displaying live logs | `true` {{< /table >}} -For additional information on database connection details refer to the official documentation: [database documentation](config-database.md). +For additional information on database connection details refer to the official documentation: [database documentation]({{< relref "config-database.md" >}}). diff --git a/content/en/platform/corda/1.3/cenm/deployment-kubernetes-farm.md b/content/en/platform/corda/1.3/cenm/deployment-kubernetes-farm.md index 7cccac8d815..e9e087c7aad 100644 --- a/content/en/platform/corda/1.3/cenm/deployment-kubernetes-farm.md +++ b/content/en/platform/corda/1.3/cenm/deployment-kubernetes-farm.md @@ -12,7 +12,7 @@ weight: 60 # CENM FARM Service Helm Chart -This Helm chart is to configure, deploy, and run the [CENM FARM Service](gateway-service.md) on Kubernetes. +This Helm chart is to configure, deploy, and run the [CENM FARM Service]({{< relref "gateway-service.md" >}}) on Kubernetes. ## Example usage @@ -44,4 +44,4 @@ helm install cenm-farm farm --set prefix=cenm --set acceptLicense=Y --set volume | `zonePort` | Zone Service port | `12345` | | `logsContainersEnabled` | Enable container displaying live logs | `true` {{< /table >}} -For additional information on database connection details refer to the official documentation: [database documentation](config-database.md). +For additional information on database connection details refer to the official documentation: [database documentation]({{< relref "config-database.md" >}}). diff --git a/content/en/platform/corda/1.3/cenm/deployment-kubernetes-idman.md b/content/en/platform/corda/1.3/cenm/deployment-kubernetes-idman.md index d3366616161..39e1ea3ddbd 100644 --- a/content/en/platform/corda/1.3/cenm/deployment-kubernetes-idman.md +++ b/content/en/platform/corda/1.3/cenm/deployment-kubernetes-idman.md @@ -12,11 +12,11 @@ weight: 100 # CENM Identity Manager Helm Chart -This Helm chart is to configure, deploy, and run the CENM [Identity Manager Service](identity-manager.md) on Kubernetes. +This Helm chart is to configure, deploy, and run the CENM [Identity Manager Service]({{< relref "identity-manager.md" >}}) on Kubernetes. ## Example usage -The example below shows a command that triggers the Helm chart for the [Zone Service](zone-service.md): +The example below shows a command that triggers the Helm chart for the [Zone Service]({{< relref "zone-service.md" >}}): ```bash helm install cenm-idman idman --set prefix=cenm --set acceptLicense=Y @@ -60,4 +60,4 @@ helm install cenm-idman idman --set idmanPublicIP=X.X.X.X --set prefix=cenm --se | `logsContainersEnabled` | Defines whether the container displaying live logs is enabled or disabled | `true` | {{< /table >}} -For additional information on database connection details refer to the official documentation: [database documentation](config-database.md). +For additional information on database connection details refer to the official documentation: [database documentation]({{< relref "config-database.md" >}}). diff --git a/content/en/platform/corda/1.3/cenm/deployment-kubernetes-nmap.md b/content/en/platform/corda/1.3/cenm/deployment-kubernetes-nmap.md index 7275011b32c..1bebfef4112 100644 --- a/content/en/platform/corda/1.3/cenm/deployment-kubernetes-nmap.md +++ b/content/en/platform/corda/1.3/cenm/deployment-kubernetes-nmap.md @@ -12,7 +12,7 @@ weight: 200 # CENM Network Map Service Helm Chart -This Helm chart is to configure, deploy, and run the [CENM Network Map Service](network-map.md) on Kubernetes. +This Helm chart is to configure, deploy, and run the [CENM Network Map Service]({{< relref "network-map.md" >}}) on Kubernetes. ## Example usage @@ -61,4 +61,4 @@ helm install nmap nmap --set shell.password="superDifficultPassword" | `logsContainersEnabled` | Enable container displaying live logs | `true` {{< /table >}} -For additional information on database connection details refer to the official documentation: [database documentation](config-database.md). +For additional information on database connection details refer to the official documentation: [database documentation]({{< relref "config-database.md" >}}). diff --git a/content/en/platform/corda/1.3/cenm/deployment-kubernetes-signer.md b/content/en/platform/corda/1.3/cenm/deployment-kubernetes-signer.md index c74211ff380..6ee76b31cec 100644 --- a/content/en/platform/corda/1.3/cenm/deployment-kubernetes-signer.md +++ b/content/en/platform/corda/1.3/cenm/deployment-kubernetes-signer.md @@ -12,7 +12,7 @@ weight: 400 # CENM Signing Service Helm Chart -This Helm chart is to configure, deploy, and run the [CENM Signing Service](signing-service.md) on Kubernetes. +This Helm chart is to configure, deploy, and run the [CENM Signing Service]({{< relref "signing-service.md" >}}) on Kubernetes. As the initial step this chart runs automatically PKI tool which creates and stores certificates necessary for correct Corda Network operation. By default, the certificates have sample X.500 subject names (for example, the Identity Manager Service certificate has the subject name “CN=Test Identity Manager Service Certificate, OU=HQ, O=HoldCo LLC, L=New York, C=US”). The subject name can be set by configuration options starting with `pki.certificates.` prefix. @@ -21,8 +21,8 @@ Passwords to the security certificates keys and keystores cannot be configurable For more information about PKI Tool and Certificate Hierarchy refer to: -* [Certificate Hierarchy Guide](pki-guide.md) -* [PKI Tool](pki-tool.md) +* [Certificate Hierarchy Guide]({{< relref "pki-guide.md" >}}) +* [PKI Tool]({{< relref "pki-tool.md" >}}) ## Example usage diff --git a/content/en/platform/corda/1.3/cenm/deployment-kubernetes-zone.md b/content/en/platform/corda/1.3/cenm/deployment-kubernetes-zone.md index d19ff32264b..3813456ede2 100644 --- a/content/en/platform/corda/1.3/cenm/deployment-kubernetes-zone.md +++ b/content/en/platform/corda/1.3/cenm/deployment-kubernetes-zone.md @@ -12,7 +12,7 @@ weight: 500 # CENM Zone Service Helm Chart -This Helm chart is to configure, deploy, and run the [CENM Zone Service](zone-service.md) on Kubernetes. +This Helm chart is to configure, deploy, and run the [CENM Zone Service]({{< relref "zone-service.md" >}}) on Kubernetes. ## Example usage @@ -54,4 +54,4 @@ helm install cenm-zone auth --set idmanPublicIP=X.X.X.X --set prefix=cenm --set | `logsContainersEnabled` | Enable container displaying live logs | `true` {{< /table >}} -For additional information on database connection details, refer to the official documentation: [database documentation](config-database.md). +For additional information on database connection details, refer to the official documentation: [database documentation]({{< relref "config-database.md" >}}). diff --git a/content/en/platform/corda/1.3/cenm/deployment-kubernetes.md b/content/en/platform/corda/1.3/cenm/deployment-kubernetes.md index 7104487d7f4..a090eb86288 100644 --- a/content/en/platform/corda/1.3/cenm/deployment-kubernetes.md +++ b/content/en/platform/corda/1.3/cenm/deployment-kubernetes.md @@ -65,7 +65,7 @@ Recommended production specification for CENM components running on separate VMs ### Deployment overview The provided deployment runs all CENM services run inside a single, dedicated Kubernetes namespace (default name:`cenm`). -Each service runs in its own dedicated Kubernetes pod, with the exception of the [Angel Service](angel-service.md), which runs in the same pod as its managed service. +Each service runs in its own dedicated Kubernetes pod, with the exception of the [Angel Service]({{< relref "angel-service.md" >}}), which runs in the same pod as its managed service. {{< note >}} Naturally, the following command will not show a dedicated Angel Service pod: @@ -77,7 +77,7 @@ The Angel Service and its managed service must both be healthy in order for the The CENM network is bootstrapped with PKI certificates, and sample X.500 subject names are provided as defaults (for example, the Identity Manager Service certificate subject is “CN=Test Identity Manager Service Certificate, OU=HQ, O=HoldCo LLC, L=New York, C=US”). -These can be configured in the [Signing Service Helm chart](deployment-kubernetes-signer.md). +These can be configured in the [Signing Service Helm chart]({{< relref "deployment-kubernetes-signer.md" >}}). There are two ways of bootstrapping a new CENM environment: @@ -116,7 +116,7 @@ The deployment steps are given below: - Install [Docker](https://www.docker.com/get-started). Docker is required to run the CENM CLI tool. -- Download the Docker image with CENM [Command-Line Interface (CLI) tool](cenm-cli-tool.md) so you can manage CENM services: +- Download the Docker image with CENM [Command-Line Interface (CLI) tool]({{< relref "cenm-cli-tool.md" >}}) so you can manage CENM services: ```bash docker pull corda/enterprise-cenm-cli:1.3.5-zulu-openjdk8u242 @@ -209,7 +209,7 @@ cd k8s/helm ## Network operations -Use the CENM [Command Line Interface (CLI) Tool](cenm-cli-tool.md) to access the [FARM Service](gateway-service.md) from your local machine. +Use the CENM [Command Line Interface (CLI) Tool]({{< relref "cenm-cli-tool.md" >}}) to access the [FARM Service]({{< relref "gateway-service.md" >}}) from your local machine. To start CENM CLI Tool, run Docker command starting Docker container with the tool: @@ -233,7 +233,7 @@ You can now use `cemn` commands from within the running Docker container: ./cenm context login -s -u -p http://:8080 ``` -The [FARM Service](gateway-service.md) is a gateway between the [Auth Service](auth-service.md) and front end services in CENM. It allows you to perform all network operations on the [Identity Manager Service](identity-manager.md), the [Network Map Service](network-map.md), and the [Signing Service](signing-service.md). +The [FARM Service]({{< relref "gateway-service.md" >}}) is a gateway between the [Auth Service]({{< relref "auth-service.md" >}}) and front end services in CENM. It allows you to perform all network operations on the [Identity Manager Service]({{< relref "identity-manager.md" >}}), the [Network Map Service]({{< relref "network-map.md" >}}), and the [Signing Service]({{< relref "signing-service.md" >}}). The IP address is dynamically allocated for each deployment and can be found with `kubectl get svc`. Use the following command to ensure that you are pointing at the correct namespace: @@ -358,7 +358,7 @@ database { ### Update network parameters -Use the CENM [Command-Line (CLI) tool](cenm-cli-tool.md) to run commands to update the network parameters. +Use the CENM [Command-Line (CLI) tool]({{< relref "cenm-cli-tool.md" >}}) to run commands to update the network parameters. See the CENM documentation for more information about the list of available [network parameters]({{< relref "./config-network-parameters.md" >}}) and instructions on [updating network parameters]({{< relref "./updating-network-parameters.md" >}}). @@ -373,7 +373,7 @@ This operation is scheduled to take place at regular intervals (by default, once ### Signing Service configuration -The Signing Service is not managed by the [Angel Service](angel-service.md) in this deployment, therefore any CENM Command-Line Interface (CLI) tool commands trying to change the Signing Service configuration will take no effect. +The Signing Service is not managed by the [Angel Service]({{< relref "angel-service.md" >}}) in this deployment, therefore any CENM Command-Line Interface (CLI) tool commands trying to change the Signing Service configuration will take no effect. To change the Singing Service configuration, you must log in to a Kubernetes pod, update the configuration file, and restart the service. ## Delete Network @@ -457,13 +457,13 @@ You must modify the following values in the `values.yaml` file: There are a number of settings provided on each Helm chart, which allow easy customisation of common options. Each CENM service has its own dedicated page with more detailed documentation: -* [Auth Service](deployment-kubernetes-auth.md) -* [FARM Service](deployment-kubernetes-farm.md) -* [Identity Manager Service](deployment-kubernetes-idman.md) -* [Network Map Service](deployment-kubernetes-nmap.md) -* [Corda Notary](deployment-kubernetes-notary.md) -* [Signing Service](deployment-kubernetes-signer.md) -* [Zone Service](deployment-kubernetes-zone.md) +* [Auth Service]({{< relref "deployment-kubernetes-auth.md" >}}) +* [FARM Service]({{< relref "deployment-kubernetes-farm.md" >}}) +* [Identity Manager Service]({{< relref "deployment-kubernetes-idman.md" >}}) +* [Network Map Service]({{< relref "deployment-kubernetes-nmap.md" >}}) +* [Corda Notary]({{< relref "deployment-kubernetes-notary.md" >}}) +* [Signing Service]({{< relref "deployment-kubernetes-signer.md" >}}) +* [Zone Service]({{< relref "deployment-kubernetes-zone.md" >}}) ### Overriding Service Configuration @@ -493,7 +493,7 @@ helm install cenm-database bitnami/postgresql Follow the instructions displayed by the script output to connect to the database server via `psql`. You can create a separate database server for each CENM service by running the Helm script multiple times with different names -and then setting up the database user/schema, following the instructions in the [CENM database setup](database-set-up.md) section. +and then setting up the database user/schema, following the instructions in the [CENM database setup]({{< relref "database-set-up.md" >}}) section. Alternatively, you can create several databases inside the single PostgresSQL server you have just deployed, by running the following DDL commands: diff --git a/content/en/platform/corda/1.3/cenm/enm-components.md b/content/en/platform/corda/1.3/cenm/enm-components.md index 80b15768dab..7a0679b284c 100644 --- a/content/en/platform/corda/1.3/cenm/enm-components.md +++ b/content/en/platform/corda/1.3/cenm/enm-components.md @@ -107,7 +107,7 @@ environments: * Postgres * SQL Server -For details of supported versions and configuration, see [CENM Databases](database-set-up.md). +For details of supported versions and configuration, see [CENM Databases]({{< relref "database-set-up.md" >}}). # Public Key Infrastructure (PKI) @@ -119,7 +119,7 @@ By design, they only have the ability to talk *to* the other CENM components, th In addition, signing a CRR or CSR, and potentially the Network Parameters, *should* require a human to interact with the HSM via some manual authentication mechanism. -See [Certificate Hierarchy Guide](pki-guide.md) for a detailed guide to PKI. +See [Certificate Hierarchy Guide]({{< relref "pki-guide.md" >}}) for a detailed guide to PKI. # The Node diff --git a/content/en/platform/corda/1.3/cenm/enm-with-ssl.md b/content/en/platform/corda/1.3/cenm/enm-with-ssl.md index 9177280a5f2..f2c4c4f1daa 100644 --- a/content/en/platform/corda/1.3/cenm/enm-with-ssl.md +++ b/content/en/platform/corda/1.3/cenm/enm-with-ssl.md @@ -82,7 +82,7 @@ acting as clients of the network. ### SSL Certificate Configuring All components should be configured to use SSL with the following configuration block. More details can be found in -[Identity Manager Configuration Parameters](config-identity-manager-parameters.md) and [Network Map Configuration Parameters](config-network-map-parameters.md). +[Identity Manager Configuration Parameters]({{< relref "config-identity-manager-parameters.md" >}}) and [Network Map Configuration Parameters]({{< relref "config-network-map-parameters.md" >}}). ```docker ssl = { diff --git a/content/en/platform/corda/1.3/cenm/gateway-service.md b/content/en/platform/corda/1.3/cenm/gateway-service.md index deb33bf94a8..3d25313c403 100644 --- a/content/en/platform/corda/1.3/cenm/gateway-service.md +++ b/content/en/platform/corda/1.3/cenm/gateway-service.md @@ -17,9 +17,9 @@ title: FARM Service # FARM Service -The Front-end Applications for Remote Management (FARM) Service provides a gateway between front-end CENM service interfaces, and the [Auth Service](auth-service.md) that underpins authentication and authorisation in CENM services. +The Front-end Applications for Remote Management (FARM) Service provides a gateway between front-end CENM service interfaces, and the [Auth Service]({{< relref "auth-service.md" >}}) that underpins authentication and authorisation in CENM services. -Once installed and configured, users can connect with the FARM Service via the [CENM CLI Tool](cenm-cli-tool.md) to manage CENM service tasks. Administrators can use the FARM Service address plus `/admin` to access the (CENM User Admin Tool)[user-admin] via a web browser. +Once installed and configured, users can connect with the FARM Service via the [CENM CLI Tool]({{< relref "cenm-cli-tool.md" >}}) to manage CENM service tasks. Administrators can use the FARM Service address plus `/admin` to access the (CENM User Admin Tool)[user-admin] via a web browser. {{< note >}} As a gateway service, FARM does not need its own database - so there is no database configuration required when you are setting up. @@ -37,9 +37,9 @@ When you configure the FARM Service, you need to: 1. Specify the endpoint where the Auth Service is exposed - this must match the IP or host name of the machine/VM/container and the port that is configured in the Auth Service config file. -2. Specify the SSL configuration for connecting to the Auth Service. You can do this using the [PKI tool](pki-tool.md). +2. Specify the SSL configuration for connecting to the Auth Service. You can do this using the [PKI tool]({{< relref "pki-tool.md" >}}). -3. Your authentication credentials, as specified in your [Auth Service configuration](auth-service.md). +3. Your authentication credentials, as specified in your [Auth Service configuration]({{< relref "auth-service.md" >}}). 4. Your Zone Service address. diff --git a/content/en/platform/corda/1.3/cenm/identity-manager.md b/content/en/platform/corda/1.3/cenm/identity-manager.md index d8e27b8e002..47100a54b9a 100644 --- a/content/en/platform/corda/1.3/cenm/identity-manager.md +++ b/content/en/platform/corda/1.3/cenm/identity-manager.md @@ -82,7 +82,7 @@ The main elements that need to be configured for the Identity Manager are: {{< note >}} -See [Identity Manager Configuration Parameters](config-identity-manager-parameters.md) for a detailed explanation about each possible parameter. +See [Identity Manager Configuration Parameters]({{< relref "config-identity-manager-parameters.md" >}}) for a detailed explanation about each possible parameter. {{< /note >}} ### Address @@ -138,7 +138,7 @@ database { {{< note >}} Due to the way the migrations are defined, if the Identity Manager and Network Map Services are using the same database instance then they *must* use separate database schemas. For more information regarding the supported databases -along with the schema see [CENM Databases](database-set-up.md). +along with the schema see [CENM Databases]({{< relref "database-set-up.md" >}}). {{< /note >}} @@ -184,7 +184,7 @@ database { ### Embedded shell (optional) -See [Shell Configuration](shell.html#shell-configuration) for more information on how to configure the shell. +See [Shell Configuration]({{< relref "shell.md#shell-configuration" >}}) for more information on how to configure the shell. ### Issuance Workflow @@ -267,12 +267,12 @@ workflows { } ``` -See [Workflow](workflow.md) for more information. +See [Workflow]({{< relref "workflow.md" >}}) for more information. ###### Jira Project Configuration -See [Jira Set-Up](jira-setup.md) for more information about how to configure a Jira project for CSR approval. +See [Jira Set-Up]({{< relref "jira-setup.md" >}}) for more information about how to configure a Jira project for CSR approval. #### CSR Signing Mechanism @@ -290,11 +290,11 @@ approval mechanism above, this can be achieved via one of two mechanisms: The local Signing Service is recommended for testing and toy environments. Given a local key store containing the relevant signing keys, it provides the functionality to automatically sign all approved CSRs on a configured schedule. No human interaction is needed and the credentials for the key stores have to be provided upfront. The service is an -integrated signer that is a cut-down version of the standalone [Signing Services](signing-service.md) and provides no HSM integration or +integrated signer that is a cut-down version of the standalone [Signing Services]({{< relref "signing-service.md" >}}) and provides no HSM integration or ability to manually verify changes. It is strongly recommended against using this for production environments. In order for the local signer to function, it needs to be able to access Identity Manager’s certificate and keypair -which should have been previously generated (see [Certificate Hierarchy Guide](pki-guide.md) for more information). The local signer uses local +which should have been previously generated (see [Certificate Hierarchy Guide]({{< relref "pki-guide.md" >}}) for more information). The local signer uses local key stores which should include the necessary signing keys along with their full certificate chains. To enable the local signer, the top level `localSigner` configuration block should be added to the configuration file: @@ -317,7 +317,7 @@ signing any CSR requests along with the full certificate chain back to the root ##### External Signing Service -The production grade signing mechanism is the external [Signing Services](signing-service.md). This has all the functionality of the +The production grade signing mechanism is the external [Signing Services]({{< relref "signing-service.md" >}}). This has all the functionality of the integrated local signer as well as HSM integration and the ability for a user to interactively verify and sign incoming CSRs. It should be used in all production environments where maximum security and validation checks are required. @@ -357,7 +357,7 @@ This parameter can be omitted if desired, in which case it will default to port {{< /note >}} {{< note >}} -All inter-service communication can be configured with SSL support. See [Configuring the CENM services to use SSL](enm-with-ssl.md). +All inter-service communication can be configured with SSL support. See [Configuring the CENM services to use SSL]({{< relref "enm-with-ssl.md" >}}). {{< /note >}} @@ -479,7 +479,7 @@ workflows { } ``` -See [Workflow](workflow.md) for more information. +See [Workflow]({{< relref "workflow.md" >}}) for more information. #### CRR Signing Mechanism @@ -501,7 +501,7 @@ Identity Manager. That is, the same key used for signing approved CSRs will be u ##### External Signing Service -Also similarly to CSR signing, the production grade signing mechanism for CRRs is the external [Signing Services](signing-service.md). +Also similarly to CSR signing, the production grade signing mechanism for CRRs is the external [Signing Services]({{< relref "signing-service.md" >}}). This has all the functionality of the integrated local signer as well as HSM integration and the ability for a user to interactively verify and sign incoming CRRs. It should be used in all production environments where maximum security and validation checks are required. @@ -537,7 +537,7 @@ This parameter can be omitted if desired, in which case it will default to port {{< /note >}} {{< note >}} -All inter-service communication can be configured with SSL support. See [Configuring the CENM services to use SSL](enm-with-ssl.md). +All inter-service communication can be configured with SSL support. See [Configuring the CENM services to use SSL]({{< relref "enm-with-ssl.md" >}}). {{< /note >}} @@ -868,7 +868,7 @@ shell { The example below shows a more production-like configuration of the Identity Manager. It is configured with an Issuance and Revocation workflow, using Jira workflows for CSR/CRR approvals, no local signer, and using SSL for secure communication between CENM services. In this scenario, all approved requests would be signed using an external signing -service (see [Signing Services](signing-service.md)). +service (see [Signing Services]({{< relref "signing-service.md" >}})). ```docker address = "localhost:10000" diff --git a/content/en/platform/corda/1.3/cenm/network-map-overview.md b/content/en/platform/corda/1.3/cenm/network-map-overview.md index 95a2cdeebfe..7c851d1fdc5 100644 --- a/content/en/platform/corda/1.3/cenm/network-map-overview.md +++ b/content/en/platform/corda/1.3/cenm/network-map-overview.md @@ -188,8 +188,8 @@ parameters change. * **whitelistedContractImplementations**: List of whitelisted versions of contract code. For each contract class there is a list of hashes of the approved CorDapp JAR versions containing that contract. Read -more about *contract constraints* in the [contract constraints doc](https://docs.corda.net/api-contract-constraints.html). See -[Contract Whitelist Generation](contract-whitelisting.md) for how to configure this in the network parameters +more about *contract constraints* in the [contract constraints doc](https://docs.r3.com/api-contract-constraints.html). See +[Contract Whitelist Generation]({{< relref "contract-whitelisting.md" >}}) for how to configure this in the network parameters configuration file. diff --git a/content/en/platform/corda/1.3/cenm/network-map.md b/content/en/platform/corda/1.3/cenm/network-map.md index ee153b2c85a..c11bf5e634c 100644 --- a/content/en/platform/corda/1.3/cenm/network-map.md +++ b/content/en/platform/corda/1.3/cenm/network-map.md @@ -22,7 +22,7 @@ title: Network Map Service The Network Map Service acts as a directory for all participants on the network. It is responsible for recording essential information of each participant such as connection address and available services. See -[Network Map Overview](network-map-overview.md) for an in-depth explanation. +[Network Map Overview]({{< relref "network-map-overview.md" >}}) for an in-depth explanation. ## Running The Network Map Service @@ -115,7 +115,7 @@ Similar to the Identity Manager the main elements that need to be configured for * [Admin RPC Interface](#admin-rpc-interface) {{< note >}} -See [Network Map Configuration Parameters](config-network-map-parameters.md) for a detailed explanation about each possible parameter. +See [Network Map Configuration Parameters]({{< relref "config-network-map-parameters.md" >}}) for a detailed explanation about each possible parameter. {{< /note >}} ### Address @@ -171,7 +171,7 @@ database { {{< note >}} Due to the way the migrations are defined, if the Identity Manager and Network Map Services are using the same database instance then they *must* use separate database schemas. For more information regarding the supported databases -along with the schema see [CENM Databases](database-set-up.md). +along with the schema see [CENM Databases]({{< relref "database-set-up.md" >}}). {{< /note >}} @@ -219,7 +219,7 @@ database { ### Embedded shell (optional) -See [Shell Configuration](shell.html#shell-configuration) for more information on how to configure the shell. +See [Shell Configuration]({{< relref "shell.md#shell-configuration" >}}) for more information on how to configure the shell. ### Network Data Signing Mechanism @@ -239,11 +239,11 @@ The local Signing Service is recommended for testing and toy environments. Given relevant signing keys, it provides the functionality to automatically sign all approved Network Map and Parameter updates on a configured schedule. No human interaction is needed and the credentials for the key stores have to be provided upfront. The service is an integrated signer that is a cut-down version of the standalone -[Signing Services](signing-service.md) and provides no HSM integration or ability to manually verify changes. It is strongly recommended +[Signing Services]({{< relref "signing-service.md" >}}) and provides no HSM integration or ability to manually verify changes. It is strongly recommended against using this for production environments. In order for the local signer to function, it needs to be able to access Network Map’s certificate and keypair -which should have been previously generated (see [Certificate Hierarchy Guide](pki-guide.md) for more information). The local signer uses local +which should have been previously generated (see [Certificate Hierarchy Guide]({{< relref "pki-guide.md" >}}) for more information). The local signer uses local key stores which should include the necessary signing keys along with their full certificate chains. To enable the local signer, the top level `localSigner` configuration block should be added to the configuration file: @@ -266,7 +266,7 @@ signing any network map or parameter changes along with the full certificate cha #### External Signing Service -The production grade signing mechanism is the external [Signing Services](signing-service.md). This has all the functionality of the +The production grade signing mechanism is the external [Signing Services]({{< relref "signing-service.md" >}}). This has all the functionality of the integrated local signer as well as HSM integration and the ability for a user to interactively verify and sign incoming network map or parameter changes. It should be used in all production environments where maximum security and validation checks are required. @@ -295,7 +295,7 @@ pollingInterval = 600000 ### Node Certificate Revocation Checking -In cases when the certificate revocation list infrastructure (See [Certificate Revocation List](certificate-revocation.md) for more information) +In cases when the certificate revocation list infrastructure (See [Certificate Revocation List]({{< relref "certificate-revocation.md" >}}) for more information) is provided, the additional validation for the node’s certificates can be enabled in the Network Map Service. This is achieved via the top-level `checkRevocation` flag set in the configuration file. This ensures that any node within the Network Map has a valid, trusted certificate. @@ -340,7 +340,7 @@ The `reconnect` parameter is optional - it will default to `reconnect = true` if {{< /note >}} {{< note >}} -All inter-service communication can be configured with SSL support. See [Configuring the CENM services to use SSL](enm-with-ssl.md). +All inter-service communication can be configured with SSL support. See [Configuring the CENM services to use SSL]({{< relref "enm-with-ssl.md" >}}). {{< /note >}} @@ -427,10 +427,10 @@ revocation { The `host` should correspond to the host part of the `address` value in the Identity Manager configuration. The `port` parameter for each service should correspond with the `port` value within the `enmListener` configuration block in -the service’s configuration. See [Network Map Configuration Parameters](config-network-map-parameters.md) for more information. +the service’s configuration. See [Network Map Configuration Parameters]({{< relref "config-network-map-parameters.md" >}}) for more information. {{< note >}} -All inter-service communication can be configured with SSL support. See [Configuring the CENM services to use SSL](enm-with-ssl.md) +All inter-service communication can be configured with SSL support. See [Configuring the CENM services to use SSL]({{< relref "enm-with-ssl.md" >}}) {{< /note >}} @@ -589,7 +589,7 @@ useful especially when dealing with node’s deployment in environments with IP ## Obfuscated configuration files -To view the latest changes to the obfuscated configuration files, see [Obfuscation configuration file changes](obfuscated-config-file-changes.md). +To view the latest changes to the obfuscated configuration files, see [Obfuscation configuration file changes]({{< relref "obfuscated-config-file-changes.md" >}}). {{< note >}} You should not obfuscate the Network Parameters configuration file as it is not yet supported. diff --git a/content/en/platform/corda/1.3/cenm/pki-guide.md b/content/en/platform/corda/1.3/cenm/pki-guide.md index ba8ca4b9093..81771a5083d 100644 --- a/content/en/platform/corda/1.3/cenm/pki-guide.md +++ b/content/en/platform/corda/1.3/cenm/pki-guide.md @@ -125,9 +125,9 @@ Certificate revocation is typically required if a certificate was incorrectly is **What is the recommended configuration for the CRL?* You should use a High Availability deployment in order to avoid any impact caused by temporary downtimes. -See [Identity Manager Service](identity-manager.md) for an example configuration of such a deployment. +See [Identity Manager Service]({{< relref "identity-manager.md" >}}) for an example configuration of such a deployment. -See [Certificate Revocation List](certificate-revocation.md) for instructions on revoking certificates, and [Signing Services](signing-service.md) for +See [Certificate Revocation List]({{< relref "certificate-revocation.md" >}}) for instructions on revoking certificates, and [Signing Services]({{< relref "signing-service.md" >}}) for configuration of the Signing Service for CRLs (especially the `updatePeriod` option). @@ -270,6 +270,6 @@ is only required to provide only essential information to the tool. At the same defaults and have the configuration adjusted to the specific needs of different scenarios. {{< note >}} -To learn more about running the tool, see [Public Key Infrastructure (PKI) Tool](pki-tool.md). +To learn more about running the tool, see [Public Key Infrastructure (PKI) Tool]({{< relref "pki-tool.md" >}}). {{< /note >}} diff --git a/content/en/platform/corda/1.3/cenm/pki-specifications.md b/content/en/platform/corda/1.3/cenm/pki-specifications.md index f6654847e3f..532f9dd2334 100644 --- a/content/en/platform/corda/1.3/cenm/pki-specifications.md +++ b/content/en/platform/corda/1.3/cenm/pki-specifications.md @@ -15,24 +15,24 @@ title: PKI Specifications # Public Key Infrastructure (PKI) Specifications -As described in the [Certificate Hierarchy Guide](pki-guide.md), Corda security relies heavily on the use of Public Key Infrastructure (PKI). Whether creating this hierarchy using the [PKI Tool](pki-tool.md) or setting up a Corda network on your own, your PKI must comply with existing Corda specifications. +As described in the [Certificate Hierarchy Guide]({{< relref "pki-guide.md" >}}), Corda security relies heavily on the use of Public Key Infrastructure (PKI). Whether creating this hierarchy using the [PKI Tool]({{< relref "pki-tool.md" >}}) or setting up a Corda network on your own, your PKI must comply with existing Corda specifications. Specifications and instructions are referenced here for the four scenarios below. Follow these guidelines to successfully create a Corda compliant hierarchy for your own use or to pass on to a third party service. ## Generating root, subordinate, and network certificates -For instructions on generating certificates, see the [PKI Tool](pki-tool.html#running-the-pki-tool) documentation. +For instructions on generating certificates, see the [PKI Tool]({{< relref "pki-tool.md#running-the-pki-tool" >}}) documentation. ## Setting up a network under an existing root -If you wish to set up a Corda network under an existing root and therefore are not using the PKI Tool, the certificate hierarchy you create should follow the guidelines specified in the [Certificate Hierarchy Guide](pki-guide.md). You may also find it helpful to reference the [Corda network policies](https://trust.corda.network/). +If you wish to set up a Corda network under an existing root and therefore are not using the PKI Tool, the certificate hierarchy you create should follow the guidelines specified in the [Certificate Hierarchy Guide]({{< relref "pki-guide.md" >}}). You may also find it helpful to reference the [Corda network policies](https://trust.corda.network/). ## Delegating network signing to a third party If you wish to delegate network signing to a third party software provider, this can be done partially (with the Certificate Authority only) or fully (with the Certificate Authority and the non-Certificate Authority). -Follow the specifications outlined in the [Signing and SMR Services](signing-service.html#developing-signing-plugins) documentation to delegate this task to a third party software provider. +Follow the specifications outlined in the [Signing and SMR Services]({{< relref "signing-service.md#developing-signing-plugins" >}}) documentation to delegate this task to a third party software provider. ## Using your own Certificate Authority software -To set up a Corda network using your own Certificate Authority software, use the Signable Material Retriever service. This service acts as a bridge between CENM services and one or more Signing Services. See the [Signable Material Retriever Service](signing-service.html#signable-material-retriever) documentation for instructions and specifications for using this service. +To set up a Corda network using your own Certificate Authority software, use the Signable Material Retriever service. This service acts as a bridge between CENM services and one or more Signing Services. See the [Signable Material Retriever Service]({{< relref "signing-service.md#signable-material-retriever" >}}) documentation for instructions and specifications for using this service. diff --git a/content/en/platform/corda/1.3/cenm/pki-tool.md b/content/en/platform/corda/1.3/cenm/pki-tool.md index 7db215c5cc5..a6178fe6e1f 100644 --- a/content/en/platform/corda/1.3/cenm/pki-tool.md +++ b/content/en/platform/corda/1.3/cenm/pki-tool.md @@ -20,7 +20,7 @@ title: Public Key Infrastructure (PKI) Tool ## Overview -As described in the [Certificate Hierarchy Guide](pki-guide.md), a certificate hierarchy with certain properties is required to run a Corda +As described in the [Certificate Hierarchy Guide]({{< relref "pki-guide.md" >}}), a certificate hierarchy with certain properties is required to run a Corda network. Specifically, the certificate hierarchy should include the two main CENM entities - the Identity Manager and the Network Map - and ensure that all entities map back to one common root of trust. The key pairs and certificates for these entities are used within the Signing Service to sign related network data such as approved CSRs, CRRs, Network Map @@ -119,7 +119,7 @@ are used by the tool for storing generated certificates. hierarchy. {{< note >}} -The full list of the configuration parameters can be found in [Public Key Infrastructure (PKI) Tool Configuration Parameters](config-pki-tool-parameters.md). +The full list of the configuration parameters can be found in [Public Key Infrastructure (PKI) Tool Configuration Parameters]({{< relref "config-pki-tool-parameters.md" >}}). {{< /note >}} @@ -127,7 +127,7 @@ The full list of the configuration parameters can be found in [Public Key Infras This configuration block defines all key stores that should be used by the PKI Tool. Each key store can be either local (backed by a Java key store file) or HSM (backed by a LAN HSM device). For HSM key stores, the available options and -authentication methods will depend on the HSM being used. See [Public Key Infrastructure (PKI) Tool Configuration Parameters](config-pki-tool-parameters.md) for more details. +authentication methods will depend on the HSM being used. See [Public Key Infrastructure (PKI) Tool Configuration Parameters]({{< relref "config-pki-tool-parameters.md" >}}) for more details. A mixture of key store types is allowed. That is, it is possible to generate some key pairs within a HSM device and others locally. Note that mixing key store types is not supported for a given entity. @@ -151,7 +151,7 @@ map from the user-defined alias to certificate configuration. The alias serves t reference the given entity throughout the rest of the PKI Tool config. Secondly, it also defines the alias for the generated (or existing) certificate entry in the corresponding certificate store. The certificate configuration defines the entity specific properties of both the X509 certificate and associated key pair. See -[Public Key Infrastructure (PKI) Tool Configuration Parameters](config-pki-tool-parameters.md) for more information. +[Public Key Infrastructure (PKI) Tool Configuration Parameters]({{< relref "config-pki-tool-parameters.md" >}}) for more information. If the desire is to use the resultant certificate hierarchy in a Corda network, this configuration block must define a set of certificates that meet some basic requirements. In addition to the hierarchy having to be under a single trust @@ -286,7 +286,7 @@ certificates = { ##### Free-form Certificates As an alternative to using the templates, each key pair and certificate can defined using the standard configuration -options. See the [Public Key Infrastructure (PKI) Tool Configuration Parameters](config-pki-tool-parameters.md) documentation for all possible parameters, and see below for examples +options. See the [Public Key Infrastructure (PKI) Tool Configuration Parameters]({{< relref "config-pki-tool-parameters.md" >}}) documentation for all possible parameters, and see below for examples that use this approach. Note that the templates only support local key stores - using a HSM requires the certificate hierarchy to be defined without templates. @@ -298,7 +298,7 @@ explicitly defines all necessary CRL file configurations or all CRL distribution generated without the `Certificate Revocation List Distribution Point` extension and will therefore be incompatible with any network using strict revocation checking. -As outlined in the [Public Key Infrastructure (PKI) Tool Configuration Parameters](config-pki-tool-parameters.md) doc, this extension is defined using the following logic: +As outlined in the [Public Key Infrastructure (PKI) Tool Configuration Parameters]({{< relref "config-pki-tool-parameters.md" >}}) doc, this extension is defined using the following logic: * If the certificate configuration has the `crlDistributionUrl` parameter set then use this. @@ -348,7 +348,7 @@ subordinate’s CRL file must be hosted, and available, on this endpoint. {{< note >}} Existing revocations can be added to the CRL file via the `crl.revocations` parameter. See -[Public Key Infrastructure (PKI) Tool Configuration Parameters](config-pki-tool-parameters.md) for more information. +[Public Key Infrastructure (PKI) Tool Configuration Parameters]({{< relref "config-pki-tool-parameters.md" >}}) for more information. {{< /note >}} For a given certificate, the exact crlDistributionPoint extension can be defined explicitly (rather than inheriting from @@ -375,7 +375,7 @@ certificates { As previously mentioned, it is up to the network operator to ensure that any configured CRL endpoints are available. The Identity Manager supports hosting of these CRL files (see the the “CRL Configuration” section of the -[Identity Manager Service](identity-manager.md) doc). +[Identity Manager Service]({{< relref "identity-manager.md" >}}) doc). ##### HSM Libraries @@ -457,7 +457,7 @@ This will create a JAR called `azure-keyvault-with-deps.jar` which can be refere ##### Generating SSL Keys -As outlined in the [Configuring the CENM services to use SSL](enm-with-ssl.md) doc, all inter-service CENM communication can be configured to encrypt their +As outlined in the [Configuring the CENM services to use SSL]({{< relref "enm-with-ssl.md" >}}) doc, all inter-service CENM communication can be configured to encrypt their messages via SSL. This feature requires the operator to provide a set of SSL key pairs and certificates to each service, which can be generated using the PKI tool. @@ -484,7 +484,7 @@ certificates = { {{< note >}} HSM keys used by the Signing Service require an accompanying certificate store that contains all certificates in the chain, from the signing entity back to the root. This is because the full chains cannot be stored within the -HSMs. Refer to the [Signing and SMR Services](signing-service.md) documentation for more information. +HSMs. Refer to the [Signing and SMR Services]({{< relref "signing-service.md" >}}) documentation for more information. {{< /note >}} diff --git a/content/en/platform/corda/1.3/cenm/quick-start.md b/content/en/platform/corda/1.3/cenm/quick-start.md index 1297e2bfb56..164a88c58c9 100644 --- a/content/en/platform/corda/1.3/cenm/quick-start.md +++ b/content/en/platform/corda/1.3/cenm/quick-start.md @@ -33,12 +33,12 @@ deployment. For a full production environment you would need to modify this deployment to add: -* A [Signing Service](signing-service.md) deployment to replace the built-in (local) signing component of the Identity Manager and Network Map Services. -* A [Zone Service](zone-service.md) deployment to manage configuration deployment. -* [Angel Services](angel-service.md) around the [Identity Manager](identity-manager.md), [Network Map](network-map.md), +* A [Signing Service]({{< relref "signing-service.md" >}}) deployment to replace the built-in (local) signing component of the Identity Manager and Network Map Services. +* A [Zone Service]({{< relref "zone-service.md" >}}) deployment to manage configuration deployment. +* [Angel Services]({{< relref "angel-service.md" >}}) around the [Identity Manager]({{< relref "identity-manager.md" >}}), [Network Map]({{< relref "network-map.md" >}}), and Signing Services to fetch configurations from the Zone Service. -* An [Auth Service](auth-service.md) deployment to handle user authentication and authorisation. -* A [FARM Service](gateway-service.md) deployment to act as a gateway from the user interface (CLI) to the back-end services. +* An [Auth Service]({{< relref "auth-service.md" >}}) deployment to handle user authentication and authorisation. +* A [FARM Service]({{< relref "gateway-service.md" >}}) deployment to act as a gateway from the user interface (CLI) to the back-end services. ### Prerequisites @@ -83,7 +83,7 @@ You need to generate the PKI (key pairs and certificates each service will use) first before starting any services. {{< note >}} -For more information on the certificate hierarchy, see [Certificate Hierarchy Guide](pki-guide.md). +For more information on the certificate hierarchy, see [Certificate Hierarchy Guide]({{< relref "pki-guide.md" >}}). {{< /note >}} #### Example Configuration @@ -134,13 +134,13 @@ certificates = { ``` {{< note >}} -The passwords for the key stores are defaulted to “password” and the passwords for the trust stores are defaulted to “trustpass”. To change them in the configuration setting, see [Public Key Infrastructure (PKI) Tool](pki-tool.md)). +The passwords for the key stores are defaulted to “password” and the passwords for the trust stores are defaulted to “trustpass”. To change them in the configuration setting, see [Public Key Infrastructure (PKI) Tool]({{< relref "pki-tool.md" >}})). {{< /note >}} #### Run the PKI Tool This step generates the required certificate stores and key pairs using the -[Public Key Infrastructure (PKI) Tool](pki-tool.md). You will need to +[Public Key Infrastructure (PKI) Tool]({{< relref "pki-tool.md" >}}). You will need to extract the PKI tool distribution zip archive to a chosen location, and run it using a command such as: @@ -210,7 +210,7 @@ workflows { {{< note >}} The example uses a local H2 database. You can modify this to point to a separate database instance by modifying the `database` section. -See the “Database properties” section of [Identity Manager Service](identity-manager.md) for more information. +See the “Database properties” section of [Identity Manager Service]({{< relref "identity-manager.md" >}}) for more information. {{< /note >}} ### Run The Service @@ -344,7 +344,7 @@ checkRevocation = false ``` {{< note >}} -This example uses a local H2 database. You can modify this to point to a separate database instance by modifying the `database` section. See the “Database properties” section of [Network Map Service](network-map.md) for more information. +This example uses a local H2 database. You can modify this to point to a separate database instance by modifying the `database` section. See the “Database properties” section of [Network Map Service]({{< relref "network-map.md" >}}) for more information. {{< /note >}} @@ -393,7 +393,7 @@ NetworkParameters { } ``` -See [Updating the network parameters](updating-network-parameters.md) for more information on the process for setting and updating the parameters. +See [Updating the network parameters]({{< relref "updating-network-parameters.md" >}}) for more information on the process for setting and updating the parameters. ### Start the Network Map Service @@ -438,11 +438,11 @@ ssh testuser@localhost -p 20002 ``` Note: For the purpose of this exercise, the simplest settings have been used for all the services. However, you can configure them to run with more features, such as the following: -* Certificate revocation support (“Revocation workflow ” section within [Identity Manager Service](identity-manager.md)) -* More advanced CSR approval workflows (“Certificate approval mechanism” section within [Identity Manager Service](identity-manager.md)) -* External signing of CSRs/Network Map updates including HSM integration ([Signing Service](signing-service.md)) +* Certificate revocation support (“Revocation workflow ” section within [Identity Manager Service]({{< relref "identity-manager.md" >}})) +* More advanced CSR approval workflows (“Certificate approval mechanism” section within [Identity Manager Service]({{< relref "identity-manager.md" >}})) +* External signing of CSRs/Network Map updates including HSM integration ([Signing Service]({{< relref "signing-service.md" >}})) -{{< note >}}For more information, see the configuration sections within [Identity Manager Service](identity-manager.md) and [Network Map Service](network-map.md). {{< /note >}} +{{< note >}}For more information, see the configuration sections within [Identity Manager Service]({{< relref "identity-manager.md" >}}) and [Network Map Service]({{< relref "network-map.md" >}}). {{< /note >}} ## Bundled Service alternative diff --git a/content/en/platform/corda/1.3/cenm/release-notes.md b/content/en/platform/corda/1.3/cenm/release-notes.md index 65b6f0fafa4..fb5819fa2f3 100644 --- a/content/en/platform/corda/1.3/cenm/release-notes.md +++ b/content/en/platform/corda/1.3/cenm/release-notes.md @@ -48,8 +48,8 @@ CENM 1.3.2 introduces fixes to known issues in CENM 1.3. ### Fixed issues -* We have fixed an issue where the maximum length of a certificate's serial number allowed by CENM was 28 digits (`NUMBER(28)` format in the database) - roughly about 93 bits of data. To extend the support (introduced in CENM 1.2) for third-party CAs such as [SwissPKI](https://www.swisspki.com/), the Identity Manager Service can now handle certificate serial numbers with sizes up to 20 octets/bytes (160 bits) to comply with [RFC 5280](https://tools.ietf.org/html/rfc5280). In addition, the [PKI Tool](pki-tool.md) now generates certificates with serial number sizes of up to 16 octets/bytes. -* We have fixed an issue where the [PKI Tool](pki-tool.md) would throw an error when using [securosys HSM](https://www.securosys.com/) with multiple partitions. +* We have fixed an issue where the maximum length of a certificate's serial number allowed by CENM was 28 digits (`NUMBER(28)` format in the database) - roughly about 93 bits of data. To extend the support (introduced in CENM 1.2) for third-party CAs such as [SwissPKI](https://www.swisspki.com/), the Identity Manager Service can now handle certificate serial numbers with sizes up to 20 octets/bytes (160 bits) to comply with [RFC 5280](https://tools.ietf.org/html/rfc5280). In addition, the [PKI Tool]({{< relref "pki-tool.md" >}}) now generates certificates with serial number sizes of up to 16 octets/bytes. +* We have fixed an issue where the [PKI Tool]({{< relref "pki-tool.md" >}}) would throw an error when using [securosys HSM](https://www.securosys.com/) with multiple partitions. ## Corda Enterprise Network Manager 1.3.1 @@ -124,8 +124,8 @@ CENM 1.2.3 introduces fixes to known issues in CENM 1.2. ### Fixed issues -* We have fixed an issue where the maximum length of a certificate's serial number allowed by CENM was 28 digits (`NUMBER(28)` format in the database) - roughly about 93 bits of data. To extend the support (introduced in CENM 1.2) for third-party CAs such as [SwissPKI](https://www.swisspki.com/), the Identity Manager Service can now handle certificate serial numbers with sizes up to 20 octets/bytes (160 bits) to comply with [RFC 5280](https://tools.ietf.org/html/rfc5280). In addition, the [PKI Tool](pki-tool.md) now generates certificates with serial number sizes of up to 16 octets/bytes. -* We have fixed an issue where the [PKI Tool](pki-tool.md) would throw an error when using [securosys HSM](https://www.securosys.com/) with multiple partitions. +* We have fixed an issue where the maximum length of a certificate's serial number allowed by CENM was 28 digits (`NUMBER(28)` format in the database) - roughly about 93 bits of data. To extend the support (introduced in CENM 1.2) for third-party CAs such as [SwissPKI](https://www.swisspki.com/), the Identity Manager Service can now handle certificate serial numbers with sizes up to 20 octets/bytes (160 bits) to comply with [RFC 5280](https://tools.ietf.org/html/rfc5280). In addition, the [PKI Tool]({{< relref "pki-tool.md" >}}) now generates certificates with serial number sizes of up to 16 octets/bytes. +* We have fixed an issue where the [PKI Tool]({{< relref "pki-tool.md" >}}) would throw an error when using [securosys HSM](https://www.securosys.com/) with multiple partitions. ## Corda Enterprise Network Manager 1.2.2 @@ -146,7 +146,7 @@ We are expanding our support for Docker to Corda Enterprise Network Manager. Furthermore, we are introducing a first reference deployment with Helm and Kubernetes. Out of the box - you will be able to deploy in minutes an ephemeral representative test network to complement your development cycle. -See [Kubernetes deployment documentation](deployment-kubernetes.md) for more details. +See [Kubernetes deployment documentation]({{< relref "deployment-kubernetes.md" >}}) for more details. **Support for third party CAs** @@ -154,7 +154,7 @@ To satisfy clients who wish to use third party software or service providers to The new service (SMR) extracts signable material from the Identity Manager and Network Map Services, and then delegates signing to a plugin. Customers can implement their own plugins to integrate with external signing infrastructure and return signed material back to SMR to pass to the relevant CENM service. -See [Signing Services](signing-service.md) for more details. Also see [EJBCA Sample Plugin](ejbca-plugin.md) for a sample open source CA implementation. +See [Signing Services]({{< relref "signing-service.md" >}}) for more details. Also see [EJBCA Sample Plugin]({{< relref "ejbca-plugin.md" >}}) for a sample open source CA implementation. **CRL Endpoint Check tool** @@ -162,7 +162,7 @@ As a diagnostic aid in case of problems with TLS connections, CENM 1.2 introduce This stand alone tool checks CRL endpoint health of all certificates in a provided keystore, as a simpler alternative to manually extracting CRL endpoints individually from the certificate and then verifying them. -See [CRL Endpoint Check Tool](crl-endpoint-check-tool.md) for usage and further details. +See [CRL Endpoint Check Tool]({{< relref "crl-endpoint-check-tool.md" >}}) for usage and further details. ### Minor Features @@ -202,10 +202,10 @@ the logs files do not conflict. * Correct service healthcheck command when executed from the CRaSH shell. * Add new command to Network Map shell to view list of nodes that have accepted (or haven’t) a given parameters update (“view nodesAcceptedParametersUpdate accepted: , parametersHash: ”), -which can help to monitor the procedure of [Updating the network parameters](updating-network-parameters.md). +which can help to monitor the procedure of [Updating the network parameters]({{< relref "updating-network-parameters.md" >}}). * Add working directory argument for CENM services, which is a path prefix for config and certificate files. * Add `run networkParametersRegistration`, `run flagDay` and `run cancelUpdate` commands to the Network Map -service shell, to enable running flag days without restarting the service. See [Updating the network parameters](updating-network-parameters.md) for +service shell, to enable running flag days without restarting the service. See [Updating the network parameters]({{< relref "updating-network-parameters.md" >}}) for full details. * Add `view publicNetworkNodeInfos` command to Network Map Service shell, to see all public network participants’ node infos, including its’ platform version. @@ -249,14 +249,14 @@ configurations to be compatible with 1.1. **Oracle Database Support** Support has been added for Oracle DB versions 12cR2 and 11gR2 as a backend data store. -For full setup instructions see [CENM Databases](database-set-up.md). +For full setup instructions see [CENM Databases]({{< relref "database-set-up.md" >}}). **Configuration Migration Tool** To simplify the upgrade process from early versions of CENM a configuration migration tool has been added. This is intended to upgrade v0.2.2 / v0.3+ configurations to v1.1, including both restructuring changes to the configuration file and updating the value of fields (such as database driver class). -See [Config migration tool](tool-config-migration.md) for details on this tool. +See [Config migration tool]({{< relref "tool-config-migration.md" >}}) for details on this tool. **Hardware Security Module Support** @@ -315,18 +315,18 @@ fresh to the product but also those who are upgrading from pre-release versions. The Signing Service is a new addition to the suite of CENM services, sitting alongside the Identity Manager and Network Map. It provides a network operator with full control over the signing of node identity data (CSRs and CRRs) and global network data (Network Map and Network Parameters) and includes features such as HSM integration, signing scheduling and -support for multiple Network Map Services. See [Signing Services](signing-service.md) to learn more about this service. +support for multiple Network Map Services. See [Signing Services]({{< relref "signing-service.md" >}}) to learn more about this service. **Brand new PKI tooling** The PKI Tool enables a network operator to easily generate Corda-compliant certificate hierarchy (keys and certificates) as well as certificate revocation lists. The tool supports both local and HSM key stores and can be -customized with the configuration file. See [Public Key Infrastructure (PKI) Tool](pki-tool.md) to learn about all the features of the PKI Tool. +customized with the configuration file. See [Public Key Infrastructure (PKI) Tool]({{< relref "pki-tool.md" >}}) to learn about all the features of the PKI Tool. **Full End to End SSL communication** All CENM components now communicate over SSL with one another, this completes the removal of the “database as message -queue” of older versions. See [Configuring the CENM services to use SSL](enm-with-ssl.md) for more information. +queue” of older versions. See [Configuring the CENM services to use SSL]({{< relref "enm-with-ssl.md" >}}) for more information. **Security And Performance Fixes** @@ -354,13 +354,13 @@ versioned changes to the protocol without changing that which the Corda nodes de The Signing Service is a new addition to the suite of CENM services, sitting alongside the Identity Manager and Network Map. It provides a network operator with full control over the signing of node identity data (CSRs and CRRs) and global network data (Network Map and Network Parameters) and includes features such as HSM integration, signing scheduling and -support for multiple Network Map Services. See [Signing Services](signing-service.md) to learn more about this service. +support for multiple Network Map Services. See [Signing Services]({{< relref "signing-service.md" >}}) to learn more about this service. **Epoch Control** The PKI Tool enables a network operator to easily generate Corda-compliant certificate hierarchy (keys and certificates) as well as certificate revocation lists. The tool supports both local and HSM key stores and can be -customized with the configuration file. See [Public Key Infrastructure (PKI) Tool](pki-tool.md) to learn about all the features of the PKI Tool. +customized with the configuration file. See [Public Key Infrastructure (PKI) Tool]({{< relref "pki-tool.md" >}}) to learn about all the features of the PKI Tool. **Shell** @@ -385,7 +385,7 @@ sub-zones of nodes that operate in what appear to the nodes to be isolated netwo network parameters. Critically, however, their certificate governance remains under the jurisdiction of a global Doorman. This way, temporary benefits such as higher privacy, differential network parameters upgrade schedules or use of temporary private notaries can be delivered. Note that the ability to merge one sub-zone into another is not -currently supported. See the [Sub Zones](sub-zones.md) documentation for more information. +currently supported. See the [Sub Zones]({{< relref "sub-zones.md" >}}) documentation for more information. **Protocol Separation** @@ -400,12 +400,12 @@ The two top-level endpoints are now * `/network-map` * `/network-map-user` -see [Network Map Overview](network-map-overview.md) for more information. +see [Network Map Overview]({{< relref "network-map-overview.md" >}}) for more information. Another change that is introduced in the newest release is the ability to interact with the Doorman and Network Map services via a shell. The commands available currently mainly allow an operator to inspect the state of the service, for example by viewing the current set of nodes within the public network, or viewing the list of Certificate Signing -Requests that are awaiting approval. See the [Embedded Shell](shell.md) documentation for more information. +Requests that are awaiting approval. See the [Embedded Shell]({{< relref "shell.md" >}}) documentation for more information. Added support for overriding the default “increment previous value by 1” behaviour for epoch values during network parameter updates/initialisation. This allows a user to specify the epoch within the parameter config file and it diff --git a/content/en/platform/corda/1.3/cenm/setting-up-notary.md b/content/en/platform/corda/1.3/cenm/setting-up-notary.md index 526ffa61535..478990c1d9c 100644 --- a/content/en/platform/corda/1.3/cenm/setting-up-notary.md +++ b/content/en/platform/corda/1.3/cenm/setting-up-notary.md @@ -94,7 +94,7 @@ java -jar corda.jar --config-file --just-generate-node-info ### Setup Network Map Service -Follow instructions here [Network Map Service](network-map.md) +Follow instructions here [Network Map Service]({{< relref "network-map.md" >}}) ### Run The Notary diff --git a/content/en/platform/corda/1.3/cenm/signing-service.md b/content/en/platform/corda/1.3/cenm/signing-service.md index 2c685f9cda6..2caa61045b3 100644 --- a/content/en/platform/corda/1.3/cenm/signing-service.md +++ b/content/en/platform/corda/1.3/cenm/signing-service.md @@ -25,7 +25,7 @@ Corda Enterprise Network Manager, alongside the Identity Operator and Network Ma a bridge between the main CENM services and PKI/HSM infrastructure, enabling a network operator to verify and sign incoming requests and changes to the network. -As mentioned in the CENM service documentation ([Identity Manager Service](identity-manager.md) and [Network Map Service](network-map.md)), the main CENM services +As mentioned in the CENM service documentation ([Identity Manager Service]({{< relref "identity-manager.md" >}}) and [Network Map Service]({{< relref "network-map.md" >}})), the main CENM services can be configured with an integrated *local signer* that will automatically sign all unsigned data using a provided key. While this is convenient, it is intended for use within for development and testing environments, and **should not** be used in production environments. Instead, large and important changes to the network should go through a series of checks before @@ -36,7 +36,7 @@ particular data to require authentication from multiple users. ## Signing Service -CENM’s Signing Service supports the following HSMs (see [CENM support matrix](cenm-support-matrix.md) for more information): +CENM’s Signing Service supports the following HSMs (see [CENM support matrix]({{< relref "cenm-support-matrix.md" >}}) for more information): * Utimaco @@ -74,7 +74,7 @@ for the configured signing keys. The overall flow of communication can be seen i ![Signing Service communication](/en/images/signing-service-communication.png "Signing Service communication") {{< note >}} All inter-service communication can be configured with SSL support to ensure the connection is encrypted. See -[Configuring the CENM services to use SSL](enm-with-ssl.md) +[Configuring the CENM services to use SSL]({{< relref "enm-with-ssl.md" >}}) {{< /note >}} {{< note >}} @@ -155,7 +155,7 @@ The configuration for the Signing Service consists of the following sections: The Signing Service is interacted with via the shell, which is configured at the top level of the configuration file. This shell is similar to the interactive shell available in other CENM services and is configured in a similar way. See -[Shell Configuration](shell.html#shell-configuration) for more information on how to configure the shell. +[Shell Configuration]({{< relref "shell.md#shell-configuration" >}}) for more information on how to configure the shell. #### HSM Libraries @@ -299,7 +299,7 @@ and Network Map Services. These service locations use aliases with a well-define {{< note >}} Communication with the configured service locations can be configured to use SSL for a secure, encrypted -connection. This is strongly recommended for production deployments. See [Configuring the CENM services to use SSL](enm-with-ssl.md) for more +connection. This is strongly recommended for production deployments. See [Configuring the CENM services to use SSL]({{< relref "enm-with-ssl.md" >}}) for more information. {{< /note >}} @@ -315,7 +315,7 @@ Material Retriever Service. {{< note >}} Communication with the configured SMR Service location can be configured to use SSL for a secure, encrypted -connection. This is strongly recommended for production deployments. See [Configuring the CENM services to use SSL](enm-with-ssl.md) for more +connection. This is strongly recommended for production deployments. See [Configuring the CENM services to use SSL]({{< relref "enm-with-ssl.md" >}}) for more information. {{< /note >}} @@ -357,7 +357,7 @@ not be configured in production environments. Even though scheduled signing of CRLs should not be configured in production environment, they should be signed manually from time to time depending on its’ `nextUpdate` property. This is to ensure an up-to-date CRL is distributed in the network before the previous one expires. Conventionally they have a lifecycle of 6 months -and are manually signed every 3 months. See [CRL Endpoint Check Tool](crl-endpoint-check-tool.md) for more information how to check +and are manually signed every 3 months. See [CRL Endpoint Check Tool]({{< relref "crl-endpoint-check-tool.md" >}}) for more information how to check CRLs’ update deadlines. {{< /note >}} @@ -1382,7 +1382,7 @@ as a map of human-readable aliases (referenced by the material management task c {{< note >}} Communication with the configured SMR Service location can be configured to use SSL for a secure, encrypted -connection. This is strongly recommended for production deployments. See [Configuring the CENM services to use SSL](enm-with-ssl.md) for more +connection. This is strongly recommended for production deployments. See [Configuring the CENM services to use SSL]({{< relref "enm-with-ssl.md" >}}) for more information. {{< /note >}} @@ -1925,7 +1925,7 @@ Non CA Plugin’s configuration file must be in the same directory as the servic ### Other Sample Plugins -See [EJBCA Sample Plugin](ejbca-plugin.md) for sample open source CA implementation. +See [EJBCA Sample Plugin]({{< relref "ejbca-plugin.md" >}}) for sample open source CA implementation. ### Admin RPC Interface @@ -1981,7 +1981,7 @@ authServiceConfig { ## Obfuscated configuration files -To view the latest changes to the obfuscated configuration files, see [Obfuscation configuration file changes](obfuscated-config-file-changes.md). +To view the latest changes to the obfuscated configuration files, see [Obfuscation configuration file changes]({{< relref "obfuscated-config-file-changes.md" >}}). {{< note >}} You should not obfuscate SMR plugin configuration files as they are not yet supported. diff --git a/content/en/platform/corda/1.3/cenm/tool-config-migration.md b/content/en/platform/corda/1.3/cenm/tool-config-migration.md index 69a0cca06ad..f6c52b9d395 100644 --- a/content/en/platform/corda/1.3/cenm/tool-config-migration.md +++ b/content/en/platform/corda/1.3/cenm/tool-config-migration.md @@ -45,7 +45,7 @@ java -jar config-migration-tool-<>.jar --config-file <> [o {{< important >}} v0.2.2 deployments of CENM require the data to be migrated to the v0.3+ database schema to function with -the v1.0 configurations generated by this tool. See [Upgrading Corda Enterprise Network Manager](upgrade-notes.md). +the v1.0 configurations generated by this tool. See [Upgrading Corda Enterprise Network Manager]({{< relref "upgrade-notes.md" >}}). {{< /important >}} diff --git a/content/en/platform/corda/1.3/cenm/tools-index.md b/content/en/platform/corda/1.3/cenm/tools-index.md index 17a3a7b91b9..c508573d75d 100644 --- a/content/en/platform/corda/1.3/cenm/tools-index.md +++ b/content/en/platform/corda/1.3/cenm/tools-index.md @@ -17,19 +17,19 @@ A small number of tools and utilities are available to help with setting up, run ## Public Key Infrastructure -* [Public Key Infrastructure (PKI) Tool](pki-tool.md) +* [Public Key Infrastructure (PKI) Tool]({{< relref "pki-tool.md" >}}) ## General running of network -* [Certificate Revocation Request Submission Tool](tool-crr-submission.md) +* [Certificate Revocation Request Submission Tool]({{< relref "tool-crr-submission.md" >}}) ## Operations and administration -* [CENM Command-line Interface Tool](cenm-cli-tool.md) -* [CENM User Admin tool](user-admin.md) +* [CENM Command-line Interface Tool]({{< relref "cenm-cli-tool.md" >}}) +* [CENM User Admin tool]({{< relref "user-admin.md" >}}) ## Other Tools * [Config Obfuscation Tool]({{< relref "../../4.8/enterprise/tools-config-obfuscator.md" >}}) -* [CRL Endpoint Check Tool](crl-endpoint-check-tool.md) +* [CRL Endpoint Check Tool]({{< relref "crl-endpoint-check-tool.md" >}}) diff --git a/content/en/platform/corda/1.3/cenm/troubleshooting-common-issues.md b/content/en/platform/corda/1.3/cenm/troubleshooting-common-issues.md index 6745f88075b..210d73c2909 100644 --- a/content/en/platform/corda/1.3/cenm/troubleshooting-common-issues.md +++ b/content/en/platform/corda/1.3/cenm/troubleshooting-common-issues.md @@ -71,14 +71,14 @@ Identity Manager Service. To verify that issue 1 is not the culprit - verify that the Network Map signing process is still successfully running periodically. Unless the Network Map Service is configured for testing, it should have an external signing process -configured. See the “Signing Network Map and Network Parameters” section of [Signing Services](signing-service.md). If the service is +configured. See the “Signing Network Map and Network Parameters” section of [Signing Services]({{< relref "signing-service.md" >}}). If the service is configured to run with a local signer then verify that the configured sign interval is something fairly low to ensure that updates to the network map are persisted often (e.g. 1 minute). To verify that issue 2 is not the culprit - the logs of the Network Map Service should be checked. An error such as an invalid certificate is not recoverable and should be resolved out of band with the node operator and support. If there are any communication issues with the Identity Manager then the error will be logged and communication will be -retried after a short break. See the “Identity Manager Communication” section of [Network Map Service](network-map.md) to verify that the +retried after a short break. See the “Identity Manager Communication” section of [Network Map Service]({{< relref "network-map.md" >}}) to verify that the Identity Manager communication is correctly configured for the Network Map Service. @@ -138,7 +138,7 @@ IO. **Signing process is working as intended but timeout is configured too low** The timeout for a local signer can be configured via the service’s configuration file. See -[Identity Manager Configuration Parameters](config-identity-manager-parameters.md) and [Network Map Configuration Parameters](config-network-map-parameters.md) for more information. +[Identity Manager Configuration Parameters]({{< relref "config-identity-manager-parameters.md" >}}) and [Network Map Configuration Parameters]({{< relref "config-network-map-parameters.md" >}}) for more information. ### Explanation diff --git a/content/en/platform/corda/1.3/cenm/updating-network-parameters.md b/content/en/platform/corda/1.3/cenm/updating-network-parameters.md index 030055c091a..21fea732bf5 100644 --- a/content/en/platform/corda/1.3/cenm/updating-network-parameters.md +++ b/content/en/platform/corda/1.3/cenm/updating-network-parameters.md @@ -40,7 +40,7 @@ At a high level, the process is as follows: ## Editing network parameters configuration -See [Setting the Network Parameters](network-map.html#network-parameters) +See [Setting the Network Parameters]({{< relref "network-map.md#network-parameters" >}}) for information on the network parameters configuration file format and options. When updating the network parameters, ensure that the network parameters file has the diff --git a/content/en/platform/corda/1.3/cenm/upgrade-notes.md b/content/en/platform/corda/1.3/cenm/upgrade-notes.md index ac2a98c6fe2..d4973e4b655 100644 --- a/content/en/platform/corda/1.3/cenm/upgrade-notes.md +++ b/content/en/platform/corda/1.3/cenm/upgrade-notes.md @@ -21,7 +21,7 @@ Doorman), Network Map Service, or Signing Service - from previous versions to th in question. If not specified, you may assume the versions you are currently using are still in force. {{< warning >}} -Before you start the upgrade, you must consult the [CENM Release Notes](release-notes.md) to confirm all changes between releases. +Before you start the upgrade, you must consult the [CENM Release Notes]({{< relref "release-notes.md" >}}) to confirm all changes between releases. {{< /warning >}} ## 1.2.x to 1.3 @@ -29,19 +29,19 @@ Before you start the upgrade, you must consult the [CENM Release Notes](release- CENM 1.3 introduces a significant number of services. You should upgrade to CENM 1.2.2 before upgrading to 1.3. The key steps for the upgrade are: -1. Generate new certificates for [FARM](gateway-service.md), [Auth](auth-service.md), and [Zone](zone-service.md) Services. +1. Generate new certificates for [FARM]({{< relref "gateway-service.md" >}}), [Auth]({{< relref "auth-service.md" >}}), and [Zone]({{< relref "zone-service.md" >}}) Services. 2. Generate a JWT token key pair for Auth Service. 3. Deploy FARM Service to provide a gateway between the CLI tool and the back-end services. 4. Deploy Auth Service to provide user authentication and authorisation to other services. 5. Deploy Zone Service to store configurations for the Identity Manager, Network Map, and Signing Services. 6. Create users in the Auth Service, for zone and subzone management. -7. Edit [Identity Manager Service](identity-manager.md), [Network Map Service](network-map.md), and [Signing Service](signing-service.md) configurations to remove shell access and add an admin listener configuration. -8. Edit the [Signing Service](signing-service.md) configuration so that signing tasks refer to service aliases generated by the Zone Service. -9. Set Identity Manager Service configuration in the [Zone Service](zone-service.md). +7. Edit [Identity Manager Service]({{< relref "identity-manager.md" >}}), [Network Map Service]({{< relref "network-map.md" >}}), and [Signing Service]({{< relref "signing-service.md" >}}) configurations to remove shell access and add an admin listener configuration. +8. Edit the [Signing Service]({{< relref "signing-service.md" >}}) configuration so that signing tasks refer to service aliases generated by the Zone Service. +9. Set Identity Manager Service configuration in the [Zone Service]({{< relref "zone-service.md" >}}). 10. Set Network Map Service configuration(s) in the Zone Service. 11. Set Signing Service configuation in the Zone Service. 12. Update existing service deployments. -13. Add [Angel Services](angel-service.md) to Identity Manager, Network Map, and Signing Services, to fetch configurations from the Zone +13. Add [Angel Services]({{< relref "angel-service.md" >}}) to Identity Manager, Network Map, and Signing Services, to fetch configurations from the Zone Service. ### Generating certificates and JWT @@ -56,7 +56,7 @@ You must replace the `subject` and `crlDistributionUrl` entries in this configur appropriate to your deployment. {{% /important %}} -To generate the JWT, refer to the [Auth Service](auth-service.md) documentation. +To generate the JWT, refer to the [Auth Service]({{< relref "auth-service.md" >}}) documentation. The generated keys and certificates will then need to be distributed to the service hosts, replacing the existing SSL (but not network trust root or other signing key/certificates). @@ -65,9 +65,9 @@ replacing the existing SSL (but not network trust root or other signing key/cert To deploy the new services, follow the guides in the service documentation: -* [FARM Service](gateway-service.md) -* [Auth Service](auth-service.md) -* [Zone Service](zone-service.md) +* [FARM Service]({{< relref "gateway-service.md" >}}) +* [Auth Service]({{< relref "auth-service.md" >}}) +* [Zone Service]({{< relref "zone-service.md" >}}) {{< note >}} You should deploy two FARM Service instances - one for general access, accessible from user @@ -76,7 +76,7 @@ systems, and a second one in the secure network alongside the Signing Service. ### Create user(s) -The [Auth Service](auth-service.md) has an initial user who can manage users, however +The [Auth Service]({{< relref "auth-service.md" >}}) has an initial user who can manage users, however for separation of responsibility this user cannot manage services. Therefore you need to create user(s) for configuring the services, as well as potentially users to operate the services once they are configured, such as signing certificates. @@ -128,7 +128,7 @@ At this point you should shut down the previous services and replace their JAR f Do not start them quite yet, as they should be managed by the Angel Service. Add the `angel-1.3.0.jar` file to each managed service deployment (Identity Manager, Network Map, Zone), and configure the service start-up to be via the Angel Service. Details on the arguments to the Angel Service are covered in the -[Angel Service documentation](angel-service.md). +[Angel Service documentation]({{< relref "angel-service.md" >}}). ## 1.2.1 to 1.2.2 @@ -193,8 +193,8 @@ Ensure the services are not running before replacing the JAR files. CENM 1.1 supports multiple HSMs, however due to to the proprietary nature of the HSM libraries, the release does not work with these HSMs "out of the box". The user must provide the relevant libraries and reference them in the -configuration of the relevant component (Signing Service or PKI Tool). For more information, see [Signing Services](signing-service.md). -and [Public Key Infrastructure (PKI) Tool](pki-tool.md) for more information. +configuration of the relevant component (Signing Service or PKI Tool). For more information, see [Signing Services]({{< relref "signing-service.md" >}}). +and [Public Key Infrastructure (PKI) Tool]({{< relref "pki-tool.md" >}}) for more information. ## 0.3+ to 1.0 @@ -257,7 +257,7 @@ database { ### Configuration files CENM 1.0 Identity Manager and Network Map Services are not backward-compatible with configuration files for Doorman and Network Map Service versions 0.x. -Version 0.2.2 and 0.3 / 0.4 configuration files can be migrated to CENM 1.0 using the [configuration migration tool](tool-config-migration.md). +Version 0.2.2 and 0.3 / 0.4 configuration files can be migrated to CENM 1.0 using the [configuration migration tool]({{< relref "tool-config-migration.md" >}}). Using the generated 1.0 configurations, the services can be upgraded by stopping the services, swapping out the JAR file and configuration files, and restarting the services. @@ -314,7 +314,7 @@ and Revocation services cannot be known by the upgrader. {{< warning >}} If you require private network functionality or node certificate revocation checking then the configuration should be updated to include the appropriate settings. See the *Doorman & Revocation Communication* section -of the [Network Map Service](network-map.md) document for more information. +of the [Network Map Service]({{< relref "network-map.md" >}}) document for more information. {{< /warning >}} @@ -325,20 +325,20 @@ of the [Network Map Service](network-map.md) document for more information. The release modifies the Network Map Signing Service to request data through the Network Map Service rather than going directly to the database. Therefore the configuration needs to change to remove the redundant database configuration and instead adding the service endpoint. As this information cannot be known by the configuration upgrader, this has to be added -manually. See [Signing Services](signing-service.md) for more information on how to configure this. +manually. See [Signing Services]({{< relref "signing-service.md" >}}) for more information on how to configure this. #### The Certificate Revocation Request service requires a configuration update to specify communication the Revocation service Similarly to above, the CRR Signing Service now pulls data through the Revocation service and therefore requires a -configuration modification. See [Signing Services](signing-service.md) for more information on how to configure this. +configuration modification. See [Signing Services]({{< relref "signing-service.md" >}}) for more information on how to configure this. #### Setting the network parameters requires passing the root certificate When setting network parameters, the Network Map Service cannot validate the proposed notary certificates using the Doorman database. Hence the trusted root certificate now needs to be passed during setting of parameters. -See the “Setting the Network Parameters” section of the [Network Map Service](network-map.md) document for more information. +See the “Setting the Network Parameters” section of the [Network Map Service]({{< relref "network-map.md" >}}) document for more information. ## 0.1 to 0.2.1 diff --git a/content/en/platform/corda/1.3/cenm/user-admin.md b/content/en/platform/corda/1.3/cenm/user-admin.md index 7d59130a5a8..79951dab892 100644 --- a/content/en/platform/corda/1.3/cenm/user-admin.md +++ b/content/en/platform/corda/1.3/cenm/user-admin.md @@ -34,14 +34,14 @@ You can only use the User Admin tool if you are registered to use the tool as an ## Access the CENM User Admin tool -You access the User Admin tool from the location of your [FARM Service](gateway-service.html#manage-farm-service-configuration) instance. Enter the full address of your FARM Service, including the port number, followed by `/admin` into a web browser. +You access the User Admin tool from the location of your [FARM Service]({{< relref "gateway-service.md#manage-farm-service-configuration" >}}) instance. Enter the full address of your FARM Service, including the port number, followed by `/admin` into a web browser. For example: `http://10.230.41.12:8080/admin` ### First login -Your initialisation credentials for logging in for the first time are established using the `--initial-user-name` and `--initial-user-password` commands when managing the configuration of the [Auth Service](auth-service.md). +Your initialisation credentials for logging in for the first time are established using the `--initial-user-name` and `--initial-user-password` commands when managing the configuration of the [Auth Service]({{< relref "auth-service.md" >}}). If you do not have these, you need to access them from the operator who configured your Auth Service. diff --git a/content/en/platform/corda/1.3/cenm/zone-service.md b/content/en/platform/corda/1.3/cenm/zone-service.md index e14081abc60..3970c3d3008 100644 --- a/content/en/platform/corda/1.3/cenm/zone-service.md +++ b/content/en/platform/corda/1.3/cenm/zone-service.md @@ -31,7 +31,7 @@ The Zone Service stores relevant configurations for the following services: * Network Map Service * Signing Services -It uses the associated [Angel Service](angel-service.md) to deploy those configurations as needed. +It uses the associated [Angel Service]({{< relref "angel-service.md" >}}) to deploy those configurations as needed. Each Angel Service identifies itself to the Zone Service via an authentication token, referred to as the "zone token". The Zone Service also coordinates actions needed on Sub Zones (for example, new network parameters), which are executed @@ -62,7 +62,7 @@ The full list of configuration options follows below: - `--user`: The user for the Zone Service's database. - `--password`: The password for the Zone Service's database. - `--admin-listener-port`: The port where Angel Services connect to the Zone Service. -- `--disable-authentication`: Allows you to disable authentication and authorisation via the [Auth Service](auth-service.md). Only use this option in development environments. Defaults to `false` if no value is provided. +- `--disable-authentication`: Allows you to disable authentication and authorisation via the [Auth Service]({{< relref "auth-service.md" >}}). Only use this option in development environments. Defaults to `false` if no value is provided. - `--auth-host`: The hostname of the Auth Service. Required unless authentication and authorisation are disabled. - `--auth-port`: The port number of the Auth Service. Required unless authentication and authorisation are disabled. - `--auth-trust-store-location`: The location of the Auth Service trust root keystore. Required unless authentication and authorisation are disabled. diff --git a/content/en/platform/corda/1.4/cenm/_index.md b/content/en/platform/corda/1.4/cenm/_index.md index c54b8ca34a2..6eca2c77aab 100644 --- a/content/en/platform/corda/1.4/cenm/_index.md +++ b/content/en/platform/corda/1.4/cenm/_index.md @@ -53,7 +53,7 @@ Concepts and overview * [The workflow]({{< relref "../../../../../en/platform/corda/1.4/cenm/workflow.md" >}}) * [Databases]({{< relref "../../../../../en/platform/corda/1.4/cenm/database-set-up.md" >}}) * [Public Key Infrastructure (PKI)]({{< relref "../../../../../en/platform/corda/1.4/cenm/pki-tool.md" >}}) -* [The node](../../../../../en/platform/corda/1.4/cenm/network-map.html#node-certificate-revocation-checking) +* [The node]({{< relref "../../../../../en/platform/corda/1.4/cenm/network-map.md#node-certificate-revocation-checking" >}}) * [Sub Zones]({{< relref "../../../../../en/platform/corda/1.4/cenm/sub-zones.md" >}}) * [Network Map overview]({{< relref "../../../../../en/platform/corda/1.4/cenm/network-map-overview.md" >}}) * [Certificate Revocation List]({{< relref "../../../../../en/platform/corda/1.4/cenm/certificate-revocation.md" >}}) diff --git a/content/en/platform/corda/1.4/cenm/angel-service.md b/content/en/platform/corda/1.4/cenm/angel-service.md index 2a9ea1be485..a946cb1eb5b 100644 --- a/content/en/platform/corda/1.4/cenm/angel-service.md +++ b/content/en/platform/corda/1.4/cenm/angel-service.md @@ -71,7 +71,7 @@ The Angel Service is configured via the command-line and it downloads the config 3. It writes the new configuration. 4. It starts the managed service. -If the managed service is Network Map, the Zone Service can reply with a lifecycle event (Flag Day). This is because only the Network Map Service holds the network parameters that Flag Days update. In this case, the Angel Service will automatically perform the [required steps](updating-network-parameters.md) on the managed Network Map Service. +If the managed service is Network Map, the Zone Service can reply with a lifecycle event (Flag Day). This is because only the Network Map Service holds the network parameters that Flag Days update. In this case, the Angel Service will automatically perform the [required steps]({{< relref "updating-network-parameters.md" >}}) on the managed Network Map Service. ## Service health checking via API diff --git a/content/en/platform/corda/1.4/cenm/aws-deployment-eks.md b/content/en/platform/corda/1.4/cenm/aws-deployment-eks.md index 7dcfa575151..66061ba2966 100644 --- a/content/en/platform/corda/1.4/cenm/aws-deployment-eks.md +++ b/content/en/platform/corda/1.4/cenm/aws-deployment-eks.md @@ -12,7 +12,7 @@ weight: 100 # CENM Deployment with AWS/EKS -You can use the [PKI tool](pki-tool.md) to create a set of keys and certificates, which must be shared between all CENM services through the use of a shared file system. +You can use the [PKI tool]({{< relref "pki-tool.md" >}}) to create a set of keys and certificates, which must be shared between all CENM services through the use of a shared file system. In AWS this is achieved via the AWS Elastic Filesystem (EFS). diff --git a/content/en/platform/corda/1.4/cenm/aws-deployment-postgressql.md b/content/en/platform/corda/1.4/cenm/aws-deployment-postgressql.md index 733d7d714d9..d6b31af7c48 100644 --- a/content/en/platform/corda/1.4/cenm/aws-deployment-postgressql.md +++ b/content/en/platform/corda/1.4/cenm/aws-deployment-postgressql.md @@ -48,9 +48,9 @@ To set up each database: 1. Set up a PostgreSQL database in AWS - follow the instructions in the [AWS documentation](https://aws.amazon.com/rds/postgresql). 2. Connect to the database, using the details of the database in AWS. -3. Create a database user and a schema namespace [with restricted permissions](database-set-up.html#1-create-a-database-user-with-schema-permissions). Follow the [steps for PostgreSQL](database-set-up.html#postgresql). -4. Create the [database schema](database-set-up.html#2-database-schema-creation) for each service. -5. Perform [CENM Service configuration](database-set-up.html#3-cenm-service-configuration) - follow the [steps for PostgreSQL](database-set-up.html#postgresql-1). See also the [database configuration documentation](config-database.html). +3. Create a database user and a schema namespace [with restricted permissions]({{< relref "database-set-up.md#1-create-a-database-user-with-schema-permissions" >}}). Follow the [steps for PostgreSQL]({{< relref "database-set-up.md#postgresql" >}}). +4. Create the [database schema]({{< relref "database-set-up.md#2-database-schema-creation" >}}) for each service. +5. Perform [CENM Service configuration]({{< relref "database-set-up.md#3-cenm-service-configuration" >}}) - follow the [steps for PostgreSQL]({{< relref "database-set-up.md#postgresql-1" >}}). See also the [database configuration documentation]({{< relref "config-database.md" >}}). {{< note >}} In step 4 above, you must create a schema for each CENM service. The guide provided has steps for a restricted database schema that is used in a live production environment. You may prefer to use a less restricted database to reduce complexity in this reference environment setup. @@ -58,8 +58,8 @@ In step 4 above, you must create a schema for each CENM service. The guide provi ### Deploy CENM services -1. Deploy the [Auth Service](auth-service.html) using PostgreSQL on AWS. -2. Deploy the [Identity Manager Service](identity-manager.html) using PostgreSQL on AWS. -3. Deploy the [Network Map Service](network-map.html) using PostgreSQL on AWS. -4. Deploy the [Zone Service](zone-service.html) using PostgreSQL on AWS. -5. Deploy the [Signing Service](signing-service.html#signing-service) (it does not use a database). +1. Deploy the [Auth Service]({{< relref "auth-service.md" >}}) using PostgreSQL on AWS. +2. Deploy the [Identity Manager Service]({{< relref "identity-manager.md" >}}) using PostgreSQL on AWS. +3. Deploy the [Network Map Service]({{< relref "network-map.md" >}}) using PostgreSQL on AWS. +4. Deploy the [Zone Service]({{< relref "zone-service.md" >}}) using PostgreSQL on AWS. +5. Deploy the [Signing Service]({{< relref "signing-service.md#signing-service" >}}) (it does not use a database). diff --git a/content/en/platform/corda/1.4/cenm/cenm-cli-tool.md b/content/en/platform/corda/1.4/cenm/cenm-cli-tool.md index 73d490ec80b..80843446883 100644 --- a/content/en/platform/corda/1.4/cenm/cenm-cli-tool.md +++ b/content/en/platform/corda/1.4/cenm/cenm-cli-tool.md @@ -43,13 +43,13 @@ To install using Docker: You have installed the Docker image with CENM CLI tool. -To get the tool ready to use from within the Docker container, check the [Kubernetes deployment guide](deployment-kubernetes.html#network-operations). +To get the tool ready to use from within the Docker container, check the [Kubernetes deployment guide]({{< relref "deployment-kubernetes.md#network-operations" >}}). ## Set up the CENM CLI Tool In order to use the CLI, you must have permission to access the CENM services you plan to use. -You should have an account that has been set up by a user administrator using the [User Admin application](user-admin.md). This account gives you the credentials, roles, and permissions you need to access CENM services via the CLI. +You should have an account that has been set up by a user administrator using the [User Admin application]({{< relref "user-admin.md" >}}). This account gives you the credentials, roles, and permissions you need to access CENM services via the CLI. For the below example, the credentials of a sample CENM user are shown: @@ -75,7 +75,7 @@ To set up a new network with the CLI: `./cenm identity-manager config set-admin-address -a=identity-manager:5053` -3. Set the Identity Manager config. This command returns a **Zone token** which you should pass to your [Angel Service](angel-service.md): +3. Set the Identity Manager config. This command returns a **Zone token** which you should pass to your [Angel Service]({{< relref "angel-service.md" >}}): `./cenm identity-manager config set -f config/identitymanager.conf --zone-token` @@ -176,7 +176,7 @@ Your interaction with CENM services through the CLI is managed by the Front-end When you log in to each session, you specify the full endpoint address of the Gateway service instance you are accessing, for example: `http://10.230.41.12`. You do this using the argument `` in the command line. This endpoint forms the **context** for your session. -Setting a context means that your session can last for the full session duration set in your [Auth Service](auth-service.md) configuration, without being interrupted by any natural time-outs in your CENM service. It also means you can switch between servers, like staging and production servers, simply by switching from one context alias to another. +Setting a context means that your session can last for the full session duration set in your [Auth Service]({{< relref "auth-service.md" >}}) configuration, without being interrupted by any natural time-outs in your CENM service. It also means you can switch between servers, like staging and production servers, simply by switching from one context alias to another. In most commands in the CLI, you can specify the context you want to use with the command option: @@ -194,7 +194,7 @@ This command allows you to change the password you use to access your CENM servi {{< attention >}} -If you have been allocated a new password by an administrator using the [User admin tool](user-admin.md), you must change it to something only you know. You must do this before you continue to use CENM services. +If you have been allocated a new password by an administrator using the [User admin tool]({{< relref "user-admin.md" >}}), you must change it to something only you know. You must do this before you continue to use CENM services. {{< /attention >}} diff --git a/content/en/platform/corda/1.4/cenm/cenm-error-codes.md b/content/en/platform/corda/1.4/cenm/cenm-error-codes.md index 083c96355ae..7affb3701ff 100644 --- a/content/en/platform/corda/1.4/cenm/cenm-error-codes.md +++ b/content/en/platform/corda/1.4/cenm/cenm-error-codes.md @@ -44,11 +44,11 @@ corresponding codes will contain a message with the error code and a link pointi | Error code | Description | Actions to fix | |:------------------------------------- |:---------------------------------------------------------------------------------------- |:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `config-parsing-and-validation-error` | This error indicates that there were both parsing and validating issues with the config. | Check the additional details and double check that your configs are lining up with the [most recent CENM documentation](https://docs.corda.net/docs/cenm/index.html). | -| `config-parse-error` | This error indicates that an error has occurred during configuration parsing. | Check the additional details and double check that your configs are lining up with the [most recent CENM documentation](https://docs.corda.net/docs/cenm/index.html). | +| `config-parsing-and-validation-error` | This error indicates that there were both parsing and validating issues with the config. | Check the additional details and double check that your configs are lining up with the [most recent CENM documentation](https://docs.r3.com/docs/cenm/index.html). | +| `config-parse-error` | This error indicates that an error has occurred during configuration parsing. | Check the additional details and double check that your configs are lining up with the [most recent CENM documentation](https://docs.r3.com/docs/cenm/index.html). | | `config-file-doesnt-exist` | This error indicates that the configuration file that was provided does not exist. | Check that the provided path is correct and that the file is actually there. | | `config-file-not-readable` | This error indicates that the configuration file could not be read. | Make sure you have the rights to read the configuration file. | -| `config-validation-error` | This error indicates that there were validating issues with the configuration | Check the additional details and double check that your configurations are lined up with the [most recent CENM documentation](https://docs.corda.net/docs/cenm/index.html). | +| `config-validation-error` | This error indicates that there were validating issues with the configuration | Check the additional details and double check that your configurations are lined up with the [most recent CENM documentation](https://docs.r3.com/docs/cenm/index.html). | {{< /table >}} diff --git a/content/en/platform/corda/1.4/cenm/cenm-support-matrix.md b/content/en/platform/corda/1.4/cenm/cenm-support-matrix.md index d637b4d1139..cc035d70c91 100644 --- a/content/en/platform/corda/1.4/cenm/cenm-support-matrix.md +++ b/content/en/platform/corda/1.4/cenm/cenm-support-matrix.md @@ -19,7 +19,7 @@ The Operating System platforms supported in Corda Enterprise Network Manager are Production use of Corda Enterprise Network Manager 1.3+ is only supported on Linux OS, see details below. -For information about supported Operating Systems for Corda Enterprise, see the Corda Enterprise Edition 4.6 [platform support matrix]({{< relref "../../4.8/enterprise/platform-support-matrix.md" >}}) section or check the relevant [support documentation](https://docs.corda.net/docs/corda-enterprise/index.html) for previous versions of Corda Enterprise. +For information about supported Operating Systems for Corda Enterprise, see the Corda Enterprise Edition 4.6 [platform support matrix]({{< relref "../../4.8/enterprise/platform-support-matrix.md" >}}) section or check the relevant [support documentation](https://docs.r3.com/docs/corda-enterprise/index.html) for previous versions of Corda Enterprise. ## Hardware Security Modules (HSMs) diff --git a/content/en/platform/corda/1.4/cenm/certificate-revocation.md b/content/en/platform/corda/1.4/cenm/certificate-revocation.md index 697bb32ceda..5ad88265eec 100644 --- a/content/en/platform/corda/1.4/cenm/certificate-revocation.md +++ b/content/en/platform/corda/1.4/cenm/certificate-revocation.md @@ -21,7 +21,7 @@ It is used by nodes when they establish a TLS connection between each other and In order to add entries to the certificate revocation list there is the certificate revocation process that resembles the one from the certificate signing request (CSR). -Note: For context on how the certificate revocation list fits into the wider context, see [Certificate Hierarchy Guide](pki-guide.md). Once added, the entries cannot be removed from the certificate revocation list. +Note: For context on how the certificate revocation list fits into the wider context, see [Certificate Hierarchy Guide]({{< relref "pki-guide.md" >}}). Once added, the entries cannot be removed from the certificate revocation list. As with CSR, the approval workflow for revocation requests is integrated with the Jira tool by default, and the submitted requests follow the same lifecycle. To support the above functionality, there are two @@ -163,6 +163,6 @@ This does not use HTTP to avoid exposing any web vulnerabilities to the signing CRLs contain a field called "next update”, after which the CRL is no longer valid. This is to ensure that an up-to-date CRL is distributed in the network before the previous one expires. Conventionally, they have a lifecycle of 6 months and are manually signed every 3 months. This kind of scheduling allows plenty of time to resolve any signing issues. -{{< note >}} See [Signing Services](signing-service.md) for details on building and signing CRLs, and especially the “updatePeriod” -configuration field which is used to determine the next update deadline. See also [CRL Endpoint Check Tool](crl-endpoint-check-tool.md) +{{< note >}} See [Signing Services]({{< relref "signing-service.md" >}}) for details on building and signing CRLs, and especially the “updatePeriod” +configuration field which is used to determine the next update deadline. See also [CRL Endpoint Check Tool]({{< relref "crl-endpoint-check-tool.md" >}}) for more information how to check CRLs’ update deadlines. {{< /note >}} diff --git a/content/en/platform/corda/1.4/cenm/config-identity-manager-parameters.md b/content/en/platform/corda/1.4/cenm/config-identity-manager-parameters.md index 60410405ee4..7009ce8579a 100644 --- a/content/en/platform/corda/1.4/cenm/config-identity-manager-parameters.md +++ b/content/en/platform/corda/1.4/cenm/config-identity-manager-parameters.md @@ -26,11 +26,11 @@ The host and port on which the service runs * **database**: -See [CENM Database Configuration](config-database.md) +See [CENM Database Configuration]({{< relref "config-database.md" >}}) * **shell**: - *(Optional)* See [Shell Configuration Parameters](config-shell.md) for more information. Note that + *(Optional)* See [Shell Configuration Parameters]({{< relref "config-shell.md" >}}) for more information. Note that we are planning to deprecate the shell and the recommended path for interacting with CENM services is the admin RPC interface detailed below. @@ -80,7 +80,7 @@ It is needed as this URL is encoded in certificates issued by the Identity Manag Determines if a client should attempt to reconnect if the connection is dropped. * **ssl**: - See [SSL Settings](config-ssl.md). + See [SSL Settings]({{< relref "config-ssl.md" >}}). * **plugin**: @@ -127,7 +127,7 @@ It is needed as this URL is encoded in certificates issued by the Identity Manag A list of CRLs hosted by the Identity Manager Service, in addition to the CRLs hosted by node operators. This allows the Identity Manager Service to host the CRLs for node operators that will not host their own CRL infrastructure, at the cost of not being able to revoke TLS certificates issued by the node. * **adminListener**: A configuration property you must define in order to use the RPC API in the Identity Manager Service. - You can add `port`, `reconnect`, and `verbose`. Also, this property has an SSL field - for more information, see [SSL Settings](config-ssl.md). + You can add `port`, `reconnect`, and `verbose`. Also, this property has an SSL field - for more information, see [SSL Settings]({{< relref "config-ssl.md" >}}). * **port**: Port number to listen to for Admin RPC connections. * **verbose**: @@ -135,7 +135,7 @@ A list of CRLs hosted by the Identity Manager Service, in addition to the CRLs h * **reconnect**: *(Optional)* Determines if a client should attempt to reconnect if the connection is dropped. Defaults to `true`. * **ssl**: - See [SSL Settings](config-ssl.md) for details. + See [SSL Settings]({{< relref "config-ssl.md" >}}) for details. {{% important %}} If the `adminListener` property is present in the configuration, this means that the service must only be used via Admin RPC. In this case, the `shell` configuration property will be disabled. The `shell` and `adminListener` properties cannot be used in the configuration at the same time. @@ -144,7 +144,7 @@ If the `adminListener` property is present in the configuration, this means that * **authServiceConfig**: The admin RPC interface requires an Auth Service to verify requests, which must be configured below in a `authServiceConfig` block. Typically - this is provided automatically by the [Zone Service](zone-service.md) (via an Angel Service), + this is provided automatically by the [Zone Service]({{< relref "zone-service.md" >}}) (via an Angel Service), however the parameters are detailed below for reference: * **host**: The hostname of the Auth Service. Required unless authentication is disabled. * **port**: The port number of the Auth Service. Required unless authentication is disabled. @@ -160,7 +160,7 @@ If the `adminListener` property is present in the configuration, this means that ## Obfuscated configuration files To view the latest changes to the obfuscated configuration files, -see [Obfuscation configuration file changes](obfuscated-config-file-changes.md). +see [Obfuscation configuration file changes]({{< relref "obfuscated-config-file-changes.md" >}}). ## Redirection forbidden diff --git a/content/en/platform/corda/1.4/cenm/config-network-map-parameters.md b/content/en/platform/corda/1.4/cenm/config-network-map-parameters.md index 5b2c40fa798..160884a03e5 100644 --- a/content/en/platform/corda/1.4/cenm/config-network-map-parameters.md +++ b/content/en/platform/corda/1.4/cenm/config-network-map-parameters.md @@ -24,9 +24,9 @@ Configuration reference for the Network Map Service * **address**: The host and port on which the service runs * **database**: -See [CENM Database Configuration](config-database.md) +See [CENM Database Configuration]({{< relref "config-database.md" >}}) * **shell**: -*(Optional)* See [Shell Configuration Parameters](config-shell.md) +*(Optional)* See [Shell Configuration Parameters]({{< relref "config-shell.md" >}}) * **enmListener** (optional in a simple test deployment): Details on how the service will communicate with the rest of the CENM deployment. * **port**: @@ -36,7 +36,7 @@ Details on how the service will communicate with the rest of the CENM deployment * **reconnect**: Informs whether a client should attempt to reconnect if the connection is dropped. * **ssl**: - See [SSL Settings](config-ssl.md) + See [SSL Settings]({{< relref "config-ssl.md" >}}) * **checkRevocation** (optional, defaults to `false` if omitted): If set to true, the Network Map will check with the Identity Manager’s revocation service to find out if the registering node is revoked. * **pollingInterval**: @@ -48,7 +48,7 @@ Details where the issuance service is on the network * **port**: The port that its `enmListener` is bound to. * **ssl**: - See [SSL Settings](config-ssl.md) for details. + See [SSL Settings]({{< relref "config-ssl.md" >}}) for details. * **revocation** (optional in a simple test deployment): Details where the revocation service is on the network * **host**: @@ -56,7 +56,7 @@ Details where the revocation service is on the network * **port**: The port that its `enmListener` is bound to. * **ssl**: - See [SSL Settings](config-ssl.md) for details. + See [SSL Settings]({{< relref "config-ssl.md" >}}) for details. * **localSigner**: *(Optional)* Configuration of the local signer for the Network Map Service. Useful for debugging, testing or when HSM support is not available. * **keyStore**: @@ -104,7 +104,7 @@ version of Corda that does not support the new PKI structure (arbitrary length c * **adminListener**: To use the RPC API in the Identity Manager Service, you must define a configuration property called `adminListener`. - You can add `port`, `reconnect`, and `verbose`. Also, this property has an SSL field - see [SSL Settings](config-ssl.md) for more information. + You can add `port`, `reconnect`, and `verbose`. Also, this property has an SSL field - see [SSL Settings]({{< relref "config-ssl.md" >}}) for more information. * **port**: Port number to listen to for Admin RPC connections. * **verbose**: @@ -112,7 +112,7 @@ version of Corda that does not support the new PKI structure (arbitrary length c * **reconnect**: *(Optional)* Determines if a client should attempt to reconnect if the connection is dropped. Defaults to `true`. * **ssl**: - See [SSL Settings](config-ssl.md) for details. + See [SSL Settings]({{< relref "config-ssl.md" >}}) for details. {{% important %}} If the `adminListener` property is present in the configuration, this means that the service must only be used via Admin RPC. In this case, the `shell` configuration property will be disabled. The `shell` and `adminListener` properties cannot be used in the configuration at the same time. @@ -121,7 +121,7 @@ If the `adminListener` property is present in the configuration, this means that * **authServiceConfig**: The admin RPC interface requires an Auth Service to verify requests, which must be configured below in a `authServiceConfig` block. Typically - this is provided automatically by the [Zone Service](zone-service.md) (via an Angel Service), + this is provided automatically by the [Zone Service]({{< relref "zone-service.md" >}}) (via an Angel Service), however the parameters are detailed below for reference: * **host**: The hostname of the Auth Service. Required unless authentication is disabled. * **port**: The port number of the Auth Service. Required unless authentication is disabled. diff --git a/content/en/platform/corda/1.4/cenm/corda-networks.md b/content/en/platform/corda/1.4/cenm/corda-networks.md index 525b036017d..931e0f2636c 100644 --- a/content/en/platform/corda/1.4/cenm/corda-networks.md +++ b/content/en/platform/corda/1.4/cenm/corda-networks.md @@ -35,7 +35,7 @@ not the recommended deployment model outside of a testing setup.{{< /note >}} this service should be deployed (for more details on this see the Signing Service documentation), in brief, it is the intention that, unlike the Identity Manager, the signer is completely isolated from external communication. It only addresses a data source it shares with the Identity Manager. This ensure no hostile entity can penetrate the system -and force the signing of a certificate. See [Signing Services](signing-service.md) +and force the signing of a certificate. See [Signing Services]({{< relref "signing-service.md" >}}) * The signed certificates are recognised by the Identity Manager and returned to the requesting node (Nodes poll the Identity Manager periodically to see if their signature request has been fulfilled). @@ -80,7 +80,7 @@ one sub zone {{< /important >}} -For more information, see [Sub Zones](sub-zones.md) +For more information, see [Sub Zones]({{< relref "sub-zones.md" >}}) ### Operating a Segregated Sub Zone diff --git a/content/en/platform/corda/1.4/cenm/database-set-up.md b/content/en/platform/corda/1.4/cenm/database-set-up.md index 8d8e45721fa..a7d9bac7fb6 100644 --- a/content/en/platform/corda/1.4/cenm/database-set-up.md +++ b/content/en/platform/corda/1.4/cenm/database-set-up.md @@ -18,20 +18,20 @@ title: CENM Databases There are currently four types of CENM database schemas: -* The **Identity Manager** database schema is used by the [Identity Manager Service](identity-manager.md). It contains information relating to: +* The **Identity Manager** database schema is used by the [Identity Manager Service]({{< relref "identity-manager.md" >}}). It contains information relating to: * Certificate signing requests of nodes wanting to join the network. * Requests to revocation of nodes on the network. -* The **Network Map** database schema is used by the [Network Map Service](network-map.md). It contains information relating to: +* The **Network Map** database schema is used by the [Network Map Service]({{< relref "network-map.md" >}}). It contains information relating to: * The current participants on the network. * The current network parameters. * Any pending network parameter updates. -* The **Zone** database schema is used by the [Zone Service](zone-service.md). It contains information relating to: +* The **Zone** database schema is used by the [Zone Service]({{< relref "zone-service.md" >}}). It contains information relating to: * External addresses of services on the network. * Configurations of other services on the network. -* The **Auth** database schema is used by the [Auth Service](auth-service.md) to store RBAC data (users, permissions, groups). +* The **Auth** database schema is used by the [Auth Service]({{< relref "auth-service.md" >}}) to store RBAC data (users, permissions, groups). The services **must** use separate database schemas (either in the same database instance or in completely separate instances) due to the way the migrations are defined. If you try and run an Identity Manager Service, a Network Map Service, a Zone Service, or an Auth Service that shares the same database schema, it will result in errors. @@ -408,7 +408,7 @@ database = { } ``` -`runMigration` is set to `false` because the restricted CENM service instance database user does not have permissions to alter a database schema. See [CENM Database Configuration](config-database.md) for a complete list of database-specific properties. +`runMigration` is set to `false` because the restricted CENM service instance database user does not have permissions to alter a database schema. See [CENM Database Configuration]({{< relref "config-database.md" >}}) for a complete list of database-specific properties. diff --git a/content/en/platform/corda/1.4/cenm/deployment-kubernetes-auth.md b/content/en/platform/corda/1.4/cenm/deployment-kubernetes-auth.md index ec9c95ed665..eaa8d231d26 100644 --- a/content/en/platform/corda/1.4/cenm/deployment-kubernetes-auth.md +++ b/content/en/platform/corda/1.4/cenm/deployment-kubernetes-auth.md @@ -12,7 +12,7 @@ weight: 20 # CENM Auth Service Helm Chart -This Helm chart is to configure, deploy, and run the [CENM Auth Service](auth-service.md) on Kubernetes. +This Helm chart is to configure, deploy, and run the [CENM Auth Service]({{< relref "auth-service.md" >}}) on Kubernetes. ## Example usage @@ -49,4 +49,4 @@ helm install cenm-auth auth --set prefix=cenm --set acceptLicense=Y --set volume | `sleepTimeAfterError` | Sleep time (in seconds) after an error occurred | `120` | | `logsContainersEnabled` | Enable container displaying live logs | `true` {{< /table >}} -For additional information on database connection details refer to the official documentation: [database documentation](config-database.md). +For additional information on database connection details refer to the official documentation: [database documentation]({{< relref "config-database.md" >}}). diff --git a/content/en/platform/corda/1.4/cenm/deployment-kubernetes-idman.md b/content/en/platform/corda/1.4/cenm/deployment-kubernetes-idman.md index 3c9192c2cfb..70277ddb7ff 100644 --- a/content/en/platform/corda/1.4/cenm/deployment-kubernetes-idman.md +++ b/content/en/platform/corda/1.4/cenm/deployment-kubernetes-idman.md @@ -12,11 +12,11 @@ weight: 100 # CENM Identity Manager Helm Chart -This Helm chart is to configure, deploy, and run the CENM [Identity Manager Service](identity-manager.md) on Kubernetes. +This Helm chart is to configure, deploy, and run the CENM [Identity Manager Service]({{< relref "identity-manager.md" >}}) on Kubernetes. ## Example usage -The example below shows a command that triggers the Helm chart for the [Zone Service](zone-service.md): +The example below shows a command that triggers the Helm chart for the [Zone Service]({{< relref "zone-service.md" >}}): ```bash helm install cenm-idman idman --set prefix=cenm --set acceptLicense=Y @@ -60,4 +60,4 @@ helm install cenm-idman idman --set idmanPublicIP=X.X.X.X --set prefix=cenm --se | `logsContainersEnabled` | Defines whether the container displaying live logs is enabled or disabled | `true` | {{< /table >}} -For additional information on database connection details refer to the official documentation: [database documentation](config-database.md). +For additional information on database connection details refer to the official documentation: [database documentation]({{< relref "config-database.md" >}}). diff --git a/content/en/platform/corda/1.4/cenm/deployment-kubernetes-nmap.md b/content/en/platform/corda/1.4/cenm/deployment-kubernetes-nmap.md index b390b1bcff0..7495a41292e 100644 --- a/content/en/platform/corda/1.4/cenm/deployment-kubernetes-nmap.md +++ b/content/en/platform/corda/1.4/cenm/deployment-kubernetes-nmap.md @@ -12,7 +12,7 @@ weight: 200 # CENM Network Map Service Helm Chart -This Helm chart is to configure, deploy, and run the [CENM Network Map Service](network-map.md) on Kubernetes. +This Helm chart is to configure, deploy, and run the [CENM Network Map Service]({{< relref "network-map.md" >}}) on Kubernetes. ## Example usage @@ -61,4 +61,4 @@ helm install nmap nmap --set shell.password="superDifficultPassword" | `logsContainersEnabled` | Enable container displaying live logs | `true` {{< /table >}} -For additional information on database connection details refer to the official documentation: [database documentation](config-database.md). +For additional information on database connection details refer to the official documentation: [database documentation]({{< relref "config-database.md" >}}). diff --git a/content/en/platform/corda/1.4/cenm/deployment-kubernetes-signer.md b/content/en/platform/corda/1.4/cenm/deployment-kubernetes-signer.md index 972787067e7..8fb9160aad8 100644 --- a/content/en/platform/corda/1.4/cenm/deployment-kubernetes-signer.md +++ b/content/en/platform/corda/1.4/cenm/deployment-kubernetes-signer.md @@ -12,7 +12,7 @@ weight: 400 # CENM Signing Service Helm Chart -This Helm chart is to configure, deploy, and run the [CENM Signing Service](signing-service.md) on Kubernetes. +This Helm chart is to configure, deploy, and run the [CENM Signing Service]({{< relref "signing-service.md" >}}) on Kubernetes. As the initial step this chart runs automatically PKI tool which creates and stores certificates necessary for correct Corda Network operation. By default, the certificates have sample X.500 subject names (for example, the Identity Manager Service certificate has the subject name “CN=Test Identity Manager Service Certificate, OU=HQ, O=HoldCo LLC, L=New York, C=US”). The subject name can be set by configuration options starting with `pki.certificates.` prefix. @@ -21,8 +21,8 @@ Passwords to the security certificates keys and keystores cannot be configurable For more information about PKI Tool and Certificate Hierarchy refer to: -* [Certificate Hierarchy Guide](pki-guide.md) -* [PKI Tool](pki-tool.md) +* [Certificate Hierarchy Guide]({{< relref "pki-guide.md" >}}) +* [PKI Tool]({{< relref "pki-tool.md" >}}) ## Example usage diff --git a/content/en/platform/corda/1.4/cenm/deployment-kubernetes-zone.md b/content/en/platform/corda/1.4/cenm/deployment-kubernetes-zone.md index 0e250408d05..1ebbe74281d 100644 --- a/content/en/platform/corda/1.4/cenm/deployment-kubernetes-zone.md +++ b/content/en/platform/corda/1.4/cenm/deployment-kubernetes-zone.md @@ -12,7 +12,7 @@ weight: 500 # CENM Zone Service Helm Chart -This Helm chart is to configure, deploy, and run the [CENM Zone Service](zone-service.md) on Kubernetes. +This Helm chart is to configure, deploy, and run the [CENM Zone Service]({{< relref "zone-service.md" >}}) on Kubernetes. ## Example usage @@ -54,4 +54,4 @@ helm install cenm-zone auth --set idmanPublicIP=X.X.X.X --set prefix=cenm --set | `logsContainersEnabled` | Enable container displaying live logs | `true` {{< /table >}} -For additional information on database connection details, refer to the official documentation: [database documentation](config-database.md). +For additional information on database connection details, refer to the official documentation: [database documentation]({{< relref "config-database.md" >}}). diff --git a/content/en/platform/corda/1.4/cenm/deployment-kubernetes.md b/content/en/platform/corda/1.4/cenm/deployment-kubernetes.md index 2ec8ea252a6..88ee036c242 100644 --- a/content/en/platform/corda/1.4/cenm/deployment-kubernetes.md +++ b/content/en/platform/corda/1.4/cenm/deployment-kubernetes.md @@ -65,7 +65,7 @@ Recommended production specification for CENM components running on separate VMs ### Deployment overview The provided deployment runs all CENM services run inside a single, dedicated Kubernetes namespace (default name:`cenm`). -Each service runs in its own dedicated Kubernetes pod, with the exception of the [Angel Service](angel-service.md), which runs in the same pod as its managed service. +Each service runs in its own dedicated Kubernetes pod, with the exception of the [Angel Service]({{< relref "angel-service.md" >}}), which runs in the same pod as its managed service. {{< note >}} Naturally, the following command will not show a dedicated Angel Service pod: @@ -77,7 +77,7 @@ The Angel Service and its managed service must both be healthy in order for the The CENM network is bootstrapped with PKI certificates, and sample X.500 subject names are provided as defaults (for example, the Identity Manager Service certificate subject is “CN=Test Identity Manager Service Certificate, OU=HQ, O=HoldCo LLC, L=New York, C=US”). -These can be configured in the [Signing Service Helm chart](deployment-kubernetes-signer.md). +These can be configured in the [Signing Service Helm chart]({{< relref "deployment-kubernetes-signer.md" >}}). There are two ways of bootstrapping a new CENM environment: @@ -116,7 +116,7 @@ The deployment steps are given below: - Install [Docker](https://www.docker.com/get-started). Docker is required to run the CENM CLI tool. -- Download the Docker image with CENM [Command-Line Interface (CLI) tool](cenm-cli-tool.md) so you can manage CENM services: +- Download the Docker image with CENM [Command-Line Interface (CLI) tool]({{< relref "cenm-cli-tool.md" >}}) so you can manage CENM services: ```bash docker pull corda/enterprise-cenm-cli:1.4.4-zulu-openjdk8u242 @@ -210,7 +210,7 @@ cd k8s/helm ## Network operations -Use the CENM [Command Line Interface (CLI) Tool](cenm-cli-tool.md) to access the [Gateway Service](gateway-service.md) from your local machine. +Use the CENM [Command Line Interface (CLI) Tool]({{< relref "cenm-cli-tool.md" >}}) to access the [Gateway Service]({{< relref "gateway-service.md" >}}) from your local machine. To start CENM CLI Tool, run Docker command starting Docker container with the tool: @@ -234,7 +234,7 @@ You can now use `cemn` commands from within the running Docker container: ./cenm context login -s -u -p http://:8080 ``` -The [Gateway Service](gateway-service.md) is a gateway between the [Auth Service](auth-service.md) and front end services in CENM. It allows you to perform all network operations on the [Identity Manager Service](identity-manager.md), the [Network Map Service](network-map.md), and the [Signing Service](signing-service.md). +The [Gateway Service]({{< relref "gateway-service.md" >}}) is a gateway between the [Auth Service]({{< relref "auth-service.md" >}}) and front end services in CENM. It allows you to perform all network operations on the [Identity Manager Service]({{< relref "identity-manager.md" >}}), the [Network Map Service]({{< relref "network-map.md" >}}), and the [Signing Service]({{< relref "signing-service.md" >}}). The IP address is dynamically allocated for each deployment and can be found with `kubectl get svc`. Use the following command to ensure that you are pointing at the correct namespace: @@ -358,7 +358,7 @@ database { ### Update network parameters -Use the CENM [Command-Line (CLI) tool](cenm-cli-tool.md) to run commands to update the network parameters. +Use the CENM [Command-Line (CLI) tool]({{< relref "cenm-cli-tool.md" >}}) to run commands to update the network parameters. See the CENM documentation for more information about the list of available [network parameters]({{< relref "./config-network-parameters.md" >}}) and instructions on [updating network parameters]({{< relref "./updating-network-parameters.md" >}}). @@ -373,7 +373,7 @@ This operation is scheduled to take place at regular intervals (by default, once ### Signing Service configuration -The Signing Service is not managed by the [Angel Service](angel-service.md) in this deployment, therefore any CENM Command-Line Interface (CLI) tool commands trying to change the Signing Service configuration will take no effect. +The Signing Service is not managed by the [Angel Service]({{< relref "angel-service.md" >}}) in this deployment, therefore any CENM Command-Line Interface (CLI) tool commands trying to change the Signing Service configuration will take no effect. To change the Singing Service configuration, you must log in to a Kubernetes pod, update the configuration file, and restart the service. ## Delete Network @@ -457,13 +457,13 @@ You must modify the following values in the `values.yaml` file: There are a number of settings provided on each Helm chart, which allow easy customisation of common options. Each CENM service has its own dedicated page with more detailed documentation: -* [Auth Service](deployment-kubernetes-auth.md) -* [Gateway Service](deployment-kubernetes-gateway.md) -* [Identity Manager Service](deployment-kubernetes-idman.md) -* [Network Map Service](deployment-kubernetes-nmap.md) -* [Corda Notary](deployment-kubernetes-notary.md) -* [Signing Service](deployment-kubernetes-signer.md) -* [Zone Service](deployment-kubernetes-zone.md) +* [Auth Service]({{< relref "deployment-kubernetes-auth.md" >}}) +* [Gateway Service]({{< relref "deployment-kubernetes-gateway.md" >}}) +* [Identity Manager Service]({{< relref "deployment-kubernetes-idman.md" >}}) +* [Network Map Service]({{< relref "deployment-kubernetes-nmap.md" >}}) +* [Corda Notary]({{< relref "deployment-kubernetes-notary.md" >}}) +* [Signing Service]({{< relref "deployment-kubernetes-signer.md" >}}) +* [Zone Service]({{< relref "deployment-kubernetes-zone.md" >}}) ### Overriding Service Configuration @@ -493,7 +493,7 @@ helm install cenm-database bitnami/postgresql Follow the instructions displayed by the script output to connect to the database server via `psql`. You can create a separate database server for each CENM service by running the Helm script multiple times with different names -and then setting up the database user/schema, following the instructions in the [CENM database setup](database-set-up.md) section. +and then setting up the database user/schema, following the instructions in the [CENM database setup]({{< relref "database-set-up.md" >}}) section. Alternatively, you can create several databases inside the single PostgresSQL server you have just deployed, by running the following DDL commands: diff --git a/content/en/platform/corda/1.4/cenm/ejbca-plugin.md b/content/en/platform/corda/1.4/cenm/ejbca-plugin.md index b3bde42393e..3025bef7aee 100644 --- a/content/en/platform/corda/1.4/cenm/ejbca-plugin.md +++ b/content/en/platform/corda/1.4/cenm/ejbca-plugin.md @@ -428,7 +428,7 @@ From CENM 1.4, each signing task has a new property called `plugin`, which consi To run the EJBCA plug-in, you need to: -1. Specify its JAR path for CSR and CRL signing tasks in the Signing Service configuration (see [Signing Service](signing-service.md) for details). +1. Specify its JAR path for CSR and CRL signing tasks in the Signing Service configuration (see [Signing Service]({{< relref "signing-service.md" >}}) for details). 2. Run the Signing Service in the standard way: ```bash diff --git a/content/en/platform/corda/1.4/cenm/enm-components.md b/content/en/platform/corda/1.4/cenm/enm-components.md index 77a3267b567..1bca44b92f0 100644 --- a/content/en/platform/corda/1.4/cenm/enm-components.md +++ b/content/en/platform/corda/1.4/cenm/enm-components.md @@ -108,7 +108,7 @@ environments: * Postgres * SQL Server -For details of supported versions and configuration, see [CENM Databases](database-set-up.md). +For details of supported versions and configuration, see [CENM Databases]({{< relref "database-set-up.md" >}}). # Public Key Infrastructure (PKI) @@ -120,7 +120,7 @@ By design, they only have the ability to talk *to* the other CENM components, th In addition, signing a CRR or CSR, and potentially the Network Parameters, *should* require a human to interact with the HSM via some manual authentication mechanism. -See [Certificate Hierarchy Guide](pki-guide.md) for a detailed guide to PKI. +See [Certificate Hierarchy Guide]({{< relref "pki-guide.md" >}}) for a detailed guide to PKI. # The Node diff --git a/content/en/platform/corda/1.4/cenm/enm-with-ssl.md b/content/en/platform/corda/1.4/cenm/enm-with-ssl.md index b3785329947..19b23bddc6c 100644 --- a/content/en/platform/corda/1.4/cenm/enm-with-ssl.md +++ b/content/en/platform/corda/1.4/cenm/enm-with-ssl.md @@ -83,7 +83,7 @@ acting as clients of the network. ### SSL Certificate Configuring All components should be configured to use SSL with the following configuration block. More details can be found in -[Identity Manager Configuration Parameters](config-identity-manager-parameters.md) and [Network Map Configuration Parameters](config-network-map-parameters.md). +[Identity Manager Configuration Parameters]({{< relref "config-identity-manager-parameters.md" >}}) and [Network Map Configuration Parameters]({{< relref "config-network-map-parameters.md" >}}). ```docker ssl = { diff --git a/content/en/platform/corda/1.4/cenm/identity-manager.md b/content/en/platform/corda/1.4/cenm/identity-manager.md index 900b466cca7..0345409c132 100644 --- a/content/en/platform/corda/1.4/cenm/identity-manager.md +++ b/content/en/platform/corda/1.4/cenm/identity-manager.md @@ -82,7 +82,7 @@ The main elements that need to be configured for the Identity Manager are: {{< note >}} -See [Identity Manager Configuration Parameters](config-identity-manager-parameters.md) for a detailed explanation about each possible parameter. +See [Identity Manager Configuration Parameters]({{< relref "config-identity-manager-parameters.md" >}}) for a detailed explanation about each possible parameter. {{< /note >}} ### Address @@ -138,7 +138,7 @@ database { {{< note >}} Due to the way the migrations are defined, if the Identity Manager and Network Map Services are using the same database instance then they *must* use separate database schemas. For more information regarding the supported databases -along with the schema see [CENM Databases](database-set-up.md). +along with the schema see [CENM Databases]({{< relref "database-set-up.md" >}}). {{< /note >}} @@ -184,7 +184,7 @@ database { ### Embedded shell (optional) -See [Shell Configuration](../../../../../en/platform/corda/1.4/cenm/shell.html#shell-configuration) for more information on how to configure the shell. +See [Shell Configuration]({{< relref "../../../../../en/platform/corda/1.4/cenm/shell.md#shell-configuration" >}}) for more information on how to configure the shell. ### Issuance Workflow @@ -267,12 +267,12 @@ workflows { } ``` -See [Workflow](workflow.md) for more information. +See [Workflow]({{< relref "workflow.md" >}}) for more information. ###### Jira Project Configuration -See [Jira Set-Up](jira-setup.md) for more information about how to configure a Jira project for CSR approval. +See [Jira Set-Up]({{< relref "jira-setup.md" >}}) for more information about how to configure a Jira project for CSR approval. #### CSR Signing Mechanism @@ -290,11 +290,11 @@ approval mechanism above, this can be achieved via one of two mechanisms: The local Signing Service is recommended for testing and toy environments. Given a local key store containing the relevant signing keys, it provides the functionality to automatically sign all approved CSRs on a configured schedule. No human interaction is needed and the credentials for the key stores have to be provided upfront. The service is an -integrated signer that is a cut-down version of the standalone [Signing Services](signing-service.md) and provides no HSM integration or +integrated signer that is a cut-down version of the standalone [Signing Services]({{< relref "signing-service.md" >}}) and provides no HSM integration or ability to manually verify changes. It is strongly recommended against using this for production environments. In order for the local signer to function, it needs to be able to access Identity Manager’s certificate and keypair -which should have been previously generated (see [Certificate Hierarchy Guide](pki-guide.md) for more information). The local signer uses local +which should have been previously generated (see [Certificate Hierarchy Guide]({{< relref "pki-guide.md" >}}) for more information). The local signer uses local key stores which should include the necessary signing keys along with their full certificate chains. To enable the local signer, the top level `localSigner` configuration block should be added to the configuration file: @@ -317,7 +317,7 @@ signing any CSR requests along with the full certificate chain back to the root ##### External Signing Service -The production grade signing mechanism is the external [Signing Services](signing-service.md). This has all the functionality of the +The production grade signing mechanism is the external [Signing Services]({{< relref "signing-service.md" >}}). This has all the functionality of the integrated local signer as well as HSM integration and the ability for a user to interactively verify and sign incoming CSRs. It should be used in all production environments where maximum security and validation checks are required. @@ -357,7 +357,7 @@ This parameter can be omitted if desired, in which case it will default to port {{< /note >}} {{< note >}} -All inter-service communication can be configured with SSL support. See [Configuring the CENM services to use SSL](enm-with-ssl.md). +All inter-service communication can be configured with SSL support. See [Configuring the CENM services to use SSL]({{< relref "enm-with-ssl.md" >}}). {{< /note >}} @@ -479,7 +479,7 @@ workflows { } ``` -See [Workflow](workflow.md) for more information. +See [Workflow]({{< relref "workflow.md" >}}) for more information. #### CRR Signing Mechanism @@ -501,7 +501,7 @@ Identity Manager. That is, the same key used for signing approved CSRs will be u ##### External Signing Service -Also similarly to CSR signing, the production grade signing mechanism for CRRs is the external [Signing Services](signing-service.md). +Also similarly to CSR signing, the production grade signing mechanism for CRRs is the external [Signing Services]({{< relref "signing-service.md" >}}). This has all the functionality of the integrated local signer as well as HSM integration and the ability for a user to interactively verify and sign incoming CRRs. It should be used in all production environments where maximum security and validation checks are required. @@ -537,7 +537,7 @@ This parameter can be omitted if desired, in which case it will default to port {{< /note >}} {{< note >}} -All inter-service communication can be configured with SSL support. See [Configuring the CENM services to use SSL](enm-with-ssl.md). +All inter-service communication can be configured with SSL support. See [Configuring the CENM services to use SSL]({{< relref "enm-with-ssl.md" >}}). {{< /note >}} @@ -868,7 +868,7 @@ shell { The example below shows a more production-like configuration of the Identity Manager. It is configured with an Issuance and Revocation workflow, using Jira workflows for CSR/CRR approvals, no local signer, and using SSL for secure communication between CENM services. In this scenario, all approved requests would be signed using an external signing -service (see [Signing Services](signing-service.md)). +service (see [Signing Services]({{< relref "signing-service.md" >}})). ```docker address = "localhost:10000" diff --git a/content/en/platform/corda/1.4/cenm/network-map-overview.md b/content/en/platform/corda/1.4/cenm/network-map-overview.md index 196fc1ceea1..6b120083dc8 100644 --- a/content/en/platform/corda/1.4/cenm/network-map-overview.md +++ b/content/en/platform/corda/1.4/cenm/network-map-overview.md @@ -200,8 +200,8 @@ parameters change. * **whitelistedContractImplementations**: List of whitelisted versions of contract code. For each contract class there is a list of hashes of the approved CorDapp JAR versions containing that contract. Read -more about *contract constraints* in the [contract constraints doc](https://docs.corda.net/api-contract-constraints.html). See -[Contract Whitelist Generation](contract-whitelisting.md) for how to configure this in the network parameters +more about *contract constraints* in the [contract constraints doc](https://docs.r3.com/api-contract-constraints.html). See +[Contract Whitelist Generation]({{< relref "contract-whitelisting.md" >}}) for how to configure this in the network parameters configuration file. diff --git a/content/en/platform/corda/1.4/cenm/network-map.md b/content/en/platform/corda/1.4/cenm/network-map.md index 82a167b8537..8975361a6c6 100644 --- a/content/en/platform/corda/1.4/cenm/network-map.md +++ b/content/en/platform/corda/1.4/cenm/network-map.md @@ -22,7 +22,7 @@ title: Network Map Service The Network Map Service acts as a directory for all participants on the network. It is responsible for recording essential information of each participant such as connection address and available services. See -[Network Map Overview](network-map-overview.md) for an in-depth explanation. +[Network Map Overview]({{< relref "network-map-overview.md" >}}) for an in-depth explanation. ## Running The Network Map Service @@ -115,7 +115,7 @@ Similar to the Identity Manager the main elements that need to be configured for * [Admin RPC Interface](#admin-rpc-interface) {{< note >}} -See [Network Map Configuration Parameters](config-network-map-parameters.md) for a detailed explanation about each possible parameter. +See [Network Map Configuration Parameters]({{< relref "config-network-map-parameters.md" >}}) for a detailed explanation about each possible parameter. {{< /note >}} ### Address @@ -171,7 +171,7 @@ database { {{< note >}} Due to the way the migrations are defined, if the Identity Manager and Network Map Services are using the same database instance then they *must* use separate database schemas. For more information regarding the supported databases -along with the schema see [CENM Databases](database-set-up.md). +along with the schema see [CENM Databases]({{< relref "database-set-up.md" >}}). {{< /note >}} @@ -219,7 +219,7 @@ database { ### Embedded shell (optional) -See [Shell Configuration](../../../../../en/platform/corda/1.4/cenm/shell.html#shell-configuration) for more information on how to configure the shell. +See [Shell Configuration]({{< relref "../../../../../en/platform/corda/1.4/cenm/shell.md#shell-configuration" >}}) for more information on how to configure the shell. ### Network Data Signing Mechanism @@ -239,11 +239,11 @@ The local Signing Service is recommended for testing and toy environments. Given relevant signing keys, it provides the functionality to automatically sign all approved Network Map and Parameter updates on a configured schedule. No human interaction is needed and the credentials for the key stores have to be provided upfront. The service is an integrated signer that is a cut-down version of the standalone -[Signing Services](signing-service.md) and provides no HSM integration or ability to manually verify changes. It is strongly recommended +[Signing Services]({{< relref "signing-service.md" >}}) and provides no HSM integration or ability to manually verify changes. It is strongly recommended against using this for production environments. In order for the local signer to function, it needs to be able to access Network Map’s certificate and keypair -which should have been previously generated (see [Certificate Hierarchy Guide](pki-guide.md) for more information). The local signer uses local +which should have been previously generated (see [Certificate Hierarchy Guide]({{< relref "pki-guide.md" >}}) for more information). The local signer uses local key stores which should include the necessary signing keys along with their full certificate chains. To enable the local signer, the top level `localSigner` configuration block should be added to the configuration file: @@ -266,7 +266,7 @@ signing any network map or parameter changes along with the full certificate cha #### External Signing Service -The production grade signing mechanism is the external [Signing Services](signing-service.md). This has all the functionality of the +The production grade signing mechanism is the external [Signing Services]({{< relref "signing-service.md" >}}). This has all the functionality of the integrated local signer as well as HSM integration and the ability for a user to interactively verify and sign incoming network map or parameter changes. It should be used in all production environments where maximum security and validation checks are required. @@ -295,7 +295,7 @@ pollingInterval = 600000 ### Node Certificate Revocation Checking -In cases when the certificate revocation list infrastructure (See [Certificate Revocation List](certificate-revocation.md) for more information) +In cases when the certificate revocation list infrastructure (See [Certificate Revocation List]({{< relref "certificate-revocation.md" >}}) for more information) is provided, the additional validation for the node’s certificates can be enabled in the Network Map Service. This is achieved via the top-level `checkRevocation` flag set in the configuration file. This ensures that any node within the Network Map has a valid, trusted certificate. @@ -340,7 +340,7 @@ The `reconnect` parameter is optional - it will default to `reconnect = true` if {{< /note >}} {{< note >}} -All inter-service communication can be configured with SSL support. See [Configuring the CENM services to use SSL](enm-with-ssl.md). +All inter-service communication can be configured with SSL support. See [Configuring the CENM services to use SSL]({{< relref "enm-with-ssl.md" >}}). {{< /note >}} @@ -427,7 +427,7 @@ revocation { The `host` should correspond to the host part of the `address` value in the Identity Manager configuration. The `port` parameter for each service should correspond with the `port` value within the `enmListener` configuration block in -the service’s configuration. See [Network Map Configuration Parameters](config-network-map-parameters.md) for more information. +the service’s configuration. See [Network Map Configuration Parameters]({{< relref "config-network-map-parameters.md" >}}) for more information. You can also use the optional `timeout` parameter that enables you to set specific Network Map Service timeouts for communication to the Identity Manager and Revocation services. This allows for high node count network maps to operate at reliable performance levels. The `timeout` value is set in milliseconds and the default value is 30000 milliseconds. For example: @@ -447,7 +447,7 @@ revocation { ``` {{< note >}} -All inter-service communication can be configured with SSL support. See [Configuring the CENM services to use SSL](enm-with-ssl.md) +All inter-service communication can be configured with SSL support. See [Configuring the CENM services to use SSL]({{< relref "enm-with-ssl.md" >}}) {{< /note >}} @@ -605,7 +605,7 @@ useful especially when dealing with node’s deployment in environments with IP ## Obfuscated configuration files -To view the latest changes to the obfuscated configuration files, see [Obfuscation configuration file changes](obfuscated-config-file-changes.md). +To view the latest changes to the obfuscated configuration files, see [Obfuscation configuration file changes]({{< relref "obfuscated-config-file-changes.md" >}}). {{< note >}} You should not obfuscate the Network Parameters configuration file as it is not yet supported. diff --git a/content/en/platform/corda/1.4/cenm/pki-guide.md b/content/en/platform/corda/1.4/cenm/pki-guide.md index f115e9d42bb..691178f824a 100644 --- a/content/en/platform/corda/1.4/cenm/pki-guide.md +++ b/content/en/platform/corda/1.4/cenm/pki-guide.md @@ -125,9 +125,9 @@ Certificate revocation is typically required if a certificate was incorrectly is **What is the recommended configuration for the CRL?* You should use a High Availability deployment in order to avoid any impact caused by temporary downtimes. -See [Identity Manager Service](identity-manager.md) for an example configuration of such a deployment. +See [Identity Manager Service]({{< relref "identity-manager.md" >}}) for an example configuration of such a deployment. -See [Certificate Revocation List](certificate-revocation.md) for instructions on revoking certificates, and [Signing Services](signing-service.md) for +See [Certificate Revocation List]({{< relref "certificate-revocation.md" >}}) for instructions on revoking certificates, and [Signing Services]({{< relref "signing-service.md" >}}) for configuration of the Signing Service for CRLs (especially the `updatePeriod` option). @@ -270,6 +270,6 @@ is only required to provide only essential information to the tool. At the same defaults and have the configuration adjusted to the specific needs of different scenarios. {{< note >}} -To learn more about running the tool, see [Public Key Infrastructure (PKI) Tool](pki-tool.md). +To learn more about running the tool, see [Public Key Infrastructure (PKI) Tool]({{< relref "pki-tool.md" >}}). {{< /note >}} diff --git a/content/en/platform/corda/1.4/cenm/pki-specifications.md b/content/en/platform/corda/1.4/cenm/pki-specifications.md index 7ae3d8c8441..7fec2f72925 100644 --- a/content/en/platform/corda/1.4/cenm/pki-specifications.md +++ b/content/en/platform/corda/1.4/cenm/pki-specifications.md @@ -15,24 +15,24 @@ title: PKI Specifications # Public Key Infrastructure (PKI) Specifications -As described in the [Certificate Hierarchy Guide](pki-guide.md), Corda security relies heavily on the use of Public Key Infrastructure (PKI). Whether creating this hierarchy using the [PKI Tool](pki-tool.md) or setting up a Corda network on your own, your PKI must comply with existing Corda specifications. +As described in the [Certificate Hierarchy Guide]({{< relref "pki-guide.md" >}}), Corda security relies heavily on the use of Public Key Infrastructure (PKI). Whether creating this hierarchy using the [PKI Tool]({{< relref "pki-tool.md" >}}) or setting up a Corda network on your own, your PKI must comply with existing Corda specifications. Specifications and instructions are referenced here for the four scenarios below. Follow these guidelines to successfully create a Corda compliant hierarchy for your own use or to pass on to a third party service. ## Generating root, subordinate, and network certificates -For instructions on generating certificates, see the [PKI Tool](pki-tool.html#running-the-pki-tool) documentation. +For instructions on generating certificates, see the [PKI Tool]({{< relref "pki-tool.md#running-the-pki-tool" >}}) documentation. ## Setting up a network under an existing root -If you wish to set up a Corda network under an existing root and therefore are not using the PKI Tool, the certificate hierarchy you create should follow the guidelines specified in the [Certificate Hierarchy Guide](pki-guide.md). You may also find it helpful to reference the [Corda network policies](https://trust.corda.network/). +If you wish to set up a Corda network under an existing root and therefore are not using the PKI Tool, the certificate hierarchy you create should follow the guidelines specified in the [Certificate Hierarchy Guide]({{< relref "pki-guide.md" >}}). You may also find it helpful to reference the [Corda network policies](https://trust.corda.network/). ## Delegating network signing to a third party If you wish to delegate network signing to a third party software provider, this can be done partially (with the Certificate Authority only) or fully (with the Certificate Authority and the non-Certificate Authority). -[Use a signing plugin](signing-service.html#using-a-signing-plugin) to delegate this task to a third party software provider. See the [Developing Signing Plugins](signing-service.html#developing-signing-plugins) and the [EJBCA Sample Plugin](ejbca-plugin.md) documentation for guidance on creating a plugin that suits your needs. +[Use a signing plugin]({{< relref "signing-service.md#using-a-signing-plugin" >}}) to delegate this task to a third party software provider. See the [Developing Signing Plugins]({{< relref "signing-service.md#developing-signing-plugins" >}}) and the [EJBCA Sample Plugin]({{< relref "ejbca-plugin.md" >}}) documentation for guidance on creating a plugin that suits your needs. ## Using your own Certificate Authority software -To set up a Corda network using your own Certificate Authority software, [use a signing plugin](signing-service.html#using-a-signing-plugin). A signing plugin acts as a bridge between CENM services and one or more Signing Services. See the [Developing Signing Plugins](signing-service.html#developing-signing-plugins) and the [EJBCA Sample Plugin](ejbca-plugin.md) documentation for guidance on creating a plugin that suits your needs. +To set up a Corda network using your own Certificate Authority software, [use a signing plugin]({{< relref "signing-service.md#using-a-signing-plugin" >}}). A signing plugin acts as a bridge between CENM services and one or more Signing Services. See the [Developing Signing Plugins]({{< relref "signing-service.md#developing-signing-plugins" >}}) and the [EJBCA Sample Plugin]({{< relref "ejbca-plugin.md" >}}) documentation for guidance on creating a plugin that suits your needs. diff --git a/content/en/platform/corda/1.4/cenm/pki-tool.md b/content/en/platform/corda/1.4/cenm/pki-tool.md index 0e2abbfa2a5..39f9c266f8d 100644 --- a/content/en/platform/corda/1.4/cenm/pki-tool.md +++ b/content/en/platform/corda/1.4/cenm/pki-tool.md @@ -20,7 +20,7 @@ title: Public Key Infrastructure (PKI) Tool ## Overview -As described in the [Certificate Hierarchy Guide](pki-guide.md), a certificate hierarchy with certain properties is required to run a Corda +As described in the [Certificate Hierarchy Guide]({{< relref "pki-guide.md" >}}), a certificate hierarchy with certain properties is required to run a Corda network. Specifically, the certificate hierarchy should include the two main CENM entities - the Identity Manager and the Network Map - and ensure that all entities map back to one common root of trust. The key pairs and certificates for these entities are used within the Signing Service to sign related network data such as approved CSRs, CRRs, Network Map @@ -119,7 +119,7 @@ are used by the tool for storing generated certificates. hierarchy. {{< note >}} -The full list of the configuration parameters can be found in [Public Key Infrastructure (PKI) Tool Configuration Parameters](config-pki-tool-parameters.md). +The full list of the configuration parameters can be found in [Public Key Infrastructure (PKI) Tool Configuration Parameters]({{< relref "config-pki-tool-parameters.md" >}}). {{< /note >}} @@ -127,7 +127,7 @@ The full list of the configuration parameters can be found in [Public Key Infras This configuration block defines all key stores that should be used by the PKI Tool. Each key store can be either local (backed by a Java key store file) or HSM (backed by a LAN HSM device). For HSM key stores, the available options and -authentication methods will depend on the HSM being used. See [Public Key Infrastructure (PKI) Tool Configuration Parameters](config-pki-tool-parameters.md) for more details. +authentication methods will depend on the HSM being used. See [Public Key Infrastructure (PKI) Tool Configuration Parameters]({{< relref "config-pki-tool-parameters.md" >}}) for more details. A mixture of key store types is allowed. That is, it is possible to generate some key pairs within a HSM device and others locally. Note that mixing key store types is not supported for a given entity. @@ -151,7 +151,7 @@ map from the user-defined alias to certificate configuration. The alias serves t reference the given entity throughout the rest of the PKI Tool config. Secondly, it also defines the alias for the generated (or existing) certificate entry in the corresponding certificate store. The certificate configuration defines the entity specific properties of both the X509 certificate and associated key pair. See -[Public Key Infrastructure (PKI) Tool Configuration Parameters](config-pki-tool-parameters.md) for more information. +[Public Key Infrastructure (PKI) Tool Configuration Parameters]({{< relref "config-pki-tool-parameters.md" >}}) for more information. If the desire is to use the resultant certificate hierarchy in a Corda network, this configuration block must define a set of certificates that meet some basic requirements. In addition to the hierarchy having to be under a single trust @@ -286,7 +286,7 @@ certificates = { ##### Free-form Certificates As an alternative to using the templates, each key pair and certificate can defined using the standard configuration -options. See the [Public Key Infrastructure (PKI) Tool Configuration Parameters](config-pki-tool-parameters.md) documentation for all possible parameters, and see below for examples +options. See the [Public Key Infrastructure (PKI) Tool Configuration Parameters]({{< relref "config-pki-tool-parameters.md" >}}) documentation for all possible parameters, and see below for examples that use this approach. Note that the templates only support local key stores - using a HSM requires the certificate hierarchy to be defined without templates. @@ -298,7 +298,7 @@ explicitly defines all necessary CRL file configurations or all CRL distribution generated without the `Certificate Revocation List Distribution Point` extension and will therefore be incompatible with any network using strict revocation checking. -As outlined in the [Public Key Infrastructure (PKI) Tool Configuration Parameters](config-pki-tool-parameters.md) doc, this extension is defined using the following logic: +As outlined in the [Public Key Infrastructure (PKI) Tool Configuration Parameters]({{< relref "config-pki-tool-parameters.md" >}}) doc, this extension is defined using the following logic: * If the certificate configuration has the `crlDistributionUrl` parameter set then use this. @@ -348,7 +348,7 @@ subordinate’s CRL file must be hosted, and available, on this endpoint. {{< note >}} Existing revocations can be added to the CRL file via the `crl.revocations` parameter. See -[Public Key Infrastructure (PKI) Tool Configuration Parameters](config-pki-tool-parameters.md) for more information. +[Public Key Infrastructure (PKI) Tool Configuration Parameters]({{< relref "config-pki-tool-parameters.md" >}}) for more information. {{< /note >}} For a given certificate, the exact crlDistributionPoint extension can be defined explicitly (rather than inheriting from @@ -375,7 +375,7 @@ certificates { As previously mentioned, it is up to the network operator to ensure that any configured CRL endpoints are available. The Identity Manager supports hosting of these CRL files (see the the “CRL Configuration” section of the -[Identity Manager Service](identity-manager.md) doc). +[Identity Manager Service]({{< relref "identity-manager.md" >}}) doc). ##### HSM Libraries @@ -457,7 +457,7 @@ This will create a JAR called `azure-keyvault-with-deps.jar` which can be refere ##### Generating SSL Keys -As outlined in the [Configuring the CENM services to use SSL](enm-with-ssl.md) doc, all inter-service CENM communication can be configured to encrypt their +As outlined in the [Configuring the CENM services to use SSL]({{< relref "enm-with-ssl.md" >}}) doc, all inter-service CENM communication can be configured to encrypt their messages via SSL. This feature requires the operator to provide a set of SSL key pairs and certificates to each service, which can be generated using the PKI tool. @@ -484,7 +484,7 @@ certificates = { {{< note >}} HSM keys used by the Signing Service require an accompanying certificate store that contains all certificates in the chain, from the signing entity back to the root. This is because the full chains cannot be stored within the -HSMs. Refer to the [Signing Service](signing-service.md) documentation for more information. +HSMs. Refer to the [Signing Service]({{< relref "signing-service.md" >}}) documentation for more information. {{< /note >}} diff --git a/content/en/platform/corda/1.4/cenm/quick-start.md b/content/en/platform/corda/1.4/cenm/quick-start.md index 5521aabec89..e1ce3f999ad 100644 --- a/content/en/platform/corda/1.4/cenm/quick-start.md +++ b/content/en/platform/corda/1.4/cenm/quick-start.md @@ -33,12 +33,12 @@ deployment. For a full production environment you would need to modify this deployment to add: -* A [Signing Service](signing-service.md) deployment to replace the built-in (local) signing component of the Identity Manager and Network Map Services. -* A [Zone Service](zone-service.md) deployment to manage configuration deployment. -* [Angel Services](angel-service.md) around the [Identity Manager](identity-manager.md), [Network Map](network-map.md), +* A [Signing Service]({{< relref "signing-service.md" >}}) deployment to replace the built-in (local) signing component of the Identity Manager and Network Map Services. +* A [Zone Service]({{< relref "zone-service.md" >}}) deployment to manage configuration deployment. +* [Angel Services]({{< relref "angel-service.md" >}}) around the [Identity Manager]({{< relref "identity-manager.md" >}}), [Network Map]({{< relref "network-map.md" >}}), and Signing Services to fetch configurations from the Zone Service. -* An [Auth Service](auth-service.md) deployment to handle user authentication and authorisation. -* A [Gateway Service](gateway-service.md) deployment to act as a gateway from the user interface (CLI) to the back-end services. +* An [Auth Service]({{< relref "auth-service.md" >}}) deployment to handle user authentication and authorisation. +* A [Gateway Service]({{< relref "gateway-service.md" >}}) deployment to act as a gateway from the user interface (CLI) to the back-end services. ### Prerequisites @@ -83,7 +83,7 @@ You need to generate the PKI (key pairs and certificates each service will use) first before starting any services. {{< note >}} -For more information on the certificate hierarchy, see [Certificate Hierarchy Guide](pki-guide.md). +For more information on the certificate hierarchy, see [Certificate Hierarchy Guide]({{< relref "pki-guide.md" >}}). {{< /note >}} #### Example Configuration @@ -134,13 +134,13 @@ certificates = { ``` {{< note >}} -The passwords for the key stores are defaulted to “password” and the passwords for the trust stores are defaulted to “trustpass”. To change them in the configuration setting, see [Public Key Infrastructure (PKI) Tool](pki-tool.md)). +The passwords for the key stores are defaulted to “password” and the passwords for the trust stores are defaulted to “trustpass”. To change them in the configuration setting, see [Public Key Infrastructure (PKI) Tool]({{< relref "pki-tool.md" >}})). {{< /note >}} #### Run the PKI Tool This step generates the required certificate stores and key pairs using the -[Public Key Infrastructure (PKI) Tool](pki-tool.md). You will need to +[Public Key Infrastructure (PKI) Tool]({{< relref "pki-tool.md" >}}). You will need to extract the PKI tool distribution zip archive to a chosen location, and run it using a command such as: @@ -210,7 +210,7 @@ workflows { {{< note >}} The example uses a local H2 database. You can modify this to point to a separate database instance by modifying the `database` section. -See the “Database properties” section of [Identity Manager Service](identity-manager.md) for more information. +See the “Database properties” section of [Identity Manager Service]({{< relref "identity-manager.md" >}}) for more information. {{< /note >}} ### Run The Service @@ -344,7 +344,7 @@ checkRevocation = false ``` {{< note >}} -This example uses a local H2 database. You can modify this to point to a separate database instance by modifying the `database` section. See the “Database properties” section of [Network Map Service](network-map.md) for more information. +This example uses a local H2 database. You can modify this to point to a separate database instance by modifying the `database` section. See the “Database properties” section of [Network Map Service]({{< relref "network-map.md" >}}) for more information. {{< /note >}} @@ -393,7 +393,7 @@ NetworkParameters { } ``` -See [Updating the network parameters](updating-network-parameters.md) for more information on the process for setting and updating the parameters. +See [Updating the network parameters]({{< relref "updating-network-parameters.md" >}}) for more information on the process for setting and updating the parameters. ### Start the Network Map Service @@ -438,11 +438,11 @@ ssh testuser@localhost -p 20002 ``` Note: For the purpose of this exercise, the simplest settings have been used for all the services. However, you can configure them to run with more features, such as the following: -* Certificate revocation support (“Revocation workflow ” section within [Identity Manager Service](identity-manager.md)) -* More advanced CSR approval workflows (“Certificate approval mechanism” section within [Identity Manager Service](identity-manager.md)) -* External signing of CSRs/Network Map updates including HSM integration ([Signing Service](signing-service.md)) +* Certificate revocation support (“Revocation workflow ” section within [Identity Manager Service]({{< relref "identity-manager.md" >}})) +* More advanced CSR approval workflows (“Certificate approval mechanism” section within [Identity Manager Service]({{< relref "identity-manager.md" >}})) +* External signing of CSRs/Network Map updates including HSM integration ([Signing Service]({{< relref "signing-service.md" >}})) -{{< note >}}For more information, see the configuration sections within [Identity Manager Service](identity-manager.md) and [Network Map Service](network-map.md). {{< /note >}} +{{< note >}}For more information, see the configuration sections within [Identity Manager Service]({{< relref "identity-manager.md" >}}) and [Network Map Service]({{< relref "network-map.md" >}}). {{< /note >}} ## Bundled Service alternative diff --git a/content/en/platform/corda/1.4/cenm/release-notes.md b/content/en/platform/corda/1.4/cenm/release-notes.md index e29debaf95b..6961079f50f 100644 --- a/content/en/platform/corda/1.4/cenm/release-notes.md +++ b/content/en/platform/corda/1.4/cenm/release-notes.md @@ -54,7 +54,7 @@ We have updated the default value of the optional `timeout` parameter, introduce * We have fixed an issue where the maximum length of a certificate's serial number allowed by CENM was 28 digits (`NUMBER(28)` format in the database) - roughly about 93 bits of data. To extend the support (introduced in CENM 1.2) for third-party CAs such as [SwissPKI](https://www.swisspki.com/), the Identity Manager Service can now handle certificate serial numbers with sizes up to 20 octets/bytes (160 bits) to comply with [RFC 5280](https://tools.ietf.org/html/rfc5280). In addition, the [PKI Tool]({{< relref "../../../../../en/platform/corda/1.4/cenm/pki-tool.md" >}}) now generates certificates with serial number sizes of up to 16 octets/bytes. * We have fixed an issue where the [PKI Tool]({{< relref "../../../../../en/platform/corda/1.4/cenm/pki-tool.md" >}}) would throw an error when using [securosys HSM](https://www.securosys.com/) with multiple partitions. -* We have fixed an issue where the [signing request status command](#check-the-connection-status-of-the-signing-service) in the [CENM Command-line Interface Tool](cenm-cli-tool.md) did not work for requests with `COMPLETED` status. +* We have fixed an issue where the [signing request status command](#check-the-connection-status-of-the-signing-service) in the [CENM Command-line Interface Tool]({{< relref "cenm-cli-tool.md" >}}) did not work for requests with `COMPLETED` status. * We have fixed an issue where the `APP VERSION` column was not shown when running helm charts while bootstrapping CENM. ## Corda Enterprise Network Manager 1.4 @@ -71,11 +71,11 @@ Upgrading from CENM 1.3 to CENM 1.4 requires the following actions: * Manual update of all existing Signing Service configurations. - The SMR (Signable Material Retriever) Service, which prior to CENM 1.4 was used to handle plug-ins for signing data, [has been replaced](#new-signing-service-plug-in-functionality-replaces-the-smr-signable-material-retriever-service) by a plug-in loading logic inside the Signing Service. As a result, **all users must update their existing Signing Service configuration** when upgrading to CENM 1.4 - see the [CENM Upgrade Guide](../../../../../en/platform/corda/1.4/cenm/upgrade-notes.html#manual-update-of-all-existing-signing-service-configurations) for details. + The SMR (Signable Material Retriever) Service, which prior to CENM 1.4 was used to handle plug-ins for signing data, [has been replaced](#new-signing-service-plug-in-functionality-replaces-the-smr-signable-material-retriever-service) by a plug-in loading logic inside the Signing Service. As a result, **all users must update their existing Signing Service configuration** when upgrading to CENM 1.4 - see the [CENM Upgrade Guide]({{< relref "../../../../../en/platform/corda/1.4/cenm/upgrade-notes.md#manual-update-of-all-existing-signing-service-configurations" >}}) for details. * Zone Service database migration. - If you are upgrading to CENM 1.4 from CENM 1.3, you **must** set `runMigration = true` in the database configuration. See the [CENM Upgrade Guide](../../../../../en/platform/corda/1.4/cenm/upgrade-notes.html#zone-service-database-migration) for details. This is required due to a [Zone Service database schema change](#network-map-service-performance-enhancements). + If you are upgrading to CENM 1.4 from CENM 1.3, you **must** set `runMigration = true` in the database configuration. See the [CENM Upgrade Guide]({{< relref "../../../../../en/platform/corda/1.4/cenm/upgrade-notes.md#zone-service-database-migration" >}}) for details. This is required due to a [Zone Service database schema change](#network-map-service-performance-enhancements). {{< /warning >}} @@ -87,7 +87,7 @@ Read more about improvements of this release below. In CENM 1.4, we have adapted to CENM the internal Corda error handling logic introduced in Corda 4.5 and Corda Enterprise Edition 4.5 for Corda nodes. -As a result, CENM exceptions are now treated as CENM error codes and an error code is generated for each exception. The initial set of error codes, related to configuration parsing/validation errors, are described in the new [CENM error codes documentation page](cenm-error-codes.md). This is the start of a growing CENM error condition knowledge base, which will expand in future releases. +As a result, CENM exceptions are now treated as CENM error codes and an error code is generated for each exception. The initial set of error codes, related to configuration parsing/validation errors, are described in the new [CENM error codes documentation page]({{< relref "cenm-error-codes.md" >}}). This is the start of a growing CENM error condition knowledge base, which will expand in future releases. #### Network Map Service performance enhancements @@ -97,11 +97,11 @@ Performance and reliability improvements can be observed on the unsigned Network Performance is enhanced through the following combination of changes: -* A new, optional `timeout` parameter now enables you to set specific [Signing Service timeouts](../../../../../en/platform/corda/1.4/cenm/signing-service.html#signing-service-configuration-parameters) for communication to each of the services used within the signing processes defined in the network map, in a way that allows high node count network maps to get signed and to operate at reliable performance levels. You can also use the `timeout` parameter to set specific Network Map Service timeouts for communication to the [Identity Manager and Revocation services](../../../../../en/platform/corda/1.4/cenm/network-map.html#identity-manager--revocation-communication). The `timeout` parameter's values are stored in a new `timeout` column in the [Zone Service](../../../../../en/platform/corda/1.4/cenm/zone-service.html#signing-services-configuration)'s database tables `socket_config` and `signer_config` (refer to the [CENM Upgrade Guide](../../../../../en/platform/corda/1.4/cenm/upgrade-notes.html#zone-service-database-migration) for important details about migrating the Zone Service database from CENM 1.3). +* A new, optional `timeout` parameter now enables you to set specific [Signing Service timeouts]({{< relref "../../../../../en/platform/corda/1.4/cenm/signing-service.md#signing-service-configuration-parameters" >}}) for communication to each of the services used within the signing processes defined in the network map, in a way that allows high node count network maps to get signed and to operate at reliable performance levels. You can also use the `timeout` parameter to set specific Network Map Service timeouts for communication to the [Identity Manager and Revocation services]({{< relref "../../../../../en/platform/corda/1.4/cenm/network-map.md#identity-manager--revocation-communication" >}}). The `timeout` parameter's values are stored in a new `timeout` column in the [Zone Service]({{< relref "../../../../../en/platform/corda/1.4/cenm/zone-service.md#signing-services-configuration" >}})'s database tables `socket_config` and `signer_config` (refer to the [CENM Upgrade Guide]({{< relref "../../../../../en/platform/corda/1.4/cenm/upgrade-notes.md#zone-service-database-migration" >}}) for important details about migrating the Zone Service database from CENM 1.3). -* A [new API endpoint](../../../../../en/platform/corda/1.4/cenm/network-map-overview.html#http-network-map-protocol), `GET network-map/node-infos`, enables you to retrieve a list of all signed `NodeInfo` objects for _all_ the nodes in the network at once. +* A [new API endpoint]({{< relref "../../../../../en/platform/corda/1.4/cenm/network-map-overview.md#http-network-map-protocol" >}}), `GET network-map/node-infos`, enables you to retrieve a list of all signed `NodeInfo` objects for _all_ the nodes in the network at once. -* The following [new headers](../../../../../en/platform/corda/1.4/cenm/network-map-overview.html#http-network-map-protocol) for Network Map API responses now make headers more closely aligned with HTTP standards: +* The following [new headers]({{< relref "../../../../../en/platform/corda/1.4/cenm/network-map-overview.md#http-network-map-protocol" >}}) for Network Map API responses now make headers more closely aligned with HTTP standards: * The new header `X-Corda-Server-Version` has been added for all Network Map API responses (except for internal error responses with code 5xx) indicates the version of the Network Map and the available calls. It has a default value of `2`. * The new header `X-Corda-Platform-Version` replaces `Platform-version`. The old header name continues to be supported. * The new header `X-Corda-Client-Version` replaces `Client-version`. The old header name continues to be supported. @@ -112,7 +112,7 @@ The SMR (Signable Material Retriever) Service was introduced in CENM 1.2 with th As a result we have removed the SMR Service completely, thus reducing the number of CENM services and eliminating the need to maintain RPC servers and storage previously created by the default SMR plug-in. -A range of new functionality and changes, introduced to that effect, are described below. See the [Signing Service](signing-service.md) documentation for full details. +A range of new functionality and changes, introduced to that effect, are described below. See the [Signing Service]({{< relref "signing-service.md" >}}) documentation for full details. **Configuration changes** @@ -139,7 +139,7 @@ The following changes have been made as a result of the introduction of asynchro * API changes. To allow the Signing Service to query the signing status from the plug-in, new functions have been added for CA and non-CA plug-ins. In addition, all response classes now contain an optional `requestId` that is filled in by the plug-in - if the status is returned as `PENDING` but no `requestId` (tracking id) is provided, the signing will stop and the request will be discarded. * Shell signing. If the signing is done via Shell, the asynchronous tracking ids and statuses are printed to the console. In addition, new Shell menu items have been added for each signing task, which allow you to track the Asynchronous Signing request status. -* RPC function changes. To enable the complex task of returning Asynchronous Signing tracking ids and statuses when the signing is done via RPC, a number of changes have been made to RPC functions, including changes to requests and the addition of four new RPC requests used to query the status of each request via RPC. See the [Signing Service](signing-service.md) documentation for more information. +* RPC function changes. To enable the complex task of returning Asynchronous Signing tracking ids and statuses when the signing is done via RPC, a number of changes have been made to RPC functions, including changes to requests and the addition of four new RPC requests used to query the status of each request via RPC. See the [Signing Service]({{< relref "signing-service.md" >}}) documentation for more information. **Code changes** @@ -148,7 +148,7 @@ The following changes have been made as a result of the introduction of asynchro **Example CA plug-in** -CENM 1.4 ships with an example CA plug-in, which equips users with everything they need to know when creating their own plug-in. See the [Signing Service](signing-service.md) documentation for more information. +CENM 1.4 ships with an example CA plug-in, which equips users with everything they need to know when creating their own plug-in. See the [Signing Service]({{< relref "signing-service.md" >}}) documentation for more information. #### AWS native network deployment - reference deployment on AWS EKS, CloudHSM, PostgreSQL @@ -169,20 +169,20 @@ Not supported in CENM 1.4: See the [CENM deployment]({{< relref "../../../../../en/platform/corda/1.4/cenm/aws-deployment-guide.md" >}}) section for more information. #### Other changes -* We have added support for PostgreSQL 10.10 and 11.5 (JDBC 42.2.8), as noted in [CENM Databases](../../../../../en/platform/corda/1.4/cenm/database-set-up.html#supported-databases) and [CENM support matrix](../../../../../en/platform/corda/1.4/cenm/cenm-support-matrix.html#cenm-databases). +* We have added support for PostgreSQL 10.10 and 11.5 (JDBC 42.2.8), as noted in [CENM Databases]({{< relref "../../../../../en/platform/corda/1.4/cenm/database-set-up.md#supported-databases" >}}) and [CENM support matrix]({{< relref "../../../../../en/platform/corda/1.4/cenm/cenm-support-matrix.md#cenm-databases" >}}). * A `non-ca-plugin.jar` has been added to `signing-service-plugins` in Artifactory. * We have renamed the FARM Service, introduced in CENM 1.3, to [Gateway Service]({{< relref "../../../../../en/platform/corda/1.4/cenm/gateway-service.md" >}}). As a result, if you are [upgrading]({{< relref "../../../../../en/platform/corda/1.4/cenm/upgrade-notes.md" >}}) from CENM 1.3 to CENM 1.4, the FARM Service JAR file used in CENM 1.3 should be replaced with the Gateway Service JAR file used in CENM 1.4. -* In CENM 1.4 we have changed the way `subZoneID` is set in Signing Service configurations - see the [CENM upgrade guide](../../../../../en/platform/corda/1.4/cenm/upgrade-notes.html#change-in-setting-subzoneid-in-signing-service-configurations) for more details. +* In CENM 1.4 we have changed the way `subZoneID` is set in Signing Service configurations - see the [CENM upgrade guide]({{< relref "../../../../../en/platform/corda/1.4/cenm/upgrade-notes.md#change-in-setting-subzoneid-in-signing-service-configurations" >}}) for more details. ### Fixed issues -* We have fixed an issue where the [Auth Service](auth-service.md) could not start during database schema initialisation for PostgreSQL. +* We have fixed an issue where the [Auth Service]({{< relref "auth-service.md" >}}) could not start during database schema initialisation for PostgreSQL. * We have fixed an issue where the Signing Service failed to start, following setup without the SMR (Signable Material Retriever) Service, producing a `serviceLocations` configuration error. Note that the SMR Service has been removed in CENM 1.4 and its functionality has been merged with the Signing Service - see the [New features and enhancements](#new-features-and-enhancements) section above for more details. * We have fixed an issue where the `azure-keyvault-with-deps.jar` and `out.pkcs12` files were not copied to the `pki-pod` and PKI generation failed as a result. * We have fixed an issue where HSM passwords were not hidden in service logs. * We have fixed an issue where the Zone Service removed the `mode` field from the Signing Service's configuration with Utimaco and then failed to return this field to the Angel Service. * Commands for the Identity Manager Service and the Network Map Service, which previously returned no information, now indicate when no data is available. -* We have fixed an issue where [Gateway Service](gateway-service.md) (previously called FARM Service in CENM 1.2) logs were not available in the `logs-farm` container. +* We have fixed an issue where [Gateway Service]({{< relref "gateway-service.md" >}}) (previously called FARM Service in CENM 1.2) logs were not available in the `logs-farm` container. * We have fixed an issue where submitting a CRR request with CENM Command-line Interface Tool failed with the unexpected error `method parameters invalid`. * When using the Signing Service to manually perform signing tasks with multiple accounts for each task and the option to authenticate `ALL` users is selected, the Signing Service now indicates which user should enter their password. with multiple accounts for each task The Signing Service now prompts a specific user to login in while all are being authenticated. @@ -204,8 +204,8 @@ CENM 1.3.2 introduces fixes to known issues in CENM 1.3. ### Fixed issues -* We have fixed an issue where the maximum length of a certificate's serial number allowed by CENM was 28 digits (`NUMBER(28)` format in the database) - roughly about 93 bits of data. To extend the support (introduced in CENM 1.2) for third-party CAs such as [SwissPKI](https://www.swisspki.com/), the Identity Manager Service can now handle certificate serial numbers with sizes up to 20 octets/bytes (160 bits) to comply with [RFC 5280](https://tools.ietf.org/html/rfc5280). In addition, the [PKI Tool](pki-tool.md) now generates certificates with serial number sizes of up to 16 octets/bytes. -* We have fixed an issue where the [PKI Tool](pki-tool.md) would throw an error when using [securosys HSM](https://www.securosys.com/) with multiple partitions. +* We have fixed an issue where the maximum length of a certificate's serial number allowed by CENM was 28 digits (`NUMBER(28)` format in the database) - roughly about 93 bits of data. To extend the support (introduced in CENM 1.2) for third-party CAs such as [SwissPKI](https://www.swisspki.com/), the Identity Manager Service can now handle certificate serial numbers with sizes up to 20 octets/bytes (160 bits) to comply with [RFC 5280](https://tools.ietf.org/html/rfc5280). In addition, the [PKI Tool]({{< relref "pki-tool.md" >}}) now generates certificates with serial number sizes of up to 16 octets/bytes. +* We have fixed an issue where the [PKI Tool]({{< relref "pki-tool.md" >}}) would throw an error when using [securosys HSM](https://www.securosys.com/) with multiple partitions. ## Corda Enterprise Network Manager 1.3.1 @@ -280,8 +280,8 @@ CENM 1.2.3 introduces fixes to known issues in CENM 1.2. ### Fixed issues -* We have fixed an issue where the maximum length of a certificate's serial number allowed by CENM was 28 digits (`NUMBER(28)` format in the database) - roughly about 93 bits of data. To extend the support (introduced in CENM 1.2) for third-party CAs such as [SwissPKI](https://www.swisspki.com/), the Identity Manager Service can now handle certificate serial numbers with sizes up to 20 octets/bytes (160 bits) to comply with [RFC 5280](https://tools.ietf.org/html/rfc5280). In addition, the [PKI Tool](pki-tool.md) now generates certificates with serial number sizes of up to 16 octets/bytes. -* We have fixed an issue where the [PKI Tool](pki-tool.md) would throw an error when using [securosys HSM](https://www.securosys.com/) with multiple partitions. +* We have fixed an issue where the maximum length of a certificate's serial number allowed by CENM was 28 digits (`NUMBER(28)` format in the database) - roughly about 93 bits of data. To extend the support (introduced in CENM 1.2) for third-party CAs such as [SwissPKI](https://www.swisspki.com/), the Identity Manager Service can now handle certificate serial numbers with sizes up to 20 octets/bytes (160 bits) to comply with [RFC 5280](https://tools.ietf.org/html/rfc5280). In addition, the [PKI Tool]({{< relref "pki-tool.md" >}}) now generates certificates with serial number sizes of up to 16 octets/bytes. +* We have fixed an issue where the [PKI Tool]({{< relref "pki-tool.md" >}}) would throw an error when using [securosys HSM](https://www.securosys.com/) with multiple partitions. ## Corda Enterprise Network Manager 1.2.2 @@ -302,7 +302,7 @@ We are expanding our support for Docker to Corda Enterprise Network Manager. Furthermore, we are introducing a first reference deployment with Helm and Kubernetes. Out of the box - you will be able to deploy in minutes an ephemeral representative test network to complement your development cycle. -See [Kubernetes deployment documentation](deployment-kubernetes.md) for more details. +See [Kubernetes deployment documentation]({{< relref "deployment-kubernetes.md" >}}) for more details. **Support for third party CAs** @@ -310,7 +310,7 @@ To satisfy clients who wish to use third party software or service providers to The new service (SMR) extracts signable material from the Identity Manager and Network Map Services, and then delegates signing to a plug-in. Customers can implement their own plug-ins to integrate with external signing infrastructure and return signed material back to SMR to pass to the relevant CENM service. -See [Signing Services](signing-service.md) for more details. Also see [EJBCA Sample plug-in](ejbca-plugin.md) for a sample open source CA implementation. +See [Signing Services]({{< relref "signing-service.md" >}}) for more details. Also see [EJBCA Sample plug-in]({{< relref "ejbca-plugin.md" >}}) for a sample open source CA implementation. **CRL Endpoint Check tool** @@ -318,7 +318,7 @@ As a diagnostic aid in case of problems with TLS connections, CENM 1.2 introduce This stand alone tool checks CRL endpoint health of all certificates in a provided keystore, as a simpler alternative to manually extracting CRL endpoints individually from the certificate and then verifying them. -See [CRL Endpoint Check Tool](crl-endpoint-check-tool.md) for usage and further details. +See [CRL Endpoint Check Tool]({{< relref "crl-endpoint-check-tool.md" >}}) for usage and further details. ### Minor Features @@ -358,10 +358,10 @@ the logs files do not conflict. * Correct service healthcheck command when executed from the CRaSH shell. * Add new command to Network Map shell to view list of nodes that have accepted (or haven’t) a given parameters update (“view nodesAcceptedParametersUpdate accepted: , parametersHash: ”), -which can help to monitor the procedure of [Updating the network parameters](updating-network-parameters.md). +which can help to monitor the procedure of [Updating the network parameters]({{< relref "updating-network-parameters.md" >}}). * Add working directory argument for CENM services, which is a path prefix for config and certificate files. * Add `run networkParametersRegistration`, `run flagDay` and `run cancelUpdate` commands to the Network Map -service shell, to enable running flag days without restarting the service. See [Updating the network parameters](updating-network-parameters.md) for +service shell, to enable running flag days without restarting the service. See [Updating the network parameters]({{< relref "updating-network-parameters.md" >}}) for full details. * Add `view publicNetworkNodeInfos` command to Network Map Service shell, to see all public network participants’ node infos, including its’ platform version. @@ -405,14 +405,14 @@ configurations to be compatible with 1.1. **Oracle Database Support** Support has been added for Oracle DB versions 12cR2 and 11gR2 as a backend data store. -For full setup instructions see [CENM Databases](database-set-up.md). +For full setup instructions see [CENM Databases]({{< relref "database-set-up.md" >}}). **Configuration Migration Tool** To simplify the upgrade process from early versions of CENM a configuration migration tool has been added. This is intended to upgrade v0.2.2 / v0.3+ configurations to v1.1, including both restructuring changes to the configuration file and updating the value of fields (such as database driver class). -See [Config migration tool](tool-config-migration.md) for details on this tool. +See [Config migration tool]({{< relref "tool-config-migration.md" >}}) for details on this tool. **Hardware Security Module Support** @@ -471,18 +471,18 @@ fresh to the product but also those who are upgrading from pre-release versions. The Signing Service is a new addition to the suite of CENM services, sitting alongside the Identity Manager and Network Map. It provides a network operator with full control over the signing of node identity data (CSRs and CRRs) and global network data (Network Map and Network Parameters) and includes features such as HSM integration, signing scheduling and -support for multiple Network Map Services. See [Signing Services](signing-service.md) to learn more about this service. +support for multiple Network Map Services. See [Signing Services]({{< relref "signing-service.md" >}}) to learn more about this service. **Brand new PKI tooling** The PKI Tool enables a network operator to easily generate Corda-compliant certificate hierarchy (keys and certificates) as well as certificate revocation lists. The tool supports both local and HSM key stores and can be -customized with the configuration file. See [Public Key Infrastructure (PKI) Tool](pki-tool.md) to learn about all the features of the PKI Tool. +customized with the configuration file. See [Public Key Infrastructure (PKI) Tool]({{< relref "pki-tool.md" >}}) to learn about all the features of the PKI Tool. **Full End to End SSL communication** All CENM components now communicate over SSL with one another, this completes the removal of the “database as message -queue” of older versions. See [Configuring the CENM services to use SSL](enm-with-ssl.md) for more information. +queue” of older versions. See [Configuring the CENM services to use SSL]({{< relref "enm-with-ssl.md" >}}) for more information. **Security And Performance Fixes** @@ -510,13 +510,13 @@ versioned changes to the protocol without changing that which the Corda nodes de The Signing Service is a new addition to the suite of CENM services, sitting alongside the Identity Manager and Network Map. It provides a network operator with full control over the signing of node identity data (CSRs and CRRs) and global network data (Network Map and Network Parameters) and includes features such as HSM integration, signing scheduling and -support for multiple Network Map Services. See [Signing Services](signing-service.md) to learn more about this service. +support for multiple Network Map Services. See [Signing Services]({{< relref "signing-service.md" >}}) to learn more about this service. **Epoch Control** The PKI Tool enables a network operator to easily generate Corda-compliant certificate hierarchy (keys and certificates) as well as certificate revocation lists. The tool supports both local and HSM key stores and can be -customized with the configuration file. See [Public Key Infrastructure (PKI) Tool](pki-tool.md) to learn about all the features of the PKI Tool. +customized with the configuration file. See [Public Key Infrastructure (PKI) Tool]({{< relref "pki-tool.md" >}}) to learn about all the features of the PKI Tool. **Shell** @@ -541,7 +541,7 @@ sub-zones of nodes that operate in what appear to the nodes to be isolated netwo network parameters. Critically, however, their certificate governance remains under the jurisdiction of a global Doorman. This way, temporary benefits such as higher privacy, differential network parameters upgrade schedules or use of temporary private notaries can be delivered. Note that the ability to merge one sub-zone into another is not -currently supported. See the [Sub Zones](sub-zones.md) documentation for more information. +currently supported. See the [Sub Zones]({{< relref "sub-zones.md" >}}) documentation for more information. **Protocol Separation** @@ -556,12 +556,12 @@ The two top-level endpoints are now * `/network-map` * `/network-map-user` -see [Network Map Overview](network-map-overview.md) for more information. +see [Network Map Overview]({{< relref "network-map-overview.md" >}}) for more information. Another change that is introduced in the newest release is the ability to interact with the Doorman and Network Map services via a shell. The commands available currently mainly allow an operator to inspect the state of the service, for example by viewing the current set of nodes within the public network, or viewing the list of Certificate Signing -Requests that are awaiting approval. See the [Embedded Shell](shell.md) documentation for more information. +Requests that are awaiting approval. See the [Embedded Shell]({{< relref "shell.md" >}}) documentation for more information. Added support for overriding the default “increment previous value by 1” behaviour for epoch values during network parameter updates/initialisation. This allows a user to specify the epoch within the parameter config file and it diff --git a/content/en/platform/corda/1.4/cenm/setting-up-notary.md b/content/en/platform/corda/1.4/cenm/setting-up-notary.md index f77870110ce..97db3027d07 100644 --- a/content/en/platform/corda/1.4/cenm/setting-up-notary.md +++ b/content/en/platform/corda/1.4/cenm/setting-up-notary.md @@ -94,7 +94,7 @@ java -jar corda.jar --config-file --just-generate-node-info ### Setup Network Map Service -Follow instructions here [Network Map Service](network-map.md) +Follow instructions here [Network Map Service]({{< relref "network-map.md" >}}) ### Run The Notary diff --git a/content/en/platform/corda/1.4/cenm/signing-service.md b/content/en/platform/corda/1.4/cenm/signing-service.md index 410ea812417..d5fb2cbf993 100644 --- a/content/en/platform/corda/1.4/cenm/signing-service.md +++ b/content/en/platform/corda/1.4/cenm/signing-service.md @@ -19,9 +19,9 @@ title: Signing Service The Signing Service acts as a bridge between the main CENM services and the PKI/HSM infrastructure, enabling a network operator to verify and sign incoming requests and changes to the network. -The Signing Service forms a part of the main Corda Enterprise Network Manager (CENM) services, alongside the [Identity Manager Service](identity-manager.md) and the [Network Map Service](network-map.md) (and complemented by the [Auth Service](auth-service.md), the [Zone Service](zone-service.md), the [Angel Service](angel-service.md), and the [Gateway Service](gateway-service.md)). +The Signing Service forms a part of the main Corda Enterprise Network Manager (CENM) services, alongside the [Identity Manager Service]({{< relref "identity-manager.md" >}}) and the [Network Map Service]({{< relref "network-map.md" >}}) (and complemented by the [Auth Service]({{< relref "auth-service.md" >}}), the [Zone Service]({{< relref "zone-service.md" >}}), the [Angel Service]({{< relref "angel-service.md" >}}), and the [Gateway Service]({{< relref "gateway-service.md" >}})). -As mentioned in other CENM service documentation ([Identity Manager Service](identity-manager.md) and [Network Map Service](network-map.md)), the main CENM services +As mentioned in other CENM service documentation ([Identity Manager Service]({{< relref "identity-manager.md" >}}) and [Network Map Service]({{< relref "network-map.md" >}})), the main CENM services can be configured with an integrated *local signer* that will automatically sign all unsigned data using a provided key. While this is convenient, it is intended for use for development and testing environments, and **should not** be used in production environments. Instead, large and important changes to the network should go through a series of checks before @@ -31,7 +31,7 @@ particular data to require authentication from multiple users. ## Signing Service overview -The Signing Service supports the following HSMs (see [CENM support matrix](../../../../../en/platform/corda/1.4/cenm/cenm-support-matrix.html#hardware-security-modules-hsms) for more information): +The Signing Service supports the following HSMs (see [CENM support matrix]({{< relref "../../../../../en/platform/corda/1.4/cenm/cenm-support-matrix.md#hardware-security-modules-hsms" >}}) for more information): * Utimaco SecurityServer Se Gen2. * Gemalto Luna. @@ -65,7 +65,7 @@ for the configured signing keys. The overall flow of communication can be seen i {{< note >}} All inter-service communication can be configured with SSL support to ensure the connection is encrypted. See -[Configuring the CENM services to use SSL](enm-with-ssl.md) for more information. +[Configuring the CENM services to use SSL]({{< relref "enm-with-ssl.md" >}}) for more information. {{< /note >}} {{< note >}} @@ -141,7 +141,7 @@ The configuration for the Signing Service consists of the following sections: The Signing Service is interacted with via the shell, which is configured at the top level of the configuration file. This shell is similar to the interactive shell available in other CENM services and is configured in a similar way. See -[Shell Configuration](../../../../../en/platform/corda/1.4/cenm/shell.html#shell-configuration) for more information on how to configure the shell. +[Shell Configuration]({{< relref "../../../../../en/platform/corda/1.4/cenm/shell.md#shell-configuration" >}}) for more information on how to configure the shell. #### HSM libraries @@ -314,7 +314,7 @@ not be configured in production environments. Even though scheduled signing of CRLs should not be configured in production environment, they should be signed manually from time to time depending on its’ `nextUpdate` property. This is to ensure an up-to-date CRL is distributed in the network before the previous one expires. Conventionally they have a lifecycle of 6 months -and are manually signed every 3 months. See [CRL Endpoint Check Tool](crl-endpoint-check-tool.md) for more information how to check +and are manually signed every 3 months. See [CRL Endpoint Check Tool]({{< relref "crl-endpoint-check-tool.md" >}}) for more information how to check CRLs’ update deadlines. {{< /note >}} @@ -1896,7 +1896,7 @@ However, the tracking ID will still be returned and the request can be tracked v ### Other Sample Plugins -See [EJBCA Sample Plugin](ejbca-plugin.md) for sample open source CA implementation. +See [EJBCA Sample Plugin]({{< relref "ejbca-plugin.md" >}}) for sample open source CA implementation. ### Admin RPC Interface @@ -1952,4 +1952,4 @@ authServiceConfig { ## Obfuscated configuration files -To view the latest changes to the obfuscated configuration files, see [Obfuscation configuration file changes](obfuscated-config-file-changes.md). +To view the latest changes to the obfuscated configuration files, see [Obfuscation configuration file changes]({{< relref "obfuscated-config-file-changes.md" >}}). diff --git a/content/en/platform/corda/1.4/cenm/tool-config-migration.md b/content/en/platform/corda/1.4/cenm/tool-config-migration.md index 4a2e8ca304a..45d7d131352 100644 --- a/content/en/platform/corda/1.4/cenm/tool-config-migration.md +++ b/content/en/platform/corda/1.4/cenm/tool-config-migration.md @@ -45,7 +45,7 @@ java -jar config-migration-tool-<>.jar --config-file <> [o {{< important >}} v0.2.2 deployments of CENM require the data to be migrated to the v0.3+ database schema to function with -the v1.0 configurations generated by this tool. See [Upgrading Corda Enterprise Network Manager](upgrade-notes.md). +the v1.0 configurations generated by this tool. See [Upgrading Corda Enterprise Network Manager]({{< relref "upgrade-notes.md" >}}). {{< /important >}} diff --git a/content/en/platform/corda/1.4/cenm/tools-index.md b/content/en/platform/corda/1.4/cenm/tools-index.md index 0e014ade5fa..d33833ac9e4 100644 --- a/content/en/platform/corda/1.4/cenm/tools-index.md +++ b/content/en/platform/corda/1.4/cenm/tools-index.md @@ -17,18 +17,18 @@ A small number of tools and utilities are available to help with setting up, run ## Public Key Infrastructure -* [Public Key Infrastructure (PKI) Tool](pki-tool.md) +* [Public Key Infrastructure (PKI) Tool]({{< relref "pki-tool.md" >}}) ## General running of network -* [Certificate Revocation Request Submission Tool](tool-crr-submission.md) +* [Certificate Revocation Request Submission Tool]({{< relref "tool-crr-submission.md" >}}) ## Operations and administration -* [CENM Command-line Interface Tool](cenm-cli-tool.md) -* [CENM User Admin tool](user-admin.md) +* [CENM Command-line Interface Tool]({{< relref "cenm-cli-tool.md" >}}) +* [CENM User Admin tool]({{< relref "user-admin.md" >}}) ## Other Tools * [Config Obfuscation Tool]({{< relref "../../4.8/enterprise/tools-config-obfuscator.md" >}}) -* [CRL Endpoint Check Tool](crl-endpoint-check-tool.md) +* [CRL Endpoint Check Tool]({{< relref "crl-endpoint-check-tool.md" >}}) diff --git a/content/en/platform/corda/1.4/cenm/troubleshooting-common-issues.md b/content/en/platform/corda/1.4/cenm/troubleshooting-common-issues.md index 21b09ae1d9d..71a19a2c7bc 100644 --- a/content/en/platform/corda/1.4/cenm/troubleshooting-common-issues.md +++ b/content/en/platform/corda/1.4/cenm/troubleshooting-common-issues.md @@ -71,14 +71,14 @@ Identity Manager Service. To verify that issue 1 is not the culprit - verify that the Network Map signing process is still successfully running periodically. Unless the Network Map Service is configured for testing, it should have an external signing process -configured. See the “Signing Network Map and Network Parameters” section of [Signing Services](signing-service.md). If the service is +configured. See the “Signing Network Map and Network Parameters” section of [Signing Services]({{< relref "signing-service.md" >}}). If the service is configured to run with a local signer then verify that the configured sign interval is something fairly low to ensure that updates to the network map are persisted often (e.g. 1 minute). To verify that issue 2 is not the culprit - the logs of the Network Map Service should be checked. An error such as an invalid certificate is not recoverable and should be resolved out of band with the node operator and support. If there are any communication issues with the Identity Manager then the error will be logged and communication will be -retried after a short break. See the “Identity Manager Communication” section of [Network Map Service](network-map.md) to verify that the +retried after a short break. See the “Identity Manager Communication” section of [Network Map Service]({{< relref "network-map.md" >}}) to verify that the Identity Manager communication is correctly configured for the Network Map Service. @@ -138,7 +138,7 @@ IO. **Signing process is working as intended but timeout is configured too low** The timeout for a local signer can be configured via the service’s configuration file. See -[Identity Manager Configuration Parameters](config-identity-manager-parameters.md) and [Network Map Configuration Parameters](config-network-map-parameters.md) for more information. +[Identity Manager Configuration Parameters]({{< relref "config-identity-manager-parameters.md" >}}) and [Network Map Configuration Parameters]({{< relref "config-network-map-parameters.md" >}}) for more information. ### Explanation diff --git a/content/en/platform/corda/1.4/cenm/updating-network-parameters.md b/content/en/platform/corda/1.4/cenm/updating-network-parameters.md index 570bec3f45a..47bc2c9bf03 100644 --- a/content/en/platform/corda/1.4/cenm/updating-network-parameters.md +++ b/content/en/platform/corda/1.4/cenm/updating-network-parameters.md @@ -40,7 +40,7 @@ At a high level, the process is as follows: ## Editing network parameters configuration -See [Setting the Network Parameters](network-map.html#network-parameters) +See [Setting the Network Parameters]({{< relref "network-map.md#network-parameters" >}}) for information on the network parameters configuration file format and options. When updating the network parameters, ensure that the network parameters file has the diff --git a/content/en/platform/corda/1.4/cenm/upgrade-notes.md b/content/en/platform/corda/1.4/cenm/upgrade-notes.md index 22dd5c28390..936a9f69e0f 100644 --- a/content/en/platform/corda/1.4/cenm/upgrade-notes.md +++ b/content/en/platform/corda/1.4/cenm/upgrade-notes.md @@ -17,10 +17,10 @@ title: Upgrading Corda Enterprise Network Manager # Upgrading Corda Enterprise Network Manager This document provides instructions for upgrading your network management suite - Identity Manager Service (formerly -Doorman), Network Map Service, Signing Service, Zone Service, Auth Service, Angel Service - from previous versions to the newest version. Please consult the relevant [release notes](release-notes.md) of the release in question. If not specified, you may assume the versions you are currently using are still in force. +Doorman), Network Map Service, Signing Service, Zone Service, Auth Service, Angel Service - from previous versions to the newest version. Please consult the relevant [release notes]({{< relref "release-notes.md" >}}) of the release in question. If not specified, you may assume the versions you are currently using are still in force. {{< warning >}} -Before you start the upgrade, you must consult the [CENM Release Notes](release-notes.md) to confirm all changes between releases. +Before you start the upgrade, you must consult the [CENM Release Notes]({{< relref "release-notes.md" >}}) to confirm all changes between releases. {{< /warning >}} ## 1.3.x to 1.4 @@ -100,19 +100,19 @@ pluginJar CENM 1.3 introduces a significant number of services. You should upgrade to CENM 1.2.2 before upgrading to 1.3. The key steps for the upgrade are: -1. Generate new certificates for [FARM](gateway-service.md), [Auth](auth-service.md), and [Zone](zone-service.md) Services. +1. Generate new certificates for [FARM]({{< relref "gateway-service.md" >}}), [Auth]({{< relref "auth-service.md" >}}), and [Zone]({{< relref "zone-service.md" >}}) Services. 2. Generate a JWT token key pair for Auth Service. 3. Deploy the Gateway Service to provide a gateway between the CLI tool and the back-end services. 4. Deploy the Auth Service to provide user authentication and authorisation to other services. 5. Deploy the Zone Service to store configurations for the Identity Manager, Network Map, and Signing Services. 6. Create users in the Auth Service, for zone and subzone management. -7. Edit [Identity Manager Service](identity-manager.md), [Network Map Service](network-map.md), and [Signing Service](signing-service.md) configurations to remove shell access and add an admin listener configuration. -8. Edit the [Signing Service](signing-service.md) configuration so that signing tasks refer to service aliases generated by the Zone Service. -9. Set Identity Manager Service configuration in the [Zone Service](zone-service.md). +7. Edit [Identity Manager Service]({{< relref "identity-manager.md" >}}), [Network Map Service]({{< relref "network-map.md" >}}), and [Signing Service]({{< relref "signing-service.md" >}}) configurations to remove shell access and add an admin listener configuration. +8. Edit the [Signing Service]({{< relref "signing-service.md" >}}) configuration so that signing tasks refer to service aliases generated by the Zone Service. +9. Set Identity Manager Service configuration in the [Zone Service]({{< relref "zone-service.md" >}}). 10. Set Network Map Service configuration(s) in the Zone Service. 11. Set Signing Service configuation in the Zone Service. 12. Update existing service deployments. -13. Add [Angel Services](angel-service.md) to Identity Manager, Network Map, and Signing Services, to fetch configurations from the Zone +13. Add [Angel Services]({{< relref "angel-service.md" >}}) to Identity Manager, Network Map, and Signing Services, to fetch configurations from the Zone Service. ### Generating certificates and JWT @@ -120,14 +120,14 @@ The key steps for the upgrade are: You must generate SSL key pairs and certificates for the new services before deploying them. You can do this using the PKI tool, and it is best to replace the SSL certificates and keys for all services during this process. A draft PKI tool configuration -for generating the full SSL hierarchy is provided under [config-samples/upgrade-pki-tool.conf/](../../../../../en/platform/corda/1.4/cenm/config-samples/upgrade-pki-tool.conf). +for generating the full SSL hierarchy is provided under [config-samples/upgrade-pki-tool.conf](config-samples/upgrade-pki-tool.conf). {{% important %}} You must replace the `subject` and `crlDistributionUrl` entries in this configuration with values appropriate to your deployment. {{% /important %}} -To generate the JWT, refer to the [Auth Service](auth-service.md) documentation. +To generate the JWT, refer to the [Auth Service]({{< relref "auth-service.md" >}}) documentation. The generated keys and certificates will then need to be distributed to the service hosts, replacing the existing SSL (but not network trust root or other signing key/certificates). @@ -136,9 +136,9 @@ replacing the existing SSL (but not network trust root or other signing key/cert To deploy the new services, follow the guides in the service documentation: -* [Gateway Service](gateway-service.md) -* [Auth Service](auth-service.md) -* [Zone Service](zone-service.md) +* [Gateway Service]({{< relref "gateway-service.md" >}}) +* [Auth Service]({{< relref "auth-service.md" >}}) +* [Zone Service]({{< relref "zone-service.md" >}}) {{< note >}} You should deploy two Gateway Service instances - one for general access, accessible from user @@ -147,7 +147,7 @@ systems, and a second one in the secure network alongside the Signing Service. ### Create user(s) -The [Auth Service](auth-service.md) has an initial user who can manage users, however +The [Auth Service]({{< relref "auth-service.md" >}}) has an initial user who can manage users, however for separation of responsibility this user cannot manage services. Therefore you need to create user(s) for configuring the services, as well as potentially users to operate the services once they are configured, such as signing certificates. @@ -199,7 +199,7 @@ At this point you should shut down the previous services and replace their JAR f Do not start them quite yet, as they should be managed by the Angel Service. Add the `angel-1.3.0.jar` file to each managed service deployment (Identity Manager, Network Map, Zone), and configure the service start-up to be via the Angel Service. Details on the arguments to the Angel Service are covered in the -[Angel Service documentation](angel-service.md). +[Angel Service documentation]({{< relref "angel-service.md" >}}). ## 1.2.1 to 1.2.2 @@ -264,8 +264,8 @@ Ensure the services are not running before replacing the JAR files. CENM 1.1 supports multiple HSMs, however due to to the proprietary nature of the HSM libraries, the release does not work with these HSMs "out of the box". The user must provide the relevant libraries and reference them in the -configuration of the relevant component (Signing Service or PKI Tool). For more information, see [Signing Services](signing-service.md). -and [Public Key Infrastructure (PKI) Tool](pki-tool.md) for more information. +configuration of the relevant component (Signing Service or PKI Tool). For more information, see [Signing Services]({{< relref "signing-service.md" >}}). +and [Public Key Infrastructure (PKI) Tool]({{< relref "pki-tool.md" >}}) for more information. ## 0.3+ to 1.0 @@ -328,7 +328,7 @@ database { ### Configuration files CENM 1.0 Identity Manager and Network Map Services are not backward-compatible with configuration files for Doorman and Network Map Service versions 0.x. -Version 0.2.2 and 0.3 / 0.4 configuration files can be migrated to CENM 1.0 using the [configuration migration tool](tool-config-migration.md). +Version 0.2.2 and 0.3 / 0.4 configuration files can be migrated to CENM 1.0 using the [configuration migration tool]({{< relref "tool-config-migration.md" >}}). Using the generated 1.0 configurations, the services can be upgraded by stopping the services, swapping out the JAR file and configuration files, and restarting the services. @@ -385,7 +385,7 @@ and Revocation services cannot be known by the upgrader. {{< warning >}} If you require private network functionality or node certificate revocation checking then the configuration should be updated to include the appropriate settings. See the *Doorman & Revocation Communication* section -of the [Network Map Service](network-map.md) document for more information. +of the [Network Map Service]({{< relref "network-map.md" >}}) document for more information. {{< /warning >}} @@ -396,20 +396,20 @@ of the [Network Map Service](network-map.md) document for more information. The release modifies the Network Map Signing Service to request data through the Network Map Service rather than going directly to the database. Therefore the configuration needs to change to remove the redundant database configuration and instead adding the service endpoint. As this information cannot be known by the configuration upgrader, this has to be added -manually. See [Signing Services](signing-service.md) for more information on how to configure this. +manually. See [Signing Services]({{< relref "signing-service.md" >}}) for more information on how to configure this. #### The Certificate Revocation Request service requires a configuration update to specify communication the Revocation service Similarly to above, the CRR Signing Service now pulls data through the Revocation service and therefore requires a -configuration modification. See [Signing Services](signing-service.md) for more information on how to configure this. +configuration modification. See [Signing Services]({{< relref "signing-service.md" >}}) for more information on how to configure this. #### Setting the network parameters requires passing the root certificate When setting network parameters, the Network Map Service cannot validate the proposed notary certificates using the Doorman database. Hence the trusted root certificate now needs to be passed during setting of parameters. -See the “Setting the Network Parameters” section of the [Network Map Service](network-map.md) document for more information. +See the “Setting the Network Parameters” section of the [Network Map Service]({{< relref "network-map.md" >}}) document for more information. ## 0.1 to 0.2.1 diff --git a/content/en/platform/corda/1.4/cenm/user-admin.md b/content/en/platform/corda/1.4/cenm/user-admin.md index 219fc99af80..d5155dce3f1 100644 --- a/content/en/platform/corda/1.4/cenm/user-admin.md +++ b/content/en/platform/corda/1.4/cenm/user-admin.md @@ -34,14 +34,14 @@ You can only use the User Admin tool if you are registered to use the tool as an ## Access the CENM User Admin tool -You access the User Admin tool from the location of your [Gateway service](gateway-service.md) instance. Enter the full address of your Gateway service, including the port number, followed by `/admin` into a web browser. +You access the User Admin tool from the location of your [Gateway service]({{< relref "gateway-service.md" >}}) instance. Enter the full address of your Gateway service, including the port number, followed by `/admin` into a web browser. For example: `http://10.230.41.12:8080/admin` ### First login -Your initialisation credentials for logging in for the first time are established using the `--initial-user-name` and `--initial-user-password` commands when managing the configuration of the [Auth Service](auth-service.md). +Your initialisation credentials for logging in for the first time are established using the `--initial-user-name` and `--initial-user-password` commands when managing the configuration of the [Auth Service]({{< relref "auth-service.md" >}}). If you do not have these, you need to access them from the operator who configured your Auth Service. diff --git a/content/en/platform/corda/1.4/cenm/zone-service.md b/content/en/platform/corda/1.4/cenm/zone-service.md index ec4faac6e7f..22236dbda9a 100644 --- a/content/en/platform/corda/1.4/cenm/zone-service.md +++ b/content/en/platform/corda/1.4/cenm/zone-service.md @@ -30,7 +30,7 @@ The Zone Service stores relevant configurations for the following services: * Network Map Service * Signing Services -It uses the associated [Angel Service](angel-service.md) to deploy those configurations as needed. +It uses the associated [Angel Service]({{< relref "angel-service.md" >}}) to deploy those configurations as needed. Each Angel Service identifies itself to the Zone Service via an authentication token, referred to as the "zone token". The Zone Service also coordinates actions needed on Sub Zones (for example, new network parameters), which are executed @@ -54,7 +54,7 @@ The full list of configuration options follows below: - `--tls-keystore-password`: The password for the TLS keystore. Required if `--tls` is set to `true`. - `--tls-truststore`: The path for the TLS truststore. Required if `--tls` is set to `true`. - `--tls-truststore-password`: The password for the TLS truststore. Required if `--tls` is set to `true`. -- `--run-migration`: Defines whether schema migration is enabled on the database. Defaults to `false` if no value is provided. **Important:** if you are upgrading to CENM 1.4 from CENM 1.3, you **must** set this option to `true` due to a change in the Zone Service database schema - see the [CENM upgrade guide](upgrade-notes.md) for more information. +- `--run-migration`: Defines whether schema migration is enabled on the database. Defaults to `false` if no value is provided. **Important:** if you are upgrading to CENM 1.4 from CENM 1.3, you **must** set this option to `true` due to a change in the Zone Service database schema - see the [CENM upgrade guide]({{< relref "upgrade-notes.md" >}}) for more information. - `--jdbc-driver`: The path for the JAR file containing the JDBC driver for the database. - `--driver-class-name`: The name of the JDBC driver class within the JAR file specified by `--jdbc-driver`. - `--url`: The URL for the Zone Service's database. @@ -62,7 +62,7 @@ The full list of configuration options follows below: - `--password`: The password for the Zone Service's database. - `--current-schema`: Allows you to alter the session's current schema for the database. Use this configuration option when the schema name differs from the user name. Only valid for Oracle databases. - `--admin-listener-port`: The port where Angel Services connect to the Zone Service. -- `--disable-authentication`: Allows you to disable authentication and authorisation via the [Auth Service](auth-service.md). Only use this option in development environments. Defaults to `false` if no value is provided. +- `--disable-authentication`: Allows you to disable authentication and authorisation via the [Auth Service]({{< relref "auth-service.md" >}}). Only use this option in development environments. Defaults to `false` if no value is provided. - `--auth-host`: The hostname of the Auth Service. Required unless authentication and authorisation are disabled. - `--auth-port`: The port number of the Auth Service. Required unless authentication and authorisation are disabled. - `--auth-trust-store-location`: The location of the Auth Service trust root keystore. Required unless authentication and authorisation are disabled. @@ -170,7 +170,7 @@ serviceLocations = { ``` {{< note >}} -The `timeout` parameter used in the example above is optional. It allows to set a Signing Service timeout for communication to each of the services used within the signing processes defined in the [signers map](../../../../../en/platform/corda/1.4/cenm/signing-service.html#signers-map-entry-example), in a way that allows high node count network maps to get signed and to operate at reliable performance levels. The `timeout` value is set in milliseconds and the default value is 10000 milliseconds. The `timeout` parameter's value is stored in a column in the [Zone Service](zone-service.md)'s database tables `socket_config` and `signer_config` called `timeout`. This value can remain `null` (for example, if `timeout` is not defined in `serviceLocations`), in which case the default 10000 milliseconds value (`timeout = 10000`) will be used wherever applicable. Please note that currently, due to a known issue with `serviceLocations`, when the `timeout` parameter is passed to the Zone Service via the Signing Service's `serviceLocations` configuration block, only the `timeout` value of the first `serviceLocations` location will be taken into account and used for all other service locations. +The `timeout` parameter used in the example above is optional. It allows to set a Signing Service timeout for communication to each of the services used within the signing processes defined in the [signers map]({{< relref "../../../../../en/platform/corda/1.4/cenm/signing-service.md#signers-map-entry-example" >}}), in a way that allows high node count network maps to get signed and to operate at reliable performance levels. The `timeout` value is set in milliseconds and the default value is 10000 milliseconds. The `timeout` parameter's value is stored in a column in the [Zone Service]({{< relref "zone-service.md" >}})'s database tables `socket_config` and `signer_config` called `timeout`. This value can remain `null` (for example, if `timeout` is not defined in `serviceLocations`), in which case the default 10000 milliseconds value (`timeout = 10000`) will be used wherever applicable. Please note that currently, due to a known issue with `serviceLocations`, when the `timeout` parameter is passed to the Zone Service via the Signing Service's `serviceLocations` configuration block, only the `timeout` value of the first `serviceLocations` location will be taken into account and used for all other service locations. {{< /note >}} ## Interaction with Angel Services diff --git a/content/en/platform/corda/1.5/cenm/_index.md b/content/en/platform/corda/1.5/cenm/_index.md index d007c1a93af..4cebb0294ea 100644 --- a/content/en/platform/corda/1.5/cenm/_index.md +++ b/content/en/platform/corda/1.5/cenm/_index.md @@ -25,9 +25,8 @@ that are otherwise available from [Corda Network](https://corda.network), which {{< note >}} **Release notes** -* For all Corda Enterprise Network Manager release notes, see the [Corda Enterprise Network Manager release notes]({{< relref "../../../../../en/platform/corda/1.5/cenm/release-notes.md" >}}) page. -* For all Corda 4 Enterprise Edition release notes, see [Welcome to Corda - Corda 4 Enterprise](../../../../../en/platform/corda.html#corda-4-enterprise). -* For all Corda 4 Community Edition release notes, see [Welcome to Corda - Corda 4 Community Edition (Formerly Open Source)](../../../../../en/platform/corda.html#corda-4-community-edition-formerly-open-source). +* For all Corda Enterprise Network Manager release notes, see the [Corda Enterprise Network Manager release notes]({{< relref "../../../../../en/platform/corda/1.6/cenm/release-notes.md" >}}) page. +* For all Corda 4 Enterprise Edition and Community/Open Source release notes, see [Welcome to Corda]({{< relref "../../../../../en/platform/corda/_index.md" >}}). {{< /note >}} @@ -53,10 +52,10 @@ For a quick start guide on deploying Corda Enterprise Network Manager services a * [Corda Networks]({{< relref "../../../../../en/platform/corda/1.5/cenm/corda-networks.md" >}}) * [Components of the Corda Enterprise Network Manager]({{< relref "../../../../../en/platform/corda/1.5/cenm/enm-components.md" >}}) -* [The workflow](../../../../../en/platform/corda/1.5/cenm/enm-components.html#the-workflow) -* [Databases](../../../../../en/platform/corda/1.5/cenm/enm-components.html#databases) -* [Public Key Infrastructure (PKI)](../../../../../en/platform/corda/1.5/cenm/enm-components.html#public-key-infrastructure-pki) -* [The node](../../../../../en/platform/corda/1.5/cenm/enm-components.html#the-node) +* [The workflow]({{< relref "../../../../../en/platform/corda/1.5/cenm/enm-components.md#the-workflow" >}}) +* [Databases]({{< relref "../../../../../en/platform/corda/1.5/cenm/enm-components.md#databases" >}}) +* [Public Key Infrastructure (PKI)]({{< relref "../../../../../en/platform/corda/1.5/cenm/enm-components.md#public-key-infrastructure-pki" >}}) +* [The node]({{< relref "../../../../../en/platform/corda/1.5/cenm/enm-components.md#the-node" >}}) * [Sub Zones]({{< relref "../../../../../en/platform/corda/1.5/cenm/sub-zones.md" >}}) * [Network Map overview]({{< relref "../../../../../en/platform/corda/1.5/cenm/network-map-overview.md" >}}) * [Certificate Revocation List]({{< relref "../../../../../en/platform/corda/1.5/cenm/certificate-revocation.md" >}}) diff --git a/content/en/platform/corda/1.5/cenm/aws-deployment-postgressql.md b/content/en/platform/corda/1.5/cenm/aws-deployment-postgressql.md index 2d0cab374ff..7e3807b0172 100644 --- a/content/en/platform/corda/1.5/cenm/aws-deployment-postgressql.md +++ b/content/en/platform/corda/1.5/cenm/aws-deployment-postgressql.md @@ -47,9 +47,9 @@ To set up each database: 1. Set up a PostgreSQL database in AWS - follow the instructions in the [AWS documentation](https://aws.amazon.com/rds/postgresql). 2. Connect to the database, using the details of the database in AWS. -3. Create a database user and a schema namespace [with restricted permissions](../../../../../en/platform/corda/1.5/cenm/database-set-up.html#1-create-a-database-user-with-schema-permissions). Follow the [steps for PostgreSQL](../../../../../en/platform/corda/1.5/cenm/database-set-up.html#postgresql). -4. Create the [database schema](../../../../../en/platform/corda/1.5/cenm/database-set-up.html#2-database-schema-creation) for each service. -5. Perform [CENM Service configuration](../../../../../en/platform/corda/1.5/cenm/database-set-up.html#3-cenm-service-configuration) - follow the [steps for PostgreSQL](../../../../../en/platform/corda/1.5/cenm/database-set-up.html#postgresql-1). See also the [database configuration documentation]({{< relref "../../../../../en/platform/corda/1.5/cenm/config-database.md" >}}). +3. Create a database user and a schema namespace [with restricted permissions]({{< relref "../../../../../en/platform/corda/1.5/cenm/database-set-up.md#1-create-a-database-user-with-schema-permissions" >}}). Follow the [steps for PostgreSQL]({{< relref "../../../../../en/platform/corda/1.5/cenm/database-set-up.md#postgresql" >}}). +4. Create the [database schema]({{< relref "../../../../../en/platform/corda/1.5/cenm/database-set-up.md#2-database-schema-creation" >}}) for each service. +5. Perform [CENM Service configuration]({{< relref "../../../../../en/platform/corda/1.5/cenm/database-set-up.md#3-cenm-service-configuration" >}}) - follow the [steps for PostgreSQL]({{< relref "../../../../../en/platform/corda/1.5/cenm/database-set-up.md#postgresql-1" >}}). See also the [database configuration documentation]({{< relref "../../../../../en/platform/corda/1.5/cenm/config-database.md" >}}). {{< note >}} In step 4 above, you must create a schema for each CENM service. The guide provided has steps for a restricted database schema that is used in a live production environment. You may prefer to use a less restricted database to reduce complexity in this reference environment setup. @@ -61,4 +61,4 @@ In step 4 above, you must create a schema for each CENM service. The guide provi 2. Deploy the [Identity Manager Service]({{< relref "../../../../../en/platform/corda/1.5/cenm/identity-manager.md" >}}) using PostgreSQL on AWS. 3. Deploy the [Network Map Service]({{< relref "../../../../../en/platform/corda/1.5/cenm/network-map.md" >}}) using PostgreSQL on AWS. 4. Deploy the [Zone Service]({{< relref "../../../../../en/platform/corda/1.5/cenm/zone-service.md" >}}) using PostgreSQL on AWS. -5. Deploy the [Signing Service](../../../../../en/platform/corda/1.5/cenm/signing-service.html#signing-service) (it does not use a database). +5. Deploy the [Signing Service]({{< relref "../../../../../en/platform/corda/1.5/cenm/signing-service.md#signing-service" >}}) (it does not use a database). diff --git a/content/en/platform/corda/1.5/cenm/cenm-cli-tool.md b/content/en/platform/corda/1.5/cenm/cenm-cli-tool.md index 1f9fe220e48..afbd69e3251 100644 --- a/content/en/platform/corda/1.5/cenm/cenm-cli-tool.md +++ b/content/en/platform/corda/1.5/cenm/cenm-cli-tool.md @@ -47,7 +47,7 @@ Note the `.0`. You have installed the Docker image with CENM CLI tool. -To get the tool ready to use from within the Docker container, check the [Kubernetes deployment guide](../../../../../en/platform/corda/1.5/cenm/deployment-kubernetes.html#network-operations). +To get the tool ready to use from within the Docker container, check the [Kubernetes deployment guide]({{< relref "../../../../../en/platform/corda/1.5/cenm/deployment-kubernetes.md#network-operations" >}}). ## Set up the CENM CLI Tool @@ -79,7 +79,7 @@ To set up a new network with the CLI: `./cenm identity-manager config set-admin-address -a=identity-manager:5053` -3. Set the Identity Manager config. This command returns a **Zone token** which you should pass to your [Angel Service](angel-service.md): +3. Set the Identity Manager config. This command returns a **Zone token** which you should pass to your [Angel Service]({{< relref "angel-service.md" >}}): `./cenm identity-manager config set -f config/identitymanager.conf --zone-token` diff --git a/content/en/platform/corda/1.5/cenm/deployment-kubernetes.md b/content/en/platform/corda/1.5/cenm/deployment-kubernetes.md index 02453bb66a1..37e6841f5e3 100644 --- a/content/en/platform/corda/1.5/cenm/deployment-kubernetes.md +++ b/content/en/platform/corda/1.5/cenm/deployment-kubernetes.md @@ -609,4 +609,4 @@ echo ${idmanPublicIP} ## Appendix A: Docker Images -Visit the [platform support matrix](../../../../../en/platform/corda/4.8/enterprise/platform-support-matrix.html#docker-images) for information on Corda Docker Images for version 1.5. +Visit the [platform support matrix]({{< relref "../../../../../en/platform/corda/4.8/enterprise/platform-support-matrix.md#docker-images" >}}) for information on Corda Docker Images for version 1.5. diff --git a/content/en/platform/corda/1.5/cenm/identity-manager.md b/content/en/platform/corda/1.5/cenm/identity-manager.md index 21d07fba43a..e7ae73be2de 100644 --- a/content/en/platform/corda/1.5/cenm/identity-manager.md +++ b/content/en/platform/corda/1.5/cenm/identity-manager.md @@ -185,7 +185,7 @@ database { ### Embedded shell (optional) -See [Shell Configuration](../../../../../en/platform/corda/1.5/cenm/shell.html#shell-config) for more information on how to configure the shell. +See [Shell Configuration]({{< relref "../../../../../en/platform/corda/1.5/cenm/shell.md#shell-config" >}}) for more information on how to configure the shell. ### Issuance Workflow diff --git a/content/en/platform/corda/1.5/cenm/jira-setup.md b/content/en/platform/corda/1.5/cenm/jira-setup.md index 8c998301c1a..92b9c2f2589 100644 --- a/content/en/platform/corda/1.5/cenm/jira-setup.md +++ b/content/en/platform/corda/1.5/cenm/jira-setup.md @@ -35,7 +35,7 @@ At present, there is no roadmap for the implementation of Jira Cloud plugin supp 3. Assign the user to the CSR and CRR projects. -4. Supply the user credentials to the [CENM identity manager configuration](identity-manager.html#jira-workflow). +4. Supply the user credentials to the [CENM identity manager configuration]({{< relref "identity-manager.md#jira-workflow" >}}). ## Configure projects' workflow diff --git a/content/en/platform/corda/1.5/cenm/network-map.md b/content/en/platform/corda/1.5/cenm/network-map.md index e145d95cd7e..8b431a4c856 100644 --- a/content/en/platform/corda/1.5/cenm/network-map.md +++ b/content/en/platform/corda/1.5/cenm/network-map.md @@ -219,7 +219,7 @@ database { ### Embedded shell (optional) -See [Shell Configuration](../../../../../en/platform/corda/1.5/cenm/shell.html#shell-config) for more information on how to configure the shell. +See [Shell Configuration]({{< relref "../../../../../en/platform/corda/1.5/cenm/shell.md#shell-config" >}}) for more information on how to configure the shell. ### Network Data Signing Mechanism diff --git a/content/en/platform/corda/1.5/cenm/pki-guide.md b/content/en/platform/corda/1.5/cenm/pki-guide.md index 5b0b0eb7cc9..37dd2c21619 100644 --- a/content/en/platform/corda/1.5/cenm/pki-guide.md +++ b/content/en/platform/corda/1.5/cenm/pki-guide.md @@ -59,7 +59,7 @@ Corda nodes operate with the following assumptions on the certificates hierarchy The length of the certificate chain can be arbitrary. As such, there can be any number of certificates between the Identity Manager Service and Network Map Service certificates as long as they root to the same certificate. * They need to have a custom extension defining the role of the certificate in the context of Corda. See - [here](../../../../../en/platform/corda/4.8/enterprise/network/permissioning.html#certificate-role-extension) for more details. + [here]({{< relref "../../../../../en/platform/corda/4.8/enterprise/network/permissioning.md#certificate-role-extension" >}}) for more details. Other than that, Corda nodes stay agnostic to the certificate hierarchy (in particular the depth of the certificate hierarchy tree). diff --git a/content/en/platform/corda/1.5/cenm/pki-specifications.md b/content/en/platform/corda/1.5/cenm/pki-specifications.md index fe21f982e19..458bd26b64a 100644 --- a/content/en/platform/corda/1.5/cenm/pki-specifications.md +++ b/content/en/platform/corda/1.5/cenm/pki-specifications.md @@ -21,7 +21,7 @@ Specifications and instructions are referenced here for the four scenarios below ## Generating root, subordinate, and network certificates -For instructions on generating certificates, see the [PKI Tool](../../../../../en/platform/corda/1.5/cenm/pki-tool.html#running-the-pki-tool) documentation. +For instructions on generating certificates, see the [PKI Tool]({{< relref "../../../../../en/platform/corda/1.5/cenm/pki-tool.md#running-the-pki-tool" >}}) documentation. ## Setting up a network under an existing root @@ -31,8 +31,8 @@ If you wish to set up a Corda network under an existing root and therefore are n If you wish to delegate network signing to a third party software provider, this can be done partially (with the Certificate Authority only) or fully (with the Certificate Authority and the non-Certificate Authority). -[Use a signing plugin](../../../../../en/platform/corda/1.5/cenm/signing-service.html#using-a-signing-plugin) to delegate this task to a third party software provider. See the [Developing Signing Plugins](../../../../../en/platform/corda/1.5/cenm/signing-service.html#developing-signing-plugins) and the [EJBCA Sample Plugin]({{< relref "../../../../../en/platform/corda/1.5/cenm/ejbca-plugin.md" >}}) documentation for guidance on creating a plugin that suits your needs. +[Use a signing plugin]({{< relref "../../../../../en/platform/corda/1.5/cenm/signing-service.md#using-a-signing-plugin" >}}) to delegate this task to a third party software provider. See the [Developing Signing Plugins]({{< relref "../../../../../en/platform/corda/1.5/cenm/signing-service.md#developing-signing-plugins" >}}) and the [EJBCA Sample Plugin]({{< relref "../../../../../en/platform/corda/1.5/cenm/ejbca-plugin.md" >}}) documentation for guidance on creating a plugin that suits your needs. ## Using your own Certificate Authority software -To set up a Corda network using your own Certificate Authority software, [use a signing plugin](../../../../../en/platform/corda/1.5/cenm/signing-service.html#using-a-signing-plugin). A signing plugin acts as a bridge between CENM services and one or more Signing Services. See the [Developing Signing Plugins](../../../../../en/platform/corda/1.5/cenm/signing-service.html#developing-signing-plugins) and the [EJBCA Sample Plugin]({{< relref "../../../../../en/platform/corda/1.5/cenm/ejbca-plugin.md" >}}) documentation for guidance on creating a plugin that suits your needs. +To set up a Corda network using your own Certificate Authority software, [use a signing plugin]({{< relref "../../../../../en/platform/corda/1.5/cenm/signing-service.md#using-a-signing-plugin" >}}). A signing plugin acts as a bridge between CENM services and one or more Signing Services. See the [Developing Signing Plugins]({{< relref "../../../../../en/platform/corda/1.5/cenm/signing-service.md#developing-signing-plugins" >}}) and the [EJBCA Sample Plugin]({{< relref "../../../../../en/platform/corda/1.5/cenm/ejbca-plugin.md" >}}) documentation for guidance on creating a plugin that suits your needs. diff --git a/content/en/platform/corda/1.5/cenm/pki-tool.md b/content/en/platform/corda/1.5/cenm/pki-tool.md index 6510710e4b5..2f75f88c5d3 100644 --- a/content/en/platform/corda/1.5/cenm/pki-tool.md +++ b/content/en/platform/corda/1.5/cenm/pki-tool.md @@ -20,7 +20,7 @@ title: Public Key Infrastructure (PKI) Tool ## Overview -As described in the [Certificate Hierarchy Guide](pki-guide.md), a certificate hierarchy with certain properties is required to run a Corda +As described in the [Certificate Hierarchy Guide]({{< relref "pki-guide.md" >}}), a certificate hierarchy with certain properties is required to run a Corda network. Specifically, the certificate hierarchy should include the two main CENM entities - the Identity Manager and the Network Map - and ensure that all entities map back to one common root of trust. The key pairs and certificates for these entities are used within the Signing Service to sign related network data such as approved CSRs, CRRs, Network Map @@ -119,7 +119,7 @@ are used by the tool for storing generated certificates. hierarchy. {{< note >}} -The full list of the configuration parameters can be found in [Public Key Infrastructure (PKI) Tool Configuration Parameters](config-pki-tool-parameters.md). +The full list of the configuration parameters can be found in [Public Key Infrastructure (PKI) Tool Configuration Parameters]({{< relref "config-pki-tool-parameters.md" >}}). {{< /note >}} @@ -127,7 +127,7 @@ The full list of the configuration parameters can be found in [Public Key Infras This configuration block defines all key stores that should be used by the PKI Tool. Each key store can be either local (backed by a Java key store file) or HSM (backed by a LAN HSM device). For HSM key stores, the available options and -authentication methods will depend on the HSM being used. See [Public Key Infrastructure (PKI) Tool Configuration Parameters](config-pki-tool-parameters.md) for more details. +authentication methods will depend on the HSM being used. See [Public Key Infrastructure (PKI) Tool Configuration Parameters]({{< relref "config-pki-tool-parameters.md" >}}) for more details. A mixture of key store types is allowed. That is, it is possible to generate some key pairs within a HSM device and others locally. Note that mixing key store types is not supported for a given entity. @@ -151,7 +151,7 @@ map from the user-defined alias to certificate configuration. The alias serves t reference the given entity throughout the rest of the PKI Tool config. Secondly, it also defines the alias for the generated (or existing) certificate entry in the corresponding certificate store. The certificate configuration defines the entity specific properties of both the X509 certificate and associated key pair. See -[Public Key Infrastructure (PKI) Tool Configuration Parameters](config-pki-tool-parameters.md) for more information. +[Public Key Infrastructure (PKI) Tool Configuration Parameters]({{< relref "config-pki-tool-parameters.md" >}}) for more information. If the desire is to use the resultant certificate hierarchy in a Corda network, this configuration block must define a set of certificates that meet some basic requirements. In addition to the hierarchy having to be under a single trust @@ -286,7 +286,7 @@ certificates = { ##### Free-form Certificates As an alternative to using the templates, each key pair and certificate can defined using the standard configuration -options. See the [Public Key Infrastructure (PKI) Tool Configuration Parameters](config-pki-tool-parameters.md) documentation for all possible parameters, and see below for examples +options. See the [Public Key Infrastructure (PKI) Tool Configuration Parameters]({{< relref "config-pki-tool-parameters.md" >}}) documentation for all possible parameters, and see below for examples that use this approach. Note that the templates only support local key stores - using a HSM requires the certificate hierarchy to be defined without templates. @@ -298,7 +298,7 @@ explicitly defines all necessary CRL file configurations or all CRL distribution generated without the `Certificate Revocation List Distribution Point` extension and will therefore be incompatible with any network using strict revocation checking. -As outlined in the [Public Key Infrastructure (PKI) Tool Configuration Parameters](config-pki-tool-parameters.md) doc, this extension is defined using the following logic: +As outlined in the [Public Key Infrastructure (PKI) Tool Configuration Parameters]({{< relref "config-pki-tool-parameters.md" >}}) doc, this extension is defined using the following logic: * If the certificate configuration has the `crlDistributionUrl` parameter set then use this. @@ -348,7 +348,7 @@ subordinate’s CRL file must be hosted, and available, on this endpoint. {{< note >}} Existing revocations can be added to the CRL file via the `crl.revocations` parameter. See -[Public Key Infrastructure (PKI) Tool Configuration Parameters](config-pki-tool-parameters.md) for more information. +[Public Key Infrastructure (PKI) Tool Configuration Parameters]({{< relref "config-pki-tool-parameters.md" >}}) for more information. {{< /note >}} For a given certificate, the exact crlDistributionPoint extension can be defined explicitly (rather than inheriting from @@ -375,7 +375,7 @@ certificates { As previously mentioned, it is up to the network operator to ensure that any configured CRL endpoints are available. The Identity Manager supports hosting of these CRL files (see the the “CRL Configuration” section of the -[Identity Manager Service](identity-manager.md) doc). +[Identity Manager Service]({{< relref "identity-manager.md" >}}) doc). ##### HSM Libraries @@ -459,7 +459,7 @@ This will create a JAR called `azure-keyvault-with-deps.jar` which can be refere ##### Generating SSL Keys -As outlined in the [Configuring the CENM services to use SSL](enm-with-ssl.md) doc, all inter-service CENM communication can be configured to encrypt their +As outlined in the [Configuring the CENM services to use SSL]({{< relref "enm-with-ssl.md" >}}) doc, all inter-service CENM communication can be configured to encrypt their messages via SSL. This feature requires the operator to provide a set of SSL key pairs and certificates to each service, which can be generated using the PKI tool. @@ -486,7 +486,7 @@ certificates = { {{< note >}} HSM keys used by the Signing Service require an accompanying certificate store that contains all certificates in the chain, from the signing entity back to the root. This is because the full chains cannot be stored within the -HSMs. Refer to the [Signing Service](signing-service.md) documentation for more information. +HSMs. Refer to the [Signing Service]({{< relref "signing-service.md" >}}) documentation for more information. {{< /note >}} diff --git a/content/en/platform/corda/1.5/cenm/release-notes.md b/content/en/platform/corda/1.5/cenm/release-notes.md index ea88f8af4a8..be429abd6fe 100644 --- a/content/en/platform/corda/1.5/cenm/release-notes.md +++ b/content/en/platform/corda/1.5/cenm/release-notes.md @@ -113,7 +113,7 @@ Upgrade to avoid exposure to the [Apache Log4j 2 vulnerability to attack](https: ### Fixed issues -We have updated the Log4j dependency to version 2.16.0 to mitigate CVE-2021-44228. This includes an update to the [CENM Management Console](cenm-console.md). +We have updated the Log4j dependency to version 2.16.0 to mitigate CVE-2021-44228. This includes an update to the [CENM Management Console]({{< relref "cenm-console.md" >}}). ## Corda Enterprise Network Manager 1.5.1 @@ -123,7 +123,7 @@ CENM 1.5.1 introduces fixes to known issues in CENM 1.5. * CENM 1.5.1 now supports [Oracle Database 19c](https://docs.oracle.com/en/database/oracle/oracle-database/19/index.html). * We have bumped the supported version of the AWS CloudHSM client library from 3.0.0 to 3.2.1. -* Configuration passwords are now hidden in both **CODE VIEW** and **FORM VIEW** modes in the [CENM management console](cenm-console.md) **CONFIGURATION**. +* Configuration passwords are now hidden in both **CODE VIEW** and **FORM VIEW** modes in the [CENM management console]({{< relref "cenm-console.md" >}}) **CONFIGURATION**. ### Fixed issues @@ -136,11 +136,11 @@ CENM 1.5.1 introduces fixes to known issues in CENM 1.5. ``` * We have fixed an issue where the signing request status command in the CENM Command-line Interface Tool (CLI) did not work for asynchronous signing. * We have fixed an issue where the Network Map Service failed to start with an EC public key used in the `packageOwnership` configuration in the network parameters, and an `Unrecognised algorithm` error was thrown. -* We have fixed an issue where, if a CSR was rejected with a [rejection code](workflow.html#certificate-signing-request-rejection-reasons) between 1 and 11 via the Jira workflow, the node notification would be incorrect - the `Additional remark` field output would contain technical data instead of a description of the rejection reason. +* We have fixed an issue where, if a CSR was rejected with a [rejection code]({{< relref "workflow.md#certificate-signing-request-rejection-reasons" >}}) between 1 and 11 via the Jira workflow, the node notification would be incorrect - the `Additional remark` field output would contain technical data instead of a description of the rejection reason. #### Fixed issues specific to the CENM management console -We have also fixed the following issues specific to the [CENM management console](cenm-console.md): +We have also fixed the following issues specific to the [CENM management console]({{< relref "cenm-console.md" >}}): * We have fixed an issue where removing scheduled times in **FORM VIEW** mode in the **SIGNER** tab of **CONFIGURATION** showed configuration details in **CODE VIEW** mode, which might result is Signing Service configuration failures. * We have fixed an issue where the **Remove Edits** option in **CONFIGURATION** did not work for a number of fields for all configuration types. @@ -166,7 +166,7 @@ We have also fixed the following issues specific to the [CENM management console ### Known issues -* There is still an option to view configuration passwords in **FORM VIEW** mode in the [CENM management console](cenm-console.md) **CONFIGURATION**. +* There is still an option to view configuration passwords in **FORM VIEW** mode in the [CENM management console]({{< relref "cenm-console.md" >}}) **CONFIGURATION**. {{< note >}} The known issue listed above is specific to CENM 1.5.1. See the release notes for previous CENM releases further down on this page for information about known issues specific to those versions. @@ -174,19 +174,19 @@ The known issue listed above is specific to CENM 1.5.1. See the release notes fo ## Corda Enterprise Network Manager 1.5 -Corda Enterprise Network Manager (CENM) 1.5 introduces a number of new features and enhancements, including a new [CENM management console](cenm-console.md), single sign-on for Azure AD for Corda services, and the ability to reissue node legal identity keys and certificates. +Corda Enterprise Network Manager (CENM) 1.5 introduces a number of new features and enhancements, including a new [CENM management console]({{< relref "cenm-console.md" >}}), single sign-on for Azure AD for Corda services, and the ability to reissue node legal identity keys and certificates. While this release is backward-compatible, you should consider upgrading to this release from earlier versions of the Corda Enterprise Network Manager. {{< warning >}} -Make sure to check out the [Upgrading Corda Enterprise Network Manager](upgrade-notes.md) page. +Make sure to check out the [Upgrading Corda Enterprise Network Manager]({{< relref "upgrade-notes.md" >}}) page. {{< /warning >}} ### New features and enhancements #### CENM management console -The [CENM management console](cenm-console.md) is a new CENM web UI that enables you to view CSR and CRR requests, display nodes in the network map, run a flag day, and update services configuration. +The [CENM management console]({{< relref "cenm-console.md" >}}) is a new CENM web UI that enables you to view CSR and CRR requests, display nodes in the network map, run a flag day, and update services configuration. #### Single sign-on for Azure AD @@ -197,7 +197,7 @@ CENM 1.5 introduces support for Azure Active Directory (AAD) as a single sign-on Corda Enterprise Edition 4.7 introduces a capability for reissuing node legal identity keys and certificates, allowing CENM to re-register a node (including a notary node) with a new certificate in the Network Map. You must not change the node's `myLegalName` during certificate rotation. {{< warning >}} -The introduction of this functionality may require changes to your custom Identity Manager Workflow Plugins, regardless of using certificate reissuance functionality in your system. Make sure to check the [Upgrading Corda Enterprise Network Manager](upgrade-notes.md) page. +The introduction of this functionality may require changes to your custom Identity Manager Workflow Plugins, regardless of using certificate reissuance functionality in your system. Make sure to check the [Upgrading Corda Enterprise Network Manager]({{< relref "upgrade-notes.md" >}}) page. {{< /warning >}} For more information about this feature, contact your R3 account manager. @@ -216,7 +216,7 @@ For more information about this feature, contact your R3 account manager. * The CENM Command-line Interface (CLI) Tool does not return a message if a token has expired when running `signer` commands. * The Identity Manager Service shows an incorrect error when the `workflow.enmListener.port` parameter is missed. * When setting up CENM services with Shell support, the Signing Service and the Network Map Service hang after running the `shutdown` command. -* When a CSR is rejected with a [rejection code](workflow.html#certificate-signing-request-rejection-reasons) between 1 and 11 via the Jira workflow, the node notification is incorrect - the `Additional remark` field output contains technical data instead of a description of the rejection reason. +* When a CSR is rejected with a [rejection code]({{< relref "workflow.md#certificate-signing-request-rejection-reasons" >}}) between 1 and 11 via the Jira workflow, the node notification is incorrect - the `Additional remark` field output contains technical data instead of a description of the rejection reason. {{< note >}} The list above contains known issues specific to CENM 1.5. See the release notes for previous CENM releases further down on this page for information about known issues specific to those versions. @@ -235,7 +235,7 @@ We have updated the default value of the optional `timeout` parameter, introduce * We have fixed an issue where the maximum length of a certificate's serial number allowed by CENM was 28 digits (`NUMBER(28)` format in the database) - roughly about 93 bits of data. To extend the support (introduced in CENM 1.2) for third-party CAs such as [SwissPKI](https://www.swisspki.com/), the Identity Manager Service can now handle certificate serial numbers with sizes up to 20 octets/bytes (160 bits) to comply with [RFC 5280](https://tools.ietf.org/html/rfc5280). In addition, the [PKI Tool]({{< relref "../../../../../en/platform/corda/1.4/cenm/pki-tool.md" >}}) now generates certificates with serial number sizes of up to 16 octets/bytes. * We have fixed an issue where the [PKI Tool]({{< relref "../../../../../en/platform/corda/1.4/cenm/pki-tool.md" >}}) would throw an error when using [securosys HSM](https://www.securosys.com/) with multiple partitions. -* We have fixed an issue where the [signing request status command](../../../../../en/platform/corda/1.4/cenm/cenm-cli-tool.html#check-the-connection-status-of-the-signing-service) in the [CENM Command-line Interface Tool]({{< relref "../../../../../en/platform/corda/1.4/cenm/cenm-cli-tool.md" >}}) did not work for requests with `COMPLETED` status. +* We have fixed an issue where the [signing request status command]({{< relref "../../../../../en/platform/corda/1.4/cenm/cenm-cli-tool.md#check-the-connection-status-of-the-signing-service" >}}) in the [CENM Command-line Interface Tool]({{< relref "../../../../../en/platform/corda/1.4/cenm/cenm-cli-tool.md" >}}) did not work for requests with `COMPLETED` status. * We have fixed an issue where the `APP VERSION` column was not shown when running helm charts while bootstrapping CENM. ## Corda Enterprise Network Manager 1.4 @@ -252,11 +252,11 @@ Upgrading from CENM 1.3 to CENM 1.4 requires the following actions: * Manual update of all existing Signing Service configurations. - The SMR (Signable Material Retriever) Service, which prior to CENM 1.4 was used to handle plug-ins for signing data, [has been replaced](#new-signing-service-plug-in-functionality-replaces-the-smr-signable-material-retriever-service) by a plug-in loading logic inside the Signing Service. As a result, **all users must update their existing Signing Service configuration** when upgrading to CENM 1.4 - see the [CENM Upgrade Guide](../../../../../en/platform/corda/1.4/cenm/upgrade-notes.html#manual-update-of-all-existing-signing-service-configurations) for details. + The SMR (Signable Material Retriever) Service, which prior to CENM 1.4 was used to handle plug-ins for signing data, [has been replaced](#new-signing-service-plug-in-functionality-replaces-the-smr-signable-material-retriever-service) by a plug-in loading logic inside the Signing Service. As a result, **all users must update their existing Signing Service configuration** when upgrading to CENM 1.4 - see the [CENM Upgrade Guide]({{< relref "../../../../../en/platform/corda/1.4/cenm/upgrade-notes.md#manual-update-of-all-existing-signing-service-configurations" >}}) for details. * Zone Service database migration. - If you are upgrading to CENM 1.4 from CENM 1.3, you **must** set `runMigration = true` in the database configuration. See the [CENM Upgrade Guide](../../../../../en/platform/corda/1.4/cenm/upgrade-notes.html#zone-service-database-migration) for details. This is required due to a [Zone Service database schema change](#network-map-service-performance-enhancements). + If you are upgrading to CENM 1.4 from CENM 1.3, you **must** set `runMigration = true` in the database configuration. See the [CENM Upgrade Guide]({{< relref "../../../../../en/platform/corda/1.4/cenm/upgrade-notes.md#zone-service-database-migration" >}}) for details. This is required due to a [Zone Service database schema change](#network-map-service-performance-enhancements). {{< /warning >}} @@ -278,11 +278,11 @@ Performance and reliability improvements can be observed on the unsigned Network Performance is enhanced through the following combination of changes: -* A new, optional `timeout` parameter now enables you to set specific [Signing Service timeouts](../../../../../en/platform/corda/1.4/cenm/signing-service.html#signing-service-configuration-parameters) for communication to each of the services used within the signing processes defined in the network map, in a way that allows high node count network maps to get signed and to operate at reliable performance levels. You can also use the `timeout` parameter to set specific Network Map Service timeouts for communication to the [Identity Manager and Revocation services](../../../../../en/platform/corda/1.4/cenm/network-map.html#identity-manager--revocation-communication). The `timeout` parameter's values are stored in a new `timeout` column in the [Zone Service](../../../../../en/platform/corda/1.4/cenm/zone-service.html#signing-services-configuration)'s database tables `socket_config` and `signer_config` (refer to the [CENM Upgrade Guide](../../../../../en/platform/corda/1.4/cenm/upgrade-notes.html#zone-service-database-migration) for important details about migrating the Zone Service database from CENM 1.3). +* A new, optional `timeout` parameter now enables you to set specific [Signing Service timeouts]({{< relref "../../../../../en/platform/corda/1.4/cenm/signing-service.md#signing-service-configuration-parameters" >}}) for communication to each of the services used within the signing processes defined in the network map, in a way that allows high node count network maps to get signed and to operate at reliable performance levels. You can also use the `timeout` parameter to set specific Network Map Service timeouts for communication to the [Identity Manager and Revocation services]({{< relref "../../../../../en/platform/corda/1.4/cenm/network-map.md#identity-manager--revocation-communication" >}}). The `timeout` parameter's values are stored in a new `timeout` column in the [Zone Service]({{< relref "../../../../../en/platform/corda/1.4/cenm/zone-service.md#signing-services-configuration" >}})'s database tables `socket_config` and `signer_config` (refer to the [CENM Upgrade Guide]({{< relref "../../../../../en/platform/corda/1.4/cenm/upgrade-notes.md#zone-service-database-migration" >}}) for important details about migrating the Zone Service database from CENM 1.3). -* A [new API endpoint](../../../../../en/platform/corda/1.4/cenm/network-map-overview.html#http-network-map-protocol), `GET network-map/node-infos`, enables you to retrieve a list of all signed `NodeInfo` objects for _all_ the nodes in the network at once. +* A [new API endpoint]({{< relref "../../../../../en/platform/corda/1.4/cenm/network-map-overview.md#http-network-map-protocol" >}}), `GET network-map/node-infos`, enables you to retrieve a list of all signed `NodeInfo` objects for _all_ the nodes in the network at once. -* The following [new headers](../../../../../en/platform/corda/1.4/cenm/network-map-overview.html#http-network-map-protocol) for Network Map API responses now make headers more closely aligned with HTTP standards: +* The following [new headers]({{< relref "../../../../../en/platform/corda/1.4/cenm/network-map-overview.md#http-network-map-protocol" >}}) for Network Map API responses now make headers more closely aligned with HTTP standards: * The new header `X-Corda-Server-Version` has been added for all Network Map API responses (except for internal error responses with code 5xx) indicates the version of the Network Map and the available calls. It has a default value of `2`. * The new header `X-Corda-Platform-Version` replaces `Platform-version`. The old header name continues to be supported. * The new header `X-Corda-Client-Version` replaces `Client-version`. The old header name continues to be supported. @@ -350,10 +350,10 @@ Not supported in CENM 1.4: See the [CENM deployment]({{< relref "../../../../../en/platform/corda/1.4/cenm/aws-deployment-guide.md" >}}) section for more information. #### Other changes -* We have added support for PostgreSQL 10.10 and 11.5 (JDBC 42.2.8), as noted in [CENM Databases](../../../../../en/platform/corda/1.4/cenm/database-set-up.html#supported-databases) and [CENM support matrix](../../../../../en/platform/corda/1.4/cenm/cenm-support-matrix.html#cenm-databases). +* We have added support for PostgreSQL 10.10 and 11.5 (JDBC 42.2.8), as noted in [CENM Databases]({{< relref "../../../../../en/platform/corda/1.4/cenm/database-set-up.md#supported-databases" >}}) and [CENM support matrix]({{< relref "../../../../../en/platform/corda/1.4/cenm/cenm-support-matrix.md#cenm-databases" >}}). * A `non-ca-plugin.jar` has been added to `signing-service-plugins` in Artifactory. * We have renamed the FARM Service, introduced in CENM 1.3, to [Gateway Service]({{< relref "../../../../../en/platform/corda/4.8/enterprise/node/gateway-service.md" >}}). As a result, if you are [upgrading]({{< relref "../../../../../en/platform/corda/1.4/cenm/upgrade-notes.md" >}}) from CENM 1.3 to CENM 1.4, the FARM Service JAR file used in CENM 1.3 should be replaced with the Gateway Service JAR file used in CENM 1.4. -* In CENM 1.4 we have changed the way `subZoneID` is set in Signing Service configurations - see the [CENM upgrade guide](../../../../../en/platform/corda/1.4/cenm/upgrade-notes.html#change-in-setting-subzoneid-in-signing-service-configurations) for more details. +* In CENM 1.4 we have changed the way `subZoneID` is set in Signing Service configurations - see the [CENM upgrade guide]({{< relref "../../../../../en/platform/corda/1.4/cenm/upgrade-notes.md#change-in-setting-subzoneid-in-signing-service-configurations" >}}) for more details. ### Fixed issues diff --git a/content/en/platform/corda/1.5/cenm/signing-service.md b/content/en/platform/corda/1.5/cenm/signing-service.md index 6c3c936408c..ffc0ca7f6b7 100644 --- a/content/en/platform/corda/1.5/cenm/signing-service.md +++ b/content/en/platform/corda/1.5/cenm/signing-service.md @@ -31,7 +31,7 @@ particular data to require authentication from multiple users. ## Signing Service overview -The Signing Service supports the following HSMs (see [CENM support matrix](../../../../../en/platform/corda/1.5/cenm/cenm-support-matrix.html#hardware-security-modules-hsms) for more information): +The Signing Service supports the following HSMs (see [CENM support matrix]({{< relref "../../../../../en/platform/corda/1.5/cenm/cenm-support-matrix.md#hardware-security-modules-hsms" >}}) for more information): * Utimaco SecurityServer Se Gen2. * Gemalto Luna. @@ -141,7 +141,7 @@ The configuration for the Signing Service consists of the following sections: The Signing Service is interacted with via the shell, which is configured at the top level of the configuration file. This shell is similar to the interactive shell available in other CENM services and is configured in a similar way. See -[Shell Configuration](../../../../../en/platform/corda/1.5/cenm/shell.html#shell-config) for more information on how to configure the shell. +[Shell Configuration]({{< relref "../../../../../en/platform/corda/1.5/cenm/shell.md#shell-config" >}}) for more information on how to configure the shell. #### HSM libraries diff --git a/content/en/platform/corda/1.5/cenm/updating-network-parameters.md b/content/en/platform/corda/1.5/cenm/updating-network-parameters.md index f36dfb9147b..07356afb58b 100644 --- a/content/en/platform/corda/1.5/cenm/updating-network-parameters.md +++ b/content/en/platform/corda/1.5/cenm/updating-network-parameters.md @@ -40,7 +40,7 @@ At a high level, the process is as follows: ## Editing network parameters configuration -See [Setting the Network Parameters](../../../../../en/platform/corda/1.5/cenm/network-map.html#network-parameters) +See [Setting the Network Parameters]({{< relref "../../../../../en/platform/corda/1.5/cenm/network-map.md#network-parameters" >}}) for information on the network parameters configuration file format and options. When updating the network parameters, ensure that the network parameters file has the diff --git a/content/en/platform/corda/1.5/cenm/upgrade-notes.md b/content/en/platform/corda/1.5/cenm/upgrade-notes.md index d144d3bf474..f928a34147d 100644 --- a/content/en/platform/corda/1.5/cenm/upgrade-notes.md +++ b/content/en/platform/corda/1.5/cenm/upgrade-notes.md @@ -17,10 +17,10 @@ title: Upgrading Corda Enterprise Network Manager # Upgrading Corda Enterprise Network Manager This document provides instructions for upgrading your network management suite - Identity Manager Service (formerly -Doorman), Network Map Service, Signing Service, Zone Service, Auth Service, Angel Service - from previous versions to the newest version. Please consult the relevant [release notes](release-notes.md) of the release in question. If not specified, you may assume the versions you are currently using are still in force. +Doorman), Network Map Service, Signing Service, Zone Service, Auth Service, Angel Service - from previous versions to the newest version. Please consult the relevant [release notes]({{< relref "release-notes.md" >}}) of the release in question. If not specified, you may assume the versions you are currently using are still in force. {{< warning >}} -Before you start the upgrade, you must consult the [CENM Release Notes](release-notes.md) to confirm all changes between releases. +Before you start the upgrade, you must consult the [CENM Release Notes]({{< relref "release-notes.md" >}}) to confirm all changes between releases. {{< /warning >}} ## 1.3.x / 1.4.x to 1.5 @@ -165,7 +165,7 @@ The key steps for the upgrade are: 5. Deploy Zone Service to store configurations for the Identity Manager, Network Map, and Signing Services. 6. Create users in the Auth Service, for zone and subzone management. 7. Edit [Identity Manager Service]({{< relref "../../../../../en/platform/corda/1.3/cenm/identity-manager.md" >}}), [Network Map Service]({{< relref "../../../../../en/platform/corda/1.3/cenm/network-map.md" >}}), and [Signing Service]({{< relref "../../../../../en/platform/corda/1.3/cenm/signing-service.md" >}}) configurations to remove shell access and add an admin listener configuration. -8. Edit the [Signing Service]({{< relref "../../../../../en/platform/corda/1.3/cenm/signing-service.md" >}}) configuration so that signing tasks refer to [service aliases](../../../../../en/platform/corda/1.5/cenm/signing-service.html#direct-cenm-service-locations) generated by the Zone Service. +8. Edit the [Signing Service]({{< relref "../../../../../en/platform/corda/1.3/cenm/signing-service.md" >}}) configuration so that signing tasks refer to [service aliases]({{< relref "../../../../../en/platform/corda/1.5/cenm/signing-service.md#direct-cenm-service-locations" >}}) generated by the Zone Service. 9. Set Identity Manager Service configuration in the [Zone Service]({{< relref "../../../../../en/platform/corda/1.3/cenm/zone-service.md" >}}). 10. Set Network Map Service configuration(s) in the Zone Service. 11. Set Signing Service configuation in the Zone Service. @@ -178,14 +178,14 @@ The key steps for the upgrade are: You must generate SSL key pairs and certificates for the new services before deploying them. You can do this using the PKI tool, and it is best to replace the SSL certificates and keys for all services during this process. A draft PKI tool configuration -for generating the full SSL hierarchy is provided under [config-samples/upgrade-pki-tool-1.3.conf](../../../../../en/platform/corda/1.3/cenm/config-samples/upgrade-pki-tool.conf/). +for generating the full SSL hierarchy is provided under [config-samples/upgrade-pki-tool.conf](config-samples/upgrade-pki-tool.conf/). {{% important %}} You must replace the `subject` and `crlDistributionUrl` entries in this configuration with values appropriate to your deployment. {{% /important %}} -To generate the JWT, refer to the [Auth Service]({{< relref "../../../../../en/platform/corda/4.8/enterprise/node/auth-service.md" >}}) documentation. +To generate the JWT, refer to the [Auth Service]({{< relref "../../4.8/enterprise/node/auth-service.md" >}}) documentation. The generated keys and certificates will then need to be distributed to the service hosts, replacing the existing SSL (but not network trust root or other signing key/certificates). @@ -194,9 +194,9 @@ replacing the existing SSL (but not network trust root or other signing key/cert To deploy the new services, follow the guides in the service documentation: -* [Gateway Service]({{< relref "../../../../../en/platform/corda/4.8/enterprise/node/gateway-service.md" >}}) -* [Auth Service]({{< relref "../../../../../en/platform/corda/4.8/enterprise/node/auth-service.md" >}}) -* [Zone Service]({{< relref "../../../../../en/platform/corda/1.5/cenm/zone-service.md" >}}) +* [Gateway Service]({{< relref "../../4.8/enterprise/node/gateway-service.md" >}}) +* [Auth Service]({{< relref "../../4.8/enterprise/node/auth-service.md" >}}) +* [Zone Service]({{< relref "../../1.5/cenm/zone-service.md" >}}) {{< note >}} You should deploy two Gateway Service instances - one for general access, accessible from user @@ -228,7 +228,7 @@ service. Service locations in the Signing Service configuration are provided automatically by the Zone Service in CENM 1.3. However, to enable this, the service aliases have strictly defined formats. You must update the task configurations to refer to service aliases matching -these names. The names are specified in [service aliases](../../../../../en/platform/corda/1.3/cenm/signing-service.html#direct-cenm-service-locations). +these names. The names are specified in [service aliases]({{< relref "../../../../../en/platform/corda/1.3/cenm/signing-service.md#direct-cenm-service-locations" >}}). ### Push configurations to Zone Service diff --git a/content/en/platform/corda/1.5/cenm/user-admin.md b/content/en/platform/corda/1.5/cenm/user-admin.md index b99f57353f7..b74bd694e3e 100644 --- a/content/en/platform/corda/1.5/cenm/user-admin.md +++ b/content/en/platform/corda/1.5/cenm/user-admin.md @@ -81,7 +81,7 @@ Users can access network services to perform tasks. To give a user permissions, Administrators *cannot* have any role as a user on your network operation services. -![create_user](../../../../../en/platform/corda/1.5/cenm/resources/create_user_new.png) +![create_user](resources/create_user_new.png) {{< note >}} You must be registered as an administrator to create new users and administrators. @@ -111,7 +111,7 @@ To add a new user or administrator: You can change a user's status, password, or group membership from the **User Details** screen. -![Manage user](../../../../../en/platform/corda/1.5/cenm/resources/user_details_new.png) +![Manage user](resources/user_details_new.png) 1. Select **Users** from the side menu to view the user list. @@ -134,7 +134,7 @@ You can change a user's status, password, or group membership from the **User De Groups let you grant multiple users the same set of permissions. Groups make it easier for you to manage permissions of future users - just add them to the relevant groups instead of configuring individual roles. -![Creating a group](../../../../../en/platform/corda/1.5/cenm/resources/create_group_new.png) +![Creating a group](resources/create_group_new.png) To create a group: @@ -157,7 +157,7 @@ You can access all your groups from the **Groups** screen. You can add or remove members of a group, or delete an existing group. Deleting a group does not delete the users in the group. -![Manage a group](../../../../../en/platform/corda/1.5/cenm/resources/group_details_new.png) +![Manage a group](resources/group_details_new.png) To make changes to a group: 1. Select **Groups** from the side menu to view your existing groups. @@ -183,7 +183,7 @@ To make changes to a group: Roles are made up of permissions that allow users to perform tasks in CENM. You can create roles by combining the required permissions, and then assigning the role to users and/or groups. -![Create a Role](../../../../../en/platform/corda/1.5/cenm/resources/create_role_new.png) +![Create a Role](resources/create_role_new.png) To create a new role: 1. Select **Roles** from the side menu. @@ -205,7 +205,7 @@ You have added a new role. All users and groups assigned this role are granted i You can assign a role to additional users and groups, remove roles from users and groups, add and remove permissions in a role, and delete roles at any time. -![Manage a Role](../../../../../en/platform/corda/1.5/cenm/resources/role_details_new.png) +![Manage a Role](resources/role_details_new.png) To amend the properties of a role: 1. Select **Roles** from the side menu. diff --git a/content/en/platform/corda/1.5/cenm/zone-service.md b/content/en/platform/corda/1.5/cenm/zone-service.md index a976e02ce7d..7cd5fc726b9 100644 --- a/content/en/platform/corda/1.5/cenm/zone-service.md +++ b/content/en/platform/corda/1.5/cenm/zone-service.md @@ -170,7 +170,7 @@ serviceLocations = { ``` {{< note >}} -The `timeout` parameter used in the example above is optional. It allows to set a Signing Service timeout for communication to each of the services used within the signing processes defined in the [signers map](../../../../../en/platform/corda/1.5/cenm/signing-service.html#signers-map-entry-example), in a way that allows high node count network maps to get signed and to operate at reliable performance levels. The `timeout` value is set in milliseconds and the default value is 10000 milliseconds. The `timeout` parameter's value is stored in a column in the [Zone Service]({{< relref "../../../../../en/platform/corda/1.5/cenm/zone-service.md" >}})'s database tables `socket_config` and `signer_config` called `timeout`. This value can remain `null` (for example, if `timeout` is not defined in `serviceLocations`), in which case the default 10000 milliseconds value (`timeout = 10000`) will be used wherever applicable. Please note that currently, due to a known issue with `serviceLocations`, when the `timeout` parameter is passed to the Zone Service via the Signing Service's `serviceLocations` configuration block, only the `timeout` value of the first `serviceLocations` location will be taken into account and used for all other service locations. +The `timeout` parameter used in the example above is optional. It allows to set a Signing Service timeout for communication to each of the services used within the signing processes defined in the [signers map]({{< relref "../../../../../en/platform/corda/1.5/cenm/signing-service.md#signers-map-entry-example" >}}), in a way that allows high node count network maps to get signed and to operate at reliable performance levels. The `timeout` value is set in milliseconds and the default value is 10000 milliseconds. The `timeout` parameter's value is stored in a column in the [Zone Service]({{< relref "../../../../../en/platform/corda/1.5/cenm/zone-service.md" >}})'s database tables `socket_config` and `signer_config` called `timeout`. This value can remain `null` (for example, if `timeout` is not defined in `serviceLocations`), in which case the default 10000 milliseconds value (`timeout = 10000`) will be used wherever applicable. Please note that currently, due to a known issue with `serviceLocations`, when the `timeout` parameter is passed to the Zone Service via the Signing Service's `serviceLocations` configuration block, only the `timeout` value of the first `serviceLocations` location will be taken into account and used for all other service locations. {{< /note >}} ## Interaction with Angel Services diff --git a/content/en/platform/corda/1.6/cenm/_index.md b/content/en/platform/corda/1.6/cenm/_index.md index e082d371358..514f3a326d5 100644 --- a/content/en/platform/corda/1.6/cenm/_index.md +++ b/content/en/platform/corda/1.6/cenm/_index.md @@ -26,8 +26,7 @@ that are otherwise available from [Corda Network](https://corda.network), which **Release notes** * For all Corda Enterprise Network Manager release notes, see the [Corda Enterprise Network Manager release notes]({{< relref "../../../../../en/platform/corda/1.6/cenm/release-notes.md" >}}) page. -* For all Corda 4 Enterprise Edition release notes, see [Welcome to Corda - Corda 4 Enterprise](../../../../../en/platform/corda.html#corda-4-enterprise). -* For all Corda 4 Community Edition release notes, see [Welcome to Corda - Corda 4 Community Edition (Formerly Open Source)](../../../../../en/platform/corda.html#corda-4-community-edition-formerly-open-source). +* For all Corda 4 Enterprise Edition and Community/Open Source release notes, see [Welcome to Corda]({{< relref "../../../../../en/platform/corda/_index.md" >}}). {{< /note >}} @@ -53,10 +52,10 @@ For a quick start guide on deploying Corda Enterprise Network Manager services a * [Corda Networks]({{< relref "../../../../../en/platform/corda/1.6/cenm/corda-networks.md" >}}) * [Components of the Corda Enterprise Network Manager]({{< relref "../../../../../en/platform/corda/1.6/cenm/enm-components.md" >}}) -* [The workflow](../../../../../en/platform/corda/1.6/cenm/enm-components.html#the-workflow) -* [Databases](../../../../../en/platform/corda/1.6/cenm/enm-components.html#databases) -* [Public Key Infrastructure (PKI)](../../../../../en/platform/corda/1.6/cenm/enm-components.html#public-key-infrastructure-pki) -* [The node](../../../../../en/platform/corda/1.6/cenm/enm-components.html#the-node) +* [The workflow]({{< relref "../../../../../en/platform/corda/1.6/cenm/enm-components.md#the-workflow" >}}) +* [Databases]({{< relref "../../../../../en/platform/corda/1.6/cenm/enm-components.md#databases" >}}) +* [Public Key Infrastructure (PKI)]({{< relref "../../../../../en/platform/corda/1.6/cenm/enm-components.md#public-key-infrastructure-pki" >}}) +* [The node]({{< relref "../../../../../en/platform/corda/1.6/cenm/enm-components.md#the-node" >}}) * [Sub Zones]({{< relref "../../../../../en/platform/corda/1.6/cenm/sub-zones.md" >}}) * [Network Map overview]({{< relref "../../../../../en/platform/corda/1.6/cenm/network-map-overview.md" >}}) * [Certificate Revocation List]({{< relref "../../../../../en/platform/corda/1.6/cenm/certificate-revocation.md" >}}) diff --git a/content/en/platform/corda/1.6/cenm/aws-deployment-postgressql.md b/content/en/platform/corda/1.6/cenm/aws-deployment-postgressql.md index ea5fdb05c93..d85e04ac250 100644 --- a/content/en/platform/corda/1.6/cenm/aws-deployment-postgressql.md +++ b/content/en/platform/corda/1.6/cenm/aws-deployment-postgressql.md @@ -47,9 +47,9 @@ To set up each database: 1. Set up a PostgreSQL database in AWS - follow the instructions in the [AWS documentation](https://aws.amazon.com/rds/postgresql). 2. Connect to the database, using the details of the database in AWS. -3. Create a database user and a schema namespace [with restricted permissions](../../../../../en/platform/corda/1.6/cenm/database-set-up.html#1-create-a-database-user-with-schema-permissions). Follow the [steps for PostgreSQL](../../../../../en/platform/corda/1.6/cenm/database-set-up.html#postgresql). -4. Create the [database schema](../../../../../en/platform/corda/1.6/cenm/database-set-up.html#2-database-schema-creation) for each service. -5. Perform [CENM Service configuration](../../../../../en/platform/corda/1.6/cenm/database-set-up.html#3-cenm-service-configuration) - follow the [steps for PostgreSQL](../../../../../en/platform/corda/1.6/cenm/database-set-up.html#postgresql-1). See also the [database configuration documentation]({{< relref "../../../../../en/platform/corda/1.6/cenm/config-database.md" >}}). +3. Create a database user and a schema namespace [with restricted permissions]({{< relref "../../../../../en/platform/corda/1.6/cenm/database-set-up.md#1-create-a-database-user-with-schema-permissions" >}}). Follow the [steps for PostgreSQL]({{< relref "../../../../../en/platform/corda/1.6/cenm/database-set-up.md#postgresql" >}}). +4. Create the [database schema]({{< relref "../../../../../en/platform/corda/1.6/cenm/database-set-up.md#2-database-schema-creation" >}}) for each service. +5. Perform [CENM Service configuration]({{< relref "../../../../../en/platform/corda/1.6/cenm/database-set-up.md#3-cenm-service-configuration" >}}) - follow the [steps for PostgreSQL]({{< relref "../../../../../en/platform/corda/1.6/cenm/database-set-up.md#postgresql-1" >}}). See also the [database configuration documentation]({{< relref "../../../../../en/platform/corda/1.6/cenm/config-database.md" >}}). {{< note >}} In step 4 above, you must create a schema for each CENM service. The guide provided has steps for a restricted database schema that is used in a live production environment. You may prefer to use a less restricted database to reduce complexity in this reference environment setup. @@ -61,4 +61,4 @@ In step 4 above, you must create a schema for each CENM service. The guide provi 2. Deploy the [Identity Manager Service]({{< relref "../../../../../en/platform/corda/1.6/cenm/identity-manager.md" >}}) using PostgreSQL on AWS. 3. Deploy the [Network Map Service]({{< relref "../../../../../en/platform/corda/1.6/cenm/network-map.md" >}}) using PostgreSQL on AWS. 4. Deploy the [Zone Service]({{< relref "../../../../../en/platform/corda/1.6/cenm/zone-service.md" >}}) using PostgreSQL on AWS. -5. Deploy the [Signing Service](../../../../../en/platform/corda/1.6/cenm/signing-service.html#signing-service) (it does not use a database). +5. Deploy the [Signing Service]({{< relref "../../../../../en/platform/corda/1.6/cenm/signing-service.md#signing-service" >}}) (it does not use a database). diff --git a/content/en/platform/corda/1.6/cenm/cenm-cli-tool.md b/content/en/platform/corda/1.6/cenm/cenm-cli-tool.md index fccaa8039eb..dd9828ea44c 100644 --- a/content/en/platform/corda/1.6/cenm/cenm-cli-tool.md +++ b/content/en/platform/corda/1.6/cenm/cenm-cli-tool.md @@ -47,7 +47,7 @@ Note the `.0`. You have installed the Docker image with CENM CLI tool. -To get the tool ready to use from within the Docker container, check the [Kubernetes deployment guide](../../../../../en/platform/corda/1.6/cenm/deployment-kubernetes.html#network-operations). +To get the tool ready to use from within the Docker container, check the [Kubernetes deployment guide]({{< relref "../../../../../en/platform/corda/1.6/cenm/deployment-kubernetes.md#network-operations" >}}). ## Set up the CENM CLI Tool @@ -79,7 +79,7 @@ To set up a new network with the CLI: `./cenm identity-manager config set-admin-address -a=identity-manager:5053` -3. Set the Identity Manager config. This command returns a **Zone token** which you should pass to your [Angel Service](angel-service.md): +3. Set the Identity Manager config. This command returns a **Zone token** which you should pass to your [Angel Service]({{< relref "angel-service.md" >}}): `./cenm identity-manager config set -f config/identitymanager.conf --zone-token` diff --git a/content/en/platform/corda/1.6/cenm/deployment-kubernetes.md b/content/en/platform/corda/1.6/cenm/deployment-kubernetes.md index 8ba43a17115..2691d2835e9 100644 --- a/content/en/platform/corda/1.6/cenm/deployment-kubernetes.md +++ b/content/en/platform/corda/1.6/cenm/deployment-kubernetes.md @@ -609,4 +609,4 @@ echo ${idmanPublicIP} ## Appendix A: Docker Images -Visit the [platform support matrix](../../../../../en/platform/corda/4.11/enterprise/platform-support-matrix.html#docker-images) for information on Corda Docker Images for version 1.6. +Visit the [platform support matrix]({{< relref "../../../../../en/platform/corda/4.11/enterprise/platform-support-matrix.md#docker-images" >}}) for information on Corda Docker Images for version 1.6. diff --git a/content/en/platform/corda/1.6/cenm/identity-manager.md b/content/en/platform/corda/1.6/cenm/identity-manager.md index 7244468e10d..2cfab52f4f8 100644 --- a/content/en/platform/corda/1.6/cenm/identity-manager.md +++ b/content/en/platform/corda/1.6/cenm/identity-manager.md @@ -185,7 +185,7 @@ database { ### Embedded shell (optional) -See [Shell Configuration](../../../../../en/platform/corda/1.6/cenm/shell.html#shell-config) for more information on how to configure the shell. +See [Shell Configuration]({{< relref "../../../../../en/platform/corda/1.6/cenm/shell.md#shell-config" >}}) for more information on how to configure the shell. ### Issuance Workflow diff --git a/content/en/platform/corda/1.6/cenm/jira-setup.md b/content/en/platform/corda/1.6/cenm/jira-setup.md index 39c64ae03e9..5e002d2aa34 100644 --- a/content/en/platform/corda/1.6/cenm/jira-setup.md +++ b/content/en/platform/corda/1.6/cenm/jira-setup.md @@ -35,7 +35,7 @@ At present, there is no roadmap for the implementation of Jira Cloud plugin supp 3. Assign the user to the CSR and CRR projects. -4. Supply the user credentials to the [CENM identity manager configuration](identity-manager.html#jira-workflow). +4. Supply the user credentials to the [CENM identity manager configuration]({{< relref "identity-manager.md#jira-workflow" >}}). ## Configure projects' workflow diff --git a/content/en/platform/corda/1.6/cenm/network-map.md b/content/en/platform/corda/1.6/cenm/network-map.md index ace724f53f0..9af1c4c85f6 100644 --- a/content/en/platform/corda/1.6/cenm/network-map.md +++ b/content/en/platform/corda/1.6/cenm/network-map.md @@ -219,7 +219,7 @@ database { ### Embedded shell (optional) -See [Shell Configuration](../../../../../en/platform/corda/1.6/cenm/shell.html#shell-config) for more information on how to configure the shell. +See [Shell Configuration]({{< relref "../../../../../en/platform/corda/1.6/cenm/shell.md#shell-config" >}}) for more information on how to configure the shell. ### Network Data Signing Mechanism diff --git a/content/en/platform/corda/1.6/cenm/pki-guide.md b/content/en/platform/corda/1.6/cenm/pki-guide.md index 6f1d60e135a..8acd3c1a47a 100644 --- a/content/en/platform/corda/1.6/cenm/pki-guide.md +++ b/content/en/platform/corda/1.6/cenm/pki-guide.md @@ -59,7 +59,7 @@ Corda nodes operate with the following assumptions on the certificates hierarchy The length of the certificate chain can be arbitrary. As such, there can be any number of certificates between the Identity Manager Service and Network Map Service certificates as long as they root to the same certificate. * They need to have a custom extension defining the role of the certificate in the context of Corda. See - [here](../../../../../en/platform/corda/4.8/enterprise/network/permissioning.html#certificate-role-extension) for more details. + [here]({{< relref "../../../../../en/platform/corda/4.8/enterprise/network/permissioning.md#certificate-role-extension" >}}) for more details. Other than that, Corda nodes stay agnostic to the certificate hierarchy (in particular the depth of the certificate hierarchy tree). diff --git a/content/en/platform/corda/1.6/cenm/pki-specifications.md b/content/en/platform/corda/1.6/cenm/pki-specifications.md index ba2b83f5ec0..a896cdc8899 100644 --- a/content/en/platform/corda/1.6/cenm/pki-specifications.md +++ b/content/en/platform/corda/1.6/cenm/pki-specifications.md @@ -21,7 +21,7 @@ Specifications and instructions are referenced here for the four scenarios below ## Generating root, subordinate, and network certificates -For instructions on generating certificates, see the [PKI Tool](../../../../../en/platform/corda/1.6/cenm/pki-tool.html#running-the-pki-tool) documentation. +For instructions on generating certificates, see the [PKI Tool]({{< relref "../../../../../en/platform/corda/1.6/cenm/pki-tool.md#running-the-pki-tool" >}}) documentation. ## Setting up a network under an existing root @@ -31,8 +31,8 @@ If you wish to set up a Corda network under an existing root and therefore are n If you wish to delegate network signing to a third party software provider, this can be done partially (with the Certificate Authority only) or fully (with the Certificate Authority and the non-Certificate Authority). -[Use a signing plugin](../../../../../en/platform/corda/1.6/cenm/signing-service.html#using-a-signing-plugin) to delegate this task to a third party software provider. See the [Developing Signing Plugins](../../../../../en/platform/corda/1.6/cenm/signing-service.html#developing-signing-plugins) and the [EJBCA Sample Plugin]({{< relref "../../../../../en/platform/corda/1.6/cenm/ejbca-plugin.md" >}}) documentation for guidance on creating a plugin that suits your needs. +[Use a signing plugin]({{< relref "../../../../../en/platform/corda/1.6/cenm/signing-service.md#using-a-signing-plugin" >}}) to delegate this task to a third party software provider. See the [Developing Signing Plugins]({{< relref "../../../../../en/platform/corda/1.6/cenm/signing-service.md#developing-signing-plugins" >}}) and the [EJBCA Sample Plugin]({{< relref "../../../../../en/platform/corda/1.6/cenm/ejbca-plugin.md" >}}) documentation for guidance on creating a plugin that suits your needs. ## Using your own Certificate Authority software -To set up a Corda network using your own Certificate Authority software, [use a signing plugin](../../../../../en/platform/corda/1.6/cenm/signing-service.html#using-a-signing-plugin). A signing plugin acts as a bridge between CENM services and one or more Signing Services. See the [Developing Signing Plugins](../../../../../en/platform/corda/1.6/cenm/signing-service.html#developing-signing-plugins) and the [EJBCA Sample Plugin]({{< relref "../../../../../en/platform/corda/1.6/cenm/ejbca-plugin.md" >}}) documentation for guidance on creating a plugin that suits your needs. +To set up a Corda network using your own Certificate Authority software, [use a signing plugin]({{< relref "../../../../../en/platform/corda/1.6/cenm/signing-service.md#using-a-signing-plugin" >}}). A signing plugin acts as a bridge between CENM services and one or more Signing Services. See the [Developing Signing Plugins]({{< relref "../../../../../en/platform/corda/1.6/cenm/signing-service.md#developing-signing-plugins" >}}) and the [EJBCA Sample Plugin]({{< relref "../../../../../en/platform/corda/1.6/cenm/ejbca-plugin.md" >}}) documentation for guidance on creating a plugin that suits your needs. diff --git a/content/en/platform/corda/1.6/cenm/pki-tool.md b/content/en/platform/corda/1.6/cenm/pki-tool.md index 0da5300d947..8ceb69516ad 100644 --- a/content/en/platform/corda/1.6/cenm/pki-tool.md +++ b/content/en/platform/corda/1.6/cenm/pki-tool.md @@ -20,7 +20,7 @@ title: Public Key Infrastructure (PKI) Tool ## Overview -As described in the [Certificate Hierarchy Guide](pki-guide.md), a certificate hierarchy with certain properties is required to run a Corda +As described in the [Certificate Hierarchy Guide]({{< relref "pki-guide.md" >}}), a certificate hierarchy with certain properties is required to run a Corda network. Specifically, the certificate hierarchy should include the two main CENM entities - the Identity Manager and the Network Map - and ensure that all entities map back to one common root of trust. The key pairs and certificates for these entities are used within the Signing Service to sign related network data such as approved CSRs, CRRs, Network Map @@ -119,7 +119,7 @@ are used by the tool for storing generated certificates. hierarchy. {{< note >}} -The full list of the configuration parameters can be found in [Public Key Infrastructure (PKI) Tool Configuration Parameters](config-pki-tool-parameters.md). +The full list of the configuration parameters can be found in [Public Key Infrastructure (PKI) Tool Configuration Parameters]({{< relref "config-pki-tool-parameters.md" >}}). {{< /note >}} @@ -127,7 +127,7 @@ The full list of the configuration parameters can be found in [Public Key Infras This configuration block defines all key stores that should be used by the PKI Tool. Each key store can be either local (backed by a Java key store file) or HSM (backed by a LAN HSM device). For HSM key stores, the available options and -authentication methods will depend on the HSM being used. See [Public Key Infrastructure (PKI) Tool Configuration Parameters](config-pki-tool-parameters.md) for more details. +authentication methods will depend on the HSM being used. See [Public Key Infrastructure (PKI) Tool Configuration Parameters]({{< relref "config-pki-tool-parameters.md" >}}) for more details. A mixture of key store types is allowed. That is, it is possible to generate some key pairs within a HSM device and others locally. Note that mixing key store types is not supported for a given entity. @@ -151,7 +151,7 @@ map from the user-defined alias to certificate configuration. The alias serves t reference the given entity throughout the rest of the PKI Tool config. Secondly, it also defines the alias for the generated (or existing) certificate entry in the corresponding certificate store. The certificate configuration defines the entity specific properties of both the X509 certificate and associated key pair. See -[Public Key Infrastructure (PKI) Tool Configuration Parameters](config-pki-tool-parameters.md) for more information. +[Public Key Infrastructure (PKI) Tool Configuration Parameters]({{< relref "config-pki-tool-parameters.md" >}}) for more information. If the desire is to use the resultant certificate hierarchy in a Corda network, this configuration block must define a set of certificates that meet some basic requirements. In addition to the hierarchy having to be under a single trust @@ -286,7 +286,7 @@ certificates = { ##### Free-form Certificates As an alternative to using the templates, each key pair and certificate can defined using the standard configuration -options. See the [Public Key Infrastructure (PKI) Tool Configuration Parameters](config-pki-tool-parameters.md) documentation for all possible parameters, and see below for examples +options. See the [Public Key Infrastructure (PKI) Tool Configuration Parameters]({{< relref "config-pki-tool-parameters.md" >}}) documentation for all possible parameters, and see below for examples that use this approach. Note that the templates only support local key stores - using a HSM requires the certificate hierarchy to be defined without templates. @@ -298,7 +298,7 @@ explicitly defines all necessary CRL file configurations or all CRL distribution generated without the `Certificate Revocation List Distribution Point` extension and will therefore be incompatible with any network using strict revocation checking. -As outlined in the [Public Key Infrastructure (PKI) Tool Configuration Parameters](config-pki-tool-parameters.md) doc, this extension is defined using the following logic: +As outlined in the [Public Key Infrastructure (PKI) Tool Configuration Parameters]({{< relref "config-pki-tool-parameters.md" >}}) doc, this extension is defined using the following logic: * If the certificate configuration has the `crlDistributionUrl` parameter set then use this. @@ -348,7 +348,7 @@ subordinate’s CRL file must be hosted, and available, on this endpoint. {{< note >}} Existing revocations can be added to the CRL file via the `crl.revocations` parameter. See -[Public Key Infrastructure (PKI) Tool Configuration Parameters](config-pki-tool-parameters.md) for more information. +[Public Key Infrastructure (PKI) Tool Configuration Parameters]({{< relref "config-pki-tool-parameters.md" >}}) for more information. {{< /note >}} For a given certificate, the exact crlDistributionPoint extension can be defined explicitly (rather than inheriting from @@ -375,7 +375,7 @@ certificates { As previously mentioned, it is up to the network operator to ensure that any configured CRL endpoints are available. The Identity Manager supports hosting of these CRL files (see the the “CRL Configuration” section of the -[Identity Manager Service](identity-manager.md) doc). +[Identity Manager Service]({{< relref "identity-manager.md" >}}) doc). ##### HSM Libraries @@ -506,7 +506,7 @@ This will create a JAR called `azure-keyvault-with-deps.jar` which can be refere ##### Generating SSL Keys -As outlined in the [Configuring the CENM services to use SSL](enm-with-ssl.md) doc, all inter-service CENM communication can be configured to encrypt their +As outlined in the [Configuring the CENM services to use SSL]({{< relref "enm-with-ssl.md" >}}) doc, all inter-service CENM communication can be configured to encrypt their messages via SSL. This feature requires the operator to provide a set of SSL key pairs and certificates to each service, which can be generated using the PKI tool. @@ -533,7 +533,7 @@ certificates = { {{< note >}} HSM keys used by the Signing Service require an accompanying certificate store that contains all certificates in the chain, from the signing entity back to the root. This is because the full chains cannot be stored within the -HSMs. Refer to the [Signing Service](signing-service.md) documentation for more information. +HSMs. Refer to the [Signing Service]({{< relref "signing-service.md" >}}) documentation for more information. {{< /note >}} diff --git a/content/en/platform/corda/1.6/cenm/signing-service.md b/content/en/platform/corda/1.6/cenm/signing-service.md index cc2046ce4b9..46ddeea5d48 100644 --- a/content/en/platform/corda/1.6/cenm/signing-service.md +++ b/content/en/platform/corda/1.6/cenm/signing-service.md @@ -31,7 +31,7 @@ particular data to require authentication from multiple users. ## Signing Service overview -The Signing Service supports the following HSMs (see [CENM support matrix](../../../../../en/platform/corda/1.6/cenm/cenm-support-matrix.html#hardware-security-modules-hsms) for more information): +The Signing Service supports the following HSMs (see [CENM support matrix]({{< relref "../../../../../en/platform/corda/1.6/cenm/cenm-support-matrix.md#hardware-security-modules-hsms" >}}) for more information): * Utimaco SecurityServer Se Gen2. * Gemalto Luna. @@ -141,7 +141,7 @@ The configuration for the Signing Service consists of the following sections: The Signing Service is interacted with via the shell, which is configured at the top level of the configuration file. This shell is similar to the interactive shell available in other CENM services and is configured in a similar way. See -[Shell Configuration](../../../../../en/platform/corda/1.6/cenm/shell.html#shell-config) for more information on how to configure the shell. +[Shell Configuration]({{< relref "../../../../../en/platform/corda/1.6/cenm/shell.md#shell-config" >}}) for more information on how to configure the shell. #### HSM libraries diff --git a/content/en/platform/corda/1.6/cenm/updating-network-parameters.md b/content/en/platform/corda/1.6/cenm/updating-network-parameters.md index ddea9613cac..3d7e6e7a529 100644 --- a/content/en/platform/corda/1.6/cenm/updating-network-parameters.md +++ b/content/en/platform/corda/1.6/cenm/updating-network-parameters.md @@ -40,7 +40,7 @@ At a high level, the process is as follows: ## Editing network parameters configuration -See [Setting the Network Parameters](../../../../../en/platform/corda/1.6/cenm/network-map.html#network-parameters) +See [Setting the Network Parameters]({{< relref "../../../../../en/platform/corda/1.6/cenm/network-map.md#network-parameters" >}}) for information on the network parameters configuration file format and options. When updating the network parameters, ensure that the network parameters file has the diff --git a/content/en/platform/corda/1.6/cenm/upgrade-notes.md b/content/en/platform/corda/1.6/cenm/upgrade-notes.md index 78afe200f61..f3f21d66bec 100644 --- a/content/en/platform/corda/1.6/cenm/upgrade-notes.md +++ b/content/en/platform/corda/1.6/cenm/upgrade-notes.md @@ -16,10 +16,10 @@ title: Upgrading Corda Enterprise Network Manager # Upgrading Corda Enterprise Network Manager -This document provides instructions for upgrading your network management suite — Identity Manager Service, Network Map Service, Signing Service, Zone Service, Auth Service, Angel Service — from previous versions to the newest version. Please consult the relevant [release notes](release-notes.md) of the release in question. If not specified, you may assume the versions you are currently using are still in force. +This document provides instructions for upgrading your network management suite — Identity Manager Service, Network Map Service, Signing Service, Zone Service, Auth Service, Angel Service — from previous versions to the newest version. Please consult the relevant [release notes]({{< relref "release-notes.md" >}}) of the release in question. If not specified, you may assume the versions you are currently using are still in force. {{< warning >}} -Before you start the upgrade, you must consult the [CENM Release Notes](release-notes.md) to confirm all changes between releases. +Before you start the upgrade, you must consult the [CENM Release Notes]({{< relref "release-notes.md" >}}) to confirm all changes between releases. {{< /warning >}} ## 1.5.x to 1.6 diff --git a/content/en/platform/corda/1.6/cenm/user-admin.md b/content/en/platform/corda/1.6/cenm/user-admin.md index 06187378101..a3f61bf34b6 100644 --- a/content/en/platform/corda/1.6/cenm/user-admin.md +++ b/content/en/platform/corda/1.6/cenm/user-admin.md @@ -81,7 +81,7 @@ Users can access network services to perform tasks. To give a user permissions, Administrators *cannot* have any role as a user on your network operation services. -![create_user](../../../../../en/platform/corda/1.6/cenm/resources/create_user_new.png) +![create_user](resources/create_user_new.png) {{< note >}} You must be registered as an administrator to create new users and administrators. @@ -111,7 +111,7 @@ To add a new user or administrator: You can change a user's status, password, or group membership from the **User Details** screen. -![Manage user](../../../../../en/platform/corda/1.6/cenm/resources/user_details_new.png) +![Manage user](resources/user_details_new.png) 1. Select **Users** from the side menu to view the user list. @@ -134,7 +134,7 @@ You can change a user's status, password, or group membership from the **User De Groups let you grant multiple users the same set of permissions. Groups make it easier for you to manage permissions of future users - just add them to the relevant groups instead of configuring individual roles. -![Creating a group](../../../../../en/platform/corda/1.6/cenm/resources/create_group_new.png) +![Creating a group](resources/create_group_new.png) To create a group: @@ -157,7 +157,7 @@ You can access all your groups from the **Groups** screen. You can add or remove members of a group, or delete an existing group. Deleting a group does not delete the users in the group. -![Manage a group](../../../../../en/platform/corda/1.6/cenm/resources/group_details_new.png) +![Manage a group](resources/group_details_new.png) To make changes to a group: 1. Select **Groups** from the side menu to view your existing groups. @@ -183,7 +183,7 @@ To make changes to a group: Roles are made up of permissions that allow users to perform tasks in CENM. You can create roles by combining the required permissions, and then assigning the role to users and/or groups. -![Create a Role](../../../../../en/platform/corda/1.6/cenm/resources/create_role_new.png) +![Create a Role](resources/create_role_new.png) To create a new role: 1. Select **Roles** from the side menu. @@ -205,7 +205,7 @@ You have added a new role. All users and groups assigned this role are granted i You can assign a role to additional users and groups, remove roles from users and groups, add and remove permissions in a role, and delete roles at any time. -![Manage a Role](../../../../../en/platform/corda/1.6/cenm/resources/role_details_new.png) +![Manage a Role](resources/role_details_new.png) To amend the properties of a role: 1. Select **Roles** from the side menu. diff --git a/content/en/platform/corda/1.6/cenm/zone-service.md b/content/en/platform/corda/1.6/cenm/zone-service.md index a9303342237..b5f73fd2779 100644 --- a/content/en/platform/corda/1.6/cenm/zone-service.md +++ b/content/en/platform/corda/1.6/cenm/zone-service.md @@ -278,7 +278,7 @@ serviceLocations = { ``` {{< note >}} -The `timeout` parameter used in the example above is optional. It allows to set a Signing Service timeout for communication to each of the services used within the signing processes defined in the [signers map](../../../../../en/platform/corda/1.6/cenm/signing-service.html#signers-map-entry-example), in a way that allows high node count network maps to get signed and to operate at reliable performance levels. The `timeout` value is set in milliseconds and the default value is 10000 milliseconds. The `timeout` parameter's value is stored in a column in the [Zone Service]({{< relref "../../../../../en/platform/corda/1.6/cenm/zone-service.md" >}})'s database tables `socket_config` and `signer_config` called `timeout`. This value can remain `null` (for example, if `timeout` is not defined in `serviceLocations`), in which case the default 10000 milliseconds value (`timeout = 10000`) will be used wherever applicable. Please note that currently, due to a known issue with `serviceLocations`, when the `timeout` parameter is passed to the Zone Service via the Signing Service's `serviceLocations` configuration block, only the `timeout` value of the first `serviceLocations` location will be taken into account and used for all other service locations. +The `timeout` parameter used in the example above is optional. It allows to set a Signing Service timeout for communication to each of the services used within the signing processes defined in the [signers map]({{< relref "../../../../../en/platform/corda/1.6/cenm/signing-service.md#signers-map-entry-example" >}}), in a way that allows high node count network maps to get signed and to operate at reliable performance levels. The `timeout` value is set in milliseconds and the default value is 10000 milliseconds. The `timeout` parameter's value is stored in a column in the [Zone Service]({{< relref "../../../../../en/platform/corda/1.6/cenm/zone-service.md" >}})'s database tables `socket_config` and `signer_config` called `timeout`. This value can remain `null` (for example, if `timeout` is not defined in `serviceLocations`), in which case the default 10000 milliseconds value (`timeout = 10000`) will be used wherever applicable. Please note that currently, due to a known issue with `serviceLocations`, when the `timeout` parameter is passed to the Zone Service via the Signing Service's `serviceLocations` configuration block, only the `timeout` value of the first `serviceLocations` location will be taken into account and used for all other service locations. {{< /note >}} ## Interaction with Angel Services diff --git a/content/en/platform/corda/4.10/community/api-contract-constraints.md b/content/en/platform/corda/4.10/community/api-contract-constraints.md index 810b58b4070..49e813ea43f 100644 --- a/content/en/platform/corda/4.10/community/api-contract-constraints.md +++ b/content/en/platform/corda/4.10/community/api-contract-constraints.md @@ -13,7 +13,7 @@ tags: - api - contract - constraints -title: 'API: Contract Constraints' +title: 'API: Contract constraints' --- # Contract constraints @@ -36,13 +36,10 @@ This document explains: ## Glossary These terms are used throughout this document: -*contract constraints* Instructions in a CorDapp's attachments that determine which versions of a CorDapp parties in a transaction can use to provide contracts. - -**composite key** A key that consists of two or more attributes that together uniquely identify an entity occurrence. - -*signature constraint* A constraint that lets participants use any version of the CorDapp signed by the `CompositeKey`. - -*blacklisting* A process that prevents a transaction signer from processing transactions. +- **Contract constraints:** Instructions in a CorDapp's attachments that determine which versions of a CorDapp parties in a transaction can use to provide contracts. +- **Composite key:** A key that consists of two or more attributes that together uniquely identify an entity occurrence. +- **Signature constraint:** A constraint that lets participants use any version of the CorDapp signed by the `CompositeKey`. +- **Blacklisting:** A process that prevents a transaction signer from processing transactions. @@ -54,7 +51,7 @@ You can upgrade smart contracts via: * **Explicit upgrade**. Create a special *contract upgrade transaction* and get all the participants listed on a state to sign it using the contract upgrade flows. This lets you upgrade states even if they have a constraint. Unlike implicit upgrade, this is a complex method which requires all participants to sign and manually authorise the upgrade, and consumes notary and ledger resources. -This article focuses on implicit contract upgrades. To learn about the explicit upgrades see [Release new CorDapp versions](upgrading-cordapps.md). +This article focuses on implicit contract upgrades. To learn about the explicit upgrades see [Release new CorDapp versions]({{< relref "upgrading-cordapps.md" >}}). @@ -70,7 +67,7 @@ Before signature constraints were released with Corda 4.0, constraints were mana * **Hash constraint**: Participants can only use one version of the CorDapp state. This prevents the CorDapp from being upgraded in the future while still making use of any states created using the original version. * **Compatibility zone whitelisted (or CZ whitelisted) constraint**: The compatibility zone operator lists the hashes of the versions that can be used with a contract class name. -You can [migrate CorDapp contraints](cordapp-constraint-migration.md) from older versions by consuming and evolving pre-Corda 4 issued hash or CZ whitelisted constrained states using a Corda 4 signed CorDapp with signature constraints. +You can [migrate CorDapp contraints]({{< relref "cordapp-constraint-migration.md" >}}) from older versions by consuming and evolving pre-Corda 4 issued hash or CZ whitelisted constrained states using a Corda 4 signed CorDapp with signature constraints. ## Signature constraints @@ -86,7 +83,7 @@ The `TransactionBuilder` uses signature constraints when adding output states fo ## Signing CorDapps -CorDapps that use signature constraints must be signed by a `CompositeKey` or a simpler `PublicKey`. CorDapps can be signed by a single organisation or multiple organisations. After the CorDapp is signed, it can be distributed to the relevant Corda nodes. Signed CorDapps require a [version number](versioning.md). +CorDapps that use signature constraints must be signed by a `CompositeKey` or a simpler `PublicKey`. CorDapps can be signed by a single organisation or multiple organisations. After the CorDapp is signed, it can be distributed to the relevant Corda nodes. Signed CorDapps require a [version number]({{< relref "versioning.md" >}}). {{< note >}} The platform currently supports `CompositeKey`s, up to a maximum of 20 keys. @@ -100,7 +97,7 @@ Nodes will also trust attachments that: * Are installed manually. * Are uploaded via RPC. -You can [sign a CorDapp directly from Gradle](cordapp-build-systems.html#signing-the-cordapp-jar). +You can [sign a CorDapp directly from Gradle]({{< relref "cordapp-build-systems.md#signing-the-cordapp-jar" >}}). ### CorDapp contract storage and retrieval @@ -111,7 +108,7 @@ You can retrieve a JAR by hash using `AttachmentStorage.openAttachment`. You can {{< warning >}} -Follow best practices by [structuring your CorDapp](cordapp-structure.md) as two modules: one that only contains contracts, states, and core data types, and another containing the rest of the CorDapp elements. If you structure your CorDapp as a single module, your entire CorDapp is published to the ledger. This causes the ledger to view changes to your flows or other parts of your CorDapp as a new CorDapp, and could trigger unnecessary upgrade procedures. +Follow best practices by [structuring your CorDapp]({{< relref "writing-a-cordapp.md" >}}) as two modules: one that only contains contracts, states, and core data types, and another containing the rest of the CorDapp elements. If you structure your CorDapp as a single module, your entire CorDapp is published to the ledger. This causes the ledger to view changes to your flows or other parts of your CorDapp as a new CorDapp, and could trigger unnecessary upgrade procedures. {{< /warning >}} @@ -122,7 +119,7 @@ If you need to prevent a signer from processing transactions, you can *blacklist CorDapps and other attachments installed on a node still run, even if they are signed by a blacklisted key. Only attachments received from a peer are affected. -You can also [blacklist keys](corda-configuration-file.html#corda-configuration-file-blacklisted-attachment-signer-keys). +You can also [blacklist keys]({{< relref "corda-configuration-file.md#corda-configuration-file-blacklisted-attachment-signer-keys" >}}). Below are two examples of scenarios involving blacklisted signing keys. In each example: @@ -302,7 +299,7 @@ If the node cannot resolve an attachment constraint it will throw a `MissingCont ### Not setting CorDapp packages in tests -You must specify which CorDapp packages to scan when you run tests. Provide a package containing the contract class in `MockNetworkParameters`. See [Testing CorDapps](api-testing.md). +You must specify which CorDapp packages to scan when you run tests. Provide a package containing the contract class in `MockNetworkParameters`. See [Testing CorDapps]({{< relref "api-testing.md" >}}). You must also specify a package when testing using `DriverDSl`. `DriverParameters` has a property `cordappsForAllNodes` (Kotlin) or method `withCordappsForAllNodes` in Java. Pass the collection of `TestCordapp` created by utility method `TestCordapp.findCordapp(String)`. @@ -345,7 +342,7 @@ Driver.driver( ### Starting a node that is missing CorDapp(s) -Make sure you place all CorDapp JARs in the `cordapps` directory of each node. The Gradle Cordform task `deployNodes` copies all JARs by default, if you have specified CorDapps to deploy. See [Creating nodes locally](generating-a-node.html#creating-nodes-locally) for detailed instructions. +Make sure you place all CorDapp JARs in the `cordapps` directory of each node. The Gradle Cordform task `deployNodes` copies all JARs by default, if you have specified CorDapps to deploy. See [Creating nodes locally]({{< relref "generating-a-node.md#creating-nodes-locally" >}}) for detailed instructions. ### Including an incorrect fully-qualified contract name diff --git a/content/en/platform/corda/4.10/community/api-contracts.md b/content/en/platform/corda/4.10/community/api-contracts.md index add43588451..2cd8892a681 100644 --- a/content/en/platform/corda/4.10/community/api-contracts.md +++ b/content/en/platform/corda/4.10/community/api-contracts.md @@ -70,7 +70,7 @@ class XContract : Contract { ``` {{< note >}} -See [Reissuing states](reissuing-states.md) for information about reissuing states with a guaranteed state replacement, which lets you break transaction backchains. +See [Reissuing states]({{< relref "reissuing-states.md" >}}) for information about reissuing states with a guaranteed state replacement, which lets you break transaction backchains. {{< /note >}} ## The `Contract` class @@ -202,7 +202,7 @@ data class CommandWithParties( val signingParties: List, val value: T ) - +``` * `signers`: The list of each signer’s `PublicKey`. * `signingParties` (deprecated): The list of the signer’s identities, if known. @@ -238,6 +238,6 @@ class XContract : Contract { ## Further reading -* [Contract Constraints](api-contract-constraints.md) -* [Write CorDapp States](api-states.md) -* [Writing CorDapp Flows](api-flows.md) +* [Contract constraints]({{< relref "api-contract-constraints.md" >}}) +* [Write CorDapp states]({{< relref "api-states.md" >}}) +* [Writing CorDapp flows]({{< relref "api-flows.md" >}}) diff --git a/content/en/platform/corda/4.10/community/api-flows.md b/content/en/platform/corda/4.10/community/api-flows.md index aab5e3ce27c..a10842ae766 100644 --- a/content/en/platform/corda/4.10/community/api-flows.md +++ b/content/en/platform/corda/4.10/community/api-flows.md @@ -66,7 +66,7 @@ The `initiator`: The `initiator`: -1. Runs the [contracts](api-contracts.md) contained in the CorDapp. +1. Runs the [contracts]({{< relref "api-contracts.md" >}}) contained in the CorDapp. 2. Verifies that the transaction is valid based on the contracts. @@ -103,7 +103,7 @@ The `responder`: 1. Receives the transaction from the counterparty. 2. Verifies the transaction’s existing signatures. -3. Runs the [contracts](api-contracts.md) contained in the CorDapp. +3. Runs the [contracts]({{< relref "api-contracts.md" >}}) contained in the CorDapp. 4. Verifies that the transaction is valid based on the contracts. @@ -268,14 +268,14 @@ public static class InitiatorFlow extends FlowLogic { ### Accessing the node's `ServiceHub` You can access the node's `ServiceHub` within `FlowLogic.call`. The `ServiceHub` provides access to the -node's services. See [Accessing node services](api-service-hub.md) for more information. +node's services. See [Accessing node services]({{< relref "api-service-hub.md" >}}) for more information. ### Common flow tasks To agree ledger updates, you need to perform a number of common tasks within `FlowLogic.call`: -* **Transaction building:** The majority of the work performed during a flow is building, verifying, and signing a transaction. See [Understanding transactions](api-transactions.md). -* **Extracting states from the vault:**: When building a transaction, you’ll often need to extract the states you wish to consume from the vault. See [Writing vault queries](api-vault-query.md). +* **Transaction building:** The majority of the work performed during a flow is building, verifying, and signing a transaction. See [Understanding transactions]({{< relref "api-transactions.md" >}}). +* **Extracting states from the vault:**: When building a transaction, you’ll often need to extract the states you wish to consume from the vault. See [Writing vault queries]({{< relref "api-vault-query.md" >}}). * **Retrieving information about other nodes:**: You can retrieve information about other nodes on the network and the services they offer using `ServiceHub.networkMapCache`. ### Notaries @@ -660,7 +660,7 @@ Corda installs four initiating subflow pairs on each node by default: {{< warning >}} `SwapIdentitiesFlow` and `SwapIdentitiesHandler` are only installed if you include the `confidential-identities` module. The `confidential-identities` module is not yet stabilized, so the -`SwapIdentitiesFlow`/`SwapIdentitiesHandler` API may change in future releases. See [API stability guarantees](api-stability-guarantees.md). +`SwapIdentitiesFlow`/`SwapIdentitiesHandler` API may change in future releases. See [API stability guarantees]({{< relref "api-stability-guarantees.md" >}}). {{< /warning >}} @@ -765,7 +765,7 @@ transaction fail to verify it, or the receiving flow (the finality handler) fail all parties will not have the up-to-date view of the ledger. To recover from this scenario, the receiver’s finality handler is automatically sent to the `node-flow-hospital`. There, it is suspended and retried from its last checkpoint -upon node restart, or according to other conditional retry rules - see [flow hospital runtime behavior](node-flow-hospital.md). +upon node restart, or according to other conditional retry rules - see [flow hospital runtime behavior]({{< relref "node-flow-hospital.md" >}}). This gives the node operator the opportunity to recover from the error. Until the issue is resolved, the node will continue to retry the flow on each startup. Upon successful completion by the receiver’s finality flow, the ledger will become fully consistent. @@ -1188,7 +1188,7 @@ You could use this functionality to: thread pool. {{< note >}} -The size of the external operation thread pool can be configured. See [the node configuration documentation](corda-configuration-file.md). +The size of the external operation thread pool can be configured. See [the node configuration documentation]({{< relref "corda-configuration-file.md" >}}). {{< /note >}} You can call `FlowExternalOperation` from a flow to run an operation on a new thread, allowing the flow to suspend: diff --git a/content/en/platform/corda/4.10/community/api-identity.md b/content/en/platform/corda/4.10/community/api-identity.md index df4e5c7a544..5701ab60b55 100644 --- a/content/en/platform/corda/4.10/community/api-identity.md +++ b/content/en/platform/corda/4.10/community/api-identity.md @@ -59,7 +59,7 @@ certificate path proving the certificate was issued by the doorman service. {{< warning >}} The `confidential-identities` module is still not stabilised, so this API may change in future releases. -See [API stability guarantees](api-stability-guarantees.md). +See [API stability guarantees]({{< relref "api-stability-guarantees.md" >}}). {{< /warning >}} diff --git a/content/en/platform/corda/4.10/community/api-persistence.md b/content/en/platform/corda/4.10/community/api-persistence.md index eb14dbc629e..d48798705eb 100644 --- a/content/en/platform/corda/4.10/community/api-persistence.md +++ b/content/en/platform/corda/4.10/community/api-persistence.md @@ -21,7 +21,7 @@ title: 'API: Persistence' Corda offers developers the option to expose all or some parts of a contract state to an *Object Relational Mapping* (ORM) tool to be persisted in a *Relational Database Management System* (RDBMS). -The purpose of this, is to assist [Vault](key-concepts-vault.md) +The purpose of this, is to assist [Vault]({{< relref "key-concepts-vault.md" >}}) development and allow for the persistence of state data to a custom database table. Persisted states held in the vault are indexed for the purposes of executing queries. This also allows for relational joins between Corda tables and the organization’s existing data. @@ -33,7 +33,7 @@ automatically every time a state is recorded in the node’s local vault as part {{< note >}} By default, nodes use an H2 database which is accessed using *Java Database Connectivity* JDBC. Any database with a JDBC driver is a candidate and several integrations have been contributed to by the community. -Please see the info in “[Node database](node-database-access-h2.md)” for details. +Please see the info in [Node database]({{< relref "node-database-access-h2.md" >}}) for details. {{< /note >}} @@ -367,7 +367,7 @@ database.transaction { [HibernateConfigurationTest.kt](https://github.com/corda/corda/blob/release/os/4.10/node/src/test/kotlin/net/corda/node/services/persistence/HibernateConfigurationTest.kt) -JDBC sessions can be used in flows and services (see “[Writing flows](api-flows.md)”). +JDBC sessions can be used in flows and services (see [Writing flows]({{< relref "api-flows.md" >}})). The following example illustrates the creation of a custom Corda service using a `jdbcSession`: @@ -445,7 +445,7 @@ override fun call(): List { } ``` -For examples on testing `@CordaService` implementations, see the oracle example [here](key-concepts-oracles.md). +For examples on testing `@CordaService` implementations, see the oracle example [here]({{< relref "key-concepts-oracles.md" >}}). ### Restricted control of connections diff --git a/content/en/platform/corda/4.10/community/api-scanner.md b/content/en/platform/corda/4.10/community/api-scanner.md index 2134a8f37ac..62de4650773 100644 --- a/content/en/platform/corda/4.10/community/api-scanner.md +++ b/content/en/platform/corda/4.10/community/api-scanner.md @@ -19,7 +19,7 @@ title: Checking API stability # Checking API stability We have committed not to alter Corda’s API so that developers will not have to keep rewriting their CorDapps with each -new Corda release. The stable Corda modules are listed [here](api-stability-guarantees.md). Our CI process runs an “API Stability” +new Corda release. The stable Corda modules are listed [here]({{< relref "api-stability-guarantees.md" >}}). Our CI process runs an “API Stability” check for each GitHub pull request in order to check that we don’t accidentally introduce an API-breaking change. @@ -45,7 +45,7 @@ its signature somehow altered. * Addition of a new method to an interface or abstract class. Types that have been annotated as `@DoNotImplement` are excluded from this check. (This annotation is also inherited across subclasses and sub-interfaces.) * Exposure of an internal type via a public API. Internal types are considered to be anything in a `*.internal.` package -or anything in a module that isn’t in the stable modules list [here](api-stability-guarantees.md). +or anything in a module that isn’t in the stable modules list [here]({{< relref "api-stability-guarantees.md" >}}). Developers can execute these commands themselves before submitting their PR, to ensure that they haven’t inadvertently broken Corda’s API. diff --git a/content/en/platform/corda/4.10/community/api-states.md b/content/en/platform/corda/4.10/community/api-states.md index 5ec38ad98bb..a990674f818 100644 --- a/content/en/platform/corda/4.10/community/api-states.md +++ b/content/en/platform/corda/4.10/community/api-states.md @@ -20,7 +20,7 @@ title: 'API: States' # CorDapp states -Before you read this article, make sure you understand the [state key concepts](key-concepts-states.md). +Before you read this article, make sure you understand the [state key concepts]({{< relref "key-concepts-states.md" >}}). In Corda, a contract state (or just ‘state’) stores data that the CorDapp needs to move from one transaction to another. @@ -54,7 +54,7 @@ The `participants` in a state: * Receive any finalized transactions as part of `FinalityFlow` / `ReceiveFinalityFlow`. {{< note >}} -See [Reissuing states](reissuing-states.md) for information about reissuing states with a guaranteed state replacement, which allows you to break transaction backchains. +See [Reissuing states]({{< relref "reissuing-states.md" >}}) for information about reissuing states with a guaranteed state replacement, which allows you to break transaction backchains. {{< /note >}} ## ContractState sub-interfaces diff --git a/content/en/platform/corda/4.10/community/api-transactions.md b/content/en/platform/corda/4.10/community/api-transactions.md index b53846e8950..efaa71aee9d 100644 --- a/content/en/platform/corda/4.10/community/api-transactions.md +++ b/content/en/platform/corda/4.10/community/api-transactions.md @@ -21,9 +21,9 @@ title: 'API: Transactions' # API: Transactions {{< note >}} -Before reading this page, you should be familiar with the key concepts of [Transactions](key-concepts-transactions.md). +Before reading this page, you should be familiar with the key concepts of [Transactions]({{< relref "key-concepts-transactions.md" >}}). -See also [Reissuing states](reissuing-states.md) for information about reissuing states with a guaranteed state replacement, which allows you to break transaction backchains. +See also [Reissuing states]({{< relref "reissuing-states.md" >}}) for information about reissuing states with a guaranteed state replacement, which allows you to break transaction backchains. {{< /note >}} @@ -419,7 +419,7 @@ TransactionBuilder txBuilder = new TransactionBuilder(specificNotary); {{< /tabs >}} -We discuss the selection of a notary in [API: Flows](api-flows.md). +We discuss the selection of a notary in [API: Flows]({{< relref "api-flows.md" >}}). If the transaction does not have any input states or a time-window, it does not require a notary, and can be instantiated without one: @@ -802,7 +802,7 @@ If a transaction has inputs, we need to retrieve all the states in the transacti verify the transaction’s contents. This is because the transaction is only valid if its dependency chain is also valid. We do this by requesting any states in the chain that our node doesn’t currently have in its local storage from the proposer(s) of the transaction. This process is handled by a built-in flow called `ReceiveTransactionFlow`. -See [API: Flows](api-flows.md) for more details. +See [API: Flows]({{< relref "api-flows.md" >}}) for more details. We can now verify the transaction’s contents to ensure that it satisfies the contracts of all the transaction’s input and output states: @@ -1085,5 +1085,5 @@ TransactionSignature sig2 = getServiceHub().createSignature(onceSignedTx, otherI ### Notarising and recording -Notarising and recording a transaction is handled by a built-in flow called `FinalityFlow`. See [API: Flows](api-flows.md) for +Notarising and recording a transaction is handled by a built-in flow called `FinalityFlow`. See [API: Flows]({{< relref "api-flows.md" >}}) for more details. diff --git a/content/en/platform/corda/4.10/community/api-vault-query.md b/content/en/platform/corda/4.10/community/api-vault-query.md index edea3c6a6d2..dce3a5132bc 100644 --- a/content/en/platform/corda/4.10/community/api-vault-query.md +++ b/content/en/platform/corda/4.10/community/api-vault-query.md @@ -31,7 +31,7 @@ Corda provides a number of flexible query mechanisms for accessing the Vault: * Vault Query API -* Using a JDBC session (as described in [API: Persistence](api-persistence.html#jdbc-session)) +* Using a JDBC session (as described in [API: Persistence]({{< relref "api-persistence.md#jdbc-session" >}})) * Custom [JPA](https://docs.spring.io/spring-data/jpa/docs/current/reference/html)/[JPQL](http://docs.jboss.org/hibernate/orm/current/userguide/html_single/Hibernate_User_Guide.html#hql) queries * Custom 3rd party Data Access frameworks such as [Spring Data](http://projects.spring.io/spring-data) @@ -175,7 +175,7 @@ There are four implementations of this interface which can be chained together t * `VaultQueryCriteria` provides filterable criteria on attributes within the **VAULT_STATES** table. Filterable attributes include one or more of the following: status (`UNCONSUMED`, -`CONSUMED`), state reference, contract state type, notary name, soft locked states, timestamps (`RECORDED`, `CONSUMED`), state constraints (see [Constraint Types](api-contract-constraints.md)), relevancy (`ALL`, `RELEVANT`, `NON_RELEVANT`), and participants (exact or any match). +`CONSUMED`), state reference, contract state type, notary name, soft locked states, timestamps (`RECORDED`, `CONSUMED`), state constraints (see [Constraint Types]({{< relref "api-contract-constraints.md" >}})), relevancy (`ALL`, `RELEVANT`, `NON_RELEVANT`), and participants (exact or any match). {{< note >}} Sensible defaults are defined for frequently used attributes (`status` = `UNCONSUMED`, always include soft locked states).{{< /note >}} @@ -199,7 +199,7 @@ interfaces' common state attributes to the **VAULT_LINEAR_STATES** table.{{< /no * `VaultCustomQueryCriteria` provides the means to specify one or many arbitrary expressions on attributes defined -by a custom contract state that implements its own schema as described in the [API: Persistence](api-persistence.md) +by a custom contract state that implements its own schema as described in the [API: Persistence]({{< relref "api-persistence.md" >}}) documentation and associated examples. Custom criteria expressions are expressed using one of the following type-safe forms of `CriteriaExpression`: `BinaryLogical`, `Not`, `ColumnPredicateExpression`, and `AggregateFunctionExpression`. The `ColumnPredicateExpression` allows for the specification of arbitrary criteria using the previously enumerated operator @@ -221,7 +221,7 @@ construction of custom criteria using any combination of `ColumnPredicate`. See `QueryCriteriaUtils` for a complete specification of the DSL. {{< note >}} Custom contract schemas are automatically registered upon node startup for CorDapps. Please refer to -[API: Persistence](api-persistence.md) for mechanisms of registering custom schemas for different testing +[API: Persistence]({{< relref "api-persistence.md" >}}) for mechanisms of registering custom schemas for different testing purposes.{{< /note >}} @@ -262,11 +262,11 @@ Custom contract states that implement the `Queryable` interface may now extend t {{< /note >}} {{< note >}} -When specifying the `ContractType` as a parameterised type to the `QueryCriteria` in Kotlin, queries now include all concrete implementations of that type if this is an interface. Previously, it was only possible to query on concrete types (or the universe of all `ContractState`). +When specifying the `ContractType` as a parameterized type to the `QueryCriteria` in Kotlin, queries now include all concrete implementations of that type if this is an interface. Previously, it was only possible to query on concrete types (or the universe of all `ContractState`). {{< /note >}} The Vault Query API leverages the rich semantics of the underlying JPA [Hibernate](https://docs.jboss.org/hibernate/jpa/2.1/api/) based -[API: Persistence](api-persistence.md) framework adopted by Corda. +[API: Persistence]({{< relref "api-persistence.md" >}}) framework adopted by Corda. {{< note >}} diff --git a/content/en/platform/corda/4.10/community/app-upgrade-notes.md b/content/en/platform/corda/4.10/community/app-upgrade-notes.md index 8d33fde802c..c864f5b12b1 100644 --- a/content/en/platform/corda/4.10/community/app-upgrade-notes.md +++ b/content/en/platform/corda/4.10/community/app-upgrade-notes.md @@ -135,7 +135,7 @@ used as an `AbstractParty` but has an actual value that is one of `Party` or `An implement `Destination`, while the superclass does not. Kotlin must pick a type for the variable, and so chooses the most specific ancestor of both `AbstractParty` and `Destination`. This is `Any`, which is not a valid type for use as an `AbstractParty` later. For more information on `Destination`, see the KDocs for the interface -[here](../../../../api-ref/api-ref-corda-4.html#corda-community-edition-4x-api-reference). +[here]({{< relref "../../../../api-ref/api-ref-corda-4.md#corda-community-edition-4x-api-reference" >}}). Note that this is a Kotlin-specific issue. Java can instead choose `? extends AbstractParty & Destination` here, which can later be used as `AbstractParty`. diff --git a/content/en/platform/corda/4.10/community/apps/bankinabox/api-guide.md b/content/en/platform/corda/4.10/community/apps/bankinabox/api-guide.md index 4e81a8a42bc..d44f9d84d9b 100644 --- a/content/en/platform/corda/4.10/community/apps/bankinabox/api-guide.md +++ b/content/en/platform/corda/4.10/community/apps/bankinabox/api-guide.md @@ -20,7 +20,7 @@ These endpoints and their corresponding flows are described below, organised by ## Base URL -As Bank in a Box is used for testing and learning, the base URL is `localhost` with the [port assigned during installation](./getting-started.html#service-endpoints-display-logs-and-exec-into-container) using the Kubernetes port forward feature. +As Bank in a Box is used for testing and learning, the base URL is `localhost` with the [port assigned during installation]({{< relref "./getting-started.md#service-endpoints-display-logs-and-exec-into-container" >}}) using the Kubernetes port forward feature. For the examples shown below, the base URL is: `http://localhost:7777/` @@ -262,9 +262,9 @@ curl --location --request POST 'http://localhost:7777/register/admin/revokeRole? The Account Controller includes API endpoints that manage user accounts in the Bank in a Box. Requests sent to these endpoints allow an admin user to create a current account, create a savings account, issue a loan, set account limits, approve overdrafts, and list all accounts or account by account or customer ID. -### Create a Current Account +### Create a current account -Send a `POST` request to the `/accounts/create-current-account` endpoint to invoke the `CreateCurrentAccountFlow`. This flow creates a zero balance current account for a customer with the provided customer ID. The user also has the option to specify a withdrawal and/or transfer daily limit. This request requires authorization. It can be sent by an admin user. +Send a `POST` request to the `/accounts/create-current-account` endpoint to invoke the [CreateCurrentAccountFlow]({{< relref "./back-end-guide.md#createcurrentaccountflow" >}}). This flow creates a zero balance current account for a customer with the provided customer ID. The user also has the option to specify a withdrawal and/or transfer daily limit. This request requires authorization. It can be sent by an admin user. - Request type: `POST`. - Path: `/accounts/create-current-account`. @@ -322,9 +322,9 @@ Sample response: ``` -### Create a Savings Account +### Create a savings account -Send a `POST` request to the `/accounts/create-savings-account` endpoint to invoke the `CreateSavingsAccountFlow`. This flow creates a zero balance savings account for a customer with the provided customer ID. This request requires authorization. It can be sent by an admin user. +Send a `POST` request to the `/accounts/create-savings-account` endpoint to invoke the [CreateSavingsAccountFlow]({{< relref "back-end-guide.md#createsavingsaccountflow" >}}). This flow creates a zero balance savings account for a customer with the provided customer ID. This request requires authorization. It can be sent by an admin user. - Request type: `POST`. - Path: `/accounts/create-savings-account`. @@ -382,7 +382,7 @@ Sample response: ### Approve overdraft -Send a `PUT` request to the `/accounts/approve-overdraft-account` endpoint to invoke the `ApproveOverdraftFlow`. This flow is used to approve an overdraft limit for an account with the specified account ID. This request requires authorization. It can be sent by an admin user. +Send a `PUT` request to the `/accounts/approve-overdraft-account` endpoint to invoke the [ApproveOverdraftFlow]({{< relref "./back-end-guide.md#approveoverdraftflow" >}}). This flow is used to approve an overdraft limit for an account with the specified account ID. This request requires authorization. It can be sent by an admin user. - Request type: `PUT`. - Path: `/accounts/approve-overdraft-account`. @@ -439,7 +439,7 @@ Sample response: ### Issue a loan -Send a `POST` request to the `/accounts/issue-loan` endpoint to invoke the `IssueLoanFlow`. The `IssueLoanFlow` issues a new loan to a customer with the repayment account referenced by the account ID. This request requires authorization. It can be sent by an admin user. +Send a `POST` request to the `/accounts/issue-loan` endpoint to invoke the [IssueLoanFlow]({{< relref "back-end-guide.md#issueloanflow" >}}). The `IssueLoanFlow` issues a new loan to a customer with the repayment account referenced by the account ID. This request requires authorization. It can be sent by an admin user. - Request type: `POST`. - Path: `/accounts/issue-loan`. @@ -522,9 +522,9 @@ Sample response: ``` -### Set Account Status +### Set account status -Send a `PUT` request to the `/accounts/set-status` endpoint to invoke the `SetAccountStatusFlow`. The `SetAccountStatusFlow` updates the status of an account with a specified account ID. This request requires authorization. It can be sent by an admin user. +Send a `PUT` request to the `/accounts/set-status` endpoint to invoke the [SetAccountStatusFlow]({{< relref "./back-end-guide.md#setaccountstatusflow" >}}). The `SetAccountStatusFlow` updates the status of an account with a specified account ID. This request requires authorization. It can be sent by an admin user. - Request type: `PUT`. - Path: `/accounts/set-status`. @@ -580,7 +580,7 @@ Sample response: ### Set account limits -Send a `PUT` request to the `/accounts/set-limits` endpoint to invoke the `SetAccountLimitsFlow`. The `SetAccountLimitsFlow` changes the daily withdrawal and transfer limits, or maximum spending, for the provided account ID. This request requires authorization. It can be set by an admin or customer user. +Send a `PUT` request to the `/accounts/set-limits` endpoint to invoke the [SetAccountLimitsFlow]({{< relref "back-end-guide.md#setaccountlimitsflow" >}}). The `SetAccountLimitsFlow` changes the daily withdrawal and transfer limits, or maximum spending, for the provided account ID. This request requires authorization. It can be set by an admin or customer user. - Request type: `PUT`. - Path: `/accounts/set-limits`. @@ -637,7 +637,7 @@ Sample response: ### Get account by account ID -Send a `GET` request to the `/accounts/{accountId}` endpoint to invoke the `GetAccountFlow`. This flow returns the account information for a given account ID. This request requires authorization. It can be sent by an admin user or the customer who owns the account. +Send a `GET` request to the `/accounts/{accountId}` endpoint to invoke the [GetAccountFlow]({{< relref "back-end-guide.md#getaccountflow" >}}). This flow returns the account information for a given account ID. This request requires authorization. It can be sent by an admin user or the customer who owns the account. - Request type: `GET`. - Path: `/accounts/{accountId}`. @@ -686,7 +686,7 @@ Sample response: ### Get accounts -Send a `GET` request to the `/accounts` endpoint to invoke the `GetAccountsPaginatedFlow`. This flows displays a list of accounts and their associated customer information that match the given search criteria. This request requires authorization. It can be sent by an admin user. +Send a `GET` request to the `/accounts` endpoint to invoke the [GetAccountsPaginatedFlow]({{< relref "./back-end-guide.md#getaccountspaginatedflow" >}}). This flows displays a list of accounts and their associated customer information that match the given search criteria. This request requires authorization. It can be sent by an admin user. - Request type: `GET`. - Path: `/accounts`. @@ -1003,7 +1003,7 @@ Sample response: ### Get accounts for a specific customer ID -Send a `GET` request to the `/accounts/customer/{customerId}` endpoint to invoke the `GetAccountsForCustomerPaginatedFlow`. The `GetAccountsForCustomerPaginatedFlow` displays a list of accounts for the given customer ID. This request requires authorization. It can be sent by an admin user. +Send a `GET` request to the `/accounts/customer/{customerId}` endpoint to invoke the [GetAccountsForCustomerPaginatedFlow]({{< relref "./back-end-guide.md#getaccountsforcustomerpaginatedflow" >}}). The `GetAccountsForCustomerPaginatedFlow` displays a list of accounts for the given customer ID. This request requires authorization. It can be sent by an admin user. - Request type: `GET`. - Path: `/accounts/customer/{customerId}`. @@ -1191,7 +1191,7 @@ Sample response: ### Create a customer -Send a `POST` request to the `/customers/create` endpoint to invoke the `CreateCustomerFlow`. This flow creates a customer profile that includes personal details and contact information, and returns the customer ID. This request requires authorization. It can be sent by an admin user. +Send a `POST` request to the `/customers/create` endpoint to invoke the [CreateCustomerFlow]({{< relref "back-end-guide.md#createcustomerflow" >}}). This flow creates a customer profile that includes personal details and contact information, and returns the customer ID. This request requires authorization. It can be sent by an admin user. - Request type: `POST`. - Path: `/customers/create`. @@ -1226,7 +1226,7 @@ Sample response: ### Get customers -Send a `GET` request to the `/customers` endpoint to invoke the `GetCustomersPaginatedFlow`. This flow returns a paginated list of all customers matching the given search crtieria. This request requires authorization. It can be sent by an admin user. +Send a `GET` request to the `/customers` endpoint to invoke the [GetCustomersPaginatedFlow]({{< relref "./back-end-guide.md#getcustomerspaginatedflow" >}}). This flow returns a paginated list of all customers matching the given search criteria. This request requires authorization. It can be sent by an admin user. - Request type: `GET`. - Path: `/customers`. @@ -1315,7 +1315,7 @@ Sample response: ### Get customer by customer ID -Send a `GET` request to the `/customers/{customerId}` endpoint to invoke the [GetCustomerByIDFlow](back-end-guide.html#getcustomerbyidflow). This flow retrieves the `CustomerSchemaV1.Customer`, which stores personal details and contact information along with creation and modification timestamps, for a given `customerId`. This request requires authorization. It can be sent by an admin user. +Send a `GET` request to the `/customers/{customerId}` endpoint to invoke the [GetCustomerByIDFlow]({{< relref "back-end-guide.md#getcustomerbyidflow" >}}). This flow retrieves the `CustomerSchemaV1.Customer`, which stores personal details and contact information along with creation and modification timestamps, for a given `customerId`. This request requires authorization. It can be sent by an admin user. - Request type: `GET`. - Path: `/customers/{customerId}`. @@ -1384,7 +1384,7 @@ Sample response: ### Update customer -Send a `PUT` request to the `/customers/update/{customerId}` endpoint to invoke the `UpdateCustomerFlow`. This flow adds personal details and contact information, and returns the customer ID. This request requires authorization. It can be sent by an admin user or the customer user. +Send a `PUT` request to the `/customers/update/{customerId}` endpoint to invoke the [UpdateCustomerFlow]({{< relref "./back-end-guide.md#updatecustomerflow" >}}). This flow adds personal details and contact information, and returns the customer ID. This request requires authorization. It can be sent by an admin user or the customer user. - Request type: `PUT`. - Path: `/customers/update/{customerId}`. @@ -1444,7 +1444,7 @@ The Payments Controller includes API endpoints that manage payments in Bank in a ### Withdraw money -Send a `POST` request to the `/payments/withdraw-fiat` endpoint to invoke the `WithdrawFiatFlow`. The `WithdrawFiatFlow` withdraws a specified amount from an account with the provided account ID. This request requires authorization. It can be sent by an admin user. +Send a `POST` request to the `/payments/withdraw-fiat` endpoint to invoke the [WithdrawFiatFlow]({{< relref "./back-end-guide.md#withdrawfiatflow" >}}). The `WithdrawFiatFlow` withdraws a specified amount from an account with the provided account ID. This request requires authorization. It can be sent by an admin user. - Request type: `POST`. - Path: `/payments/withdraw-fiat`. @@ -1501,7 +1501,7 @@ Sample response: ### Deposit money -Send a `POST` request to the `/payments/deposit-fiat` endpoint to invoke the `DepositFiatFlow`. The `DepositFiatFlow` is used to deposit a specified amount to an account with the provided account ID. This request requires authorization. It can be sent by an admin user. +Send a `POST` request to the `/payments/deposit-fiat` endpoint to invoke the [DepositFiatFlow]({{< relref "./back-end-guide.md#depositfiatflow" >}}). The `DepositFiatFlow` is used to deposit a specified amount to an account with the provided account ID. This request requires authorization. It can be sent by an admin user. - Request type: `POST`. - Path: `/payments/deposit-fiat`. @@ -1562,7 +1562,7 @@ Sample response: ### Make an intrabank payment -Send a `POST` request to the `/payments/intrabank-payment` endpoint to invoke the `IntrabankPaymentFlow`. The `IntrabankPaymentFlow` is used to transfer a specified amount of money from a current account to another account. It can be sent by a customer user. +Send a `POST` request to the `/payments/intrabank-payment` endpoint to invoke the [IntrabankPaymentFlow]({{< relref "./back-end-guide.md#intrabankpaymentflow" >}}). The `IntrabankPaymentFlow` is used to transfer a specified amount of money from a current account to another account. It can be sent by a customer user. This request can only be performed by the customer who owns the `fromAccount`. This requires authorization from a **customer** bearer token. Use a customer's [Bank in a Box username](#register-a-user-account) to [request a token](#authentication) for this request. @@ -1631,7 +1631,7 @@ Sample response: ### Create a recurring payment -Send a `POST` request to the `/payments/create-recurring-payment` endpoint to invoke the `CreateRecurringPaymentFlow`. The `CreateRecurringPaymentFlow` creates a recurring payment for the specified amount of money to be transferred from a current account to another account. It can be sent by a customer user. +Send a `POST` request to the `/payments/create-recurring-payment` endpoint to invoke the [CreateRecurringPaymentFlow]({{< relref "./back-end-guide.md#createrecurringpaymentflow" >}}). The `CreateRecurringPaymentFlow` creates a recurring payment for the specified amount of money to be transferred from a current account to another account. It can be sent by a customer user. This request can only be performed by the customer who owns the `fromAccount`. This requires authorization from a **customer** bearer token. Use a customer's [Bank in a Box username](#register-a-user-account) to [request a token](#authentication) for this request. @@ -1681,7 +1681,7 @@ Sample response: ### Cancel recurring payment -Send a `POST` request to the `/payments/cancel-recurring-payment` endpoint to invoke the `CancelRecurringPaymentFlow`. The `CancelRecurringPaymentFlow` cancels a recurring payment specified by its recurring payment ID. It can be sent by an admin user or a customer user. +Send a `POST` request to the `/payments/cancel-recurring-payment` endpoint to invoke the [CancelRecurringPaymentFlow]({{< relref "./back-end-guide.md#cancelrecurringpaymentflow" >}}). The `CancelRecurringPaymentFlow` cancels a recurring payment specified by its recurring payment ID. It can be sent by an admin user or a customer user. This request can only be performed by the customer who owns the `fromAccount`. This requires authorization from a **customer** bearer token. Use a customer's [Bank in a Box username](#register-a-user-account) to [request a token](#authentication) for this request. @@ -1717,7 +1717,7 @@ The Recurring Payments Controller includes API endpoints that reference recurrin ### Get recurring payment by ID -Send a `GET` request to the `/recurring-payments/{recurringPaymentId}` endpoint to invoke the `GetRecurringPaymentByIdFlow`. The `GetRecurringPaymentByIdFlow` returns information for a recurring payment, specified by its recurring payment ID. This request requires authorization. It can be sent by an admin user. +Send a `GET` request to the `/recurring-payments/{recurringPaymentId}` endpoint to invoke the [GetRecurringPaymentByIdFlow]({{< relref "./back-end-guide.md#getrecurringpaymentsbyidflow" >}}). The `GetRecurringPaymentByIdFlow` returns information for a recurring payment, specified by its recurring payment ID. This request requires authorization. It can be sent by an admin user. - Request type: `GET`. - Path: `/recurring-payments/{recurringPaymentId}`. @@ -1749,7 +1749,7 @@ Response: This request returns a data transfer object that stores details of a r ### Get recurring payments paginated -Send a `GET` request to the `/recurring-payments` endpoint to invoke the `GetRecurringPaymentsPaginatedFlow`. The `GetRecurringPaymentsPaginatedFlow` returns a list of recurring payments that match the given search criteria. This request requires authorization. It can be sent by an admin user. +Send a `GET` request to the `/recurring-payments` endpoint to invoke the [GetRecurringPaymentsPaginatedFlow]({{< relref "./back-end-guide.md#getrecurringpaymentspaginatedflow" >}}). The `GetRecurringPaymentsPaginatedFlow` returns a list of recurring payments that match the given search criteria. This request requires authorization. It can be sent by an admin user. - Request type: `GET`. - Path: `/recurring-payments`. @@ -1827,7 +1827,7 @@ Sample response: ### Get recurring payments for a specified account -Send a `GET` request to the `/recurring-payments/account/{accountId}` endpoint to invoke the `GetRecurringPaymentsForAccountPaginatedFlow`. The `GetRecurringPaymentsForAccountPaginatedFlow` returns a list of recurring payments for a specified account that match the given search criteria. This request requires authorization. It can be sent by an admin user. +Send a `GET` request to the `/recurring-payments/account/{accountId}` endpoint to invoke the [GetRecurringPaymentsForAccountPaginatedFlow]({{< relref "./back-end-guide.md#getrecurringpaymentsforaccountpaginatedflow" >}}). The `GetRecurringPaymentsForAccountPaginatedFlow` returns a list of recurring payments for a specified account that match the given search criteria. This request requires authorization. It can be sent by an admin user. - Request type: `GET`. - Path: `/recurring-payments/account/{accountId}`. @@ -1957,7 +1957,7 @@ Sample response: ### Get recurring payments for a specified customer -Send a `GET` request to the `/recurring-payments/customer/{customerId}` endpoint to invoke the `GetRecurringPaymentsForCustomerPaginatedFlow`. The `GetRecurringPaymentsForCustomerPaginatedFlow` returns a list of recurring payments for the specified customer ID that match the given search criteria. This request requires authorization. It can be sent by an admin user. +Send a `GET` request to the `/recurring-payments/customer/{customerId}` endpoint to invoke the [GetRecurringPaymentsForCustomerPaginatedFlow]({{< relref "./back-end-guide.md#getrecurringpaymentsforcustomerpaginatedflow" >}}). The `GetRecurringPaymentsForCustomerPaginatedFlow` returns a list of recurring payments for the specified customer ID that match the given search criteria. This request requires authorization. It can be sent by an admin user. - Request type: `GET`. - Path: `/recurring-payments/customer/{customerId}`. @@ -2126,11 +2126,11 @@ Sample response: ## Transaction Controller -The Transaction Controller includes API endpoints that reference transactions in Bank in a Box. Requests sent to these endpoints return lists of exisiting transactions that match the given search parameters. +The Transaction Controller includes API endpoints that reference transactions in Bank in a Box. Requests sent to these endpoints return lists of existing transactions that match the given search parameters. ### Get transactions -Send a `GET` request to the `/transactions` endpoint to invoke the `GetTransactionsPaginatedFlow`. The `GetTransactionsPaginatedFlow` returns a list of all transactions matching the given search criteria. This request requires authorization. It can be sent by an admin user. +Send a `GET` request to the `/transactions` endpoint to invoke the [GetTransactionsPaginatedFlow]({{< relref "./back-end-guide.md#gettransactionspaginatedflow" >}}). The `GetTransactionsPaginatedFlow` returns a list of all transactions matching the given search criteria. This request requires authorization. It can be sent by an admin user. - Request type: `GET`. - Path: `/transactions`. @@ -2215,7 +2215,7 @@ Sample response: ### Get transactions for a specified account -Send a `GET` request to the `/transactions/account/{accountId}` endpoint to invoke the `GetTransactionsForAccountPaginatedFlow`. The `GetTransactionsForAccountPaginatedFlow` returns a list of transactions for a specified account ID, matching the given search criteria. This request requires authorization. It can be sent by an admin user. +Send a `GET` request to the `/transactions/account/{accountId}` endpoint to invoke the [GetTransactionsForAccountPaginatedFlow]({{< relref "./back-end-guide.md#gettransactionsforaccountpaginatedflow" >}}). The `GetTransactionsForAccountPaginatedFlow` returns a list of transactions for a specified account ID, matching the given search criteria. This request requires authorization. It can be sent by an admin user. - Request type: `GET`. - Path: `/transactions/account/{accountId}`. @@ -2345,7 +2345,7 @@ Sample response: ### Get transactions for a specified customer -Send a `GET` request to the `/transactions/customer/{customerId}` endpoint to invoke the `GetTransactionsForCustomerPaginatedFlow`. The `GetTransactionsForCustomerPaginatedFlow` returns a list of transactions for a specified customer ID, matching the given search criteria. This request requires authorization. It can be sent by an admin user. +Send a `GET` request to the `/transactions/customer/{customerId}` endpoint to invoke the [GetTransactionsForCustomerPaginatedFlow]({{< relref "./back-end-guide.md#gettransactionsforcustomerpaginatedflow" >}}). The `GetTransactionsForCustomerPaginatedFlow` returns a list of transactions for a specified customer ID, matching the given search criteria. This request requires authorization. It can be sent by an admin user. - Request type: `GET`. - Path: `/transactions/customer/{customerId}`. @@ -2474,7 +2474,7 @@ Sample response: ### Get transactions by transaction ID -Send a `GET` request to the `/transactions/{transactionId}` endpoint to invoke the `GetTransactionByIdFlow`. The `GetTransactionByIdFlow` returns the transaction information for a specified transaction ID. This request requires authorization. It can be sent by an admin user. +Send a `GET` request to the `/transactions/{transactionId}` endpoint to invoke the [GetTransactionByIdFlow]({{< relref "./back-end-guide.md#gettransactionbyidflow" >}}). The `GetTransactionByIdFlow` returns the transaction information for a specified transaction ID. This request requires authorization. It can be sent by an admin user. - Request type: `GET`. - Path: `/transactions/{transactionId}`. diff --git a/content/en/platform/corda/4.10/community/apps/bankinabox/back-end-guide.md b/content/en/platform/corda/4.10/community/apps/bankinabox/back-end-guide.md index 3696458a684..6359f2b952b 100644 --- a/content/en/platform/corda/4.10/community/apps/bankinabox/back-end-guide.md +++ b/content/en/platform/corda/4.10/community/apps/bankinabox/back-end-guide.md @@ -728,7 +728,7 @@ val signedTx = subFlow(DepositFiatFlow(accountId, amount)) ## Payments -As noted in the [Loans](#loans) section, [Corda scheduled states](../../../enterprise/event-scheduling.html#implementing-scheduled-events) are utilised in Bank in a Box to create recurring payments that start on a given date and are executed in a specific time period. +As noted in the [Loans](#loans) section, [Corda scheduled states]({{< relref "../../../enterprise/event-scheduling.md#implementing-scheduled-events" >}}) are utilized in Bank in a Box to create recurring payments that start on a given date and are executed in a specific time period. Payments in Bank in a Box are also a good example of how CorDapps can be integrated with external systems. diff --git a/content/en/platform/corda/4.10/community/apps/bankinabox/user-interface/admin-ui-guide.md b/content/en/platform/corda/4.10/community/apps/bankinabox/user-interface/admin-ui-guide.md index b17b46f498e..fe47db288ec 100644 --- a/content/en/platform/corda/4.10/community/apps/bankinabox/user-interface/admin-ui-guide.md +++ b/content/en/platform/corda/4.10/community/apps/bankinabox/user-interface/admin-ui-guide.md @@ -14,7 +14,7 @@ section_menu: corda-community-4-10 # Admin user interface -The admin user interface of Bank in a Box allows an admin user to perform the tasks of a bank employee. Read on to familiarise yourself with the elements of the user interface. To learn how to perform tasks as an admin user, see the [How to guide](./how-to.html#admin-tasks). +The admin user interface of Bank in a Box allows an admin user to perform the tasks of a bank employee. Read on to familiarise yourself with the elements of the user interface. To learn how to perform tasks as an admin user, see the [How to guide]({{< relref "./how-to.md#admin-tasks" >}}). ## Log in and home screen @@ -52,7 +52,7 @@ When you open the navigation menu, you will see the following: ## User management -When you click on **User management** in the navigation menu, you will be taken to the **User management** screen. Here you can [assign and revoke user permissions](./how-to.html#assign-or-revoke-a-user-role). +When you click on **User management** in the navigation menu, you will be taken to the **User management** screen. Here you can [assign and revoke user permissions]({{< relref "./how-to.md#assign-or-revoke-a-user-role" >}}). ## Customers screen @@ -66,9 +66,9 @@ To find a specific customer, use the search bar. After typing three characters, The search is case-sensitive. {{< /note >}} -When you click on a customer name, you will be directed to the **Update Customer** screen where you can [view and update a customer profile](./how-to.html#update-customer-profile). +When you click on a customer name, you will be directed to the **Update Customer** screen where you can [view and update a customer profile]({{< relref "./how-to.m d#update-customer-profile" >}}). -You may also wish to [create a new customer](./how-to.html#create-a-customer-profile). Click on the **Create New** button in the top right corner to be directed to the **Create Customer** screen. +You may also wish to [create a new customer]({{< relref "./how-to.md#create-a-customer-profile" >}}). Click on the **Create New** button in the top right corner to be directed to the **Create Customer** screen. ## Accounts screen @@ -122,7 +122,7 @@ On this tab, you can view customer information that is tied to the account. This {{< note >}} -Customer information can be viewed but not modified from this tab. For instructions on modifying customer information, see the documentation on [updating a customer profile](./how-to.html#update-customer-profile). +Customer information can be viewed but not modified from this tab. For instructions on modifying customer information, see the documentation on [updating a customer profile]({{< relref "./how-to.md#update-customer-profile" >}}). {{< /note >}} #### Transactions tab @@ -267,7 +267,7 @@ To find a specific recurring payment, use the search bar. After typing three cha If you wish to see all relevant information for a specific recurring payment, click on the recurring payment and you will be directed to the [Recurring payments view](#recurring-payments-view). -You may also wish to [create a new recurring payment](./how-to.html#create-a-recurring-payment). Click on the Create New button in the top right corner to be directed to the **Create a recurring payment** screen. +You may also wish to [create a new recurring payment]({{< relref "./how-to.md#create-a-recurring-payment" >}}). Click on the **Create New** button in the top right corner to be directed to the **Create a recurring payment** screen. ### Recurring payments view diff --git a/content/en/platform/corda/4.10/community/apps/bankinabox/user-interface/customer-ui-guide.md b/content/en/platform/corda/4.10/community/apps/bankinabox/user-interface/customer-ui-guide.md index d2f630a21b8..b20c3e7f223 100644 --- a/content/en/platform/corda/4.10/community/apps/bankinabox/user-interface/customer-ui-guide.md +++ b/content/en/platform/corda/4.10/community/apps/bankinabox/user-interface/customer-ui-guide.md @@ -14,7 +14,7 @@ section_menu: corda-community-4-10 # Customer and guest user interface -The customer user interface of Bank in a Box allows a customer user to perform all of their daily banking activities with ease. Read on to familiarise yourself with the elements of the user interface. To learn how to perform tasks as a customer user, see the [How to guide](./how-to.html#customer-tasks). +The customer user interface of Bank in a Box allows a customer user to perform all of their daily banking activities with ease. Read on to familiarise yourself with the elements of the user interface. To learn how to perform tasks as a customer user, see the [How to guide]({{< relref "./how-to.md#customer-tasks" >}}). ## Log in and home screen @@ -38,7 +38,7 @@ The guest user interface has the same log in screen and navigation menu as the c ## Update My Profile screen -When you access the **Update My Profile** screen, you will see your customer information displayed. Here you can [make changes to your customer profile](./how-to.html#update-a-customer-profile) as necessary in the following fields: +When you access the **Update My Profile** screen, you will see your customer information displayed. Here you can [make changes to your customer profile]({{< relref "./how-to.md#update-a-customer-profile" >}}) as necessary in the following fields: * **Customer name** - The customer's name. * **Contact number** - The customer's phone number. @@ -97,7 +97,7 @@ On this tab you can view the following information: * **Overdraft limit** - The overdraft limit that has been approved for the account. * **Overdraft balance** - The amount of money currently remaining in overdraft. -On this tab you also have the option to [set withdrawal and transfer daily limits on a customer account](./how-to.html#set-withdrawal-and-transfer-limits). +On this tab you also have the option to [set withdrawal and transfer daily limits on a customer account]({{< relref "./how-to.md#set-withdrawal-and-transfer-limits" >}}). #### Customer tab @@ -194,11 +194,11 @@ Under the **Accounts** tab, you can view: On this screen you can create a new intrabank payment. This is a transfer that can be made between a customer's accounts or to another bank client's account. -See the documentation on [creating an intrabank payment](./how-to.html#create-an-intrabank-payment) to learn more. +See the documentation on [creating an intrabank payment]({{< relref "./how-to.md#create-an-intrabank-payment" >}}) to learn more. ## Recurring payments screen On this screen you can create a new recurring payment. Recurring payments can be used for any payment that a customer makes periodically - for example, bills or loan payments. -See the documentation on [creating a recurring payment](./how-to.html#create-a-recurring-payment) to learn more. +See the documentation on [creating a recurring payment]({{< relref "./how-to.md#create-a-recurring-payment" >}}) to learn more. diff --git a/content/en/platform/corda/4.10/community/apps/bankinabox/user-interface/user-interface.md b/content/en/platform/corda/4.10/community/apps/bankinabox/user-interface/user-interface.md index 1c1bd7610de..edf190a44ef 100644 --- a/content/en/platform/corda/4.10/community/apps/bankinabox/user-interface/user-interface.md +++ b/content/en/platform/corda/4.10/community/apps/bankinabox/user-interface/user-interface.md @@ -14,7 +14,7 @@ section_menu: corda-community-4-10 # User interfaces on Bank in a Box -The user interface on Bank in a Box provides an easy to use solution based on [React](https://reactjs.org/). The guides listed below will help you to understand the different role-based interfaces and how to perform a variety of tasks in the application. See the [getting started](../getting-started.html#deployment) section for instructions on deploying the user interface. +The user interface on Bank in a Box provides an easy to use solution based on [React](https://reactjs.org/). The guides listed below will help you to understand the different role-based interfaces and how to perform a variety of tasks in the application. See the [getting started]({{< relref "../getting-started.md#deployment" >}}) section for instructions on deploying the user interface. * [Admin user interface]({{< relref "./admin-ui-guide.md" >}}). * [Customer and guest user interface]({{< relref "./customer-ui-guide.md" >}}). diff --git a/content/en/platform/corda/4.10/community/apps/payments/payment-service-flows.md b/content/en/platform/corda/4.10/community/apps/payments/payment-service-flows.md index 0659fa2466d..d7301a21681 100644 --- a/content/en/platform/corda/4.10/community/apps/payments/payment-service-flows.md +++ b/content/en/platform/corda/4.10/community/apps/payments/payment-service-flows.md @@ -9,7 +9,7 @@ menu: section_menu: corda-community-4-10 --- -Use Payment Service flows to initiate payments and account management requests from a node on a Corda network. These requests can then be picked up by the [Payments Agent](payments-agent.md) on your network. +Use Payment Service flows to initiate payments and account management requests from a node on a Corda network. These requests can then be picked up by the [Payments Agent]({{< relref "payments-agent.md" >}}) on your network. Use the Payment Service flows to: diff --git a/content/en/platform/corda/4.10/community/apps/payments/payments-index.md b/content/en/platform/corda/4.10/community/apps/payments/payments-index.md index 39f1c9a1c02..3f29c25d09c 100644 --- a/content/en/platform/corda/4.10/community/apps/payments/payments-index.md +++ b/content/en/platform/corda/4.10/community/apps/payments/payments-index.md @@ -26,7 +26,7 @@ Payments on a Corda network are facilitated by the designated Payments Agent. Th In this Technical Preview, you can play the role of the Payments Agent to facilitate payments requested on a local network, via the Modulr sandbox. -If you are considering setting up a payments network, read more about the [Payments Agent flows](payments-agent.md) to see the actions you can perform. +If you are considering setting up a payments network, read more about the [Payments Agent flows]({{< relref "payments-agent.md" >}}) to see the actions you can perform. ## The Payments SDK diff --git a/content/en/platform/corda/4.10/community/apps/payments/payments-sdk.md b/content/en/platform/corda/4.10/community/apps/payments/payments-sdk.md index 0ba7d3dff7c..e8eb7c5b0e9 100644 --- a/content/en/platform/corda/4.10/community/apps/payments/payments-sdk.md +++ b/content/en/platform/corda/4.10/community/apps/payments/payments-sdk.md @@ -20,7 +20,7 @@ All code samples are in Kotlin. You must have access to: * The [Corda Customer Hub](https://customerhub.r3.com/s/r3-customcommunitylogin) trial area. -* Modulr Sandbox. This is so you can [test your CorDapp on a local environment](send-payments.html#set-up-modulr-sandbox-for-payments-agent). +* Modulr Sandbox. This is so you can [test your CorDapp on a local environment]({{< relref "send-payments.md#set-up-modulr-sandbox-for-payments-agent" >}}). ## Access Corda Payments on Corda Customer Hub diff --git a/content/en/platform/corda/4.10/community/apps/payments/send-payments.md b/content/en/platform/corda/4.10/community/apps/payments/send-payments.md index ae1e0711471..04cb9beec36 100644 --- a/content/en/platform/corda/4.10/community/apps/payments/send-payments.md +++ b/content/en/platform/corda/4.10/community/apps/payments/send-payments.md @@ -24,14 +24,14 @@ By following this guide, you can: You must have: * Access to the [Corda Enterprise Customer Hub](https://customerhub.r3.com/s/r3-customcommunitylogin) Trial area. -* A [Corda Payments-enabled CorDapp](payments-sdk.md). +* A [Corda Payments-enabled CorDapp]({{< relref "payments-sdk.md" >}}). * Modulr sandbox credentials. ## Set up Modulr Sandbox for Payments Agent Corda Payments is dependent on integration with a Payment Service Provider (PSP). In this technical preview, you can only use Modulr as the PSP. Your payments are simulated using the Modulr Sandbox environment. This is a mock environment, so no real money is paid to anyone. -To run the Payments Agent, you must have a **Partner Account** for your Modulr Sandbox. This involves contacting Modulr by email. You can follow the Modulr instructions to do this here: https://secure-sandbox.modulrfinance.com/sandbox/onboarding. +To run the Payments Agent, you must have a **partner account** for your Modulr Sandbox. This involves contacting Modulr by email. You can follow the Modulr instructions to do this here: https://secure-sandbox.modulrfinance.com/sandbox/onboarding. Once you have registered, Modulr will communicate your API key and secret. The Payments Agent holds these keys. Customers of the Payments Agent (anyone on the network who wants to use Corda Payments) do not require Modulr accounts with API key or secret. diff --git a/content/en/platform/corda/4.10/community/blob-inspector.md b/content/en/platform/corda/4.10/community/blob-inspector.md index 47e019baf6e..9c30c20c3b3 100644 --- a/content/en/platform/corda/4.10/community/blob-inspector.md +++ b/content/en/platform/corda/4.10/community/blob-inspector.md @@ -18,8 +18,8 @@ title: Blob Inspector # Blob inspector -The Corda blob inspector tool gives you a human-readable view of content stored in a [custom binary serialization format](serialization.md). -The blob inspector shows you the output of binary blob files (or URL end-points) in YAML or JSON using `JacksonSupport` (see [JSON](json.md) for more on Jackson serialization). +The Corda blob inspector tool gives you a human-readable view of content stored in a [custom binary serialization format]({{< relref "serialization.md" >}}). +The blob inspector shows you the output of binary blob files (or URL end-points) in YAML or JSON using `JacksonSupport` (see [JSON]({{< relref "json.md" >}}) for more on Jackson serialization). The tool is distributed as a `.jar.` file - `corda-tools-blob-inspector-4.10.jar`. To run it, pass in the file or URL as the first parameter: @@ -101,7 +101,7 @@ This property is materialized into `NodeInfo` and is output under the `deseriali ## Classpath -If you run the blob inspector without any JAR files on the classpath, then it will deserialize objects using the class carpenter, (see [Object serialization](serialization.md)). +If you run the blob inspector without any JAR files on the classpath, then it will deserialize objects using the class carpenter, (see [Object serialization]({{< relref "serialization.md" >}})). This happens because the types are not available, so the serialization framework has to synthesize them. {{< note >}} @@ -134,4 +134,4 @@ blob-inspector [-hvV] [--full-parties] [--schema] [--format=type] ### Sub-commands -`install-shell-extensions`: Install `blob-inspector` alias and auto-completion for bash and zsh. See [Shell extensions for CLI Applications](cli-application-shell-extensions.md). +`install-shell-extensions`: Install `blob-inspector` alias and auto-completion for bash and zsh. See [Shell extensions for CLI Applications]({{< relref "cli-application-shell-extensions.md" >}}). diff --git a/content/en/platform/corda/4.10/community/building-a-cordapp-index.md b/content/en/platform/corda/4.10/community/building-a-cordapp-index.md index da305ef273a..86a9cfb726a 100644 --- a/content/en/platform/corda/4.10/community/building-a-cordapp-index.md +++ b/content/en/platform/corda/4.10/community/building-a-cordapp-index.md @@ -20,14 +20,14 @@ title: CorDapps -* [What is a CorDapp?](cordapp-overview.md) -* [Getting set up for CorDapp development](getting-set-up.md) -* [Running a sample CorDapp](tutorial-cordapp.md) -* [Structuring a CorDapp](writing-a-cordapp.md) -* [Building and installing a CorDapp](cordapp-build-systems.md) -* [Building Building CorDapps against a non-release branch](building-against-non-release.md) -* [Debugging a CorDapp](debugging-a-cordapp.md) -* [Secure coding guidelines](secure-coding-guidelines.md) -* [Configuring Responder Flows](flow-overriding.md) -* [Starting a flow with a client-provided unique ID](flow-start-with-client-id.md) -* [Flow cookbook](flow-cookbook.md) +* [What is a CorDapp?]({{< relref "cordapp-overview.md" >}}) +* [Getting set up for CorDapp development]({{< relref "getting-set-up.md" >}}) +* [Running a sample CorDapp]({{< relref "tutorial-cordapp.md" >}}) +* [Structuring a CorDapp]({{< relref "writing-a-cordapp.md" >}}) +* [Building and installing a CorDapp]({{< relref "cordapp-build-systems.md" >}}) +* [Building Building CorDapps against a non-release branch]({{< relref "building-against-non-release.md" >}}) +* [Debugging a CorDapp]({{< relref "debugging-a-cordapp.md" >}}) +* [Secure coding guidelines]({{< relref "secure-coding-guidelines.md" >}}) +* [Configuring Responder Flows]({{< relref "flow-overriding.md" >}}) +* [Starting a flow with a client-provided unique ID]({{< relref "flow-start-with-client-id.md" >}}) +* [Flow cookbook]({{< relref "flow-cookbook.md" >}}) diff --git a/content/en/platform/corda/4.10/community/building-corda.md b/content/en/platform/corda/4.10/community/building-corda.md index c11d8157a9e..e23c463984f 100644 --- a/content/en/platform/corda/4.10/community/building-corda.md +++ b/content/en/platform/corda/4.10/community/building-corda.md @@ -19,7 +19,7 @@ title: Building Corda # Building Corda These instructions are for downloading and building the Corda code locally. If you only wish to develop CorDapps for -use on Corda, you don’t need to do this, follow the instructions at [Getting set up for CorDapp development](getting-set-up.md) and use the precompiled binaries. +use on Corda, you don’t need to do this, follow the instructions at [Getting set up for CorDapp development]({{< relref "getting-set-up.md" >}}) and use the precompiled binaries. ## Windows diff --git a/content/en/platform/corda/4.10/community/business-network-membership.md b/content/en/platform/corda/4.10/community/business-network-membership.md index 0ae0f89ae80..6c886ebcbc8 100644 --- a/content/en/platform/corda/4.10/community/business-network-membership.md +++ b/content/en/platform/corda/4.10/community/business-network-membership.md @@ -84,7 +84,7 @@ dependencies { } ``` -3. Add both dependencies in your **Cordform** - `deployNodes` - [task](generating-a-node.html#tasks-using-the-cordform-plug-in). +3. Add both dependencies in your **Cordform** - `deployNodes` - [task]({{< relref "generating-a-node.md#tasks-using-the-cordform-plug-in" >}}). You have installed the Business Network membership extension. diff --git a/content/en/platform/corda/4.10/community/checkpoint-tooling.md b/content/en/platform/corda/4.10/community/checkpoint-tooling.md index e3032e0c611..dd2b9cc2c93 100644 --- a/content/en/platform/corda/4.10/community/checkpoint-tooling.md +++ b/content/en/platform/corda/4.10/community/checkpoint-tooling.md @@ -20,12 +20,12 @@ title: Checkpoint Tooling This page contains information about checkpoint tooling. These tools can be used to debug the causes of stuck flows. -Before reading this page, please ensure you understand the mechanics and principles of Corda Flows by reading [Flows](key-concepts-flows.md) and [Writing flows](api-flows.md). -It is also recommended that you understand the purpose and behaviour of the [Flow Hospital](node-flow-hospital.md) in relation to *checkpoints* and flow recovery. -An advanced explanation of checkpoints within the flow state machine can be found here: [Flow framework internals](contributing-flow-internals.html#checkpoints). +Before reading this page, please ensure you understand the mechanics and principles of Corda Flows by reading [Flows]({{< relref "key-concepts-flows.md" >}}) and [Writing flows]({{< relref "api-flows.md" >}}). +It is also recommended that you understand the purpose and behavior of the [Flow Hospital]({{< relref "node-flow-hospital.md" >}}) in relation to *checkpoints* and flow recovery. +An advanced explanation of checkpoints within the flow state machine can be found here: [Flow framework internals]({{< relref "contributing-flow-internals.md#checkpoints" >}}). -As a recap, a flow *checkpoint* is a serialised snapshot of the flow’s stack frames and any objects reachable from the stack. Checkpoints are saved to the database automatically when a flow suspends or resumes, which typically happens when sending or receiving messages. A flow may be replayed +As a recap, a flow *checkpoint* is a serialized snapshot of the flow’s stack frames and any objects reachable from the stack. Checkpoints are saved to the database automatically when a flow suspends or resumes, which typically happens when sending or receiving messages. A flow may be replayed from the last checkpoint if the node restarts. Automatic checkpointing is an unusual feature of Corda and significantly helps developers write reliable code that can survive node restarts and crashes. It also assists with scaling up, as flows that are waiting for a response can be flushed from memory. @@ -191,7 +191,7 @@ To run simply pass in the following jar to the JVM used to start a Corda node: ` {{< note >}} As above also ensure to use the jar when using corda gradle plugin configuration tasks: e.g. `cordformation deployNodes` task. -See [Generating a node](generating-a-node.md). +See [Generating a node]({{< relref "generating-a-node.md" >}}). {{< /note >}} @@ -201,7 +201,7 @@ This tool requires additional memory footprint and R3 recommended a minimal heap {{< /warning >}} -The agent can be customised with a number of optional parameters described below. +The agent can be customized with a number of optional parameters described below. ### Configuration @@ -581,7 +581,7 @@ Useful commands include 'help' to see what is available, and 'bye' to shut down Thu Jul 11 19:52:56 BST 2019>>> run setFlowsDrainingModeEnabled enabled: false ``` -See also [Flow draining mode](key-concepts-node.html#draining-mode). +See also [Flow draining mode]({{< relref "key-concepts-node.md#draining-mode" >}}). * contacting other participants in the network where their nodes are not responding to an initiated flow. @@ -625,7 +625,7 @@ The feature provides a way for flows to reload from checkpoints, even if no erro ### How to use this feature -Add the `reloadCheckpointAfterSuspend` [node configuration option](corda-configuration-fields.md) and set it to `true`, as shown below: +Add the `reloadCheckpointAfterSuspend` [node configuration option]({{< relref "corda-configuration-fields.md" >}}) and set it to `true`, as shown below: ``` reloadCheckpointAfterSuspend = true diff --git a/content/en/platform/corda/4.10/community/cipher-suites.md b/content/en/platform/corda/4.10/community/cipher-suites.md index e2efd85a2af..41047c8392d 100644 --- a/content/en/platform/corda/4.10/community/cipher-suites.md +++ b/content/en/platform/corda/4.10/community/cipher-suites.md @@ -29,8 +29,8 @@ carefully selected based on various factors, such as provided security-level and with various HSM vendors, algorithm standardisation, variety of cryptographic primitives, business demand, option for post-quantum resistance, side channel security, efficiency and rigorous testing. -Before we present the pool of supported schemes it is useful to be familiar with [Network certificates](permissioning.md) -and [API: Identity](api-identity.md). An important design decision in Corda is its shared hierarchy between the +Before we present the pool of supported schemes it is useful to be familiar with [Network certificates]({{< relref "permissioning.md" >}}) +and [API: Identity]({{< relref "api-identity.md" >}}). An important design decision in Corda is its shared hierarchy between the TLS and Node Identity certificates. ## Certificate hierarchy @@ -52,7 +52,7 @@ A Corda network has 8 types of keys and a regular node requires 4 of them: * The **confidential identity** key(s) (per node) We can visualise the certificate structure as follows (for a detailed description of cert-hierarchy, -see [Network certificates](permissioning.md)): +see [Network certificates]({{< relref "permissioning.md" >}})): {{< figure alt="certificate structure" width=80% zoom="/en/images/certificate_structure.png" >}} diff --git a/content/en/platform/corda/4.10/community/cli-application-shell-extensions.md b/content/en/platform/corda/4.10/community/cli-application-shell-extensions.md index 22aa7b5dd9f..9e9261adff2 100644 --- a/content/en/platform/corda/4.10/community/cli-application-shell-extensions.md +++ b/content/en/platform/corda/4.10/community/cli-application-shell-extensions.md @@ -86,9 +86,9 @@ restart the shell or see [above](#installing-shell-extensions) for instructions |Description|Alias|JAR Name| |---------------------------------------------------------|------------------------------|----------------------------------------------------------| -|[Corda node](running-a-node.html#starting-an-individual-corda-node)|`corda --