Deploy EJBCA as VA with automation
ENTERPRISE
This outlines how to deploy a Validation Authority (VA) using the EJBCA Enterprise configuration export/import tool EJBCA ConfigDump.
EJBCA installation with configdump import does not support replication during installation stage. Please use helm install
with configdump with replicaCount: 1
and then after the installation is complete perform an helm upgrade
to desired replicaCount
.
Prerequisites
Before you begin, you should be familiar with how to deploy EJBCA CA in Kubernetes.
Enroll server TLS certificates.
Configure Ingress and internal services with TLS.
Prepare database and other credentials.
EJBCA installation with ConfigDump import does not support replication during the installation stage. Instead, use helm install
with ConfigDump and replicaCount: 1
. After installation, perform a helm upgrade
to the desired replicaCount
.
Step 1 - Deploy EJBCA VA
Prepare configuration dump for the RA installation
The following attributes are created using the EJBCA ConfigDump configuration file in the examples provided:
Certification Authorities (CAs): Import the existing CAs as external CAs in the RA instance. You need to configure the CA certificate and subjectDN for this example. Note that these are truncated in the following ConfigMap example.
Roles and Role Members: Roles used for certificate authentication with CN (common name) SuperAdmin and AutomationAdmin.
Protocols: Configuration that enables protocols, such as OCSP.
Prepare the configuration dump file as a Kubernetes ConfigMap:
apiVersion: v1
kind: ConfigMap
metadata:
name: ejbca-va-init-configmap
data:
configdump.json: |
{
"certification-authorities": {
"ManagementCA": {
"Object Type": "Certification Authority",
"Version": 2,
"Name": "ManagementCA",
"Type of CA": "X.509",
"Description": "CA created by certificate import.",
"Serial Number Octet Size": 20,
"Pre-produce OCSP Responses": false,
"Microsoft CA Compatible Mode Used": false,
"Store responses on-demand": false,
"Pre-produce OCSP Responses Upon certificate issuance/revocation": false,
"Certificate Profile": "ROOTCA",
"Default Certificate Profile": "Not used",
"Use Append-Only Table": false,
"Certificate Chain": [
"MIIDQzCCAiugAfooeh....truncated....yH/InCosTfSmqu9LVM2TKLsmmAHsiKKyFlI="
],
"Enforce Unique Public Keys": true,
"Enforce key renewal": false,
"Enforce Unique DN": true,
"User Storage": true,
"Certificate Storage": true,
"Accept Revocations for Non-Existing Entries": false,
"Subject DN": "CN=ManagementCA,OU=SomeOrg",
"Signed By": "Self Signed",
"Validity": "0d",
"Subject Alternative Name": null,
"Use UTF-8 in Policy Notice Text": true,
"LDAP DN Order": true,
"Authority Key Id Used": true,
"CRL Number Used": true,
"Partitioned CRL Used": false,
"CRL Expiration Period": "1d",
"CRL Issue Interval": "0m",
"CRL Overlap Time": "10m",
"Delta CRL Period": "0m",
"Generate CRL Upon Revocation": false,
"Allow Changing Revocation Reason": false,
"Finish User": true,
"CA Healthcheck Enabled": true,
"Request Processor": null
},
"RootCA": {
"Object Type": "Certification Authority",
"Version": 2,
"Name": "RootCA",
"Type of CA": "X.509",
"Description": "CA created by certificate import.",
"Serial Number Octet Size": 20,
"Pre-produce OCSP Responses": false,
"Microsoft CA Compatible Mode Used": false,
"Store responses on-demand": false,
"Pre-produce OCSP Responses Upon certificate issuance/revocation": false,
"Certificate Profile": "ROOTCA",
"Default Certificate Profile": "Not used",
"Use Append-Only Table": false,
"Certificate Chain": [
"MIIDLTCCAhWgAhI....truncated....rAGORO8GHKxovrA=="
],
"Enforce Unique Public Keys": true,
"Enforce key renewal": false,
"Enforce Unique DN": true,
"User Storage": true,
"Certificate Storage": true,
"Accept Revocations for Non-Existing Entries": false,
"Subject DN": "CN=RootCA,C=SE",
"Signed By": "Self Signed",
"Validity": "0d",
"Subject Alternative Name": null,
"Use UTF-8 in Policy Notice Text": true,
"LDAP DN Order": true,
"Authority Key Id Used": true,
"CRL Number Used": true,
"Partitioned CRL Used": false,
"CRL Expiration Period": "1d",
"CRL Issue Interval": "0m",
"CRL Overlap Time": "10m",
"Delta CRL Period": "0m",
"Generate CRL Upon Revocation": false,
"Allow Changing Revocation Reason": false,
"Finish User": true,
"CA Healthcheck Enabled": true,
"Request Processor": null
}
},
"available-protocols": {
"available-protocol-configuration": {
"Object Type": "Available Protocols",
"Version": 1,
"Name": "available-protocol-configuration",
"ACME": false,
"Certstore": true,
"CMP": false,
"CRLstore": true,
"EST": false,
"MSAE": false,
"OCSP": true,
"SCEP": false,
"RA Web": false,
"REST CA Management": false,
"REST Certificate Management": false,
"REST Coap Management": false,
"REST Crypto Token Management": false,
"REST End Entity Management": false,
"REST End Entity Management V2": false,
"REST Configdump": true,
"REST Certificate Management V2": false,
"REST SSH V1": false,
"REST System V1": false,
"Webdist": true,
"Web Service": true,
"ITS Certificate Management": false,
"Custom header name for REST calls from browser": "X-Keyfactor-Requested-With"
}
},
"peer-connectors": {
"global-peer-configuration": {
"Object Type": "Peer Global Configuration",
"Version": 1,
"Allow incoming connections": true,
"Allow outgoing connections": false
}
},
"admin-roles": {
"Super Administrator Role": {
"Object Type": "Role",
"Version": 1,
"Name": "Super Administrator Role",
"Role Members": [
{
"Token Type": "CertificateAuthenticationToken",
"Issuer": "ManagementCA",
"Match With": "WITH_COMMONNAME",
"Match Value": "AutomationAdmin"
},
{
"Token Type": "CertificateAuthenticationToken",
"Issuer": "ManagementCA",
"Match With": "WITH_COMMONNAME",
"Match Value": "SuperAdmin"
},
{
"Token Type": "CliAuthenticationToken",
"Issuer": null,
"Match With": "USERNAME",
"Match Value": "ejbca"
}
],
"Namespace": "",
"RA Style Id": 0,
"Access Rules": {
"/": "Allow"
}
},
"vaIncomingCaPeer": {
"Object Type": "Role",
"Version": 1,
"Name": "vaIncomingCaPeer",
"Role Members": [
{
"Token Type": "CertificateAuthenticationToken",
"Issuer": "ManagementCA",
"Match With": "WITH_COMMONNAME",
"Match Value": "peer-key"
}
],
"Namespace": "",
"RA Style Id": 0,
"Access Rules": {
"/ca/": "Allow",
"/peerincoming/": "Allow",
"/peerpublish/": "Allow",
"/cryptotoken/keys/generate/": "Allow",
"/cryptotoken/use/": "Allow",
"/cryptotoken/view/": "Allow",
"/internalkeybinding/modify/": "Allow",
"/internalkeybinding/view/": "Allow"
}
}
}
}
Deployment customization with values.yaml
image:
variant: va
#imagePullSecrets:
# - name: keyfactor-registry
ejbca:
configdumpImport:
enabled: true
initialize: true
configMapName: ejbca-va-init-configmap
configMapKey: configdump.json
env:
DATABASE_JDBC_URL: "jdbc:mariadb://mariadb:3306/ejbca?characterEncoding=utf8"
DATABASE_USER: ejbca
envRaw:
- name: DATABASE_PASSWORD
valueFrom:
secretKeyRef:
name: mariadb-passwords
key: mariadb-password
nginx:
enabled: true
host: "ejbca-va-internal-host"
mountInternalNginxCert: true
secretInternalNginxCert: "internal-nginx-credential-secret-va1"
ingress:
enabled: true
className: "nginx"
annotations:
nginx.ingress.kubernetes.io/auth-tls-verify-client: "optional"
nginx.ingress.kubernetes.io/auth-tls-secret: "default/ejbca-ingress-trust-secret"
nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "true"
nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"
hosts:
- host: "ejbcava.example.com"
paths:
- path: /
pathType: Prefix
tls:
- hosts:
- "ejbcava.example.com"
secretName: ingress-credential-secret-va1
Step 2 - Configure Peer Connection
To configure the Peer setup in the CA instance with ConfiDump, you need to make a ConfigDump REST POST call to the CA instance with a SuperAdmin token with initialize set to true.
You can use the following script where SuperAdmin.p12
or ADMINP12
is the SuperAdmin token enrolled after the CA installation:
You need an existing and configured Remote Authentication resource. Alternatively, add internal-key-binding section when the ConfigDump call is made to the CA similar to what is described in Step 2 in Deploy EJBCA as RA with automation. There is also a script provided to make the ConfigDump REST POST call.
Ensure peer-connectors.{peer-name}.URL
is configured according to the service name attached to the NGINX sidecar of the peer. Typically, this is {peer-chart-release-name}.{peer-namespace}
.
Additionally, the common name(CN) of the server TLS certificate must match the Match Value
in admin-roles.Role Members
, such as ejbca-va1
in the following example.
{
"peer-connectors": {
"ejbca-va1": {
"Object Type": "Peer Connector",
"Version": 1,
"Name": "ejbca-va1",
"Peer Enabled": true,
"URL": "https://ejbcava-deployment-nginx/ejbca/peer/v1",
"Long Hanging Connections Enabled": false,
"Min Long Hanging Connections": 10,
"Max Long Hanging Connections": 20,
"Authentication Key Binding": "peer-key"
}
},
"admin-roles": {
"VA-Peer-Connection": {
"Object Type": "Role",
"Version": 1,
"Name": "VA-Peer-Connection",
"Role Members": [
{
"Token Type": "CertificateAuthenticationToken",
"Issuer": "ManagementCA",
"Match With": "WITH_COMMONNAME",
"Match Value": "ejbca-va1"
}
],
"Namespace": "",
"RA Style Id": 0,
"Access Rules": {
"/administrator/": "Allow",
"/ca/": "Allow"
}
}
}
}
Step 3 - Verify the setup
To verify the EJBCA VA setup, refer to instructions in Deploy RA and VA in Kubernetes.