--- version: "4.0" language: "en" --- # SignServer Cloud Documentation ## SignServer Cloud Documentation Browse the latest SignServer Cloud documentation ### Featured * #### [SignServer Cloud AWS Launch Guide](https://docs.keyfactor.com/signserver-cloud/latest/signserver-cloud-aws-launch-guide.md) Get information on how to deploy SignServer Cloud from AWS and log in to SignServer for the first time. * #### [SignServer Cloud Azure Launch Guide](https://docs.keyfactor.com/signserver-cloud/latest/signserver-cloud-azure-launch-guide.md) Get information on how to deploy SignServer Cloud from Azure and log in to SignServer for the first time. * #### [SignServer Cloud Quick Start Guide](https://docs.keyfactor.com/signserver-cloud/latest/signserver-cloud-quick-start-guide.md) Walks you through configuring SignServer Cloud to get started with code and document signing. ### Documentation * #### [SignServer Cloud Azure](https://docs.keyfactor.com/signserver-cloud/latest/signserver-cloud-azure.md) View guides on how to get your instance of SignServer Cloud on Azure running and get started with SignServer. * #### [SignServer Cloud AWS](https://docs.keyfactor.com/signserver-cloud/latest/signserver-cloud-aws.md) View guides on how to get your instance of SignServer Cloud on AWS running and get started with SignServer. * #### [SignServer Cloud Release Notes](https://docs.keyfactor.com/signserver-cloud/latest/signserver-cloud-release-notes.md) Get information on features and improvements implemented in each SignServer Cloud release. --- version: "4.0" language: "en" --- # Activate Cluster - SDK3 To activate the cluster, do the following: 1. SSH into the SignServer instance if not already done so. 2. Use the following command to start the AWS CloudHSM [**cloudhsm_mgmt_util**](https://docs.aws.amazon.com/cloudhsm/latest/userguide/cloudhsm_mgmt_util.html) command line tool: # sudo /opt/cloudhsm/bin/cloudhsm_mgmt_util /opt/cloudhsm/etc/cloudhsm_mgmt_util.cfg If you get a connection timed out, the security group has not been added to the instance. If you get "E2E failed: unable to establish ssl connection" this is because there is no customerCA.crt (or its an incorrect file) in /opt/cloudhsm/etc. 3. Use the `enable_e2e` command to enable end-to-end encryption: aws-cloudhsm> enable_e2e E2E enabled on server 0(server1) 4. Use the `loginHSM` command to log in to the HSM as the [precrypto officer (PRECO)](https://docs.aws.amazon.com/cloudhsm/latest/userguide/hsm-users.html) user: aws-cloudhsm> loginHSM PRECO admin password loginHSM success on server 0(server1) 5. Use the `changePswd` command to change the precrypto officer (PRECO) user's password: aws-cloudhsm> changePswd PRECO admin *************************CAUTION******************************** This is a CRITICAL operation, should be done on all nodes in the cluster. Cav server does NOT synchronize these changes with the nodes on which this operation is not executed or failed, please ensure this operation is executed on all nodes in the cluster. **************************************************************** Do you want to continue(y/n)?y Changing password for admin(PRECO) on 1 nodes 6. Logout as user PRECO: aws-cloudhsm> logoutHSM logoutHSM success on server 0 7. Use the following syntax to login to the HSM going forward: `loginHSM ` For example: aws-cloudhsm> loginHSM CO admin --- version: "4.0" language: "en" --- # Activate the cluster - SDK5 To activate the cluster, do the following: 1. SSH into the EJBCA instance. 2. Use the following command to activate the cluster # /opt/cloudhsm/bin/cloudhsm-cli cluster activate --password If you get a connection timed out error, the security group has not been added to the instance. --- version: "4.0" language: "en" --- # Allow Peer Connection in SignServer To allow Per Connection in SignServer: 1. Access the SignServer Administration GUI. 2. Select **Administrators** at the top. Under the **Incoming Connections** section you will see a new connection attempt: ![image2018-7-31_16-42-49.png](https://docs.keyfactor.com/__attachments/a_e7a212255078f0fa070cc0c6ac6bcf4294304164386f55b68bbe9a2499404af6/image2018-7-31_16-42-49.png?cb=6e9d3ef82f9e568a6729a43bbaab2f6f) 3. Click **Add Authorization**. 4. Select **Peer System** and click **Add**. ![image2018-7-31_16-42-59.png](https://docs.keyfactor.com/__attachments/a_304be8c17bbd1632539ee3fb3a9ceb64fe91dc1a0833a3c2f0839e89f59b2892/image2018-7-31_16-42-59.png?cb=8312fb459f75b3a58fdfbd4fc2a513e9) 5. There is now a second Authorization with a Peer System role. ![image2018-7-31_16-43-27.png](https://docs.keyfactor.com/__attachments/a_0e7003f49e7c88e1c460fc9857c227aa04431ddba167e58b1147821fdd28a273/image2018-7-31_16-43-27.png?cb=b762f2524e6c684761707f97e8f408f0) --- version: "4.0" language: "en" --- # Allow Peer Connections in SignServer To allow Per Connections in SignServer: 1. Log in to the SignServer Administration Web. 2. Select **Administrators** at the top. 3. Under **Peer Systems** , select **Allow incoming connections** and click **Save.** The following text displays "*No peer has successfully connected to this node*." ![image2018-7-31_16-24-27.png](https://docs.keyfactor.com/__attachments/a_49cd029c8a7232563b56b7d80d7d1be494e89465ad671c68092ec201ec566ae2/image2018-7-31_16-24-27.png?cb=6bee6e62bd35e86ea75219a31da5a9f6) --- version: "4.0" language: "en" --- # Appendix A - Migrate from SDK3 to SDK5 For the AWS specific version of the migration process from SDK3 to SDK5, please see the AWS PKCS11 migration documentation [here](https://docs.aws.amazon.com/cloudhsm/latest/userguide/pkcs11-migrate-to-sdk-5.html). Start by stopping EJBCA or SignServer: systemctl stop wildfly Remove the old CloudHSM client and PKCS11 library sudo yum remove cloudhsm-client Install the new SDK5 CloudHSM PKCS11 Library Start by downloading the proper client for your Linux distribution and architecture from the following page: Install the new client with a yum command and the URL associated with your distribution. For example, on Amazon Linux 2023 with X84_64 architecture use the following command: sudo yum install https://s3.amazonaws.com/cloudhsmv2-software/CloudHsmClient/Amzn2023/cloudhsm-pkcs11-latest.amzn2023.x86_64.rpm Install the new SDK5 CloudHSM CLI sudo yum install https://s3.amazonaws.com/cloudhsmv2-software/CloudHsmClient/Amzn2023/cloudhsm-cli-latest.amzn2023.x86_64.rpm Determine the IP address of your cluster. You can get one of the CloudHSM IP addresses from the AWS Console or from the AWS CLI if you have it installed. From the AWS CLI on the node, use the following: aws cloudhsmv2 describe-clusters Configure the HSM client to know the location of your HSM client certificate. This is typically located at /opt/cloudhsm/etc/customerCA.crt. sudo /opt/cloudhsm/bin/configure-pkcs11 --hsm-ca-cert /opt/cloudhsm/etc/customerCA.crt -a If you are using a single HSM in the cluster the HSM client needs to be aware of this. There is a Key Durability Check that needs to be disabled. If you have more than one HSM in the cluster, this can be skipped. sudo /opt/cloudhsm/bin/configure-pkcs11 --disable-key-availability-check sudo /opt/cloudhsm/bin/configure-cli --disable-key-availability-check Start WildFly systemctl start wildfly Continue to the next page to Configure the Crypto Token --- version: "4.0" language: "en" --- # Assigning Security Group The Cloud HSM initialization process creates a new Security Group as part of its install process. This Security Group needs to be added to the SignServer instance for the two to communicate. To assign the security group to the SignServer instance, do the following: 1. Select your SignServer Cloud Instance (or right click on it) and select: **Networking \> Change Security Groups**. ![image2018-12-3_13-28-40.png](https://docs.keyfactor.com/__attachments/a_ea670d40db68d50055dfde68ce35b37146795f767e2d73b4a03c2f376f2929ee/image2018-12-3_13-28-40.png?cb=6da0869f6e922d9772f918466365703a) 2. You will see a new security group that was generated from the CloudHSM install process. Select it and click **Assign Security Group**. ![image2018-9-6_12-43-39.png](https://docs.keyfactor.com/__attachments/a_a77c2a0b782a6119daebfe8614189187f90eb21fc9040238f2210715d88347ef/image2018-9-6_12-43-39.png?cb=d95332648a45743d7880bc9596971456) --- version: "4.0" language: "en" --- # Automatically Renewing the Key Binding Key A service can be created to automatically update the key used for the authentication key binding key. This is done via an EJBCA service. To create a service to automatically renew the key binding key: 1. Select **Services** under **System Functions**. 2. Under **Add Service** , enter the name **Peer Connection to SignServer Updater** and click **Add**. ![image2018-7-31_16-51-9.png](https://docs.keyfactor.com/__attachments/a_9931707baf917e587c946060ccb7ac973ed83904b18c4e7decd2ca562a1af7d3/image2018-7-31_16-51-9.png?cb=daa697088313eec826068a3cd93e87dd) 3. Select the newly added service, click **Edit Service** and set the following attributes: * **Select Worker:** Remote Internal Key Binding Updater * **Peer System:** Peer Connection to SignServer * **Renew key pair:** Selected * **Active:** Selected 4. Click **Save**. --- version: "4.0" language: "en" --- # AWS EC2 Image Builder EC2 Image Builder is a fully managed AWS service that helps you to automate the creation, management, and deployment of customized, secure, and up-to-date server images. You can use the AWS Management Console to create custom images in your AWS account. For more information on the EC2 Image Builder, refer to the [AWS EC2 Image Builder Documentation](https://docs.aws.amazon.com/imagebuilder/latest/userguide/what-is-image-builder.html). The following walks you through how to get started with AWS EC2 Image Builder. ## Create a Pipeline To create a pipeline, follow these steps: 1. In the AWS console, click **Create Image Pipeline**. To access the EC2 Image Builder, search for EC2 Image Builder in the AWS Console. * Enter a name and description for the pipeline. For example, "EJBCA Enterprise Image" or "SignServer Enterprise Image". * If you would like to run this image builder on a schedule, create one. Otherwise, select **Manual** . Then, click **Next**. 2. Select **Create new recipe**. * In the **Image type** section, ensure that the Output type **Amazon Machine Image (AMI)** option is selected. * In the **Recipe details** section, enter a name such as "EJBCA Enterprise Image Recipe" or "SignServer Enterprise Image Recipe" and give it a version. This is a version of the recipe, not the product. 3. Click **Select managed images**. This is the base image we are going to put the EJBCA or SignServer Component on. * In **Image Operating System (OS)** , select **Amazon Linux** and in **Image Name** , select **Amazon Linux 2023 x86**. This is the only OS that the EJBCA or SignServer Components support. It is recommended to pick the latest version so it has all of the current patches that AWS offers with their OS distributions. 4. Scroll down to the Components section, select **Add build components** , and then **AWS Marketplace - new**. 5. Search for "**ejbca** " or "**signserver**". You will see multiple listings for each of the products represented in the marketplace. Generally, the first one is EJBCA Enterprise 8x5 support, and the second is EJBCA Enterprise 24x7 support. Below that are versions for RA and VA, both with different support levels. SignServer Enterprise images follow the same model. The products are identical, but the support level is different and reflected in the cost of the product. To ensure you are selecting the correct one desired, click the link displayed for the product to open a component details screen. Below is a link for **Product listing** that takes you to the marketplace. If you or someone in your organization has not previously subscribed to this product, you will need to perform those steps. For more information about subscribing to Keyfactor products, refer to the documentation on [AWS Launch Guide](https://docs.keyfactor.com/ejbca-cloud/latest/ejbca-cloud-aws-launch-guide). 6. Select the component and click **Add to recipe**. 7. Give the image some storage to function. We recommend 30GiB at minimum, but this value will vary depending upon your needs. If you are running a local database, you will need to account for this. It is recommended to use an external RDS or Aurora database. For more information, refer to the [AWS Cluster Configuration Guide](https://docs.keyfactor.com/ejbca-cloud/latest/ejbca-cloud-aws-cluster-configuration-guide). 8. Click **Next**. 9. If you would like to create a workflow to include other components into the creation of this image, click **Custom workflows** . Otherwise, click **Default workflows,** and then click **Next**. 10. Select **Create a new infrastructure configuration** . Enter a name and description for this profile such as "EJBCA Enterprise Instance Profile" or "SignServer Enterprise Instance Profile". Select an IAM role if you have one already and proceed to STEP. If you do not have one, click **Create new role.** * Click **Create role** , select AWS Service, select "**EC2** " (should be at the top under commonly used services) as the use case (Image Builder runs on EC2 instances), and then click **Next**. * Search for and attach the following policies. If you need more granular control, create a custom policy with specific permissions: AmazonEC2ImageBuilderFullAccess EC2InstanceProfileForImageBuilder EC2InstanceProfileForImageBuilderECRContainerBuilds AmazonSSMManagedInstanceCore * On the next screen, give the role a name like "EC2ImageBuilderRole", and click **Create role**. * The role creation process should have been done in a new tab. Go back to the **Create pipeline** tab and click the refresh arrow next to the **Choose IAM role** list. For more information on AWS Permissions with EC2 Image Builder, refer to the AWS documentation on [How Image Builder works with IAM policies and roles](https://docs.aws.amazon.com/imagebuilder/latest/userguide/security_iam_service-with-iam.html#security_iam_service-with-iam-roles). 11. In the **AWS Infrastructure** section, select an instance type from the list. For a list of instance types supported, refer to the Marketplace listings for [EJBCA](https://aws.amazon.com/marketplace/server/procurement?productId=649bfbf8-b652-46f4-a30e-741e00cfe256), and [SignServer](https://aws.amazon.com/marketplace/server/procurement?productId=7460b440-f14c-407a-ab14-2a48d284c18d). The most common and recommended instance type is a t3.large. Click **Next**. 12. In the **VPC, subnet and security groups** section, select a VPC, subnet and the security groups needed to access the instance. 13. Select **Create distribution settings using service defaults** , and click **Next**. 14. Click **Create pipeline**. 15. In the **Actions** list, click **Run pipeline**. 16. Click **View details** and select the **Workflow** tab. You should see a running step. Click this step to open the output. 17. You can select the **Application Logs** tab or the **Log stream** . Selecting the log stream allows you to tail the logs in real time by clicking **Start tailing**. * Once the instance becomes reachable, it will start the staging process of EJBCA or SignServer. The process includes running a list of scripts that will stage the product and install dependencies to get the Amazon Linux image ready to be an EJBCA or SignServer Enterprise Cloud node. * Once the image creation process is complete, the main image builder tab will update all of the steps to be completed back on the **Workflow** tab. * Once all of the steps are completed, you can navigate to the EC2 section of the AWS Console, select AMIs and see the newly created image (it helps to sort by creation date). 18. Launching this image will start an EJBCA or SignServer Cloud instance. For more information on starting and deploying an EJBCA or SignServer Cloud instance, refer to the [AWS Launch guide for EJBCA](https://docs.keyfactor.com/ejbca-cloud/latest/ejbca-cloud-aws-launch-guide) or [AWS Launch Guide for SignServer](https://docs.keyfactor.com/signserver-cloud/latest/signserver-cloud-aws-launch-guide). --- version: "4.0" language: "en" --- # AWS Operating Environment Clustering with Galera is not the recommended way to Cluster SignServer. See the guide on [Clustering with RDS](https://docs.keyfactor.com/signserver-cloud/latest/clustering-with-an-rds-database-in-aws.md) for a better deployment method. ## EC2 Begin by starting two [SignServer Enterprise Cloud](https://aws.amazon.com/marketplace/seller-profile?id=7edf9048-58e6-4086-9d98-b8e0c1d78fce) instances. In this example, following nodes are used: * Node 1 using IP 172.16.0.202 -- US East 1 -- 172.16.0.0/16 address space * Node 2 using IP 172.16.0.188 -- US East 1 -- 172.16.0.0/16 address space * Node 3 using IP 172.31.0.115 -- US East 2 -- 172.31.0.0/16 address space Two of these nodes are in US-East-1 and the third is in US-East-2. For the purposes of this guide, the instance ID from Node 1 is used as the password. You can obtain this from the EC2 console in the instance details, or run the following command: # curl -s http://169.254.169.254/latest/meta-data/instance-id ![Clustering EC2 VPC.png](https://docs.keyfactor.com/__attachments/a_1c8674c4212a265c9205217d2dbdd631262e748d27be29843c83f6d868a9fdd8/Clustering%20EC2%20VPC.png?cb=18f21fcfbe94184b733fcf755b7c6b96) ## VPC Configuration To get the nodes to communicate, it is assumed a VPC Peering Connection is setup and in place. For assistance with configuring a VPC Peering Connection, refer to Amazon's [VPC Peering Guide.](https://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/Welcome.html) Optionally, for testing purposes, all nodes can be setup within the same VPC. This is not ideal and does not provide any availability guarantees if one of the AWS sites has an outage. A Route Table needs to be created that allows these nodes to communicate over the Peering Connection. For more information on configuring Route Tables between VPCs, refer to Amazon's documentation on[Updating Your Route Tables for a VPC Peering Connection](https://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/vpc-peering-routing.html). A security group is also needed in each VPC. That configuration is outlined in [Cluster Security Groups](https://docs.keyfactor.com/signserver-cloud/latest/security-groups.md) since it pertains directly to the Galera communication. --- version: "4.0" language: "en" --- # AWS Operating Environment ## EC2 Begin by starting an [EJBCA Enterprise Cloud](https://aws.amazon.com/marketplace/seller-profile?id=7edf9048-58e6-4086-9d98-b8e0c1d78fce) and a SignServer Enterprise Cloud instance. In this example, the following 2 nodes are used: * EJBCA Node using IP 172.16.2.21-- US East 1 -- 172.16.0.0/16 address space * SignServer Node using IP 172.16.2.98 -- US East 1 -- 172.16.0.0/16 address space For simplicity of this guide, these nodes are in US-East-1 region. ![image2018-7-31_16-17-39.png](https://docs.keyfactor.com/__attachments/a_1ca010ebb626312ef15e87bedb5fce653b77f2375fb07cfcb150300d8a572cc6/image2018-7-31_16-17-39.png?cb=f0cb4d23a531c63b91e2c6642dcbfa80) ## VPC Configuration If it is desired to have these two nodes communicate from different VPCs, it is assumed a VPC Peering Connection is setup and in place. For assistance with configuring a VPC Peering Connection, refer to Amazon's [VPC Peering Guide](https://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/Welcome.html). Optionally, all nodes can be setup within different VPCs. A Route Table will need to be created that allows these nodes to communicate over the Peering Connection. For more information on configuring Route Tables between VPCs, refer to Amazon's [VPC Peering Guide](https://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/vpc-peering-routing.html). A security group is also needed in each VPC. That configuration is outlined in the section [EJBCA/SignServer Peering Security Groups](https://docs.keyfactor.com/signserver-cloud/latest/ejbca-signserver-peering-security-groups.md) below since it pertains directly to the Galera communication. Consult the AWS documentation for further information. --- version: "4.0" language: "en" --- # Backup using AWS Snapshot To backup an instance of SignServer Cloud, you can either use the CLI script included on the instance or create a snapshot in the AWS Console. This section describes how to backup using AWS snapshot. For information on how to backup via script, see [Backup via CLI Script](https://docs.keyfactor.com/signserver-cloud/latest/backup-via-cli-script.md). ## Backup using AWS Snapshot To backup the instance by taking a snapshot in the AWS Console: 1. Access the EC2 Console at and click **Running Instances**. ![Using AWS Snapshot.png](https://docs.keyfactor.com/__attachments/a_1ab64e1ae7ac0107b5952f5fb317ab94730e094429c19a9f2f1fb32fd3c00dc9/Using%20AWS%20Snapshot.png?cb=7ffc4d5c804c9e9051e244d6dca9a6f5) 2. Select the instance to take a snapshot of. 3. Right-click the instance, point to **Image** and select **Create Image**. ![Using AWS Snapshot2.png](https://docs.keyfactor.com/__attachments/a_f58c4099114c9b497a3dedd19785164dfb80746b9b4d7838342055ab327ce249/Using%20AWS%20Snapshot2.png?cb=bbe42442b06690fd78ffb010308e42ea) 4. Enter a name and description for the image in the **Image name** and **Image description** fields, and then click **Create Image**. ![image2018-7-26_16-2-31.png](https://docs.keyfactor.com/__attachments/a_8b610905976376bb5224343fc59f21efc02863d84014780362707f10823c917f/image2018-7-26_16-2-31.png?cb=2ca756972c5928e69481ecf06a33bc28) 5. In the sidebar, select **Snapshots**. You will see the pending snapshot being created. ![Using AWS Snapshot4.png](https://docs.keyfactor.com/__attachments/a_a13c38bf411150e1345eb6519d91d0c225ea761bc99fb698026e2770ef2c8259/Using%20AWS%20Snapshot4.png?cb=a873520c3c8e821597911d19f0f05d2d) 6. Once the snapshot is accessible it will be marked as **Completed** in the **Status** column. --- version: "4.0" language: "en" --- # Backup via CLI Script To backup an instance of SignServer Cloud, you can either use the CLI script included on the instance or create a snapshot in the AWS Console. This section describes how to backup via script. For information on using the AWS Console with snapshots, see [Backup using AWS Snapshot](https://docs.keyfactor.com/signserver-cloud/latest/backup-using-aws-snapshot.md). ## Backup via Script To backup the instance using the script included on the instance: 1. Using the SSH key that you selected when procuring the instance, SSH into the SignServer Cloud instance using the username **ec2-user**: # ssh --i ssh-key.pem ec2-user@elastic-ip.compute-1.amazonaws.com ![image2018-7-26_15-27-42.png](https://docs.keyfactor.com/__attachments/a_50a616cba768f89aa5d4bbbe35cdcb833015730317a3ced92a84cbaff64258ed/image2018-7-26_15-27-42.png?cb=376c2d4b168b1945434ddb4ef81e23ea) 2. Run the command `sudo su` to get elevated privileges: # sudo su 3. Change to the `/opt/PrimeKey/support` directory. 4. Run the script `system_backup.sh` to create a backup of your system. 5. Press **Y** to proceed and enter a password to protect the backup once prompted: ![image2018-7-26_15-58-37.png](https://docs.keyfactor.com/__attachments/a_6933f6a7b355d59e2fb026c3099956791c439f3366bedb7ede93219c25e6fc31/image2018-7-26_15-58-37.png?cb=78e14e1e38c0d61af7c3569c106ae218) 6. Make a note of the name of the backup file created. Copy the backup file to a directory that is accessible by the **ec2-user** , for example `/home/ec2-user/`. In this case, the file named: "/opt/PrimeKey/support/backup_files/signserver_db-ec2-54-162-206-73.compute-1.amazonaws.com-1532645892.tar.gz" is copied to `/home/ec2-user/`: # cp /opt/PrimeKey/support/backup_files/signserver_db-ec2-54-162-206-73.compute-1.amazonaws.com-1532645892.tar.gz /home/ec2-user/ 7. It is recommended to copy this backup to another system, either locally from your administration workstation, or in another AWS data center. For more information on how to copy the file from the SignServer Cloud instance, see the [Copying Backup Files to Other Systems](https://docs.keyfactor.com/signserver-cloud/latest/copying-backup-files-to-other-systems.md) section. For instructions on how to automate the backup of the system in order not to prompt for passwords, see the [Optional - Automating the Backup Script](https://docs.keyfactor.com/signserver-cloud/latest/optional-automating-the-backup-script.md) section. --- version: "4.0" language: "en" --- # Cluster Replication Configuration The following sections cover configuration of Cluster Replication. ## Replication Configuration on Node 1 Designate the node to start with. This will be the node that is used to cluster its data to the other nodes. When accessing the databases on the nodes for the first time use their instance ID as the password. Once the data is replicated to the remaining nodes in the cluster from Node 1, they will all use the same password as Node 1. The MySQL configuration file is located at /etc/my.cnf.d/server.cnf. This file already has much of the configuration needed to get a cluster working. Change the cluster name as required by editing the wsrep_cluster_name="galera" value to the desired value. In this example, "signserver_cluster" is used. This value should be the same on all nodes in the cluster. 1. Create a backup of the system by running: # /opt/PrimeKey/support/system_backup.sh For more information on backing up SignServer Enterprise Cloud instances, refer to the [SignServer Cloud Backup Guide](https://docs.keyfactor.com/signserver-cloud/latest/signserver-cloud-aws-backup-guide.md). 2. Run the following commands to ensure that the remote systems and localhost can write to the database. Change\ to the desired password and the "172.16.0.%" to be valid for the VPC subnet used. The "%" character is a wildcard and can be used if desired. For example, if the internal address space is "10.10.1.0/24" then "10.10.1.%" could be used. Note If this configuration is being done in more than one VPC, change the subnet space or IP address for each subnet with the commands below. Three separate statements for each of the specific IP addresses for each node in the cluster can be created for tighter security if desired. # mysql -u root --password= -e "GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT on *.* to 'repl_user'@'172.16.0.%' identified by '';" NEXT LINE ONLY NEEDED WHEN USING ADDITIONAL VPCS: # mysql -u root --password= -e "GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT on *.* to 'repl_user'@'172.31.0.%' identified by '';" 3. Edit the /etc/my.cnf.d/server.cnf file and look for the \[galera\] section, under the comment "# Galera Cluster Configuration". Add the following lines to the section, changing the two "wsrep_cluster_address" IP addresses to the Node 2 and Node 3 IP addresses in the cluster, the value for "wsrep_node_name" for Node 1 and the "wsrep_node_address" to be the IP address for Node 1 if not already set: wsrep_cluster_name=signserver_cluster wsrep_cluster_address="gcomm://172.16.0.188,172.31.0.115" wsrep_node_name=SignServerNode1 wsrep_node_address="172.16.0.202" ## Replication Configuration on Node 2 1. SSH into Node 2 and perform a backup: # /opt/PrimeKey/support/system_backup.sh 2. Stop mysql on this node: # service mysql stop 3. Edit the /etc/my.cnf.d/server.cnf file and look for the \[galera\] section, under the comment "# Galera Cluster Configuration". Add the following lines to the section, changing the two "wsrep_cluster_address" IP addresses to the Node 1 and Node 3 IP addresses in the cluster, the value for "wsrep_node_name" for Node 2, and the "wsrep_node_address" to be the IP address for Node 2 if not already set. Also change the wsrep_sst_auth to be**the password from node 1**: [mysql] wsrep_cluster_name=signserver_cluster wsrep_cluster_address="gcomm://172.16.0.202,172.31.0.115" wsrep_node_name=SignServerNode2 wsrep_node_address="172.16.0.188" wsrep_sst_auth=repl_user: ## WildFly Configuration for Node 2 * Edit the Wildfly datasource.properties file and update the password to the password used in the database: # vim /opt/PrimeKey/wildfly_config/datasource.properties Note Change DATABASE_PASSWORD= \ to the password of the main node that replicated the data. In this case this is the**password from Node 1**. ## Replication Configuration on Node 3 1. SSH into Node 3 and perform a backup: # /opt/PrimeKey/support/system_backup.sh 2. Stop mysql on this node: # service mysql stop 3. Edit the /etc/my.cnf.d/server.cnf file and look for the \[galera\] section, under the comment "# Galera Cluster Configuration". Add the following lines to the section, changing the two "wsrep_cluster_address" IP addresses to the Node 1 and Node 2 IP addresses in the cluster, the value for "wsrep_node_name" for Node 3 and the "wsrep_node_address" to be the IP address for Node 3 if not already set: [mysqld] wsrep_cluster_name=signserver_cluster wsrep_cluster_address="gcomm://172.16.0.202,172.16.0.188" wsrep_node_name=SignServerNode3 wsrep_node_address="172.31.0.115" wsrep_sst_auth=repl_user: ## WildFly Configuration for Node 3 * Edit the Wildfly datasource.properties file and update the password to the password used in the database: # vim /opt/PrimeKey/wildfly_config/datasource.properties Change DATABASE_PASSWORD= \ to the password of the main node that replicated the data. In this case, the password needed is the password from Node 1. --- version: "4.0" language: "en" --- # Clustering with an RDS database in AWS There are multiple ways to cluster SignServer and the following sections provide information on [clustering with RDS](https://keyfactor.atlassian.net/wiki/pages/createpage.action?spaceKey=ECD&title=Clustering%20with%20RDS). Before SignServer Cloud 2.0, the typical approach was to cluster the local Galera nodes with each other, see [Clustering with Galera on Local Nodes](https://keyfactor.atlassian.net/wiki/pages/createpage.action?spaceKey=ECD&title=Clustering%20with%20Galera%20on%20Local%20Nodes). As of SignServer Cloud version 2.0, you can install directly into a Relational Database Service (RDS) database. This makes clustering and upgrades more straightforward since the data is a single, centralized source of truth. Clustering with an RDS database is the preferred way to cluster SignServer. Using the configuration wizard, you can directly install into an RDS database, allowing you to point nodes to this new centralized database and load balance between them. For more information, see [Clustering with RDS](https://keyfactor.atlassian.net/wiki/pages/createpage.action?spaceKey=ECD&title=Clustering%20with%20RDS). Performing local Galera Node clusters is not recommended by SignServer professionals. Clustering this way brings many system management aspects that must be considered: 1. Galera node upgrades - How are database upgrades being handled? 2. Maintenance of application servers - When rebooting an application server for any reason you are also rebooting a database replica. 3. Who maintains the expertise to fix a node when a replication error occurs. Many times configurations on nodes can get out of sync and this is not notices until a restart happens. 4. How are full state transfers handled? If a node is down long term, is an expert on hand that can handle the difference between a Full and Incremental State Transfer (SST vs IST). Recommendations are to install to a Cloud Hosted database like RDS or Aurora. This brings in a solid, cloud managed database with all of the availability, backup and patching methods delivered by cloud providers. A selection can also be made to install into an existing RDS database using the database configuration wizard. For more information, see **Wizard Based Configuration** in [Clustering with RDS](https://keyfactor.atlassian.net/wiki/pages/createpage.action?spaceKey=ECD&title=Clustering%20with%20RDS). --- version: "4.0" language: "en" --- # Clustering with RDS Backing up and restoring a node's configuration from SignServer Cloud 2.0 to another version of 2.0 or later allows the node to be automatically configured in a cluster using a Relational Database Service (RDS). This automatic method will also get the CloudHSM keys as well as TLS certificates automatically. If a version prior to SignServer Cloud 2.0 is installed or the instance is manually configured to point to RDS, please skip the first sections below and proceed to [Clustering with RDS#Manual RDS Configuration](https://docs.keyfactor.com/signserver-cloud/latest/clustering-with-rds.md#ClusteringwithRDS-ManualRDSConfiguration). ## Wizard Based Configuration SignServer Cloud 2.1 The following describes how to configure nodes using the wizard as of version SignServer Cloud 2.0. To configure nodes (using the wizard as of version SignServer Cloud 2.0): 1. Launch the same quantity of nodes from the AWS Marketplace as is currently in production according to the [AWS Launch Guide](https://doc.primekey.com/ejbca-cloud/ejbca-cloud-aws/aws-launch-guide). 2. If using a VIP in this SignServer cluster, add the VIP address in the wizard [Step 1: Host Settings](https://keyfactor.atlassian.net/wiki/pages/createpage.action?spaceKey=ECD&title=Configure%20via%20EJBCA%20Enterprise%20Cloud%20Configuration%20Wizard). ![image2023-12-5_11-11-12.png](https://docs.keyfactor.com/__attachments/a_0f7436e26197fa65fb74a4c2bde83aec2805b986a343439f8aba0a152770f0eb/image2023-12-5_11-11-12.png?cb=2863edef3f8b3a2bbd7f632fef1e277f) 3. Select the option to use an **Existing SignServer Database** in the configuration wizard at launch time. ![image2023-12-5_11-10-45.png](https://docs.keyfactor.com/__attachments/a_8d6731d620e36c7fc378cbab53a65dfdf6a723267ee29928edb55e42b6ebc15c/image2023-12-5_11-10-45.png?cb=e9a7853afc24ddeaffd13664407dd0fa) 4. Wait for the node to boot using the configuration from the existing installation. 5. Once the new nodes are running and connected to the RDS database, remove the old nodes from the load balancer (if used) and add the new ones. 6. Confirm the new nodes are properly serving traffic. ## Automatic Configuration with Backup/Restore Scripts To automatically configure with backup and/or restore scripts, using SignServer Cloud version 2.0: 1. Backup your cloud node according to instructions in the [SignServer Cloud AWS Backup Guide](https://doc.primekey.com/signserver-cloud/signserver-cloud-aws/aws-backup-guide). 2. Launch another instance in AWS from the AWS Marketplace, according to the [SignServer Cloud AWS Launch Guide](https://doc.primekey.com/ejbca-cloud/signserver-cloud-aws/aws-launch-guide). 3. Pick the wizard defaults and install a local database. Note that this configuration will be overwritten when the node is clustered to the RDS database. 4. Copy the backup file to the new instance. 5. Run the `/opt/PrimeKey/support/system_restore.sh` script pointing it to the backup file you just copied to the new instance. For information on restoring a backup, see the [SignServer Cloud AWS Restore and Upgrade Guide](https://doc.primekey.com/signserver-cloud/signserver-cloud-aws/aws-restore-and-upgrade-guide/). 6. Generate new TLS certificates for the SignServer host with the `/opt/PrimeKey/support/new_tls_cert.sh` script. For more information on how to use the `new_tls_cert.sh` script, see the [SignServer Cloud TLS Certificate Generation Guide](https://doc.primekey.com/signserver-cloud/signserver-cloud-aws/aws-tls-certificate-generation-guide). ## Manual RDS Configuration This procedure assumes that an SignServer instance is running in AWS and it is connected to RDS and a second node for redundancy is needed: 1. Launch another instance in AWS from the AWS Marketplace, according to the [SignServer Cloud AWS Launch Guide](https://doc.primekey.com/signserver-cloud/signserver-cloud-aws/aws-launch-guide). Select the defaults and install a local database. Note that this configuration will be overwritten when the node is restored. 2. SSH into the newly launched node and edit the `datasource.properties` file. Bash vi /opt/PrimeKey/wildfly_config/datasource.properties 3. Edit the configuration so that it points to the RDS database using the password you configured. You can get these values from the RDS console, or from node 1. The file contains the following properties: * **DATABASE_ADDRESS**: The RDS address of the database in AWS. * **DATABASE_NAME**: The name of the database chosen in the SignServer Cloud Configuration Wizard. * **DATABASE_USERNAME**: The name of the user chosen in the SignServer Cloud Configuration Wizard. * **DATABASE_PASSWORD:**The password chosen in the RDS console when configuring the database. 4. Restart WildFly: Bash systemctl restart wildfly 5. Ensure the SignServer UI loads correctly and that the contents of SignServer match the installation on Node 1. 6. Generate a new TLS certificate for the host from the RDS database. If you are going to use a VIP to load balance between the two nodes, add that into the certificate. For example, if using pki.company.com, add that with **-d**. This VIP should be in the TLS certificate on both nodes. If node 1 does not have the VIP in its certificate, run the following. For more information on how to use the `new_tls_cert.sh` script, see the [SignServer Cloud TLS Certificate Generation Guide](https://doc.primekey.com/signserver-cloud/signserver-cloud-aws/aws-tls-certificate-generation-guide). Bash /opt/PrimeKey/support/new_tls_cert.sh -p -d pki.domain.com 7. Ensure the SignServer UI loads and the data is consistent with Node 1. --- version: "4.0" language: "en" --- # Configure the cloudhsm-client - SDK3 To configure the CloudHSM client **cloudhsm-client**: 1. SSH into the SignServer instance. 2. Copy your issuing certificate (the one that you used to sign the cluster's certificate) to the following location on the client instance: /opt/cloudhsm/etc/customerCA.crt You need root permissions on the client instance to copy your certificate to this location. If you used your SignServer instance to generate this file it is located in `/home/ec2-user `and you may also move or copy it to this location. 3. Stop the cloudhsm-client. # sudo stop cloudhsm-client or # sudo service cloudhsm-client stop 4. Use the following command to update the configuration files for the AWS CloudHSM client and command line tools, specifying the IP address of the HSM in your cluster. If you do not know the HSM's IP address, view your cluster in the [AWS CloudHSM console](https://console.aws.amazon.com/cloudhsm/). # sudo /opt/cloudhsm/bin/configure -a Updating server config in /opt/cloudhsm/etc/cloudhsm_client.cfg Updating server config in /opt/cloudhsm/etc/cloudhsm_mgmt_util.cfg 5. Start the CloudHSM client: # sudo start cloudhsm-client or # sudo service cloudhsm-client start 6. Ensure the cloudhsm_mgmt_util configuration file is up to date. Do this to ensure cloudhsm_mgmt_util is aware of all the HSM instances in the cluster. # sudo /opt/cloudhsm/bin/configure -m 7. Connect to the HSM instances, enable end-to-end encryption, and log in to the HSM instances. Enabling end-to-end encryption encrypts the communication between cloudhsm_mgmt_util and the HSM to prevent interception of sensitive information such as passwords: # /opt/cloudhsm/bin/cloudhsm_mgmt_util /opt/cloudhsm/etc/cloudhsm_mgmt_util.cfg aws-cloudhsm> enable_e2e --- version: "4.0" language: "en" --- # Configure the cloudhsm-client - SDK5 This guide assumes that the CloudHSM client is pre-installed on an EJBCA or SignServer Cloud instance. If the cloudHSM client is not yet installed, refer to [Appendix D - Installing the CloudHSM Client](https://keyfactor.atlassian.net/wiki/spaces/EJBCACD/pages/371819972/Appendix+D+-+Installing+the+CloudHSM+Client). It also assumes that any old Liquidsec keys have been converted to the newer P11NG format as outlined in the Appendix. To configure the CloudHSM client **cloudhsm-client**,: 1. SSH into the EJBCA instance. 2. Copy your issuing certificate (the one that you used to sign the cluster's certificate) to the following location on the client instance: /opt/cloudhsm/etc/customerCA.crt You need root permissions on the client instance to copy your certificate to this location. If you used your EJBCA instance to generate this file it is located in /home/ec2-user and you may also move or copy it to this location. 3. Update the cloudhsm client configuration # vim /opt/cloudhsm/etc/cloudhsm-cli.cfg # Edit the line that has "%%HSM_IP_ADDRESS%%" and change this value to your HSM IP address. 4. Use the following command to update the configuration files for the AWS CloudHSM client and command line tools, specifying the IP address of the HSM in your cluster. If you do not know the HSM's IP address, view your cluster in the [AWS CloudHSM console](https://console.aws.amazon.com/cloudhsm/). /opt/cloudhsm/bin/configure-pkcs11 --hsm-ca-cert /opt/cloudhsm/etc/customerCA.crt -a "HSM_IP_ADDRESS" 5. If you have only one HSM in the cluster, run this additional command or EJBCA will not be able to use the keys on the hSM # /opt/cloudhsm/bin/configure-pkcs11 --disable-key-availability-check # /opt/cloudhsm/bin/configure-cli --disable-key-availability-check --- version: "4.0" language: "en" --- # Configure via SignServer Cloud Configuration Wizard in Azure 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](https://docs.keyfactor.com/signserver-cloud/latest/log-in-to-signserver-cloud.md) to retrieve the superadmin certificate from your instance. ## Step 1: Host Settings In the first step, you enter the host settings for the instance. 1. The host name is automatically detected but can be changed. The host name must match the name of the host or DNS name that is entered into a browser when accessing the Administration Interface of this SignServer installation. 2. 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 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. 3. Click **Next** to continue to the database configuration. ![image2022-12-1_17-31-44.png](https://docs.keyfactor.com/__attachments/a_b1d01675fd055e0a152cc3401d2ca25b0da7a90c735e59e6578979592a1f8e0a/image2022-12-1_17-31-44.png?cb=bbb4cdf4dde4fbbc9bb72c6882a6af14) ### 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 is 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. ### New Installation 1. To use a cloud hosted database such as Azure Database for MySQL, select the option to use an external database and enter the database information including Access URL, username, password and database name. The Azure Database engine can be MariaDB, PostgreSQL, or Oracle Database. Azure configures TLS on all deployed databases automatically. In order for this feature to work, you must have configured a valid Azure database instance. For more information, refer to the Azure documentation on [Create an Azure Database Instance](https://learn.microsoft.com/en-us/azure/?product=databases). 2. 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 Azure Datavase instance with no existing SignServer database. If the database exists already and the **Existing SignServer Database** option is cleared, the wizard gives 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 Azure 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 Azure Database, 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](https://doc.primekey.com/signserver-cloud/signserver-cloud-aws) 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 Azure Database instance. 3. Once the database connection is successful, the *Success* message is shown. 4. Click **Next** to continue to [Step 3: ManagementCA Configuration](#). ![image2023-12-5_8-22-47.png](https://docs.keyfactor.com/__attachments/a_504baf2c99c946692a0501875adefebb21b0c3c005d5593f44014b676d6ce006/image2023-12-5_8-22-47.png?cb=23cb41be035cade5ec50454d78561935) ### Cluster Join To join a node to an existing SignServer database, provided you already have a database with an existing SignServer installation: 1. Select **Existing****SignServer****Database (cluster join)?** to join this node to an existing SignServer installation. 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](https://keyfactor.atlassian.net/wiki/pages/createpage.action?spaceKey=ECD&title=EJBCA%20ECE%20on%20AWS%20CloudHSM%20Integration%20Guide) section regarding [CloudHSM Liquidsec Key Conversion](https://keyfactor.atlassian.net/wiki/pages/createpage.action?spaceKey=ECD&title=EJBCA%20and%20CloudHSM%20Integration%20Introduction). 2. Click **Test** to ensure success. The wizard checks the connection to the Azure Database and checks for the existence of the database provided in the database name field. If the wizard cannot find this database, the test fails and not allow you to proceed. 3. 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 | Azure calls this the "Admin username". Admin username must start with a letter. | | Database password | 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 Azure 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](https://docs.keyfactor.com/signserver-cloud/latest/configure-via-signserver-cloud-configuration-wiz-1.md#UseExisting(Import)ManagementCA). The only required field when creating a new Management CA is the **Superadmin password** . For all available fields, see [ManagementCA Configuration Fields](https://docs.keyfactor.com/signserver-cloud/latest/configure-via-signserver-cloud-configuration-wiz-1.md#ManagementCAConfigurationFields) below. ![image2023-12-5_8-26-0.png](https://docs.keyfactor.com/__attachments/a_c09474b6a132adadf45d4581c7dc77dd36cc8cc786404812f47c82492def1273/image2023-12-5_8-26-0.png?cb=0fd968859ae8e1f037ec343eb2d77d8b) ### 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: 1. Select **Use existing ManagementCA**. 2. Click **Browse** and select the public portion of the superadmin certificate from the existing Certificate Authority. 3. Enter the **Admin's Issuer Public Cert** for the user for which you have a keystore from this CA. ![image2023-12-5_8-28-56.png](https://docs.keyfactor.com/__attachments/a_03988252b7b00d2921919890f89fb69cf79c77d2c54eb6c0b868b0c509f30dc5/image2023-12-5_8-28-56.png?cb=e30fc219e87d73847d8845772f5b91c6) Help with the Public Portion of Certificates: For help getting the public portion of a superadmin and superadmins issuers certificate, use a tool like [++Keystore Explorer++](https://keystore-explorer.org/). Keystore Explorer can easily extract these artifacts. Follow these steps: 1. Install and open Keystore Explorer. 2. Pick **Open an existing Keystore** and select your superadmin.p12 (or other SignServer administrator keystore). ![image2023-12-5_8-58-21.png](https://docs.keyfactor.com/__attachments/a_bd0690aed5f490c3221ba3934237a93e64167bf32bad2fdfd3238c5e32a66d8c/image2023-12-5_8-58-21.png?cb=3232caa33893702a39eb3679ec306d13) 3. Enter the password for the keystore to access its contents: ![image2023-12-5_9-0-3.png](https://docs.keyfactor.com/__attachments/a_6733818cf6cf43459c1e6581768c00bba5655bf7ba3baf64f6cfe3908a5def7c/image2023-12-5_9-0-3.png?cb=eb78743b49e5a12c466a585092651229) 4. Once you are in 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: ![image2023-12-5_9-1-42.png](https://docs.keyfactor.com/__attachments/a_5680571831e56962ff6ac7e9c063a27e95dbb4ca306409a22cafdfa4bca6a5dd/image2023-12-5_9-1-42.png?cb=e6e21cdb77c3e4c9ad34550e26e8a9da) 5. Click the administrator portion of the certificate (in this case, SuperAdmin) and select **Export**. 6. 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: ![image2023-12-5_9-7-51.png](https://docs.keyfactor.com/__attachments/a_cb995a72bc69f8543dde94198b9d1fa2337fbe89dbab94fd2bd5254ce2e19ec5/image2023-12-5_9-7-51.png?cb=b647116cf6b71f2eb4228ce2bcdb2dd8) 7. 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: ![image2023-12-5_9-53-30.png](https://docs.keyfactor.com/__attachments/a_e72787378c5abe42a982754b1b2549bf4db571ca24cd0ce8c89a07f9296369ee/image2023-12-5_9-53-30.png?cb=405b916a81cf3204a54529336ffe9134) 8. Add these to the Signserver Cloud Wizard: ![image2023-12-5_9-54-44.png](https://docs.keyfactor.com/__attachments/a_38a395230ca0c1649586176eacd40d8ac8fb994d92b5485c0621d6280ddea58b/image2023-12-5_9-54-44.png?cb=63fe8523fe9bb4a6e263869211c197b7) 4. Click **Next** to continue to the Review and Submit page to review a summary of all settings. ## Step 4: Azure Key Vault Configuration The Azure Key Vault Configuration settings are not relevant if you have selected to **Use Existing ManagementCA** since this means that no CA keys will be created. The Azure Key Vault Configuration settings are optional. EJBCA will create keys for the ManagementCA in the database by default. Azure Key Vault key generation can be configured now so that the initial ManagementCAs keys are stored and created in Azure Key Vault. If you would like to have those keys created in Azure Key Vault, you can enter the credentials for your vault here. * You **must** have completed the Azure Key Vault setup for this feature to work. Using the instructions in the [Azure Key Vault Integration Guide](https://doc.primekey.com/ejbca-cloud/ejbca-cloud-azure/azure-key-vault-integration-guide), complete through vault creation and have your Application User password, Client ID and Vault name. * You also must have applied the Firewalls and Virtual Network settings that allow the EJBCA Cloud instance communication to the configured Azure Key Vault. Testing connectivity to the Azure Key Vault before the installation is not possible. Therefore, if the EJBCA installation fails to connect to the Azure Key Vault with the credentials provided for any reason, the setup will fall back to a soft key pair generation so the EJBCA installation itself does not fail. There may be more details in the log file `/var/log/install.log` on the EJBCA host as to why installation with Azure Key Vault 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. ![image2023-12-5_12-28-29.png](https://docs.keyfactor.com/__attachments/a_16c722882405a2fa07464376fb3355bb7833a25e0bf3bff36f3b4efb9a51cdc3/image2023-12-5_12-28-29.png?cb=a49f42ff25809fa6202cabeb2eab7084) ### Azure Key Vault Configuration Fields The following lists available fields. | **Field** | **Description** | |---------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Azure Key Vault Name | Name of the Vault instance to use. | | Key Vault Client Secret | The client secret of the Azure Application User allowed to access the Key Vault. | | Key Vault Application Client ID | The Client-ID of the Azure Application User configured to access the Key Vault. For more information see the [EJBCA Cloud Azure Key Vault Integration Guide](https://doc.primekey.com/ejbca-cloud/ejbca-cloud-azure/azure-key-vault-integration-guide/creating-an-app-registration-in-active-directory). | | Key Vault Type | Either Premium or Standard depending on the type of Key Vault EJBCA Cloud will be configured to connect to. | ## 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. ![image2022-12-2_16-14-52.png](https://docs.keyfactor.com/__attachments/a_ebb0107d4879373f3a91b23f608c460d2dd2918cfe67f4aec789360888ce740f/image2022-12-2_16-14-52.png?cb=da51da8c4e0cbc904a3a6393e5e6af89) Once you click **Submit**, a timer begins. 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. ![image2023-12-5_9-58-20.png](https://docs.keyfactor.com/__attachments/a_f3dc79c28e2935cc2eaabe87beb492943e55c11fa8d1afa238905264c6bc1173/image2023-12-5_9-58-20.png?cb=9851597d2878b652a31f0910f32c3fd8) --- version: "4.0" language: "en" --- # Configure via SignServer Cloud Configuration Wizard in AWS 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](https://docs.keyfactor.com/signserver-cloud/latest/log-in-to-signserver-cloud.md) to retrieve the superadmin certificate from your instance. ## Step 1: Host Settings In the first step, you enter the host settings for the instance. 1. 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. 2. 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 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. 3. Click **Next** to continue to the database configuration. ![image2022-12-1_17-31-44.png](https://docs.keyfactor.com/__attachments/a_dde7822e67c4fc787e5c38d60924f94efcdf923338f358f97369242db05cf347/image2022-12-1_17-31-44.png?cb=bbb4cdf4dde4fbbc9bb72c6882a6af14) ### 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 1. 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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.Oracle.Options.SSL.html#Appendix.Oracle.Options.SSL.OptionGroup) 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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Tutorials.WebServerDB.CreateDBInstance.html). 2. Click the database **Test** button to ensure success. 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. See the latest [SignServer Cloud Documentation](https://doc.primekey.com/signserver-cloud/signserver-cloud-aws) 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. 3. Once the database connection is successful, the *Success* message is shown. 4. Click **Next** to continue to [Step 3: ManagementCA Configuration](https://docs.keyfactor.com/signserver-cloud/latest/configure-via-signserver-cloud-configuration-wizar.md#ManagementCA-Configuration). ![image2023-12-5_8-22-47.png](https://docs.keyfactor.com/__attachments/a_81b6bf3e611bc2f63922b44046695d8245745dceca8188862b70877664506754/image2023-12-5_8-22-47.png?cb=23cb41be035cade5ec50454d78561935) ### 2b: Cluster Join To join a node to an existing SignServer database, provided you already have a database with an existing SignServer installation: 1. Select **Existing****SignServer****Database (cluster join)?** to join this node to an existing SignServer installation. 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++](https://keyfactor.atlassian.net/wiki/pages/createpage.action?spaceKey=ECD&title=EJBCA%20ECE%20on%20AWS%20CloudHSM%20Integration%20Guide) section regarding [++CloudHSM Liquidsec Key Conversion++](https://keyfactor.atlassian.net/wiki/pages/createpage.action?spaceKey=ECD&title=EJBCA%20and%20CloudHSM%20Integration%20Introduction). 2. 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. 3. 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](https://docs.keyfactor.com/signserver-cloud/latest/configure-via-signserver-cloud-configuration-wizar.md#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++](https://docs.keyfactor.com/signserver-cloud/latest/configure-via-signserver-cloud-configuration-wizar.md) or [++imported from an existing Management CA++](https://docs.keyfactor.com/signserver-cloud/latest/configure-via-signserver-cloud-configuration-wizar.md). ### 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](https://docs.keyfactor.com/signserver-cloud/latest/configure-via-signserver-cloud-configuration-wizar.md#UseExisting(Import)ManagementCA). The only required field when creating a new Management CA is the **Superadmin password** . For all available fields, see [ManagementCA Configuration Fields](https://docs.keyfactor.com/signserver-cloud/latest/configure-via-signserver-cloud-configuration-wizar.md#ManagementCAConfigurationFields). ![image2023-12-5_8-26-0.png](https://docs.keyfactor.com/__attachments/a_56fcd66baa93f80ae0b223a7f62ddacbf228ee0b09c7e4affb2d501d51a56152/image2023-12-5_8-26-0.png?cb=0fd968859ae8e1f037ec343eb2d77d8b) ### ManagementCA Configuration Fields The following lists available fields. 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: 1. Select **Use existing ManagementCA**. 2. Click **Browse** and select the public portion of the superadmin certificate from the existing Certificate Authority. 3. Enter the **Admin's Issuer Public Cert** for the user for which you have a keystore from this CA. ![image2023-12-5_8-28-56.png](https://docs.keyfactor.com/__attachments/a_e44ecf50af2f8a59c2843aae63021e6b84194e3cbe07b067a3e26394fcad9e26/image2023-12-5_8-28-56.png?cb=e30fc219e87d73847d8845772f5b91c6) Help with the Public Portion of Certificates: For help getting the public portion of a superadmin and superadmins issuers certificate, use a tool like [Keystore Explorer](https://keystore-explorer.org/). Keystore Explorer can easily extract these artifacts. Follow these steps: 1. Install and open Keystore Explorer. 2. Pick **Open an existing Keystore** and select your superadmin.p12 (or other SignServer administrator keystore). ![image2023-12-5_8-58-21.png](https://docs.keyfactor.com/__attachments/a_6c0a43c4f055323470a10c59fec508a3051b37756923582ce86d181ef71a350c/image2023-12-5_8-58-21.png?cb=3232caa33893702a39eb3679ec306d13) 3. Enter the password for the keystore to access its contents: ![image2023-12-5_9-0-3.png](https://docs.keyfactor.com/__attachments/a_ef1c7f50fbceb795b77a12da0702465d688c139c0e94e96ede5e5ab5fba4b4cd/image2023-12-5_9-0-3.png?cb=eb78743b49e5a12c466a585092651229) 4. Once you are in 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: ![image2023-12-5_9-1-42.png](https://docs.keyfactor.com/__attachments/a_a9fdd9caf9378ae6226148053d122735e8a1795e58d27b088616fc7ff9a25630/image2023-12-5_9-1-42.png?cb=e6e21cdb77c3e4c9ad34550e26e8a9da) 5. Click the administrator portion of the certificate (in this case, SuperAdmin) and select **Export**. 6. 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: ![image2023-12-5_9-7-51.png](https://docs.keyfactor.com/__attachments/a_56a2ed2a7c4438a27cf4ed4b7703b7cfeb9a69949a8129cccae62b95ef1824af/image2023-12-5_9-7-51.png?cb=b647116cf6b71f2eb4228ce2bcdb2dd8) 7. 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: ![image2023-12-5_9-53-30.png](https://docs.keyfactor.com/__attachments/a_7a8783ec4e51907cc67aacc48316c02a699d2e199049a89f64fae52a7982e381/image2023-12-5_9-53-30.png?cb=405b916a81cf3204a54529336ffe9134) 8. Add these to the Signserver Cloud Wizard: ![image2023-12-5_9-54-44.png](https://docs.keyfactor.com/__attachments/a_18b92319bb0089cd7a1c137b8efeacc2e49e9a736cd6ad756e63ab14f9e46c38/image2023-12-5_9-54-44.png?cb=63fe8523fe9bb4a6e263869211c197b7) 4. Click **Next** to continue to the Review and Submit page to review a summary of all settings. ## 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](https://doc.primekey.com/ejbca-cloud/ejbca-cloud-aws/aws-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. ![image2023-12-5_9-55-32.png](https://docs.keyfactor.com/__attachments/a_72ce2af1c4ceb7c7074403f756f4f1bd5ae90139509bf73104d5a2de09799df2/image2023-12-5_9-55-32.png?cb=14011c27a7e9b3353dd0d75f1f3a5346) ### 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](https://docs.aws.amazon.com/cloudhsm/latest/userguide/getting-started.html). | ## 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. ![image2022-12-1_17-50-9.png](https://docs.keyfactor.com/__attachments/a_fcb28c9cacc37cff3cc71a61920afe5654f2b0668a99aa5ad11161b22769dec1/image2022-12-1_17-50-9.png?cb=7084c987794402a074c421ff8618f730) Once you click **Submit**, a timer begins. At this point, your instance configuration with your chosen settings is starting. The page automatically refreshes and you can proceed to the next section. ![image2023-12-5_9-58-20.png](https://docs.keyfactor.com/__attachments/a_e87975515e404342805650a13154c06934f6d9f45b0a8821007ae356b4fcf785/image2023-12-5_9-58-20.png?cb=9851597d2878b652a31f0910f32c3fd8) --- version: "4.0" language: "en" --- # Configuring Automatic Generation and Key Renewal over Peers Configuration of Automatic Generation and Key Renewal over Peers is done in the following steps. ## SignServer Configuration The following steps create a PDF Signer that allows key and certificate renewal over the peer connection. This saves from having to pass around CSRs from SignServer to EJBCA when doing certificate renewals. To create the PDF Signer: 1. Access the SignServer Administration Web. 2. Click on **Workers** , click **Add** and then select **From Template**. ![image2018-7-31_16-45-39.png](https://docs.keyfactor.com/__attachments/a_393c77adbd6342c8acfb06feabb2fffcf286c771b323d76025ed7bfb9e43920e/image2018-7-31_16-45-39.png?cb=5e29f06adc288e760d5b31c99b5179b9) 3. In **Load from Template** , select **pdfsigner.properties** and click **Next**. ![image2018-7-31_16-45-57.png](https://docs.keyfactor.com/__attachments/a_2c9ea12bb6095cd9b4d2f8a70201f4d4d9e836f76250fa37b0d906056593d9cf/image2018-7-31_16-45-57.png?cb=31e8efcc8cd0eff65d08b6b1251a7335) 4. In the **Configuration,** comment out the line `WORKERGENID1.DEFAULTKEY=signer00003` since we want to use our own key, and click **Apply** . ![image2018-7-31_16-46-12.png](https://docs.keyfactor.com/__attachments/a_e3ba26f7288822ac46025e98b5fd4335914c65229fbb19547f46400c7687dd61/image2018-7-31_16-46-12.png?cb=6c28a785386f329fdebd7df04b47d301) 5. The **PDFSigner** worker is added with an "Inactive" state. Click the Worker to select it and then select the **Configuration** tab. ![image2018-7-31_16-46-27.png](https://docs.keyfactor.com/__attachments/a_46a3e0f2867ddba11321824e5677f319429b4f46a8da4983409ddadfc825f786/image2018-7-31_16-46-27.png?cb=b7dd1e6ad7e9e79b2556d180bc5cc73b) 6. Click **Add** and specify the following under **Add Property**: * **Name:** "PEERS_VISIBLE" * **Value:** "true" ![image2018-7-31_16-46-50.png](/__attachments/a_b8b61f7415887bbf8d01d927733ae509f2898ab8c383c066e532a3d9bf2fee76/image2018-7-31_16-46-50.png?cb=87de5dbe9edba8931985acb47fac219e) 7. Click **Submit** to add the property tothe configuration. 8. Click **back** onto the worker to select it and then click **Renew key**. ![image2018-7-31_16-47-14.png](https://docs.keyfactor.com/__attachments/a_95fce3f029aab9d8bd946147e013963b416d5ec49390d9d4fcbf65bdf5b69fe4/image2018-7-31_16-47-14.png?cb=3a9f0cf2879d2855040586af710f4a81) 9. Under **Renew Keys,** enter the following details: * **Key Algorithm:** "RSA" * **Key Specification:** "2048" * **New Key Alias:** "PDFSignKey0001" ![image2018-7-31_16-47-30.png](/__attachments/a_3d620343271361a9495a137f1b603c2fe019267cf5383928224918fce82a734d/image2018-7-31_16-47-30.png?cb=7f7b5074c8c14986ea8b2da04fddd826) 10. Click **Generate**. ## EJBCA Configuration Configure EJBCA according to the following: 1. Access the Administration GUI for EJBCA. 2. Select **Certificate Profiles** under **CA Functions** and add a profile called "**PDF Signer Certificate Profile**: ![image2018-7-31_16-48-16.png](https://docs.keyfactor.com/__attachments/a_2e3ef296612b445313a6ef66f110bf70ae9bbe43e667ab067688e2d6f81ef60b/image2018-7-31_16-48-16.png?cb=3b729bc64c9fbe54b5198f4a6f6c8d0a) 3. Click **Edit** on the Certificate Profile once added, specify the following attributes and click **Save:** * **Available Key Algorithms**: RSA * **Available Bit Lengths**: 2048 * **Validity or end date of the certificate**: 5y * **Extended Key Usage**: PDF Signing 4. Under **RA Functions** , click **End Entity Profiles**. 5. Enter a name for a new profile in the **Add Profile Field** such as **PDF Signer EE Profile** , and click **Add**. ![image2018-7-31_16-48-26.png](https://docs.keyfactor.com/__attachments/a_5740e2db6843d1e0182654e9e34d700dad24b65f6be5c887fb2d03684ff1714b/image2018-7-31_16-48-26.png?cb=f17b847c89a2450908e888b095ccb5dd) 6. Select the **PDF Signer EE Profile** and click **Edit End Entity Profile**. 7. Within the profile, select the following values and click **Save**: * **Default Certificate Profile:** PDF Signer Certificate Profile * **Available Certificate Profiles:** PDF Signer Certificate Profile 8. Select the **SignServer Peer EE Profile** and click **Edit End Entity Profile**. 9. Within the profile select the following values: * **Default Certificate Profile**: PDF Signer Certificate Profile * **Available Certificate Profiles**: PDF Signer Certificate Profile * **Default CA:** ManagementCA * **Available CAs:** ManagementCA * **Default Token:** User Generated * **Available Tokens:** All ![image2018-7-31_16-49-8.png](https://docs.keyfactor.com/__attachments/a_278e63b05e232576c947b62a508310d400c5248083be829afa9d51d737a2cca0/image2018-7-31_16-49-8.png?cb=c5a44054bf8b7206c1e3eed331952aff) ## Create the End Entity on EJBCA To create the End Entity on EJBCA: 1. In the EJBCA Admin Web, select **Add End Entity** under the **RA Functions** section. 2. Specify the following for the End Entity and then click A**d**d. * **End Entity Profil**e: PDF Signer EE Profile * **Username:** PDFSigner * **Password:** \ * **CN, Common name** : "PDFSigner" ![warning](https://docs.keyfactor.com/__attachments/a_d0ce636f65f6429b87590440b0897ecd5c7af09427324b6e417cce97782c3b10/atlassian-warning?cb=14432459925d605e05cae2605cdfe666) must match the worker name in SignServer * **Certificate Profile:** PDF Signer Certificate Profile ![image2018-7-31_16-49-40.png](/__attachments/a_5691cc6cea3681886eaf0ac1da3eef35a47baebc4e3a40a5ea70630d548dfdee/image2018-7-31_16-49-40.png?cb=023653bdf53e2e42dd7ecb2e60ec3fd0) 3. Select **Peer Systems** under **System Functions**. 4. Click **Manage** on the **Peer Connection to SignServer** and select the **Remote Key Bindings** tab. The **Remote name** of **PDFSigner** and the **Remote key pair** value of **PDSSignKey0001** should be populated already if the configuration was done correctly. In **Local end entity** enter **PDFSigner**: ![image2018-7-31_16-49-53.png](https://docs.keyfactor.com/__attachments/a_ca153109a3a6795b2eeae1841e92c760865fa6e06a95f69c89fc9c295a9d6201/image2018-7-31_16-49-53.png?cb=be63edcebfc390ee67e6d9da008b7269) 5. Click **Issue signing certificate**. The certificate details will now show with a certificate serial number bound to the binding: ![image2018-7-31_16-50-8.png](https://docs.keyfactor.com/__attachments/a_44dcff3f724385e0a2e61ca3401bd073ac8823c226d52fbd1d836832fc8b353e/image2018-7-31_16-50-8.png?cb=dc8721f854af2d3342dba14557e7236c) 6. Go to the SignServer Admin Web, select the**Workers** tab and check that the PDFSigner worker now is active. ![image2018-7-31_16-50-22.png](https://docs.keyfactor.com/__attachments/a_b5e299555def6fdf1b7b9c5b0dba040761cfe1bb0d9b32f72fb7fc9d728d8962/image2018-7-31_16-50-22.png?cb=22c7f34088a5f405b9897670c3c7034f) --- version: "4.0" language: "en" --- # Copying Backup Files to Other Systems ## Copying File to Local Workstation Using either the command line interface (CLI) or a Secure Copy Protocol (SCP) utility, copy the file to your local system. You can copy the file directly from one instance to another if your VPC allows it. In this example, we will bring the file down locally and then SCP it to the new instance. 1. Using the CLI: # scp -i ~/Documents/C2\ Comp/PrimeKey/EC2\ Creds/c2-ssh/c2-ssh.pem ec2-user@ec2-34-229-187-81.compute-1.amazonaws.com:/home/ec2-user/signserver_db-ip-172-16-0-128.ec2.internal-1509663778.tar.gz ~/Downloads/signserver_db-ip-172-16-0-128.ec2.internal-1509663778.tar.gz 2. Using a SCP utility (in this case Cyberduck): 1. Specify details to connect to your instance, for example hostname, username, and SSH key: ![Copy Backup to New Instance2.png](/__attachments/a_3f8830fac8cddc6ec28fca0e31642a74bc3841517a4b6472d5a621f1818023cd/Copy%20Backup%20to%20New%20Instance2.png?cb=cc621713d544eff81e142d2e998ba78c) 2. Connect to the instance and download the file to the local system: ![Copy Backup to New Instance3.png](/__attachments/a_9532311f894ba6925116f66cdddcf84cc49a72c41553b419f8b8b69298a7a483/Copy%20Backup%20to%20New%20Instance3.png?cb=74526e00692351b80d721d124d181e43) 3. Wait for the download to complete. ## Copy Backup File to Another Instance 1. SCP the backup file to another instance using the following CLI command: # scp -i ~/Documents/C2\ Comp/PrimeKey/EC2\ Creds/c2-ssh/c2-ssh.pem ~/Downloads/signserver_db-ip-172-16-0-128.ec2.internal-1509663778.tar.gz ec2-user@ec2-52-23-217-245.compute-1.amazonaws.com:/home/ec2-user/ 2. Once the backup file is copied, SSH into the new host and verify that the file was copied correctly. --- version: "4.0" language: "en" --- # Create a CloudHSM Cluster AWS CloudHSM provides Hardware Security Modules (HSMs) in a cluster, a collection of individual HSMs that AWS CloudHSM keeps in sync. When you create a cluster, you specify an Amazon Virtual Private Cloud (VPC) and a Subnet in the Availability Zone (AZ) of your instance. You then create an HSM in your cluster, selecting an Availability Zone (AZ) for the creation of the HSM. Follow the steps below to create a cluster and an HSM: 1. Navigate to the AWS CloudHSM console on [https://console.aws.amazon.com/cloudhsm.](https://console.aws.amazon.com/cloudhsm) 2. Click **Create Cluster**. 3. In the **Cluster configuration** section, select the **VPC** and Subnet in the Availability Zone (AZ) of your SignServer Instance: ![image2018-9-6_12-39-11.png](https://docs.keyfactor.com/__attachments/a_1d58d0e17e31c47e89236b0aeeaecc8743349feed2e5abb2f3ab1ccdc0dd0e13/image2018-9-6_12-39-11.png?cb=7bc4ea5c7364bd526c8ecf3238fc65eb) 4. Wait for the cluster creation process to complete: ![image2018-9-6_12-39-43.png](https://docs.keyfactor.com/__attachments/a_32b62891b3705826d830022052064dda5ea9023843efb537217d6ec1bedd6374/image2018-9-6_12-39-43.png?cb=ad4e42812fc474bc58c6200cd8a89b6e) 5. Once its completed, the cluster will be in an Uninitialized state. Click **Initialize**. ![image2018-9-6_12-40-6.png](https://docs.keyfactor.com/__attachments/a_fd75cdb2810d76c9db9498e280885f33a982bcc58f6941409843901c5dcc9fa0/image2018-9-6_12-40-6.png?cb=8fa29fc6ab796250ed39fe95297f8f07) 6. Choose an **Availability Zone (AZ)** to create the HSM in: ![image2018-9-6_12-40-23.png](https://docs.keyfactor.com/__attachments/a_a2b0671cba64a1af26b3241bd26bfee8aa383424f879842ab915b1cae266fc8f/image2018-9-6_12-40-23.png?cb=5eea6013081b0dd0905530dcc50003d9) 7. Click Create and wait for the HSM to be created. Click refresh ![image2018-9-12_16-3-31.png](https://docs.keyfactor.com/__attachments/a_8e381a0a087066f4315e6c3084ad47f3b47e30d5689701751a3ddd281345fa3f/image2018-9-12_16-3-31.png?cb=6f9a3f77f927716b230ca71ffdf5953b) after a few minutes. ![image2018-9-6_12-40-45.png](https://docs.keyfactor.com/__attachments/a_143c4a897f111a3c2179356424e1982f161bc9f00965aec8ae65f41c19482d40/image2018-9-6_12-40-45.png?cb=f6b369cba9b591c207da69eccf3904a8) 8. Once completed, the wizard will show you the HSM created and allow you to continue by clicking **Next**: ![image2018-9-6_12-40-55.png](https://docs.keyfactor.com/__attachments/a_1ebad904a84c4160b6ead61ba106d8785666e5df2c6ece227f95c16c62fa09ec/image2018-9-6_12-40-55.png?cb=e70d47513207232119fcc5dfdce2cea6) 9. Links appear to Download a certificate signing request (CSR) from the HSM Cluster to authenticate it. ![image2018-9-6_12-41-8.png](https://docs.keyfactor.com/__attachments/a_9f1e382333453be8050e180e4e34eef807531a3b45eb4eb86ce1b09218c79269/image2018-9-6_12-41-8.png?cb=b73b366cf7629dc21709683628937d78) 10. The certificates are used in the next step, see [Use OpenSSL to Validate the HSM](https://docs.keyfactor.com/signserver-cloud/latest/use-openssl-to-validate-the-hsm.md). --- version: "4.0" language: "en" --- # Create a CloudHSM Crypto User - SDK3 To create a CloudHSM crypto user, do the following: 1. Login as the CO admin: aws-cloudhsm> login CO admin 2. Create a signserver crypto user: aws-cloudhsm> createUser CU signserver 3. Use `listUsers` to see all users: aws-cloudhsm> listUsers aws-cloudhsm>listUsers Users on server 0(172.16.2.59): Number of users found:2 User Id User Type User Name MofnPubKey LoginFailureCnt 2FA 1 CO admin NO 0 NO 2 CU signserver NO 0 NO 4. Quit the client utility: aws-cloudhsm> quit For more detailed user management, refer to the AWS CloudHSM documentation[Managing HSM Users in AWS CloudHSM](https://docs.aws.amazon.com/cloudhsm/latest/userguide/manage-hsm-users.html). --- version: "4.0" language: "en" --- # Create a CloudHSM Crypto User - SDK5 To create a CloudHSM crypto user, do the following: 1. Set some environment variables so the CLI can be used without interactive mode: export CLOUDHSM_ROLE=admin export CLOUDHSM_PIN=admin: 2. Create users to create keys. Each user can access and use only its own keys. Here is an exmaple where we create three users that can only see the keys of the CA they own. Best practice is to not use the password flag on the CLI. This is shown for example purposes for scripting needs. # /opt/cloudhsm/bin/cloudhsm-cli user create --username ejbca_root --role crypto-user --password # /opt/cloudhsm/bin/cloudhsm-cli user create --username ejbca_issuing --role crypto-user --password # /opt/cloudhsm/bin/cloudhsm-cli user create --username ejbca_managementca --role crypto-user --password 3. For more detailed user management, refer to the AWS CloudHSM documentation[Managing HSM Users in AWS CloudHSM](https://docs.aws.amazon.com/cloudhsm/latest/userguide/manage-hsm-users.html). --- version: "4.0" language: "en" --- # Create a P11NG CryptoToken in SignServer with SDK5 To create a P11NG CryptoToken: 1. Click the **Add** link to create a new worker in SignServer. ![image-20240923-212025.png](https://docs.keyfactor.com/__attachments/a_126548180750ec59c5c055a3df4f86ad323457d0235190dfb22540be78df4141/image-20240923-212025.png?cb=4685be22c0269514f5fc0ded90a17018) 2. Select **From Template** and select the cloudhsm-p11ng.properties template. ![image-20240923-212101.png](https://docs.keyfactor.com/__attachments/a_4806a482e34c06918abc35a74cf0a516167e335b6bfe60629cf04a38438dd979/image-20240923-212101.png?cb=ee751a4d242271a0baf54b75af9a3c15) 3. Click **Next**. 4. Edit the following values for your cluster: * WORKER4.PIN=CUNAME:PASSWORD * WORKER4.SLOTLABELVALUE=hsm1 * WORKER4.SLOTLABELTYPE=SLOT_LABEL If you don't have a key named testkey0001 on your HSM, edit the DEFAULTKEY value to be one that is on your HSM. The key is required to be present for the Crypto Token to activate: `WORKER4.DEFAULTKEY=myKey1` 5. Select the Status Summary tab and it should now show the Crypto Token as Active: ![image-20240923-211751.png](https://docs.keyfactor.com/__attachments/a_f2a418a1aacb91046155e8a63180e2da579d74948a7ed582d9786a2f3211726b/image-20240923-211751.png?cb=9409e021309c4a067ff420da218a65ce) 6. Click the Crypto Token tab and ensure all of the keys are displayed. 7. Select one of the keys, and click **Test**. 8. Click **Test** again and ensure the key is usable by SignServer: ![image-20240923-211910.png](https://docs.keyfactor.com/__attachments/a_5764af6ae64174d446663883e28bd8702d861a8e94cc68669dc78addb3b23d61/image-20240923-211910.png?cb=d4441eea920997fd26e91561a5827e88) --- version: "4.0" language: "en" --- # Create a CryptoToken in SignServer with SDK3 If you have already performed these steps before creating the keys with the clientToolBox, restart SignServer using the command: `service wildfly restart` If you are creating the crypto token for the first time, proceed with the following steps: 1. Login to SignServer as Superadmin. 2. Select **Add** under **All Workers**: ![image2018-12-3_13-54-20.png](https://docs.keyfactor.com/__attachments/a_62d5f6b6e1fdb8161d06eb340a7075cf7f89fd9ed7a64812b0a9fc75f71201b7/image2018-12-3_13-54-20.png?cb=d822d9395d545bc09fe2b13147f7bc49) 3. Select **From Template**. ![image2018-12-3_13-55-16.png](https://docs.keyfactor.com/__attachments/a_d794f3b06a4c20918eb7fc3dfc223626e9bf71427e0bc8900396c0edb27bcc6f/image2018-12-3_13-55-16.png?cb=3844f69cc9d508ab8f35ff19863fdd4a) 4. Select the **cloudHSM-p11ng.properties** template and click **Next.** ![image2018-12-3_13-56-26.png](https://docs.keyfactor.com/__attachments/a_8d8f6ca73276ba8b97f2d07d28aa4ce9bbcda9c2abbbf9a89de87d2b7c7bc0c5/image2018-12-3_13-56-26.png?cb=5645079bd80bdda5b230f3e74b068303) 5. Specify the values as follows (Changing the values in **bold**as required): * WORKER3.IMPLEMENTATION_CLASS=org.signserver.server.signers.CryptoWorker * WORKER3.NAME=CryptoTokenP11 * WORKER3.PIN=**CryptoUser:CUPassword123!** * WORKER3.CRYPTOTOKEN_IMPLEMENTATION_CLASS=org.signserver.server.cryptotokens.PKCS11CryptoToken * WORKER3.DEFAULTKEY=**testKey0001** * WORKER3.SLOTLABELVALUE=1 * WORKER3.TYPE=CRYPTO_WORKER * WORKER3.SHAREDLIBRARYNAME=AWSCloudHSM * WORKER3.SLOTLABELTYPE=SLOT_NUMBER ![image2018-12-3_14-0-20.png](https://docs.keyfactor.com/__attachments/a_8ec63df3cd182e51dd08037ef42345f89f1c034d0a4c8d74ca77eb8ee91af9e8/image2018-12-3_14-0-20.png?cb=655d8f8a7e336f1bf27e3733fd339f28) 6. Click **Apply**. 7. The worker comes back as active. ![image2018-12-3_14-7-28.png](https://docs.keyfactor.com/__attachments/a_7b484438a8819efcd77574460821a7ee956144115045ad06bf6c69833a7109b6/image2018-12-3_14-7-28.png?cb=6cb409c44a0150b8e260c2e4c12dfa90) 8. To see what keys are active in the crypto token that SignServer can see, select the **CryptoTokenP11** worker. ![image2018-12-3_14-3-51.png](https://docs.keyfactor.com/__attachments/a_d480b644c2d27e3637aeb217e0882f1357c011b5f48a92b2e963d04db263851a/image2018-12-3_14-3-51.png?cb=3ad16dce2aba8f4521b8f77d8c1f1305) 9. Select the **Crypto Token** link ![image2018-12-3_14-10-29.png](https://docs.keyfactor.com/__attachments/a_7c82934e65550320c19ab9a1605d33e8bcccbaeddefa76b32818ad00e7b109fb/image2018-12-3_14-10-29.png?cb=7aadfd7ace182b5e66a2eadd0612fa68) 10. The keys are displayed inside the Crypto Token. ![image2018-12-3_14-23-41.png](/__attachments/a_2d6f121b426ae50009567f427cf6f59de40587005df6e4512ac9a2c05cc4bf39/image2018-12-3_14-23-41.png?cb=02bbd3825474f60ffc167270313c4bac) --- version: "4.0" language: "en" --- # Create Keystore in HSM with ClientToolBox To create a keystore in the HSM using clientToolBox, do the following: 1. A utility called clientToolBox is included with your SignServer Cloud instance. The clientToolBox utility is usually provided with EJBCA, but has been preloaded onto your SignServer ECE instance for ease. Create a key called **testkey** with clientToolBox. SignServer uses this key for healthcheck and keepalive to the HSM. ![warning](https://docs.keyfactor.com/__attachments/a_d0ce636f65f6429b87590440b0897ecd5c7af09427324b6e417cce97782c3b10/atlassian-warning?cb=14432459925d605e05cae2605cdfe666) It is important to run these commands as the Wildfly user. This is due to file system access permissions and maintaining the permissions for wildfly to be able to use these keys. # su - wildfly # /opt/PrimeKey/clientToolBox/ejbcaClientToolBox.sh PKCS11HSMKeyTool generate /opt/PrimeKey/cloudhsm/p11.conf 2048 testKey0001 2. You are prompted for a password in the format of `:` For example, the following is the PKCS #11 PIN for an [HSM crypto user (CU)](https://docs.aws.amazon.com/cloudhsm/latest/userguide/hsm-users.html) with user name **CryptoUser** and password**CUPassword123!**: CryptoUser:CUPassword123! 3. Create one more keys called **signKey** with the following command: # /opt/PrimeKey/clientToolBox/ejbcaClientToolBox.sh PKCS11HSMKeyTool generate /opt/PrimeKey/cloudhsm/p11.conf 4096 signKey0001 --- version: "4.0" language: "en" --- # Creating an App Registration in Active Directory The following shows you how to add and register an application using **App registrations** in the Azure portal and then how to generate a secret (password), needed when obtaining tokens. ## Registering the App in Active Directory and Generating Secret 1. Log in and access your Azure portal at [https://portal.azure.com.](https://portal.azure.com/) 2. Select the **Azure Active Directory** service in the left-hand navigation pane, and then select **App registrations \> New registration**. ![NewRegistration.png](https://docs.keyfactor.com/__attachments/a_fdb365e1fb6257deb844f061966df2f011cd84dcbd6f996b3f07c2bff9151f6c/NewRegistration.png?cb=882e92b217866bf6236dd526a1dc4fbd) 3. Specify an app name (that will be displayed to users of the app), for example "signserver-vault", and then click **Register.** Azure AD assigns a unique application (client) ID to your app and displays your application's **Overview** page. 4. On the **Overview** page, make a note of the **Application (client) ID** . This value will be required in SignServer when creating a **Crypto Token**. ![image2020-4-27_11-26-59.png](https://docs.keyfactor.com/__attachments/a_073ca9d4fc02fd87cf780b228bf2b9b8fffab7c4bf034c5b58598ced84c5cf6a/image2020-4-27_11-26-59.png?cb=f9ae5278eea167f4c1e019e68b0b85d0) 5. Click **Certificates \& secrets**to add a secret (password). 6. Click **New client secret** in the **Client secrets** section. 7. Enter a name for the secret, such as "signserver-vault-access". Set the expiration if desired. In this example, the expiration is set to **Never** expire to allow the CA to always have access to the keys in the HSM. Click **Add** once done. ![image2020-4-27_11-27-57.png](https://docs.keyfactor.com/__attachments/a_948c91da237cb278dc63edfafa0b72beb0b03578b20a4b9464edfed7defda93b/image2020-4-27_11-27-57.png?cb=1c20ed8aefb4e64f435fbae2e5a498dc) 8. A secret is generated and displayed. Note this secret down in a password manager such as Last Pass as it will only be displayed once in the portal. The secret will also be required in SignServer when creating a **Crypto Token** in the later step [Creating an Azure Key Vault Crypto Token in SignServer](https://docs.keyfactor.com/signserver-cloud/latest/creating-an-azure-key-vault-crypto-token-in-signse.md). ![image2020-4-27_11-29-9.png](https://docs.keyfactor.com/__attachments/a_38eef59aa86fa5578ed775b60cf39364215f02dbe5ffbfec98ff1689667330f7/image2020-4-27_11-29-9.png?cb=ffbbe346f365c54c3d58cb3922690cfe) Next, continue with [Creating the Azure Key Vault](https://docs.keyfactor.com/signserver-cloud/latest/creating-an-azure-key-vault.md). --- version: "4.0" language: "en" --- # Creating an Azure Key Vault The following shows how to create the Azure Key Vault. 1. Search for Key Vault in the Azure portal and then select **Key vaults** in the results. ![Search.png](https://docs.keyfactor.com/__attachments/a_8900a109f0094ffe5d677c7f853e838b56dd634fc117fbeaa4177f3a547f4d32/Search.png?cb=88a9b2a64da37f9999de303c0242d084) 2. Click **Add.** 3. In the Create key vault section, enter the name for the Key Vault. In this example, create a SignServer Crypto Token vault for SignServer and use the name **SignServerKeyVault**. Note the name down since it will be required in SignServer when creating a Crypto Token. 4. Specify the same **Resource Group** that the SignServer Instance uses. ![image2020-4-27_12-15-35.png](https://docs.keyfactor.com/__attachments/a_a2438568b6052aaf07866f40c90dbf270e5edf9c55d44db863803452a00797b2/image2020-4-27_12-15-35.png?cb=8133680f62d0be6cc03fba600e112e93) 5. Under **Pricing tier** , there are two options, **Standard** and **Premium.** It is recommended to choose **Premium** and then click **Select**. ![image2020-4-27_11-56-37.png](https://docs.keyfactor.com/__attachments/a_600e1dafd859ee39abd85e0aa9b77f483bc10388f647bf38506ff9fce2510521/image2020-4-27_11-56-37.png?cb=7829b05610770db363dd153c70af80af) 6. Click **Next** to create an **Access Policy** from the Create Key Vault dialog, and then click **Add** **Access Policy**. ![image2020-4-27_11-58-1.png](https://docs.keyfactor.com/__attachments/a_5563270cf578d36ab34177e3d630a6f82005d6e6a04463b228019719886e5bf9/image2020-4-27_11-58-1.png?cb=0f9fdd7e868fe1526cf142a0ac7e17ad) 7. Select **Key Management** from the **Configure from template** list. 8. Select **Key Permissions**. 9. Select all of the permissions under **Cryptographic Operations**. ![image2020-4-27_12-16-34.png](https://docs.keyfactor.com/__attachments/a_63d96de74e429367873703ffa5f8171a1201253e4075cbbd38a0f5b9696127fe/image2020-4-27_12-16-34.png?cb=ff580433bf047b427ad3ea8673f064de) 10. Click **Select Principal**. ![image2020-4-27_12-2-24.png](/__attachments/a_1681605924c47e7cc1c7eae171f7d22982d140df9be286f78e2ab7aca3c5e4bf/image2020-4-27_12-2-24.png?cb=2480a7c62093a6cdc6cb7d24c5c50cc1) 11. Search for the App Registration added in the previous section [Creating an App Registration in Active Directory](https://docs.keyfactor.com/signserver-cloud/latest/creating-an-app-registration-in-active-directory.md). In this example, select the name "signserver-vault" and click **Select**. ![image2020-4-27_11-59-35.png](/__attachments/a_990fb85495662c1177d01a917f9100fdbeaf83bf897aae0c687edb7e1145bba8/image2020-4-27_11-59-35.png?cb=e1a3176b431e9656bf7af1c51f263f82) 12. Click **Add** on the **Add access policy** screen. 13. Click **OK** on the **Access policies** screen. 14. Click **Next** to configure Networking the **Virtual Network Access** section. 15. Select **Public endpoint**. ![image2020-4-27_12-7-49.png](/__attachments/a_b978a5a9d8a38024d916b49fcad0cbb898468028bbb24bce9556f39cbd62f6ff/image2020-4-27_12-7-49.png?cb=9e8f7bdec67519d955995e11af624d53) 16. Click **Add existing virtual networks**. 17. From the **Add networks** list, select the virtual network in the resource group that SignServer Cloud was deployed into. In this example, **SignServer_With_KeyVault**. ![image2020-4-27_12-10-10.png](/__attachments/a_b591d99370361467bdfdbff6037006cafc8dd726a69abc808262926d9ee95c3c/image2020-4-27_12-10-10.png?cb=5d644e7086e7779030e378f80702547d) 18. Click **Select All** under **Subnets** . Click **Enable**and wait for Azure to enable the service endpoint. ![image2020-4-27_12-10-38.png](/__attachments/a_50f910f8297619a0614bf9bdebccd794f48f89ac3f747a02695b9485af4a738d/image2020-4-27_12-10-38.png?cb=3837ae06d4fadc9188f4e8ae384891de) 19. Once completed, click **Add**. 20. Click **Next** to assign any Tags if desired. 21. Click **Next** to Review the configuration. ![image2020-4-27_12-13-40.png](/__attachments/a_d6527f173e321727b58557d14c707e37db09f001f8a1aa1681d696fb2785e7ac/image2020-4-27_12-13-40.png?cb=684e845ec6f9bca25c731424ec1697c3) 22. Click **Create** and wait for the deployment to complete. 23. Once the deployment completes, proceed to the next section to [view Keys in Key Vault](https://docs.keyfactor.com/signserver-cloud/latest/viewing-keys-in-key-vault.md). --- version: "4.0" language: "en" --- # Creating an Azure Key Vault Crypto Token in SignServer The following provides instructions for creating an Azure Key Vault Crypto Token in SignServer and how to manually activate the newly created Crypto Token if required. ## Configuring Crypto Token To create an Azure Key Vault Crypto Token in SignServer, do the following: 1. Select the SignServer AdminWeb **Workers** tab, and click **Add**. 2. Click **From Template** , select the **azurekeyvault-crypto.properties** template in the list, and click **Next**. 3. Change the following properties to the values that reflect your key vault. 1. **WORKERGENID1.KEY_VAULT_NAME:** In this example, **SignServerKeyVault** as specified when [Creating an Azure Key Vault](https://docs.keyfactor.com/signserver-cloud/latest/creating-an-azure-key-vault.md). 2. **WORKERGENID1.KEY_VAULT_CLIENT_ID:** The **Application (client) ID** as noted down from the Overview page when [creating the App Registration](https://docs.keyfactor.com/signserver-cloud/latest/creating-an-app-registration-in-active-directory.md). 3. **WORKERGENID1.KEY_VAULT_TYPE:** As selected when when [Creating an Azure Key Vault](https://docs.keyfactor.com/signserver-cloud/latest/creating-an-azure-key-vault.md), for example, **Premium.** 4. **WORKERGENID1.PIN:** The client secret generated during the [App Registration](https://docs.keyfactor.com/signserver-cloud/latest/creating-an-app-registration-in-active-directory.md) step. Uncomment this row and add the client secret **signserver-vault-access** value if you want the Crypto Token to auto-activate. To activate the token manually, see [Creating an Azure Key Vault Crypto Token in SignServer#Manually Activating Crypto Token](https://docs.keyfactor.com/signserver-cloud/latest/creating-an-azure-key-vault-crypto-token-in-signse.md#CreatinganAzureKeyVaultCryptoTokeninSignServer-ManuallyActivatingCryptoToken). 5. **WORKERGENID1.DEFAULTKEY:** The name of the first key that SignServer uses to activate the Crypto Token. The key can be created in the Azure Key Vault user interface according to the previous step [Creating First Key for SignServer](https://docs.keyfactor.com/signserver-cloud/latest/creating-first-key-for-signserver.md). 4. Click **Apply** to add the Crypto Token. 5. The Crypto Token is displayed in the list as **Active** if the client secret was added as the PIN in the previous step. ![image2020-4-27_13-52-41.png](https://docs.keyfactor.com/__attachments/a_8433047c5181748ffd02c21abf6ea5b0eb11056a47ba9e7312fead7c2a419147/image2020-4-27_13-52-41.png?cb=82bd5b45c40711043d2f1831071338f6) ## Manually Activating Crypto Token If the configured Crypto Token is not activated, do the following to manually activate the token: 1. Select the newly created Crypto Token Azure Key Vault. 2. Click the **Crypto Token** tab. ![image2020-4-27_13-57-11.png](https://docs.keyfactor.com/__attachments/a_7644a234aaed0fbbec91a490e50f001acf5c9b10d2d35a2a4d667cc21ae68e41/image2020-4-27_13-57-11.png?cb=3ab57ba75635c0551ccc9f0930a9c235) 3. Click **Activate** and add the client secret generated during the [App Registration](https://docs.keyfactor.com/signserver-cloud/latest/creating-an-app-registration-in-active-directory.md) step. ![image2020-4-27_13-55-5.png](https://docs.keyfactor.com/__attachments/a_d4c8811dd0cac7d5cf81531f140324960a6ebd98c399050e1e6cef91106154b0/image2020-4-27_13-55-5.png?cb=461cd6b8f82f1456278c3547e675a2c4) 4. Click **Activate** to activate the Crypto Token. --- version: "4.0" language: "en" --- # Creating First Key for SignServer In order for a CryptoToken to activate in SignServer it requires the ability to see a default key in the CryptoToken. Perform the steps below to create a test key that SignServer can use to activate the Crypto Token. To create a first test key for SignServer: 1. Click **Keys** in the Azure Key Vault created to be used with SignServer, in this example **SignServerKeyVault** (created in the [Creating an Azure Key Vault](https://docs.keyfactor.com/signserver-cloud/latest/creating-an-azure-key-vault.md) step). ![image2020-4-27_13-16-41.png](https://docs.keyfactor.com/__attachments/a_a81f39d89eeb56af81da8e61523e8bd6e44b286e12a1dc15a36eb7d2973ff7b7/image2020-4-27_13-16-41.png?cb=c875bc68d988934b9aa95c2e2f012416) 2. Click **Generate/Import**. 3. Specify the following and then click **Create:** 4. The default key **Name** defined in the CryptoToken of SignServer will be "testkey0" but any key name can be used. 5. Select **RSA** for the **KeyType** 6. Select **2048** for the **RSA Key Size**. ![image2020-4-27_13-18-30.png](https://docs.keyfactor.com/__attachments/a_267a4a47b0ae0ef641e1d238f209d58c915cad345b566da3a721bc1f4479ad96/image2020-4-27_13-18-30.png?cb=51e7bf0ed081b470d3084d9624e34460) 7. The key is created and displayed in the list. ![image-20250922-095018.png](https://docs.keyfactor.com/__attachments/a_2238735ba4ebaf669e40a09b3ed54b65e0b1e875cd88baf274b8076c98f09132/image-20250922-095018.png?cb=e15f551b487174c608f9a0ede37c6426) Next, continue to [Creating an Azure Key Vault Crypto Token in SignServer](https://docs.keyfactor.com/signserver-cloud/latest/creating-an-azure-key-vault-crypto-token-in-signse.md) for instructions on configuring an Azure Key Vault Crypto Token. --- version: "4.0" language: "en" --- # Creating the Peer Connection To create the Peer Connection: 1. Select **Peer Systems** under **System Functions** and make sure that the**Allow outgoing connections** option is selected. ![image2018-7-31_16-38-20.png](https://docs.keyfactor.com/__attachments/a_55775f2950edb770513c1627537ab63ef4791829925469c816fbc03c72382a6a/image2018-7-31_16-38-20.png?cb=e22f01f0f338d4a63ee1b76f8ebb5e72) 2. Click **Add** and specify the following in the **Create Peer Connector** screen: Name: **Peer Connection to SignServer** URL: **https://ip-172-16-2-98.ec2.internal/signserver/peer/v1** Note This will be the internal DNS name for your SignServer instance. Authentication Key Binding: **Peer System Key Binding to SignServer** Enabled: **Selected** ![image2018-7-31_16-40-11.png](https://docs.keyfactor.com/__attachments/a_701e48d610990f9dbb262fdf90b27a9915ba0bc60f4627ee687dfb91243417f4/image2018-7-31_16-40-11.png?cb=f9149d44388023e1de61ad2d1f97b91a) 3. Click **Create**. 4. Click **Ping** . You should get an error that says: "*Unable to connect to peer. Unauthorized*". This "error" is expected because we have not yet allowed the connection on the SignServer side. ![image2018-7-31_16-40-48.png](https://docs.keyfactor.com/__attachments/a_67589a5fbbefdd77f0f86cd7d3bc03d67e69fb2b286372348c239374408d2731/image2018-7-31_16-40-48.png?cb=c5f3fd2d54f6c1998a353bca0584ac0c) --- version: "4.0" language: "en" --- # Deleting old Backup Files To automatically delete old backup files and keep the drive from filling up, run the `system_backup.sh` script with the `--delete-files` option and give it a numerical value: # /opt/PrimeKey/support/system_backup.sh --delete-files 10 --- version: "4.0" language: "en" --- # EJBCA/SignServer Peering Security Groups EJBCA to SignServer Peering uses port 443 (SSL/TLS) for communication. This connection is initiated from the EJBCA server to the SignServer node and needs to only go one way but allow return communication. 1. Create a security group that allows for TLS traffic within the VPCs. In this example, the VPC internal address space is **172.16.0.0/16** in US-East-1. Create a Security Group called **Allow All TLS Traffic** with the following rules: ![image2018-7-31_16-20-47.png](https://docs.keyfactor.com/__attachments/a_a005af6c25096e230fbc17205bacba0a3be7837d59a3c37e932be50cf7b1c503/image2018-7-31_16-20-47.png?cb=532ddc186e753818cc1a94b58c3a29b4) ![image2018-7-31_16-20-57.png](https://docs.keyfactor.com/__attachments/a_d32f7065e27fd0faa772db01c15865a3aaed6f096b6a96e337489e393be0fcb6/image2018-7-31_16-20-57.png?cb=dfab37688aaabf4e23b21f8c0507f86d) This allows any connections outbound to any address and any inbound connection on port 443 from any address on the 172.16.0.0/16 subnet. The same rule in the other VPC will also need the same rule configured. These rules may be tightened as required for the organization. 2. Apply these Security Groups to the EJBCA Cloud and SignServer Cloud Nodes in each of the VPCs. Right-click the node, select**Networking** and then **Change Security Groups**: ![image2018-7-31_16-21-6.png](https://docs.keyfactor.com/__attachments/a_13a7c74f0135a8e8cd11443caf4641b6d21316907c04fc845057c73fb17496df/image2018-7-31_16-21-6.png?cb=bb573e62ddf84d84a94734f6163797dd) 3. Apply the security group to the instances so that they can communicate with each other: ![image2018-7-31_16-21-52.png](https://docs.keyfactor.com/__attachments/a_b9c6d52ab06d5be12743cd617706db84902b051b87c528dbcab7cbf5656b0d2d/image2018-7-31_16-21-52.png?cb=6c1c5bb4ed71983850ba5344a64d4a2b) 4. In the node details there is a link to **View Inbound Rules**. The associated IPs should be set up according to the following example (modified for your IP ranges subnets): ![image2018-7-31_16-22-6.png](https://docs.keyfactor.com/__attachments/a_d7d1bef4769320beabd5d1b47256885e7c5f4515f0646392b043c5994b99dbde/image2018-7-31_16-22-6.png?cb=08216d6c1d21b73c4cbed81b57bc76c8) --- version: "4.0" language: "en" --- # Example Configuration The following displays a sample server.cnf configuration: # # These groups are read by MariaDB server. # Use it for options that only the server (but not clients) should see # # See the examples of server my.cnf files in /usr/share/mysql/ # # this is read by the standalone daemon and embedded servers # # For explanations see # http://dev.mysql.com/doc/mysql/en/server-system-variables.html # This will be passed to all mysql clients # It has been reported that passwords should be enclosed with ticks/quotes # escpecially if they contain "#" chars... # Remember to edit /etc/mysql/debian.cnf when changing the socket location. [client] port = 3306 socket = /var/run/mysqld/mysqld.sock # Here is entries for some specific programs # The following values assume you have at least 32M ram # This was formally known as [safe_mysqld]. Both versions are currently parsed. [mysqld_safe] socket = /var/run/mysqld/mysqld.sock nice = 0 syslog [mysqld] # # * Basic Settings # user = mysql pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port = 3306 basedir = /usr datadir = /var/lib/mysql # Configure the tmp directory to reside on the data partion where we have enough space for SSTs. # (Xtrabackup will use this variable.) tmpdir = /var/lib/mysql/tmp character_set_server=utf8 collation_server=utf8_unicode_ci lc_messages_dir = /usr/share/mysql lc_messages = en_US skip-external-locking wsrep_on=ON # gcache.size is how much data we will cache and use for IST. # If more data has been produced since the node was disconnected an SST will be triggered. # By setting it to 16G a customer can issue about 0.5M certs before connecting a second node without SST. # (Nothing wrong with SSTs, but during IST it easer to follow the sync progress and it looks more user friendly.) # pc.npvo=true: Recent primary component overrides older ones in case of conflicting prims. # ## Can only be set in URL due to a bug: pc.wait_prim=false: The node waits for primary component forever # pc.weight=2: Default weight for the node that can be overridden by parameters in the gcomm URL #Uncomment this and you are setting up Galera recommendations with the default paths in the SignServer Cloud Galera Clustering Guide otherwise add your own #wsrep_provider_options="socket.ssl_key=/etc/mysql/localhost-Key.pem;socket.ssl_cert=/etc/mysql/localhost.pem;socket.ssl_ca=/etc/mysql/localhost-CA.pem;gcache.size=6G;gcache.page_size=512M; pc.npvo=true;" # Galera Cluster Configuration wsrep_cluster_name=signserver_cluster #wsrep_cluster_address="gcomm://" wsrep_cluster_address="gcomm://172.16.0.103" wsrep_node_name=SignServerNode1 wsrep_node_address="172.16.0.36" # Galera Synchronization Configuration wsrep_sst_auth=repl_user:i-04811bfcfa454383e wsrep_sst_method=mariabackup # # Instead of skip-networking the default is now to listen only on # localhost which is more compatible and is not less secure. #bind-address = 127.0.0.1 bind-address = 0.0.0.0 # # * Fine Tuning # max_connections = 200 connect_timeout = 5 # The number of seconds the server waits for activity on a noninteractive connection before closing it. (Default 28800s) wait_timeout = 3600 max_allowed_packet = 256M thread_cache_size = 128 sort_buffer_size = 4M bulk_insert_buffer_size = 16M tmp_table_size = 32M max_heap_table_size = 32M # Turn off reverse DNS lookup of clients skip-name-resolve # # * MyISAM # # This replaces the startup script and checks MyISAM tables if needed # the first time they are touched. On error, make copy and try a repair. myisam_recover = BACKUP key_buffer_size = 32M #open-files-limit = 2000 table_open_cache = 400 myisam_sort_buffer_size = 128M concurrent_insert = 2 read_buffer_size = 2M read_rnd_buffer_size = 1M # # * Query Cache Configuration # # Disable to query cache to avoid locking query_cache_limit=0 query_cache_type=0 query_cache_size=0 # * Logging and Replication # # Both location gets rotated by the cronjob. # Be aware that this log type is a performance killer. # As of 5.1 you can enable the log at runtime! general_log_file = /var/log/mysql/mysql.log general_log = 0 # # # Error logging goes to syslog due to /etc/mysql/conf.d/mysqld_safe_syslog.cnf. # # we do want to know about network errors and such log_warnings = 2 # # Disable slow log slow_query_log=0 #slow_query_log_file = /var/log/mysql/mariadb-slow.log #long_query_time = 10 #log_slow_rate_limit = 1000 #log_slow_verbosity = query_plan #log-queries-not-using-indexes #log_slow_admin_statements # Disable bin-logging, since we don't use regular replication sync_binlog = 0 #log_bin = /var/lib/mysql/mariadb-bin #log_bin_index = /var/lib/mysql/mariadb-bin.index #expire_logs_days = 10 #max_binlog_size = 100M # ROW is required by Galera (intercepts binlogs, but binlogs does not have to be written to disk) binlog_format=ROW # * InnoDB default_storage_engine = InnoDB innodb_buffer_pool_size=2G # Use one pool per GiB of 'innodb_buffer_pool_size' innodb_buffer_pool_instances = 2 # If SHOW GLOBAL STATUS LIKE 'innodb_log_waits'; starts returning a non-zero value # transactions are to large to fit in the innodb_log_buffer_size and uses disk IO. innodb_log_buffer_size = 32M # Recommended to be 25% of innodb_buffer_pool_size. Larger file however means slower recovery. # Changing this value requires a delete of the old files while shutdown. # (sudo rm /var/lib/mysql/ibdata1 /var/lib/mysql/ib_logfile0 /var/lib/mysql/ib_logfile1) innodb_log_file_size=512M innodb_file_per_table = 1 innodb_open_files = 400 innodb_io_capacity = 400 innodb_flush_method = O_DIRECT # Always flush it to Galera innodb_flush_log_at_trx_commit=1 # Parallel slave thread processing requires the following settings: innodb_autoinc_lock_mode=2 innodb_locks_unsafe_for_binlog=1 # Galera Provider Configuration wsrep_provider=/usr/lib64/galera/libgalera_smm.so # Number of threads on the "slave" side applying incoming data. # wsrep_slave_threads = 4*number of cores wsrep_slave_threads=16 # In case of conflict during the full state transfer, overwrite the slave slave_exec_mode=IDEMPOTENT [mysqldump] quick quote-names max_allowed_packet = 256M [mysql] #no-auto-rehash # faster start of mysql but no tab completition [isamchk] key_buffer = 16M # this is only for embedded server [embedded] # This group is only read by MariaDB servers, not by MySQL. # If you use the same .cnf file for MySQL and MariaDB, # you can put MariaDB-only options here [mariadb] # This group is only read by MariaDB-10.1 servers. # If you use the same .cnf file for MariaDB of different versions, # use this group for options that older servers don't understand [mariadb-10.1] --- version: "4.0" language: "en" --- # Generate TLS Certificates for SignServer The default certificates for SignServer are generated upon installation and are self-signed. It is recommended to configure new certificates from a CA which EJBCA trusts. Running a script on the command line of EJBCA Cloud can make this a simple process. To generate new TLS certificates for SignServer: 1. Start a shell session to the EJBCA instance: # ssh -i ec2-user@ # cd /opt/PrimeKey/support 2. Run the script titled `create_ra_tls_certs.sh`. Running this script with the `-d` and `-i` flags will generate certificates that Apache on the SignServer instance will use. In this demo environment example, our DNS and IP address for our SignServer instance are: * ec2-54-165-63-62.compute-1.amazonaws.com * ip-172-16-2-98.ec2.internal * 54.165.63.62 * 172.16.2.98 Running the script passing these addresses to the command line will look like the following: # sudo ./create_ra_tls_certs.sh -d ec2-54-165-63-62.compute-1.amazonaws.com -d ip-172-16-2-98.ec2.internal -i 54.165.63.62 -i 172.16.2.98 3. Answer **y** to the prompt about copying the certificates with proper names for Apache. This will output them to. `/home/ec2-user/pem.` 4. Copy this pem folder to the SignServer instance. This should be done over a secure channel between the nodes, via SSH or whatever method meets the organizations security needs. 5. Copy these files to `/home/ec2-user/pem,` then move them into the appropriate position in `/etc/httpd/ssl` on the SignServer node and restart apache with the following commands: # cd /home/ec2-user/pem # sudo cp * /etc/httpd/ssl/. # sudo service httpd restart 6. Run the following command to allow the EJBCA Superadmin access to SignServer: # cd /opt/signserver # bin/signserver wsadmins -allowany 7. Go to the SignServer **Administrators** tab and click **Add**. 8. Click **Load Current** and add the **Roles: Admin, Auditor,** and **Archive Auditor** for the EJBCA SuperAdmin, and then click **Add.** ![image-20250918-072735.png](https://docs.keyfactor.com/__attachments/a_bc20366bc0cf943ca8d2d29ba8e37ab542a7dafa58d295d7d1aa5248e03642d6/image-20250918-072735.png?cb=47c1862333da66ccca5265feead286cc) 9. On the SignServer **Administrators** tab, change the **Current Setting: Allow any** to **Only Listed** by clicking **Switch to "Only Listed"**. ![image-20250918-072753.png](https://docs.keyfactor.com/__attachments/a_fb5f01bd9afb5a1188b07b7e3cd1f83a15184bcbe426eda5fb907822b5136bad/image-20250918-072753.png?cb=b0f957d8c5c5bc7c805588df42f2d965) --- version: "4.0" language: "en" --- # Initialize the CloudHSM Follow the steps below to use your signed HSM certificate and your CA's issuing certificate to initialize your AWS CloudHSM cluster. 1. On the AWS CloudHSM console **Upload the certificates** page, do the following: 1. Next to **Cluster certificate** , click **Upload file** and select the HSM certificate that you signed previously. If you completed the steps in the previous [Use OpenSSL to Validate the HSM](https://docs.keyfactor.com/signserver-cloud/latest/use-openssl-to-validate-the-hsm.md) section, select the file named `CustomerSignedHsmCertificate.crt`. If you performed these steps on the cloud instance you will need to download them back to a client that has access to the HSM cluster creation wizard. 2. Next to **Issuing certificate** , click **Upload file** and select your CA's issuing certificate. If you completed the steps in the previous section, select the file named `customerCA.crt`. If you used a CA to issue the cluster certificate, provide a certificate chain that begins with the certificate that issued the cluster certificate and ends with the CA's root certificate. The certificate chain must be in PEM format and can contain a maximum of 5000 characters. 3. Click **Upload and initialize** . ![image2018-9-12_16-39-48.png](/__attachments/a_b85fbe2b98a09edebbc72bc7c03664ae470a86d2fc7aaf1b9c3b381bd1c3146e/image2018-9-12_16-39-48.png?cb=32cadc88d2fb6bcc997d16c6e812f276) 2. The wizard initializes the HSM and informs you that the initialization is now in progress. Click refresh ![image2018-9-12_16-41-23.png](https://docs.keyfactor.com/__attachments/a_c72a7a2c67510ad67857bdb2621367bbb3edfa6ded4a9ea1dadff21a34e860f0/image2018-9-12_16-41-23.png?cb=91d32fc92acab34ada94103d1893926b) to refresh the status. ![image2018-9-12_16-41-0.png](https://docs.keyfactor.com/__attachments/a_3351ed962da751ee95c3d6b9c72e9253fcbce55e73e2303b152c703b7d17b426/image2018-9-12_16-41-0.png?cb=7d75989dddd8ec4c37fa4817a8c8f6e6) --- version: "4.0" language: "en" --- # Launch SignServer Cloud This section describes how to launch SignServer Enterprise Cloud from AWS Marketplace. All operating system and installed software patches are current at the time the image is published to the marketplace. After deployment, the image runs within the customer's environment, and Keyfactor does not have access to manage updates. Customers are responsible for maintaining the image and applying ongoing security and software updates. The EC2 Console is a web interface that allows you to configure the SignServer Cloud instance details from a web browser before you launch it. Follow the instructions below to launch a SignServer Cloud EC2 instance: ## Step 1: Select SignServer Cloud Instance ### Locate SignServer Cloud on AWS Marketplace Browse to the [AWS Marketplace](https://aws.amazon.com/marketplace) and search for "keyfactor" to display results. Select the instance type to use and click the title of the desired listing, in this case **SignServer Enterprise Cloud Edition 24x7 Support** . Review the details and click **Continue to Subscribe**. ![SignServerEnterpriseCloudEdition.png](https://docs.keyfactor.com/__attachments/a_63f8970fa11af05c0b3688de36b5fa933c510af8940309271bf33c49c6dc1969/SignServerEnterpriseCloudEdition.png?cb=936f41b8d91ed607b9a52bdd05ad3c7e) ### Accept the Terms Click **Accept Terms** to agree to the terms of use and subscribe. ### Continue to Configuration Review the terms and click **Continue to Configuration** to review your instance. ## Step 2: Configure SignServer Cloud Select the options desired for Software Version and Region. The defaults should be sufficient. ![image2018-8-30_14-9-55.png](https://docs.keyfactor.com/__attachments/a_c8e497b9667b5adc0d749507860e8fa5cfc823d27cc6d0078232caff9b0e45b7/image2018-8-30_14-9-55.png?cb=e95c14b7b048ce4e76931e7571eb1d25) Optionally, you can select an annual option to save 20% off the AWS list price. Skip this section if this is not desired. If you choose this option, select the Instance Type, and number of subscriptions desired. ![image2018-8-30_14-11-10.png](https://docs.keyfactor.com/__attachments/a_dd14ee8c1318dca6fc450ac820670706330b6a1d6f034c3d384afe07b1d87a5f/image2018-8-30_14-11-10.png?cb=94662c1f5657d3ef81436e599a2c6874) Click **Continue to Launch** to continue the setup. ![image2018-8-30_14-12-47.png](https://docs.keyfactor.com/__attachments/a_9905f5fdc1cec47cfb4274ed05c5e5b9a094b5e1f2df781891ca6baf678860a0/image2018-8-30_14-12-47.png?cb=74ce6d7f1ff6b1e10bc1013ba8ed0bfa) ## Step 3: Launch SignServer Cloud Review your configuration and select instance type and settings. ### Instance Type Amazon EC2 provides a selection of instance types optimized to fit different use cases. Instance types comprise varying combinations of CPU, memory, and storage. The following instance types are available: | **Size Type** | **Memory** | **CPU** | **Storage** | |---------------|------------|--------------------------------------------------------------------------|------------------| | m3.large | 7 GiB | 6.5 EC2 Compute Units (2 virtual cores with 3.25 EC2 Compute Units each) | 1 x 32 GB SSD | | t2.2xlarge | 32 GiB | 8 virtual cores | EBS storage only | | t2.xlarge | 16 GiB | 4 virtual cores | EBS storage only | | t2.medium | 4 GiB | 2 virtual cores | EBS storage only | Select one of the supported instance types, in this case **t2.xlarge**. ![image2018-8-30_14-18-41.png](https://docs.keyfactor.com/__attachments/a_7763b9a468de983ab8ae9478709a2615e9520ca1b482c70b8c0264043568adbd/image2018-8-30_14-18-41.png?cb=9870101d071c764bf4f715c8a9cb13e0) ### VPC and Security Group Select the desired VPC and Subnet. For more information on getting started with Amazon Virtual Private Cloud (Amazon VPC), refer to AWS Documentation on [VPCs and Subnets](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Subnets.html). ![image2018-8-30_14-20-9.png](https://docs.keyfactor.com/__attachments/a_302742c1ec87886782bd2d77c92312c8987c2ba2c6b4bba2a9cfd4e249493a72/image2018-8-30_14-20-9.png?cb=07c662e3ea84575874625ff11e842b4f) For the Security Group, click the button that allows **Create New Based on Seller Settings**. ![image2018-8-30_14-21-27.png](https://docs.keyfactor.com/__attachments/a_88f2fa0e2c097827687395702c983c9db67064e8d5036556b1bd1368d769d466/image2018-8-30_14-21-27.png?cb=fe74eb27915bc4a9624004dc7d1737d4) If you wish to create your own Security Group, you need to allow port range 80, 443 and 22. For details, see [VPC and Security Group](https://docs.keyfactor.com/signserver-cloud/latest/launch-signserver-cloud.md#VPCandSecurityGroup). ![image2018-8-30_14-23-37.png](https://docs.keyfactor.com/__attachments/a_42fda28eea5e54864422dc22399e365b3467459e5d644f6531b5b8669f43cbf3/image2018-8-30_14-23-37.png?cb=75029118ba907de92936c5b9b038b4b2) ### Key Pair Choose a Key Pair to associate with this SignServer Enterprise Cloud Edition EC2 instance. Specify the name of the key pair you plan to use to access the command line of the SignServer instance. When you later connect to the instance, you must specify the private key that corresponds to the key pair you specify now when launching the instance. For information on creating a key pair using Amazon EC2, refer to AWS Documentation on [Amazon EC2 Key Pairs](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html). ![image2018-8-30_14-25-3.png](https://docs.keyfactor.com/__attachments/a_a5347560a33afbfca2530eda0b54ed7d4e8e16df47197a524878be8afe23db73/image2018-8-30_14-25-3.png?cb=9aa1358746df6ba1ae1fb565b7b8f233) Click **Save** and then click **Launch**. ![image2018-8-30_14-29-18.png](https://docs.keyfactor.com/__attachments/a_de8afce35d817ad4ecf238a881ff0eba194bd338d56c5fecaa7807a19caef600/image2018-8-30_14-29-18.png?cb=252547c63159bbaa4ca612ffd14834db) ## Step 4: View Software Installation Details and Status After launching, the AMI details are displayed, and the status of the deployment is available in the EC2 Dashboard. Click **EC2 Console** to view your instance. ### Confirm Running SignServer Cloud Instance It may take several minutes for your instance to launch. After the **Instance State** changes from **pending** to **running**, the SignServer Cloud instance is started. ![image2018-8-30_14-31-17.png](https://docs.keyfactor.com/__attachments/a_da5492ca3bffc345c9fe50cf1318a91f6853f63e05552dc681539d7434f0b48b/image2018-8-30_14-31-17.png?cb=ae08840300ae25bce848574efbd30b9a) Click the pencil icon in the **Name** column ![image2018-8-30_14-32-21.png](https://docs.keyfactor.com/__attachments/a_b10659a7209e8c2143b2121982769ae4408c35397f97eb662740f109ef8a18b6/image2018-8-30_14-32-21.png?cb=cf3b04be4e29832e4329331004f5bbd4) to give the AMI a name like **SignServer Enterprise Cloud** to make it easier to identify. ![image2018-8-30_14-33-30.png](https://docs.keyfactor.com/__attachments/a_3130f03bce1c3316ea0056fc0b6ce66509970e981270e16a6621820b2d2717e1/image2018-8-30_14-33-30.png?cb=2863ad9cc55dd22f735cf534ab0a7d04) --- version: "4.0" language: "en" --- # Launch SignServer Cloud on Azure The following describes how to launch SignServer Enterprise Cloud from Azure Marketplace. All operating system and installed software patches are current at the time the image is published to the marketplace. After deployment, the image runs within the customer's environment, and Keyfactor does not have access to manage updates. Customers are responsible for maintaining the image and applying ongoing security and software updates. The Azure Portal is a web interface that allows you to configure the SignServer Enterprise Cloud instance details from a web browser before you launch it. Follow the instructions to launch an SignServer Cloud Azure instance. ## Locate SignServer Cloud in the Azure Marketplace The following describes how to locate the SignServer Cloud instance and create the app in Azure. 1. Browse to the [Azure Marketplace](https://azuremarketplace.microsoft.com/en-us) and search for "primekey" to display the SignServer Cloud. ![image2022-12-21_8-48-0.png](https://docs.keyfactor.com/__attachments/a_c384d6bf534fd26c8daed3c3226068ca4fedeb1085bdc4e321a1447ebe088355/image2022-12-21_8-48-0.png?cb=a9caa0ebfdfed3c1d9bb753884995536) 2. Review the plans as desired under the **Plans** tab to see the different pricing options. 3. Select the instance type to use and click **GET IT NOW** in the sidebar. 4. Select the desired support level, 8x5 or 24x7 and specify the contact information as required my Microsoft. ![image-20250922-095302.png](https://docs.keyfactor.com/__attachments/a_8eb060ac34fed2c8962c9f9c49a79c676fb0deb0478c0336bc081c65a5b2d41d/image-20250922-095302.png?cb=37439f99f6b436bffdaccb994899151e) ## Launch the Instance The following describes the steps to launch the instance in Azure using the Launch Wizard. ### Step 1: Log In and Create This action redirects you to the Azure portal: 1. Login to the Azure portal if not already done. 2. Confirm that the proper support plan is selected. ![image2022-12-21_8-49-52.png](https://docs.keyfactor.com/__attachments/a_8fa0a0b5ae14cf63a7049088aa9776b5dd69c0a4c5cad8bb31252c590f1c4f61/image2022-12-21_8-49-52.png?cb=2e8a32ba36e438a68b01521d7900b4d0) 3. Click **Create**. ### Step 2: Basics This brings you to the SignServer Cloud Launch Wizard for Azure. 1. Select the desired subscription, click **Create new** and enter the name of a Resource Group that will hold all of the SignServer Cloud resources, and then click **OK**. ![image-20250922-095516.png](https://docs.keyfactor.com/__attachments/a_a433a960e10b5d87b06509b782477d45d13d457c070913c0de58bfcbe5a8c61b/image-20250922-095516.png?cb=0b76917b3f8a35a88fd62ed97ce90903) 2. Enter a Virtual machine name for the SignServer VM. This will be used to create the FQDN along with the DNS of the region its in. 3. Pick the desired region to run the SignServer VM. 4. Ensure that **No infrastructure redundancy required** is selected under Availability options. 5. For the VM Size, select one from the instance sizes shown. Please do not select a instance size of less than 2 Cores. SignServer is a multi threaded app and requires at least 2 Cores. It will calculate the available memory on the host and automatically configure SignServer to have a portion of it. Select see all sizes to check all available instance types. ![image2022-12-21_9-56-10.png](https://docs.keyfactor.com/__attachments/a_114d214143988ca60d457d473e2e9550146335fd1e487d148b2e54a4a010df8e/image2022-12-21_9-56-10.png?cb=434a06aa046af0b44d44bb50b8256fb5) 6. Select SSH key or username and password authentication. 7. At this step you can either click **Review + create**, or continue on to the sub tabs that are optional, by may be critical to your organization. ![image2022-12-21_11-42-37.png](https://docs.keyfactor.com/__attachments/a_be9b392433b00c33bfcf7b766da2d530bb65f89aab74ca59fca180884af726a3/image2022-12-21_11-42-37.png?cb=db89c86ae224493805aea080b9a9f503) 8. Click **Create.** ### Step 3: Network Filter (Optional) The following describes specifying Network Settings: ![image2022-12-21_11-44-53.png](https://docs.keyfactor.com/__attachments/a_41d10f8807d537eab38805d75d2712a179d6af185eebaa6b037f11f222c25ccd/image2022-12-21_11-44-53.png?cb=0213dff19c40e0dfc01d6f180b2c22c6) 1. Click the refresh button on the deployment itself until the "nsg" object becomes a link. ![image-20250922-095630.png](https://docs.keyfactor.com/__attachments/a_6ac8a77053a27dd00f58a90a02b978a078f4da37bed34d4cda214f9074e8b716/image-20250922-095630.png?cb=f2ddb6cbec939b9e911306156f4b4872) 2. There are three Network Security Rules that can be edited if you not would like to have your SignServer instance be on the internet: Public_Web_Traffic, SSL-TLS Traffic, and SSH. 3. Select each one of these rules and change the **Source** drop down to **IP Addresses** . Add the IP address [you are coming from](https://www.google.com/search?q=what+is+my+ip) to the **Source IP addresses/CIDR ranges** field. ![image2022-12-21_11-48-51.png](https://docs.keyfactor.com/__attachments/a_f30456248a8c58ca8d22bd99b54a8924fee0b884cd4883da92d5df767bda8c1a/image2022-12-21_11-48-51.png?cb=960424a065af98a1c80725d3f1574c8c) 4. Click **OK.** --- version: "4.0" language: "en" --- # Log in to SignServer Cloud (version 1.x) This section describes how to log in to SignServer Cloud for the first time, following these steps: To access the Admin Web of the deployed SignServer Cloud instance, the superadmin credentials need to be retrieved from the server and installed on a system and/or browser. KeyFactor recommends using Mozilla Firefox since it currently has self-enrollment capabilities and its own keystore separate from the operating system. Note that if you are using Google Chrome, you will need to import the key file to the local machine keystore. ## Step 1: Get the Instance ID You must use the Instance ID of your running instance to download and install the p12 file in the steps described below. To get the instance ID of your instance, do the following: 1. In the Amazon EC2 Console, go to Instance details. 2. In the lower pane, click the **Description** tab. The **Instance ID** is the ID for the instance. 3. Click the icon next to the instance ID to copy the instance ID to your clipboard. ![copy to dashboard.png](https://docs.keyfactor.com/__attachments/a_28f80786dffb68c95ae2bda8c5a1cc767bfdd0cbcbe0e8df73c3d9bf08eaab22/copy%20to%20dashboard.png?cb=97edede07898e49542f283fd2b622a3b) ## Step 2: Download p12 file from SignServer Keystore Retrieval Webpage To obtain the keystore: 1. Enter the SignServer Keystore URL into your browser: `https:///keystore` 2. The username is "superadmin" and the password is the **Instance ID,** see [Step 1: Get the instance ID](https://docs.keyfactor.com/signserver-cloud/latest/log-in-to-signserver-cloud.md#LogintoSignServerCloud1.XonAWS-Step1). If you copied the instance ID to your clipboard, paste it into the password field. ![image-20250917-110946.png](https://docs.keyfactor.com/__attachments/a_0ec2dbeea1757ed6095c85770699f0b32de4c72a44c41b930bb6a0d4063b7f41/image-20250917-110946.png?cb=1ffad885647a6b637b8a71f2b3e58b38) These credentials only can be used **once** and, when authenticated, these credentials are expired. If you are not able to access the keystore retrieval page, refer to the [Troubleshooting](https://docs.keyfactor.com/signserver-cloud/latest/troubleshooting.md) section. ## Step 3: Download Credentials 1. At the bottom of the Keystore retrieval page is the link to the superadmin.p12 file. Download this file and keep it safe. ![image2018-7-26_14-20-0.png](https://docs.keyfactor.com/__attachments/a_935a504c233448799e55558db60b95f3b17f2f9da40f6623a7c3a5fd73fcbdec/image2018-7-26_14-20-0.png?cb=74be265fccc3083947509ab37ea3ee6f) 2. Upon clicking on the download link, a p12 file will be prompted to download. Please keep this file safe. Note that once the download link is selected the keystore retrieval page will no longer be accessible. If the p12 file is ever lost it can be retrieved from the instance directly from the directory `/opt/signserver/p12/pem`. ## Step 4: Install p12 With the p12 file downloaded, install the bundle on your system and/or browser's trust store. To install the credentials in Mozilla Firefox: 1. On the **Firefox** menu, select **Preferences**. 2. Click **Privacy \& Security**. 3. Scroll down to the **Security** section and click **View Certificates**. 4. On the tab **Your Certificates** , select **Import**. 5. Browse to the p12 file to import and enter a password. The password is the **Instance ID** of the SignServer Cloud instance, see [Step 1: Get the instance ID](https://docs.keyfactor.com/signserver-cloud/latest/log-in-to-signserver-cloud.md#LogintoSignServerCloud1.XonAWS-Step1). ## Step 5: Browse to SignServer Admin Web With the credentials installed, select the **AdminWeb** or access to SignServer Admin Web at the URL: `https:///SignServer/adminweb`. ![image2018-7-26_14-25-49.png](https://docs.keyfactor.com/__attachments/a_f545cb91a61f38905ec842270163f644aa71d27d861e3f6612b81e3932e32084/image2018-7-26_14-25-49.png?cb=8483e15947a922ea50312a92bddfe454) If you are not able to access the Admin Web, refer to the [Troubleshooting](https://docs.keyfactor.com/signserver-cloud/latest/troubleshooting.md) section. You will be prompted with a certificate dialog to authenticate to the adminweb of your instance. ![image2018-7-26_14-29-42.png](https://docs.keyfactor.com/__attachments/a_0bc7d817bb175ddaa326a8b142fd20778739fd304213ed1eb96cfa085fc37dc3/image2018-7-26_14-29-42.png?cb=b527994538a337728e727b4fa206a55a) --- version: "4.0" language: "en" --- # Log in to SignServer Cloud This section describes how to log in to SignServer Cloud for the first time, following these steps: To access the Admin Web of the deployed SignServer Cloud instance, the superadmin credentials need to be retrieved from the server and installed on a system and/or browser. KeyFactor recommends using Mozilla Firefox since it currently has self-enrollment capabilities and its own keystore separate from the operating system. Note that if you are using Google Chrome, you will need to import the key file to the local machine keystore. ## Step 1: Download p12 file from SignServer Keystore Retrieval Webpage The landing page of the SignServer Cloud Instance will be accessible until the SuperAdmin keystore is downloaded from the instance. To get the superadmin.p12 file from your instance, do the following: 1. Enter the SignServer Keystore URL into your browser: `https:///` 2. On the landing page that appears, click the SuperAdmin Keystore Download link: ![image-20250917-110453.png](https://docs.keyfactor.com/__attachments/a_7fb89577d1613f650451c06fbcf8eec7bd11ceb6aba9becf7745e5eadc3d92f2/image-20250917-110453.png?cb=bb95b0fa64aeba375a7b2aaeef34a37e) 3. The username is "superadmin" and the password is the password that was entered into the SignServer Cloud Wizard. ![image-20250917-110521.png](https://docs.keyfactor.com/__attachments/a_660c9ba9619ec5a705b764bcca146a2a4e3cd2e883cf66f3fe488fcd0cf3fb00/image-20250917-110521.png?cb=f93568441e17b9a76a53d577e93ce1c0) These credentials only can be used **once** and, when authenticated, these credentials are expired. If you are not able to access the keystore retrieval page, refer to the [Troubleshooting](https://docs.keyfactor.com/signserver-cloud/latest/troubleshooting.md) section. ## Step 2: Download Credentials 1. At the bottom of the Keystore retrieval page is the link to the superadmin.p12 file. Download this file and keep it safe. ![image2023-12-5_10-42-38.png](https://docs.keyfactor.com/__attachments/a_12827329d95b80823735ef1d4fd34f019026bcd2ecca445f4e7896dcc90501ae/image2023-12-5_10-42-38.png?cb=25d3e919c2150045f1b1474a3fcd06ce) 2. Upon clicking on the download link, a p12 file will be prompted to download. Please keep this file safe. Once the download link is selected, the keystore retrieval page is no longer accessible. If the p12 file is ever lost, the file can be retrieved from the instance directly from the directory `/opt/signserver/p12/pem`. ## Step 3: Install p12 With the p12 file downloaded, install the bundle on your system and/or browser's trust store. To install the credentials in Mozilla Firefox: 1. On the **Firefox** menu, select **Preferences**. 2. Click **Privacy \& Security**. 3. Scroll down to the **Security** section and click **View Certificates**. 4. On the tab **Your Certificates** , select **Import**. 5. Browse to the p12 file to import and enter a password. The password is the **Instance ID** of the SignServer Cloud instance, see [Step 1: Get the instance ID](https://keyfactor.atlassian.net/wiki/display/SSCD/.Log+in+to+SignServer+Cloud+AWS+v1.3). ## Step 4: Browse to SignServer Admin Web With the credentials installed, select the **AdminWeb** or access to SignServer Admin Web at the URL: `https:///SignServer/adminweb`. ![image2018-7-26_14-25-49.png](https://docs.keyfactor.com/__attachments/a_562dc28976fe44143d917f28011d7db703ca1f21370b58576d1631e13138b1f5/image2018-7-26_14-25-49.png?cb=8483e15947a922ea50312a92bddfe454) If you are not able to access the Admin Web, refer to the [Troubleshooting](https://docs.keyfactor.com/signserver-cloud/latest/troubleshooting.md) section. You will be prompted with a certificate dialog to authenticate to the adminweb of your instance. ![image2018-7-26_14-29-42.png](https://docs.keyfactor.com/__attachments/a_a5831ceb2f4e9b740f62126104783756972740b1969a3c53ebf52621015b5e75/image2018-7-26_14-29-42.png?cb=b527994538a337728e727b4fa206a55a) --- version: "4.0" language: "en" --- # Modify the Crypto Token in SignServer After restarting SignServer, the CryptoToken is offline. ![image-20240923-211427.png](https://docs.keyfactor.com/__attachments/a_ab365edeb477ca2f2e07db5edf46d7a39895e493a9d528dc4a82afe22cebc907/image-20240923-211427.png?cb=a6a600986e4e6aa7e596556a7917943b) To modify the CryptoToken: 1. Select the CloudHSM Crypto Token to get its properties. 2. Select the Configuration Tab: ![image-20240923-211134.png](https://docs.keyfactor.com/__attachments/a_1ba4af49314b96efe3b7e31b03dbd6be7dc9ef7b6eb7d183c1a0bc38ce069445/image-20240923-211134.png?cb=a06451bd62fe2da35d95e40c13b2c175) 3. Click **Edit** on the **SLOTLABELTYPE** property. Change it to `SLOT_LABEL`, click **SUBMIT**. SLOT_LABEL 4. Click **Edit** on the **SLOTLABELVALUE** property. Change it to `hsm1`, and click **SUBMIT**. hsm1 If the `CRYPTOTOKEN_IMPLEMENTATION_CLASS` is not set to `"org.signserver.p11ng.common.cryptotoken.P11NGCryptoToken`" change this value as well. 5. Select the Status Summary tab and it should now show the Crypto Token as Active: ![image-20240923-211751.png](https://docs.keyfactor.com/__attachments/a_f8a90467b78a9e774d38b95add0ca1af3ea379006f468364d32ccbfdd7641587/image-20240923-211751.png?cb=9409e021309c4a067ff420da218a65ce) 6. Click the Crypto Token tab and ensure all of the keys are displayed. 7. Select one of the keys, and click **Test**. 8. Click **Test** again and ensure the key is usable by SignServer: ![image-20240923-211910.png](https://docs.keyfactor.com/__attachments/a_4930a9c462fd1b641887755669bd38e20c948f2e11129a6232c68d6699578627/image-20240923-211910.png?cb=d4441eea920997fd26e91561a5827e88) --- version: "4.0" language: "en" --- # Multiple Crypto Tokens with AWS CloudHSM Typically, when using SignServer and creating [CryptoTokens](https://keyfactor.atlassian.net/wiki/spaces/EJBCADS/pages/238930278/Crypto+Tokens+Overview), a CryptoToken generally looks at a slot in an HSM for its key material. You would then create multiple crypto workers to look in different HSM slots. When using CloudHSM, the CloudHSM client provided by AWS always looks at a single cluster of HSMs. This cluster is always referenced as slot 1 to the host accessing it. AWS' CloudHSM client does not allow a host to access more than one CloudHSM cluster at a time. [SignServer supports more than one crypto worker that can look at different HSMs](https://keyfactor.atlassian.net/wiki/spaces/SSDOCS/pages/371000127/PKCS+11+Crypto+Token), but because of the CloudHSM clients ability to only talk to a single HSM cluster and represent it as slot 1, SignServer ECE can only talk to a single CloudHSM cluster at a time. On-prem HSM solutions can still work in the typical manner that the HSM provider supports. The only limitation that this presents is that all of the signing keys for SignServer workers must be located in the same slot of the CloudHSM. You can have more than one key in the HSM and call that by different signing workers. --- version: "4.0" language: "en" --- # Node Clusters ## Three Node Cluster Information The cluster implementation used for Galera replication uses regular network connectivity over the main instance interface for all cluster communication. This means that cluster nodes do not have to be placed physically close to each other as long as they have good network connectivity. However, this also means that a node cannot distinguish between a node failure of another node and broken network connectivity to the other node. To avoid the situation where the cluster nodes operate independently and get diverging data sets (a split-brain situation), the cluster nodes take a vote and will cease to operate unless they are part of the majority of connected nodes. This ensures that there is only one data set that is allowed to be updated at the time. In the case of a temporary network failure, disconnected nodes can easily synchronize their data to the majority's data set and continue to operate. ## Two Node Clusters Galera recommends three nodes to avoid a split-brain situation. If only two instances are chosen, which is not recommended, make sure only one of them is getting written to and is a primary while the other is for DR purposes. An arbitrator can also be configured to avoid split brain. For more information, refer to Galera Documentation on [Galera Arbitrator](http://galeracluster.com/documentation-webpages/arbitrator.html). There is no real high availability in two node clusters. In the event that one of the node leaves the cluster ungracefully it will take the database offline on the remaining node. Two node clusters are more for redundancy than availability and must be manually intervened with to be functional again in the event of a failure. For more information, refer to Galera Documentation on [Two-node Clusters](http://galeracluster.com/documentation-webpages/twonode.html). ## High Availability This setup requires three or more nodes. In case of a node failure, the remaining nodes will still be able to form a cluster through a majority quorum vote and continue to operate. The first cluster node always has a slightly higher quorum vote than the rest of the nodes. In a setup of an even (4 or more) number of nodes where the nodes are divided over two sites, the site that has the first node will continue to operate if the connectivity between the sites fails. ## Continuous Service Availability To ensure that service clients always connect to an operational node in the cluster, an external load-balancer should be used for automatic fail-over and/or load distribution. In the case a custom application being developed for consumption of the services provided by SignServer Clouds' external interfaces, this could also be handled by making the custom application connect to any of the nodes that is found to be operational. If lower availability and manual interaction is acceptable in case of a node failure, this could also be solved by redirecting a DNS name to the service. --- version: "4.0" language: "en" --- # Optional - Automating the Backup Script Note This is one method of automating the backups using the included backup script. PrimeKey does not officially support the expect binary, but provides it as a means of automation. ## Optional Automation of Backups with Cron and Expect To automate the backups, do the following: 1. Edit the `/etc/crontab` file to schedule the tasks: # vim /etc/crontab 2. Enter the schedule that you would like to run. In this example, there are two entries. One to create the backup that runs at 1AM system time, and another to delete more than 10 log files that runs at 2AM system time. #Run Backup * 1 * * * root expect /home/ec2-user/backup_password.exp /opt/PrimeKey/support/system_backup.sh #Prune backups after 10 total * 2 * * * root /opt/PrimeKey/support/system_backup.sh --delete-files 10 You must first record the command with `autoexpect` (per the previous section [Optional - Using Expect to Automate Backups](https://docs.keyfactor.com/signserver-cloud/latest/optional-using-expect-to-automate-backups.md)). Record the command *exactly* as cron will run it. If you specify full paths with cron, you need to record the command with the same full paths with `autoexpect.` 3. To output these entries to log files of their own for testing and validation, use the following entries: #Run Backup and log to file * 1 * * * root expect /home/ec2-user/backup_password.exp /opt/PrimeKey/support/system_backup.sh >> /var/log/cron.log 2>&1 #Prune backups after 10 total and log to file * 2 * * * root /opt/PrimeKey/support/system_backup.sh --delete-files 10 >> /var/log/cron2.log 2>&1 --- version: "4.0" language: "en" --- # Optional - Using Expect to Automate Backups Use the commands `expect` and `autoexpect` to automate the backup script and avoid the script to prompt for input. This is recommended in order to not require the user running the scrips to supply the password via the CLI and also allow for permissions on the file containing the password to be locked down. To build the `expect` script by running a backup with `expect` to record the process: 1. Start by typing the following command in the preferred home directory. This creates a file called `backup_password.exp` which is essentially a recording of the prompts used during the running of the script. # autoexpect -f backup_password.exp /opt/PrimeKey/support/system_backup.sh 2. The `backup_password.exp` file now has the contents of the options used in the running of the backup. The `backup_password.exp` file now contains the password used to protect the backup in plan text. If you are uncomfortable with this, remove the file or proceed to protect the file with permissions: # sudo chown ec2_user backup_password.exp //make ec2_user the owner. # sudo chmod 700 backup_password.exp //make file only readable by ec2_user. 3. Run the backup with the file containing the recording of the process by using the `expect` command: # expect -f backup_password.exp /opt/PrimeKey/support/system_backup.sh 4. The backup file was created and the prompts filled out as specified. 5. Add this script to cron (if desired) in the next section [Optional - Automating the Backup Script](https://docs.keyfactor.com/signserver-cloud/latest/optional-automating-the-backup-script.md). --- version: "4.0" language: "en" --- # Overview This guide describes how to upgrade from one version of SignServer to another instance with a newer version. The same instructions apply to restore the backup of an instance to another for disaster recovery purposes. The SignServer Cloud instances that are purchased on an hourly basis, are designed to be terminated after an upgrade to a new instance is made. Instance termination avoids a detailed upgrade process in place of running a backup and restore script. In the example used in this guide, the source host is running SignServer 4.3.0 and the destination host is running SignServer 4.3.1: * The **source host running SignServer 4.3.0** has an elastic (public) IP of: `ec2-34-229-187-81.compute-1.amazonaws.com`. * The **destination host running SignServer 4.3.1** has an elastic (public) IP of: `ec2-52-23-217-245.compute-1.amazonaws.co`. When the upgrade is complete, all of the workers and data on the source node running 4.3.0 are migrated over to the new 4.3.1 version. --- version: "4.0" language: "en" --- # Peer Connection Configuration The Peer Connection is configured in the following steps. ## Step 1: Create Crypto Token for Peering Key To create a Crypto Token for the Peering Key, do the following: 1. Create a Crypto Token on the EJBCA instance by selecting **Crypto Tokens** under **CA Functions**. 2. Click **Create New**. ![image2018-7-31_16-25-56.png](https://docs.keyfactor.com/__attachments/a_bb76bc813d85d3c87b3c6a97d53d30573cee69b3c8f5b14ca6b8a00c69566cba/image2018-7-31_16-25-56.png?cb=4b0671613c56cadd1e31d93c3b12970d) 3. Enter a **Name** for the Crypto Token, an **Authentication Code** and enable **Auto-activation** to ensure that the Crypto Token comes online and is available after a reboot. Click **Save**. ![image2018-7-31_16-26-7.png](https://docs.keyfactor.com/__attachments/a_4511c471ba5d7b64b65e3eae5c33e4b7f1051aafe99f97b7c3bc7f1c8bae280f/image2018-7-31_16-26-7.png?cb=5e110a3ea4c1a8302515afbc3b5add4b) 4. Enter the key name **signserver_peer_systems_key** , select **RSA 2048** , and click **Generate new key pair**. ![image2018-7-31_16-26-24.png](https://docs.keyfactor.com/__attachments/a_e7b0054936baae33a564122ae5ba20b5b87def30f889cc6e4c71102a45c51e84/image2018-7-31_16-26-24.png?cb=7f7754e95215ece19053ce0397de7ab2) ## Step 2: Create a Certificate Profile for the Peer To create a Certificate Profile for the Peer, do the following: 1. Select **Certificate Profiles** under **CA Functions**. 2. In the **List of Certificate Profiles** enter a name such as **SignServer Peer Profile** and click **Add**. ![image2018-7-31_16-27-21.png](https://docs.keyfactor.com/__attachments/a_eac4fa21cfa0c1a65263b9e6544c578ffdc353402ed6f54ecf073d3d5f19531f/image2018-7-31_16-27-21.png?cb=b240c98898b2ad53dd4594add9c09619) 3. Click **Edit** on the newly created **SignServer Peer Profile** . Select the following options in the profile and click **Save**: * **Available Key Algorithms**: RSA * **Available Bit Lengths**: 2048 * **Validity or end date of the certificate**: 10y * **Extended Key Usage**: Client Authentication 4. Under **RA Functions,** select **End Entity Profiles**. 5. Enter a name for a new profile in the **Add Profile Field** such as **SignServer Peer EE Profile** , and click **Add**. ![image2018-7-31_16-27-39.png](https://docs.keyfactor.com/__attachments/a_8877d5cad6374a3da6ce32f71d21613bb58eeea178cc22f27746daaf1f719587/image2018-7-31_16-27-39.png?cb=1e7b760bf5a3041392b8c71add5befba) 6. Select the **SignServer Peer EE Profile** and click **Edit End Entity Profile**. 7. Within the profile select the following values and then click **Save**. * **Default Certificate Profile**: SignServer Peer EE Profile * **Available Certificate Profiles**: SignServer Peer EE Profile * **Default CA**: ManagementCA * **Available CAs:** ManagementCA * **Default Token:** User Generated * **Available Tokens:** User Generated ![image2018-7-31_16-31-48.png](https://docs.keyfactor.com/__attachments/a_3c8691b66c232633971f9abbf28b1464e5a65dec807b269ca41ce9435aaf44ab/image2018-7-31_16-31-48.png?cb=4e72a4c5323dad4d7fd85d3d78ff9af4) ## Step 3: Setup the Key Bindings Setup the key bindings in the following steps: 1. Click **Internal Key Bindings** under **System Functions**. 2. On the **AuthenticationKeyBinding** tab, click **Create new** and specify the following: * **Name:** Peer System Key Binding to SignServer * **Crypto Token:** PeerSystemsToken * **Key Pair Alias**: signserver_peer_systems_key * **Signature Algorithm:** SHA256WithRSA * **Protocol and Cipher Suite**: TLSv1.2;TLS_RSA_WITH_AES_256_CBC_SHA256 ![image2018-7-31_16-32-20.png](https://docs.keyfactor.com/__attachments/a_3dacc26d34d07ac0e484f4591e57baafae9fcf49eaea903819f6a822bf9eb13f/image2018-7-31_16-32-20.png?cb=d32ec6f71c944824a6a3b71e0084e5e8) 3. Click **Create** and then click **Back to overview**. ## Step 4: Generate a CSR for the KeyBinding Do the following to generate a CSR for the Key Binding: 1. In the Internal Key Bindings overview, select the **CSR** action for the **Peer System Key Binding to SignServer** to download a CSR. ![image2018-7-31_16-34-4.png](https://docs.keyfactor.com/__attachments/a_4fbd1f340634b6c8b94f20d9777d6c9067ad8a5367f41e4247ec1af05455521f/image2018-7-31_16-34-4.png?cb=e28e5b0b8a18c090829ea4a02cf06b84) 2. Save this file to a location on your computer. ![image2018-7-31_16-34-32.png](https://docs.keyfactor.com/__attachments/a_c8372ba5f74643929c836ed6da176393c89852108b5aeb67383af55a4b945185/image2018-7-31_16-34-32.png?cb=8d8dfaa6332ccda0f89bfd231a2e6765) 3. Select **RA Web** in the EJBCA Admin Web menu to access the RA Web. 4. In the EJBCA RA, click **Make New Request**. 5. In **Certificate Type** , select the **SignServer Peer EE Profile** . Then upload the CSR by clicking **Browse** to select the CSR downloaded in the previous step and click **Upload CSR**. ![image2018-7-31_16-35-19.png](https://docs.keyfactor.com/__attachments/a_665b96678fea63ebc1d41335d351dde3b267a39b64da4960f580941ac8087fe0/image2018-7-31_16-35-19.png?cb=c373ec9cbe2472fc0c9283d2d7a34c5b) 6. Change the **CN, Common Name** if desired, and then enter the **Username** "signserver_peer". ![image2018-7-31_16-35-34.png](https://docs.keyfactor.com/__attachments/a_4fd69c2ed7408f3eeefca59817a9e13c1293785219d1450c8a482c33081f557b/image2018-7-31_16-35-34.png?cb=6ce1d5137466015379b2762fdec94b43) 7. Click **Download PEM** to download the signed certificate and save this file to a location on your computer. ![image2018-7-31_16-35-47.png](https://docs.keyfactor.com/__attachments/a_3d827971376f834f190999a677e2d2c28e5ed94695d425b80918dde987b75b06/image2018-7-31_16-35-47.png?cb=5b913e4d4727aef0f0b9bed4a128a04a) 8. Go back to the EJBCA Admin Web and select **Internal Key Bindings** under **System Functions**. 9. Under the **Import externally issued certificate** header, click **Browse** , select the PEM file downloaded in the previous step and click **Import**. ![image2018-7-31_16-36-16.png](https://docs.keyfactor.com/__attachments/a_f94de5eef539e745b7832b028ee02ca77891c6c9d7f20f3c87f8af47a9d6445d/image2018-7-31_16-36-16.png?cb=5a84fd3dc76e3e035dc043c5ef7a1c32) A notification appears at the top that the *Operation completed without errors*. ![image2018-7-31_16-36-29.png](https://docs.keyfactor.com/__attachments/a_8b6e970966f1edbd287ba386559b23002d00096ef1f917fa39f5804e7b1e1d36/image2018-7-31_16-36-29.png?cb=31be6e7f228366dbdce234b83f3834e7) 10. Click **Enable** on the Key Binding. A notice appears at the top that the *Peer System Key Binding to SignServer status is now ACTIVE* and a check-mark indicates its active status. ![image2018-7-31_16-36-43.png](/__attachments/a_64c06c96b50c0590a7e7265a91355db1ceb8f1d372750764b7b7b3b4727fd5eb/image2018-7-31_16-36-43.png?cb=695591b93a3b7f95779c221a15022088) --- version: "4.0" language: "en" --- # PKCS11 PIN The PKCS #11 interface defines a PIN (personal identification number) for users of a cryptographic token. To specify a PKCS #11 PIN in the context of the AWS CloudHSM software library for PKCS#11, use the following format: : For example, the following is the PKCS #11 PIN for an HSM [crypto user (CU)](https://docs.aws.amazon.com/cloudhsm/latest/userguide/hsm-users.html) with user name **CryptoUser** and password **CUPassword123!**: CryptoUser:CUPassword123! [Next Page](https://docs.keyfactor.com/llms-full.txt/1)