Record'in Administration Guide

The way of making Record'in working

This shows the way of administrating Record'in software.

The same documentation in PDF format.


I. Purpose and intended audience

This document describes the way of administrating and configuring Record’in software by the configuration files and modules.

It is intended to software engineers and developers willing to execute and integrate Record’in software in a running environement.


II. Architecture

Record’in software relies on the cheetah webserver. You can find more information about the web server in GitHub:

https://github.com/pschweitz/CheetahWebserver

It is the webserver that enables the modularity of Record’in. Modules must be placed inside the “plugin” folder.



1.Folder structure



The folder tree of the Record’in software with some comments:

Recordin // root folder

├── database // folder containing the “nodeid” property files

├── database-recordin-private-network-standard // folder containing Blockchain data in network mode

├── database-recordin-standalone-standard // folder containing Blockchain data in standalone mode

├── dataset-recordin-standard // folder containing the required dataset for mining blocks

├── etc // folder containing the configuration files

├── icon.png // Record’in logo

├── jre1.8.0_202 // java recommanded version

├── log // folder containing the log files

├── plugins // folder containing the modules

├── Recordin-all-in-one-jar-19.01-RELEASE.jar // Record’in software archive

└── recordin.sh // Record’in startscript, “recordin.bat” for windows



2.Default modules



Record’in is released with 3 resources inside the “plugin” folder.

These 3 archives enable the web interface to access and visualize the Blockchain information. By removing these 3 archives, the web interface will no longer be accessible, but the Restful API Webservices remain accessible.

Recordin/plugins // modules folder

├── file-icons.zip // optional icons resources for the webserver

├── jqwidgets-ver5.6.0.zip // mandatory resources for the Record’in web interface

└── Recordin-Web-19.01-RELEASE.zip // Record’in web interface archives



3.Execution and log files



In order to run the Record’in software just execute the start script available for your operating system.



For Linux:

./recordin.sh



For Window:

./recordin.bat



For both start scripts, by default the produced traces are visible in the terminal standard output. Moreover, all these traces are also recorded inside log files placed inside the “log” folder:

Recordin/log

├── access.log // Webserver and WebServices access log file

├── cheetah.log // Webserver and WebServices requests log file

├── ethereum.log // EthereumJ log file

└── recordin.log // Record’in main log file



III. Configuration files

This section describes all the files found inside the “etc” folder, their configuration items and the “nodeid” properties file.



1.nodeid.properties

This file is found under the “database” folder this file must not be altered. It is generated by the EthereumJ library, and it defines the Blockchain node’s identifier used when configuring a network with several nodes.



2.ethereumj-sample.conf

This file is found under the “etc” folder, and serves for informing about the default configuration items of the EthereumJ library. Any change in this file will have not effect on the Blockchain node functioning. Some of these default configurations are overwritten during the runtime by the values setup inside the “recordin.properties” file.



3.keys.properties

This file is found under the “etc” folder, and serves to store the private keys of the users. The private keys are used when signing a transaction for creating or updating a record inside the Blockchain.

The content of this file must not be altered, otherwise any updated or new content stored inside the Blockchain will no longer be recognized by the other nodes.

In case of re-initiating a Blockchain node, either in standalone or in networking mode, this file must be dropped along with the “user.properties” file and the corresponding folder containing the Blockchain data.



4.keystore.jks

This file is found under the “etc” folder, and contains the SSL certificates for the webserver. It must be used in case the Record’in software must listen in secure mode (Both web interface and Rest WebServices).

The location of this keystore file can be changed inside the “ssl.properties” file.

The keystore configuration is similar to the configuration for a Tomcat webserver, and all documentation found in the Internet applies for the Record’in software as well.

We recommend to use the “keytool” command line, under Java JRE “bin” folder for building the keystores, and the “KeyTool IUI” tool to get a graphical view of the keystore structure:

https://code.google.com/archive/p/keytool-iui/downloads


Please refer to the SSL certificate section for more information about how to create a keystore for the webserver.



5.logback.xml

This file is found under the “etc” folder, and serves for the log files definition. Record’in software uses the “logback” library for managing its log files.



Along with the standard output, by default the Record’in software produces 4 log files:

- access.log: prints all requested (accessed) URLs with the “GET” parameters, timestamps and eventually the connected user name (or at least its session cookie)

- cheetah.log: prints the traces of the webserver (request details + custom traces from plugins). The same traces are produced in the standard output

- ethereum.log: prints all the EthereumJ library traces, for Blockchain layer functioning like synchronization with the other nodes or a for blocks mining

- recordin.log: prints all the traces of the Record’in object layer, as well as the ACL security resolution traces. The same traces are produced in the standard output



By default the logfiles are configured to print the traces with the “debug” log level, and with a 15 days log rotation.



Please refer to the logback documentation for more information:

https://logback.qos.ch/documentation.html



6.mime.types

This file is found under the “etc” folder, it is optional and is used by the webserver.

It serves for the webserver to have the correspondence information between mime types and file extensions, plus the fact they are text-based files or binaries.



7.recordin.properties

This file is found under the “etc” folder, and it serves for configuring the Blockchain node.



List of available configuration items with default values for Record’in software:

- ACLEnableAttribute=false

Value Type: boolean <true|false>

Enables filtering of attributes values according to ACLs permissions. It is setup to “false” by default because impacts performances



- ACLEnableMenu=false

Value Type: boolean <true|false>

Enables filtering display of menus according to ACLs permissions



- ACLEnableModel=false

Value Type: boolean <true|false>

Enables filtering of objects at the Model level according to ACLs permissions



- ACLEnableObject=false

Value Type: boolean <true|false>

Enables filtering of objects at their own level according to ACLs permissions



- ACLPrintDebugTraces=false

Value Type: boolean <true|false>

Serves to print the ACL permissions resolution in the “recordin.log” file, for debugging purpose


- AttachmentRetrieveDownloadTimeout=10

Value Type: integer

Sets the timeout in seconds, of the requests to retrieve contents from the other nodes



- AttachmentRetrieveFromExternal=true

Value Type: boolean <true|false>

Enable the node to retrieve contents from the other nodes



- AttachmentSendAttachments=true

Value Type: boolean <true|false>

Enable the node to send attachment contents to the other nodes



- AttachmentSendAttachmentsAuthorizedNodes=[]

Value Type: Json array of node IDs string, separated by a comma “,” and enclosed by double quotes “"

Format example: “["nodeid","nodeid"]

Serves to restrict the nodes allowed to download contents from current node in the case the “AttachmentSendAttachments” configuration item is set to “true”. When no node ID is configured (“[]”), all the other nodes will be allowed to download contents from the current node. Otherwise only the nodes with the IDs setup in this configuration item will be authorised.



- AttachmentSendGDPRObjects=true

Value Type: boolean <true|false>

Enable the node to send GDPR concerned informations to the other nodes



- AttachmentSendGDPRObjectsAuthorizedNodes=[]

Value Type: Json array of node IDs string, separated by a comma “,” and enclosed by double quotes “"

Format example: “["nodeid","nodeid"]

Serves to restrict the nodes allowed to download GDPR informations from current node in the case the “AttachmentSendGDPRObjects” configuration item is set to “true”. When no node ID is configured (“[]”), all the other nodes will be allowed to download GDPR informations from the current node. Otherwise only the nodes with the IDs setup in this configuration item will be authorised.



- AttachmentSendUserCredentials=true

Value Type: boolean <true|false>

Enable the node to send users’ credentials to the other nodes, in order to allow the users to login from other nodes



- AttachmentSendUserCredentialsAuthorizedNodes=[]

Value Type: Json array of node IDs string, separated by a comma “,” and enclosed by double quotes “"

Format example: “["nodeid","nodeid"]

Serves to restrict the nodes allowed to download users’ credentials from current node in the case the “AttachmentSendUserCredentials” configuration item is set to “true”. When no node ID is configured (“[]”), all the other nodes will be allowed to download users’ credentials from the current node. Otherwise only the nodes with the IDs setup in this configuration item will be authorised.

The users will then be allowed to login from all the other authorized nodes.



- AttachmentSignatureFailPolicy=error

Value Type: string <error|warning|none>

Serves to define the node’s behaviour in the case an attachment signature (including GDPR informations) does not corresponds to the signature recordin inside the Blockchain. This meanig the content may be altered in the external storage since the information has been stored.

error” completely prevents getting the content

warning” displays a warning message but allows to get the content

none” allows to get the content without any message, like if is was authentic



- MiningEnabled=true

Value Type: boolean <true|false>

Serves to enable block mining capability of the node. Note that a node can be configured as read/write in the “NodeReadOnly” configuration item, and not being configured as a mining node.

In such case, the transactions will then be forwarded to the other nodes for mining.



- MiningFullDataSet=true

Value Type: boolean <true|false>

Serves to define block mining process of the node. When set to “true”, the node will need a bigger (about 1GB) dataset for mining (inside the folder “dataset-recordin-standard” also loaded inside the JVM memory), but will mine blocks faster.

Please refer to the “mine.fullDataSet” configuration of EthereumJ for more information



- NodeDefaultPlatformVersion=1.0

Value Type: string

Serves to define the software platform version used for converting objects into their Json representation for recording inside the Blockchain. This information will be recorded inside the “platformVersion” system objects’ attribute, in order to tell to the next updated versions of Record’in software if they would have to read these objects using another code then their default - updated - one.



- NodeObjectCacheEnable=true

Value Type: boolean <true|false>

Serves to enable an object cache in the JVM memory to speed-up the objects’ access when reading them. If this configuration item is set to “false”, the software will then always read the objects from inside the Blockchain.

It is a “LRU” cache.

This configuration is used in combination with “NodeObjectCacheSize” item.



- NodeObjectCacheSize=10000

Value Type: integer

Sets the number of objects that will be stored inside the JVM memory cache. Useful when “NodeObjectCacheSize” is set to “true”.



- NodeObjectSearchResultMax=500

Value Type: integer

Sets the maximum number or returned results when performing a search. This is to avoid having non-ending searching processes.



- NodeReadOnly=true

Value Type: boolean <true|false>

Defines whether the current node is allowed or not to submit objects updates. If it is set to “false”, absolutely no change will be allowed on the Blockchain data from this node.

Note that a node can be configured as read only, but also remaining a mining node for the network. In such case, the transactions will then be get from the other nodes before mining.



- NodeStandalone=true

Value Type: boolean <true|false>

Defines whether the current node is intended to work alone, or to be part of a network.

When set to “false”, is tells to the underlying EthereumJ library to try connecting to other nodes setup inside the “PeerActive” configuration item.

When set to “false”, the Blockchain data will be stored in side the “database-recordin-private-network-standard” folder, otherwise the Blockchain data will be stored inside the “database-recordin-standalone-standard” folder when running in standalone mode.

Please refer to the “peer.active” configuration of EthereumJ for more information

Important note:

When set to “false”, the node will try fetching the latest blocks from the other nodes. In the case the current node is the first running on a network, it will wait for the timeout defined in the “NodeSyncTimeout” configuration item before launching the Blockchain initializing sequence (inserting the first users and Models objects).

Beware that the network could enter a in deadlock state, in the case if none of the nodes running in parallell reached this timeout. Indeed they could keep waiting on each other to reach a synchronization ending status, that would never arrive from the other nodes. Indeed, to avoid that effectively, at least one of the nodes must reach this “Sync completed” status before being able to propagate the information to the others. The synchronization completion ensures that the Blockchain contains the last known block of the network.



- NodeSyncTimeout=20

Value Type: integer

This value serves to define the timeout in seconds after which the node enters in its initializations phase when not configured in standalone mode using the “NodeStandalone” configuration item.

In the case the node is configured to run in a network, and that some other nodes are executing and reachable, this configuration will be ignored. Indeed, the node will become available for recording new contents as soon as the synchronization process completes with the other nodes.

Please refer to the “sync.makeDoneByTimeout” configuration of EthereumJ for more information



- PeerActive=[]

Value Type: Json array of Json objects, separated by a comma “,” containing URL strings of the other network nodes.

Format example: “[{ url = "enode://<nodeid>@<hostname>:<port>" }, { url = "enode://<nodeid>@<hostname>:<port>" }]

This configuration item lists all the nodes of the network, when those nodes are running in network mode. For all the nodes, we must first collect their “nodeid”, available in their “database/nodeid.properties” file, then put them together in this configuration item, along with their hostname and port. The port is the one defined in their “PeerListenPort” configuration item.

Note that to generate a “nodeid.properties” file, a nodes has to be run at least one time, even if it was in standalone mode during the first time.

This configuration is used in combination with “NodeStandalone” item.

Please refer to the “peer.active” configuration of EthereumJ for more information



- PeerListenPort=50000

Value Type: integer

This value serves to define the listening port of the Blockchain EthereumJ layer. It serves for defining the network nodes URL inside the “PeerActive” configuration item.

We recommend to setup the same ports for all the nodes which belong to a same network

Please refer to the “peer.listen.port” configuration of EthereumJ for more information



- PeerNetworkId=444

Value Type: integer

This value serves to identify a network of nodes. The value must be the same for all the nodes which belong to a same network.

Please refer to the “peer.networkId” configuration of EthereumJ for more information



8.ssl.properties

This file is found under the “etc” folder, and contains the required information for telling to the webserver the place of the keystore and its password.



List of available configuration items:

- keystore: location of the keystore

- password: password of the keystore



A keystore normally requires 2 passwords. One for opening it, and the other for the certificate alias entry. With cheetah webserver, we assume that both passwords are actually the same.



For more security, after the webserver startup, the password entry gets encrypted automatically to hide it from malicious attempts.



9.user.properties

This file is found under the “etc” folder, and serves for storing the user credentials (username and password pairs).

The password updates must not be made manually inside this file. A user must use the web interface (or any equivalent) to update the password through its user preferences object.

The only exception is for the “admin” user password. If we want to update the admin password, please follow this procedure for each node:

- stop all the nodes

- update manually the “admin” password for all nodes inside the “user.properties

- start one first node and wait until it reaches the synchronization timeout defined in the “NodeSyncTimeout” configuration item of the “recordin.properties” file. You can see the confirmation inside the “ethereum.log” file.

- start all the other nodes

For more security, after the software startup, the passwords get encrypted automatically to hide it from malicious attempts.



10.virtualhosts.properties

This file is found under the “etc” folder, and serves for configuring the virtual hosts, in the case the webserver’s “FileVirtualHostsEnabled” configuration property is setup to “true”.



We can ignore it in the context of the Record’in software.



11.webserver.properties

This file is found under the “etc” folder, and is the main configuration file of the webserver. Like for the “mime.types”, in case of absence, the webserver will run with default configurations, otherwise it will override them with the content of the file found in the “etc” folder.

The webserver looks for the following file by default: “etc/webserver.properties”.



The version of this file coming with the Record’in software contains the configurations for optimal usage of the webserver, in the context of the Blockchain for testing purpose.



For enabling authentication, please consider activating the “SessionAuthenticationEnabled” configuration item, and the “NetworkSecureSSL” for secure communication.

However nothing prevents to use the other webserver capabilities in addition to the scope of the software if it becomes applicable as well.



You can find more information about the web server in GitHub:

https://github.com/pschweitz/CheetahWebserver



List of available configuration items with default values for Record’in software:



- FileDefaultPage=index.html;default.html;index.htm;default.htm;index;default

Value Type: List of filename separated by a semicolon “;”

Default page to search and read when browsing a filesystem folder or a plugin package, in the order of appearance from left to right. If none of this list is found and the “FileFolderBrowsingEnabled” configuration item is setup to “false”, the webserver will then return a “Not Found” error code (404)



- FileDefaultRoot=www

Value Type: location in the filesystem either relative or absolute

Location of the filesystem root folder of the webserver. When connecting to the root URL “/”, in the case none of the pages identified by the “FileDefaultPage” configuration item could be found, and if the “FileFolderBrowsingEnabled” configuration item is setup to “false”, the webserver will then return a “Not Found” error code (404)



- FileFolderBrowsingEnabled=false

Value Type: boolean <true|false>

Configuration for enabling the folder browsing capability of the webserver. In the case this configuration item is setup to “true”, then the webserver will display the content of the folder or package, instead of looking for a page identified by the other “FileDefaultPage” configuration item.



- FileFolderBrowsingReadWrite=false

Value Type: boolean <true|false>

Enables the connected users to modify the shared content, like creating folders, renaming files of deleting files. Useful when “FileFolderBrowsingEnabled” is set to “true”.



- FileFolderFilesystemOnly=false

Value Type: boolean <true|false>

Enables to list the files also found in the packages as well, is addition to the files found in the filesystem. Useful when “FileFolderBrowsingEnabled” is set to “true”.



- FileFollowSymLinks=false

Value Type: boolean <true|false>

Tells the webserver to follow Linux symbolic links when resolving files in the filesystem



- FileSessionAuthFolderFree=login;css;Favicon

Value Type: List of relative folders to the webserver root, separated by a semicolon “;”

Sets the folder/sub-folders that do not require authentication in case the “SessionAuthenticationEnabled” configuration item is set to “true”. This configuration item combines with the “FileSessionAuthFolderMandatory”, and both together can setup a folder tree with combination of inner free and secured sub-folders.



- FileSessionAuthFolderMandatory=/;admin/

Value Type: List of relative folders to the webserver root, separated by a semicolon “;”

Sets the folder/sub-folders that require authentication in case the “SessionAuthenticationEnabled” configuration item is set to “true”. This configuration item combines with the “FileSessionAuthFolderFree”, and both together can setup a folder tree with combination of inner free and secured sub-folders.



- FileUploadAdminOnly=false

Value Type: boolean <true|false>

Restricts the file upload to administrator users only, identified by the “SessionAdminAccount” configuration items.



- FileUploadEnabled=true

Value Type: boolean <true|false>

Enables file upload to the webserver.



- FileUploadLimit=10485760

Value Type: long

Defines the limit in Bytes of the files to upload. Useful when “FileUploadEnabled” is set to “true”.



- FileVirtualHostsEnabled=false

Value Type: boolean <true|false>

Enables virtual hosts capability. When set to “true” this configuration item must be used in combination with the “virtualhosts.properties” configuration file.



- NetworkInterface=localhost

Value Type: string <hostname or IP address the webserver must listen>

Sets the listening network address associated with the listening port configured in the “NetworkPort” configuration item.

If this configuration item is not available (or commented), the webserver will by default try to resolve the IP address of the FQDN hostname of the server, and use it as the listening address.



- NetworkPort=8080

Value Type: integer, must not exceed 65535, and we do not recommand below 1024

Sets the listening port associated with the listening address configured in the “NetworkInterface” configuration item.



- NetworkSecureSSL=false

Value Type: boolean <true|false>

Activates the SSL networking communication protocol for data stream securization

When set to “true” this configuration item must be used in combination with the “ssl.properties” configuration file.



- NetworkSecureSSLEnforceValidation=false

Value Type: boolean <true|false>

This configuration has nothing to do with previous “NetworkSecureSSL” item. It serves when a plugin uses webserver’s embedded HTTP or WebSocket clients to either accept (or not) opening communication channels with servers having invalid certificates. When set to “true” this configuration item only accepts opening communication channels with servers having a valid certificate.



- SessionAdminAccount=admin

Value Type: List of user names separated by a semicolon “;”

This configuration item defines the list of users that will be considered as webserver’s administrators. This is useful in combination with the “FileUploadAdminOnly” configuration item, but independent of the mechanism defined in the “SessionAuthenticationMechanism” configuration item. Indeed, the users are first authenticated thanks to the defined mechanism, then the matching is performed with the user name to identify a potential administrator.



- SessionAuthenticationEnabled=true

Value Type: boolean <true|false>

Enables authentication. This configuration item is used in combination with: “SessionAuthenticationMechanism”, “SessionTimeout” , “SessionAuthenticationScheme”, “SessionEnableBruteForceProtection” and “SessionUseLoginPage” items.



- SessionAuthenticationMechanism=FILE_RECORDIN

            Value Type: string <Java Class implementing the authentication>

This configuration item must provide a Class name located under the package “org.cheetah.webserver.authentication” extending the “AbstractAuthenticator” Class.

This configuration is used in combination with “SessionAuthenticationEnabled” item.



- SessionAuthenticationScheme=Basic

            Value Type: string <Basic|Bearer>

This configuration item sets the authentication scheme put inside the “Authorization” HTTP response header, in order to inform the client of the type of authentication the webserver is waiting for. “Basic” for common authentication “Bearer” for JWT.

This configuration is used in combination with “SessionAuthenticationEnabled” item.



- SessionEnableBruteForceProtection=true

Value Type: boolean <true|false>

This configuration item implements a protection mechanism against brute force attacks. Indeed after some attempts failed, the user is invited to wait for a longer and longer time before being eligible again for authentication.

Beware that even if the good password is provided during the time the user is not allowed to authenticate, then the webserver will refuse the authentication again anyway. The time of ineligibility goes increasing as long as the provided password is not correct.

There is always a possibility to reset this by restarting the software at any time.

This configuration is used in combination with “SessionAuthenticationEnabled” item.



- SessionTimeout=30

Value Type: integer

Sets the time in minute after witch the unused sessions are closed (session cookies).

This configuration is used in combination with “SessionAuthenticationEnabled” item.



- SessionUseLoginPage=true

Value Type: boolean <true|false>

Enables usage of a login page when authentication is required. If access to a resource requires an authentication and this item is set to “false”, then it will be the browser that will ask for the username and the password.



- ThreadWorkerHTTP=10

Value Type: integer

Sets the number of working threads to handle HTTP requests.



- ThreadWorkerWebsocket=3

Value Type: integer

Sets the number of working threads to handle WebSockets requests.

This configuration is used in combination with “WebsocketEnabled” item.



- WebserverMode=Production

            Value Type: string <Production|Development>

Sets the internal functioning of the webserver. Setting “Production” will speedup internal functioning of the webserver, while ”Development”, slower, is useful when developing new modules without being enforced to restart the server for seeing changes of the pages in development.

Be aware that this mechanism for “Development” overrides natural Java Class loading, and can work for a majority of cases, but functioning is not guaranteed for everything.



- WebserverName=Recordin

            Value Type: string

Sets the name of the webserver inside the “HTTP” headers. This has no impact for the webserver operations.


- WebserverOutputCharset=utf-8

Value Type: string

Sets the output character set of the webserver.

If this configuration item is not available (or commented), or the character set name provided is not available for Java, then the webserver will use the “utf-8” by default, and will never use the default character set of the operating system.



- WebsocketEnabled=true

Value Type: boolean <true|false>

Enables the WebSocket capability of the webserver. This configuration is used in combination with “ThreadWorkerWebsocket” item.


IV. SSL Configuration



SSL keystore configuration file is always located inside the “etc” folder and named “ssl.properties”. This file contains the required information for webserver instance to initiate an SSL socket communication.

Just setup file content like following:

#####

keystore=etc/keystore.jks

password=password



- keystore parameter must provide an absolute or relative path to a keystore file

- password parameter is for both keystore and alias passwords



The password must be the same for the keystore and inner certificate alias.

It is recommended to have only one alias for server’s certificate inside the keystore.



Note, the server’s certificate must cover all reachable URLs (hostnames) for the corresponding application. Refer to “Subject Alternative Name” attribute documentation of X.509 certificates for more information.

A change on the SSL keystore configuration requires a software restart to take effect.



1.Example of keystore file creation

In this section, we will cover all steps to enable SSL encryption for a particular webserver.



In the case the organization into which the certificate has to be deployed has its own PKI, usage of OpenSSL is not necessary. In this case Java “keytool” usage will be enough.

In the case you have to sign by yourself, server certificate with the Root CA key, and/or create your own Root certificate, then usage of OpenSSL is mandatory.



In real case, most of the times, servers have to be reachable from at least 2 DNS names. For instance, its short host name, and its FQND. The developed scenario will cover this situation as well.



Refer to “Subject Alternative Name” attribute documentation of X.509 certificates for more information.

It is recommended to use “keytool” application binary of the Java Runtime Environment used for the application execution. It is located under the Java bin folder.



Consider “hostname” and “hostname.fqdn.com” as DNS aliases of the server.

Consider changing passwords and values of “CN”, “OU”, “O”, “L”, “S”, and “C” certificate attributes for both CA and server certificates.

Refer to “keytool” documentation for more information as well.



1 - Create keystore and certificate

keytool -genkeypair -keystore keystore.jks -dname "CN=hostname.fqdn.com, OU=IT, O=Company, L=City, S=Country, C=CountryAcronym" -keypass ***** -storepass ***** -keyalg RSA -alias server -validity 731 -ext SAN=dns:hostname,dns:hostname.fqdn.com -ext KU=digitalSignature,keyEncipherment -ext EKU=serverAuth



2 - Create a certificate request for signature to the certification authority

keytool -certreq -keystore keystore.jks -keypass ***** -storepass ***** -alias server -file hostname.csr



3 - In the case your organization has its own PKI, just send the CSR and wait for the signed server certificate.

In the case you want to manage or create a new PKI, go to 3-1 section for Root CA certificate creation, and server certificate signature with OpenSSL.



4 - Import provided Root CA and signed certificate of the server from certification authority

- Import of root CA:

->> trust the certificate when prompted

keytool -import -alias cert1 -file root.pem -keystore keystore.jks -storepass <your password>



- Eventually import other mid-certificate in the chain (repeat and change alias for all intermediate certificates in the chain)

keytool -import -alias cert2 -file sub.pem -keystore keystore.jks -storepass <your password>



- Finally import signed certificate

keytool -import -trustcacerts -alias server -file hostname.cer -keystore keystore.jks -storepass <your password>



*******************************************************

Create Root CA and sign server certificate with OpenSSL



3-1 - Generate key for Root CA

openssl genpkey -algorithm RSA -out rootkey.pem -pkeyopt rsa_keygen_bits:4096



3-2 - Generate certificate CSR for Root CA self-signing

openssl req -new -key rootkey.pem -days 5480 -extensions v3_ca -batch -out root.csr -utf8 -subj '/C=CountryAcronym/O=Company Root CA/OU=IT/CN=Company Root CA'



3-3 - Create an extension file (openssl.root.cnf) with following content

basicConstraints = critical, CA:TRUE

keyUsage = keyCertSign, cRLSign

subjectKeyIdentifier = hash



3-4 - Self sign Root CA certificate and append extensions

openssl x509 -req -sha256 -days 3650 -in root.csr -signkey rootkey.pem -set_serial 1 -extfile openssl.root.cnf -out root.pem



3-5 - Sign server certificate request with Root key

openssl x509 -req -CA root.pem -CAkey rootkey.pem -in hostname.csr -out hostname.cer -days 731 -Cacreateserial



3-6 – Trust Root CA certificate



Eventually import “root.pem” Root CA certificate to your browser’s CA and/or into your Java Runtime Environment lists:

keytool -import -noprompt -trustcacerts -alias rootCA -file root.pem -keystore <JRE Path>/lib/security/cacerts -storepass changeit