EJBCA Cloud AWS
- AWS Launch Guide
Quick Start Guide
- Create Crypto Tokens
- Create Root CA Certificate Profile
- Create Issuing CA Certificate Profile
- Create Certificate Authorities
- Create User and Workstation Profiles
- Create End Entity Profiles
- Request Certificate
- Create Another Administrator Account
- Import Certificate to Mozilla Firefox
- Configure Health Checks
- Create CRL Updater Service
- AWS Backup Guide
- AWS Restore and Upgrade Guide
- AWS TLS Certificate Generation Guide
- AWS RA Configuration and Administration Guide
- AWS VA Configuration and Administration Guide
AWS Cluster Configuration Guide
- Cluster AWS Operating Environment
- Multi Node Clusters
- Cluster Security Groups
- Clustering with RDS Database
- Clustering with Galera on Local Nodes
AWS CloudHSM Integration Guide
- Multiple Crypto Tokens with AWS CloudHSM
- 1 - Create CloudHSM Cluster
- 2 - Use OpenSSL to Validate the HSM
- 3 - Initialize the CloudHSM
- 4 - Assigning the Security Group to the EJBCA Instance
- 5 - Configure the cloudhsm-client
- 6 - PKCS11 PIN
- 7 - Activate the Cluster
- 8 - Create a CloudHSM Crypto User
- 9 - Create a Keystore in the HSM with clientToolBox
- 10 - Test with EJBCA ClientToolbox
- 11 - Create a CryptoToken in EJBCA
- Appendix A - Restoring an HSM Backup to a New Instance
- Appendix B - Troubleshooting HSM Issues
AWS Certificate Manager Integration Guide
- Provisioning an EJBCA Instance and setting up CloudHSM
- Create Root CA Keys
- Create CloudHSM Crypto Token for Root CA
- Create the Root and Issuing CA Certificate Profiles
- Create End Entity Sub CA Profile
- Create Root CA that uses the CloudHSM Crypto Token
- Create AWS ACM Certificate Authority CSR
- Add ACM PCA End Entity
- Generate the ACM PCA Certificate for AWS
- Fulfill the Pending ACM PCA Certificate Request
- AWS S3 Publisher Configuration Guide
- AWS KMS Configuration Guide
- How to Create Support Package
- EJBCA Cloud AWS VA
EJBCA Cloud Azure
- Azure Launch Guide
- Azure Backup Guide
- Azure Restore and Upgrade Guide
- Azure TLS Certificate Generation Guide
- Azure RA Configuration and Administration Guide
- Azure VA Configuration and Administration Guide
- Azure Cluster Configuration Guide
- Azure Key Vault Integration Guide
- How to Create Azure Support Package
- EJBCA Cloud Release Notes
SSL Configuration for Secure Replication
This step is optional but recommended. If SSL/TLS keys and certificates for encrypted Cluster Traffic are not desired, skip to the section Restarting and Verifying Cluster.
EJBCA needs to be configured to have a certificate profile that allows the certificate permissions needed to be able to perform SSL replication functions.
- Log into the EJBCA Admin GUI and select Certificate Profiles:
- Click Clone for the SslServerProfile. Enter a name for the certificate profile, for example "Galera_SSL_Profile".
- Click Create from Template.
It will return back to the list of certificate profiles.
- Click Edit on the Galera_SSL_Profile.
Certificates from this profile will last 5 years by default. Cluster replication will stop when the certificates expire. If it is desired to have certificates that last longer, edit the "Validity or end date of the certificate" to be the desired length of time, such as "10y 1d".
- In the Extended Key Usage section, multi-select (Ctrl + click) both Client Authentication and Server Authentication, and click Save.
- Navigate to End Entity Profiles, select the SslServerProfile, and click Edit End Entity Profile (a new one can also be created).
- In the Available Certificate Profiles section, multi-select (Ctrl + click) so that Galera_SSL_Profile is added to the list of available profiles, and click Save.
Key and Certificate Generation for SSL Replication
Create a certificate and key for the nodes to communicate with via SSL. Galera needs access to the key and certificate so soft keys are required for this. EJBCA or OpenSSL can be used for the following steps. To use OpenSSL, refer to the Galera Clustering documentation.
- SSH into Node 1 and access the EJBCA CLI. Change the Subject Alternative Names in the command to the IP addresses for each of the three nodes in the cluster. Change the
--canamevalue to be the name of the Issuing CA used, if desired.
# /opt/ejbca/bin/ejbca.sh ra addendentity --username repl_user --password "<PASSWORD>" --dn CN=localhost --altname "ipaddress=172.31.0.115, ipaddress=172.16.0.188, ipaddress=172.16.0.202" --caname "ManagementCA" --type 1 --token PEM --certprofile Galera_SSL_Profile --eeprofile SslServerProfile
The command creates the end entity with the proper fields specified, so the certificates can be used on all nodes in the cluster.
- The next commands generate the certificate, key and CA cert onto the server for Galera to use:
# /opt/ejbca/bin/ejbca.sh ra setclearpwd --username repl_user <PASSWORD> # /opt/ejbca/bin/ejbca.sh batch --username repl_user
This will output three certificates into the
- localhost-CA.pem: CA Certificate
- localhost-Key.pem: System Key
- localhost.pem: System Certificate
The certs and key are used on every node in this guide. A unique certificate can be created for each node by altering the EJBCA
addendentitycommand above (changing username, dn and altname values) to be unique for each node.
- The next step is to copy these files to all the remaining nodes. This should be done over a secure channel between the nodes, via SSH or whatever method meets the organizations security needs. Copy the files to
/home/ec2-user, then move them into the appropriate position in
/etc/mysqlon each node.
- Once the copy is completed, move the files to the proper directory and change the permissions.
# mkdir /etc/mysql # mv /opt/ejbca/p12/pem/localhost* /etc/mysql # chown -R mysql.mysql /etc/mysql/ # chmod -R o-rwx /etc/mysql/
Ensure to change the permissions of the files on all nodes they are copied to.
Galera SSL Replication Node Specific Configuration
The following step needs to be done on all three nodes. Edit the
/etc/my.cnf.d/server.cnf and change the server.cnf file to add in the
wsrep_provider_options value with the proper certificate values. If the paths in this document have been used, the following can be copied and pasted into the server.cnf file on each node:
# vim /etc/my.cnf.d/server.cnf # 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;"
wsrep_provider_options line exists in the server.cnf already and can be uncommented if all the paths and file names have remained the same as in this documentation.