Configure via SignServer Cloud Configuration Wizard
The following covers how to configure using the SignServer Cloud configuration wizard.
If you are using the 1.x version of SignServer Enterprise Cloud, proceed to the next step Log in to SignServer Enterprise Cloud 1.X on AWS to retrieve the superadmin certificate from your instance.
Step 1: Host Settings
In the first step, you enter the host settings for the instance.
- The host name is automatically detected but can be changed. The host name must match the name of the host or DNS name that will be entered into a browser when accessing the Administration Interface of this SignServer installation.
- Using a Subject Alternative Name (SAN) with this host can be done so that a public URL can be used to access SignServer. For example, if you would like to use https://pki.company.com/ to access a cluster of hosts, you can enter that DNS name into the wizard to be added as a SAN in the instance's TLS certificate. To use this feature, select the option to specify a Valid domain name. Note that the wizard will not verify that the domain name is a valid domain, but will confirm that the syntax is a recognized domain format.
- Click Next to continue to the database configuration.
Host Settings Fields
The following lists available fields.
Field | Description |
---|---|
Host name | Hostname of the host that SignServer is going to be installed to (auto populated). |
SAN | Alternate Name to be included in the certificate generated for this host during the installation. |
Step 2: Database Configuration
The Database Configuration settings are optional. By default, a MariaDB server will be installed locally and you can optionally specify to use an external database using either MariaDB/MySQL, PostgreSQL or Oracle Database.
Select to use a new installation or to join a node to an existing SignServer database, provided you already have a database with an existing SignServer installation.
2a: New Installation
- To use a cloud hosted database such as RDS (or Aurora), select the option to use an external database and enter the database information including Access URL, username, password and database name. The RDS or Aurora engine can be MariaDB, PostgreSQL or Oracle Database. AWS configures TLS on all deployed databases automatically. If you would like to use an Oracle Database, please follow these instructions to configure an option group that enables the TLS port and TLS connections on Oracle Databases.
In order for this feature to work, you must have configured a valid RDS or Aurora database instance. For more information, refer to the AWS documentation on Create an RDS DB Instance. - Click the database Test button to ensure success. Note that you are not allowed to continue with a cloud database installation unless the test passes successfully. This should be a fresh RDS instance with no existing SignServer database. If the database exists already and the Existing SignServer Database option is cleared, the wizard will give the error Database exists!. If this database was created ahead of time, it can be dropped since the database is created automatically by the wizard.
If the RDS Database instance is unavailable for any reason, the installation will fall back to a local installation to ensure success. The only way to recover from this is to export the database, import it into RDS, and reconfigure the node to point to a cloud database. It is recommended to fix the database connectivity problem and launch a new node from the Marketplace. Please see the latest SIgnServer Cloud Documentation for more information. The most common problem connecting to a cloud database is security group configuration. Ensure that the SignServer Cloud instance is allowed to talk to the RDS instance. - Once the database connection is successful, the Success message is shown.
- Click Next to continue to Step 3: ManagementCA Configuration.
2b: Cluster Join
To join a node to an existing SignServer database, provided you already have a database with an existing SignServer installation:
Select Existing SignServer Database (cluster join)? to join this node to an existing SignServer installation.
Cluster Join Note
If you are running a version of SignServer older than 6.0 there are steps needed to migrate your older Liquidsec public keys to CloudHSM. For more information, please see the CloudHSM Integration Guide section regarding CloudHSM Liquidsec Key Conversion.
Click Test to ensure success. The wizard will check the connection to the RDS database and check for the existence of the database provided in the database name field. If the wizard cannot find this database, the test will fail and not allow you to proceed.
- When Existing SignServer Database (cluster join)? is enabled, all other options in the wizard are disabled and you can continue to Step 5: Review and Submit.
Database Configuration Fields
The following lists available fields.
Field | Description |
---|---|
Database type | Must be one of either MariaDB (10,x), PostgreSQL (13-14) or Oracle Database (19 and up). It may work with other versions not listed. |
Database host name | Host name of the host that SignServer is going to be installed to (auto populated). |
Database port | Specify the port used for your database installation. This will default to the default or each database type. |
Database username | AWS calls this the "Master username". Master username must start with a letter. |
Database password | AWS calls this the "Master password". Master Password must be at least 8 printable ASCII characters. Can't contain any of the following: / (slash), "(double quote) and @ (at sign), as in "mypassword". |
Database name | The name of the database created inside the RDS database instance. |
Existing SignServer Database | Joins the node to an existing SignServer installation. Select Existing SignServer Database if you want to expand or upgrade the nodes in your cluster. |
Step 3: ManagementCA Configuration
The Management CA can either be created during the installation or imported from an existing Management CA.
Create a new ManagementCA
SignServer will create a Management CA based on attributes of the system to guarantee uniqueness. You can optionally import an existing ManagementCA to the instance and have certificates from that CA be allowed access to this installation, see Use Existing (Import) ManagementCA.
Note that the only required field when creating a new Management CA is the Superadmin password. For all available fields, see ManagementCA Configuration Fields below.
ManagementCA Configuration Fields
The following lists available fields. Note that the only required field on this page is the Superadmin password.
Field | Description |
---|---|
Create CA Common Name | Common Name of the ManagementCA. This CA is used to generate administrative certificates for the CA. |
Subject fields | OU= and O= can be configured for the ManagentCA DN. Includes the ReservationID, AMI-ID of the instance by default. Certificates are listed in the browser store by "O=". |
Key specification | Key specification of the ManagementCAs signing certificate. |
SuperAdmin name | Common Name of the Super administrator certificate to be generated during installation. This will be the default username in the certificate allowed access to the system. |
SuperAdmin password | Password used to both retrieve the keystore from the Public Web after installation as well as the password used to protect the keystore itself. |
Use Existing (Import) ManagementCA
You can optionally import an existing ManagementCA to the instance and have certificates from that CA be allowed access to this installation.
When importing an external ManagementCA, a role will be added for the supplied, case sensitive, Common Name (CN) provided. For example, if you supply "jsmith" as the username to be added, you must have a keystore issued to "jsmith" from the CA whose public certificate you are providing. The most common use case is an existing ManagementCA from another SignServer installation and a SuperAdmin certificate to match.
You must have a keypair generated with the Common Name supplied from the CAs public certificate you are uploading to this instance when choosing Import CA.
To use an existing Management CA with this instance, do the following:
- Select Use existing ManagementCA.
- Click Browse and select the public portion of the superadmin certificate from the existing Certificate Authority.
- Enter the Admin's Issuer Public Cert for the user for which you have a keystore from this CA.
- Click Next to continue to the Review and Submit page to review a summary of all settings.
For help getting the public portion of a superadmin and superadmins issuers certificate, use a tool like Keystore Explorer. Keystore explorer can easily extract these artifacts. Follow these steps:
Install and open Keystore Explorer. Pick "Open an existing Keystore" and select your superadmin.p12 (or other SignServer administrator keystore).
Enter the password for the keystore to access its contents:
Once you are into the keystore, double click on it to access its contents. You should then see the CA it came from and the certificate itself nested underneath it:
Click the administrator portion of the certificate (in this case SuperAdmin) and select Export. This will bring up a dialog to save the certificate. Save it to your local computer. This will be the Public Admin Cert for the SignServer Cloud Wizard:
Click the Issuer of that keystore (in this case ManagementCA) and again, select Export. This will be the Admins Issuer Public Cert for the SignServer Cloud Wizard:
Add these to the Signserver Cloud Wizard:
Step 4: CloudHSM Configuration
The CloudHSM Configuration settings are not relevant if you have selected to Use Existing ManagementCA since this means that no CA keys will be created.
The CloudHSM Configuration settings are optional. SignServer will create keys for the the first crypto worker in the database by default. CloudHSM key generation can be configured now so that the initial crypto worker keys are stored and created in CloudHSM. If you would like to have those keys created in a CloudHSM cluster, you can enter the credentials for your cluster here.
- You must have completed the CloudHSM setup complete for this feature to work. Using the instructions in the CloudHSM Integration Guide, complete through step 8 and have your customerCA.crt ready.
- You also must have applied the Security Group to this instance that allows communication to the CloudHSM cluster.
Testing connectivity to the CloudHSM cluster before the installation is not possible. Therefore, if the SignServer installation fails to connect to the CloudHSM cluster with the credentials provided for any reason, the setup will abort the HSM portion of the install and continue with the installation. There may be more details in the log file /var/log/install.log
on the SignServer host as to why installation with CloudHSM failed if it does.
To set up your own HSM later, skip this step and click Next to continue to the Review and Submit page to review a summary of all settings.
CloudHSM Configuration Fields
The following lists available fields.
Field | Description |
---|---|
CloudHSM IP Address | IP Address of the CloudHSM cluster. |
CloudHSM CryptoUser (CU) Password | Password of the CloudHSM Crypto User. |
CustomerCA.crt Upload | Your signed HSM certificate from your CloudHSM cluster initialization. For more information please refer to the AWS CloudHSM documentation. |
Step 5: Review and Submit
The Review and Submit page provides a summary of all the settings.
Once you have reviewed the settings, click Submit.
If for any reason you need to go back, click Previous and make changes accordingly.
Once you click Submit a timer will begin. At this point, your instance configuration with your chosen settings is starting. The page will automatically refresh and you can proceed to the next section.