Skip to content

Set up an OpenSSL certificate authority connector

Use an OpenSSL certificate authority (CA) connector to issue and manage certificates from an existing OpenSSL-based CA through Certificate Manager - SaaS. This connector enables CyberArk to authenticate to your OpenSSL host over SSH and automate certificate issuance, renewal, and revocation using your existing CA configuration.

How the OpenSSL connector works

When issuing a certificate, Certificate Manager - SaaS:

  1. Connects to the OpenSSL host over SSH through the selected VSatellite.
  2. Transfers the certificate signing request (CSR) to the staging directory on the OpenSSL host.
  3. Executes the OpenSSL command-line utility using the configured CA section in the OpenSSL configuration file.
  4. Retrieves the signed certificate from the OpenSSL host.
  5. Updates the OpenSSL CA database files as defined in the configuration.

All certificate signing operations are performed on the OpenSSL host. The certificate authority private key never leaves the CA server.

Before you begin

Note

To create or manage an OpenSSL certificate authority connector, you must have one of the following roles:

  • System Administrator
  • PKI Administrator
  • Platform Administrator
  • Resource Owner (for connectors owned by your team)

Before setting up the connector, verify that the OpenSSL software is installed and fully configured on the Linux server that hosts the certificate authority.

Required permissions on the OpenSSL host

The SSH account used by CyberArk Certificate Manager - SaaS must have permission to perform OpenSSL certificate operations on the CA host.

At minimum, the account must:

  • Execute the openssl binary from the system path
  • Read the OpenSSL configuration file specified in the connector settings
  • Read and write files in the CA working directory
  • Read and update the OpenSSL CA database files (for example, index and serial)
  • Create and delete files in the staging directory used for certificate requests
  • Access the CA private key file defined in the configuration file

Important

The connector does not elevate privileges. The SSH user must already have direct permission to access the required files and directories.

If file permissions or ownership are incorrectly configured, certificate issuance and revocation operations will fail.

Required configuration elements

The OpenSSL configuration file must define:

  • A valid [ ca ] section
  • A CA definition section (for example, [ CA_default ])
  • The dir parameter that defines the CA working directory
  • Valid paths for:
  • database
  • serial
  • private_key
  • certificate
  • An extensions section used for certificate issuance (for example, v3_req)

The value entered in Configuration Section Name in the connector must match the name of the CA definition section in the configuration file.

If these elements are missing or incorrectly defined, certificate issuance will fail during validation or signing.

Example: Install and initialize an OpenSSL certificate authority

Installing an OpenSSL CA requires creating a directory structure and supporting files. You can host multiple OpenSSL CAs on the same system by creating separate directory structures and configuration files.

Create the directory structure

mkdir /opt/openssl_ca
mkdir /opt/openssl_ca/certs
mkdir /opt/openssl_ca/crl
mkdir /opt/openssl_ca/private
echo 0100 > /opt/openssl_ca/serial
touch /opt/openssl_ca/index

The most critical file for the CA is the OpenSSL configuration file, typically located in the CA home directory (for example, /opt/openssl_ca) and named openssl.cnf.

Sample OpenSSL configuration file (openssl.cnf) 
HOME                      = .
RANDFILE                  = $ENV::HOME/.rnd

[ ca ]
default_ca                = CA_default

[ CA_default ]
dir                       = /opt/openssl_ca
crl_dir                   = $dir/crl
database                  = $dir/index
new_certs_dir             = $dir/certs
serial                    = $dir/serial
certificate               = $dir/issuer.crt
private_key               = $dir/private/issuer.key
policy                    = policy_match
default_days              = 365
default_crl_days          = 7
default_md                = sha1
default_bits              = 2048
preserve                  = no
unique_subject            = no
x509_extensions           = v3_req
copy_extensions           = copy

[ policy_match ]
countryName               = optional
stateOrProvinceName       = optional
localityName              = optional
organizationName          = supplied
organizationalUnitName    = optional
commonName                = optional

[ req ]
distinguished_name        = req_distinguished_name

[ req_distinguished_name ]
countryName               = Country (2 letter code)
countryName_min           = 2
countryName_max           = 2
stateOrProvinceName       = State or Province (spelled out)
localityName              = City or Locality
organizationName          = Organization
organizationalUnitName    = Organizational Unit
commonName                = Common Name (FQDN)
commonName_max            = 64

[ v3_req ]
basicConstraints          = CA:FALSE
subjectKeyIdentifier      = hash
authorityKeyIdentifier    = keyid,issuer
keyUsage                  = digitalSignature,keyEncipherment
extendedKeyUsage          = serverAuth,clientAuth
crlDistributionPoints     = URI:http://pki.example/issuer.crl

[ v3_ca ]
basicConstraints          = CA:TRUE
subjectKeyIdentifier      = hash
authorityKeyIdentifier    = keyid:always,issuer:always
keyUsage                  = cRLSign,keyCertSign

If present in the OpenSSL configuration file, the value specified for the string_mask parameter must support printable strings. Supported values include default, pkix, and nombstr.

Generate a new key pair

openssl genrsa -des3 -out /opt/openssl_ca/private/issuer.key 2048

openssl req -new -x509 -config /opt/openssl_ca/openssl.cnf -extensions v3_ca -days 4383 \
  -key /opt/openssl_ca/private/issuer.key -out /opt/openssl_ca/issuer.crt \
  -subj "/CN=FOR TESTING PURPOSES ONLY"

Requirements

Ensure that you meet the following requirements before setting up the OpenSSL CA connector:

Access requirements

  • Network access from at least one active VSatellite to the OpenSSL host
  • SSH access to the OpenSSL host
  • The SSH host key for the OpenSSL host

Configuration requirements

  • An existing OpenSSL-based certificate authority
  • An OpenSSL configuration file that defines the certificate authority
  • The name of the OpenSSL configuration section used for the CA
  • Absolute paths to:
  • The CA working directory
  • The staging directory used for temporary certificate files

Authentication requirements

  • SSH authentication using one of the following methods:
  • SSH private key (with passphrase, if encrypted)
  • Username and password
  • The private key password for the OpenSSL CA (if the CA private key is password-protected)

Set up the CA in Certificate Manager - SaaS

Step 1: Set up the connection

  1. Sign in to Certificate Manager - SaaS.

  2. Click Integrations > Certificate Authorities.

  3. Click New > Add Certificate Authority connector.

  4. Enter the Name.
  5. Select a VSatellite.
  6. In the Certificate Authority Type dropdown, select OpenSSL CA Connector.
  7. Click Next.

Step 2: Enter additional information

  1. Enter the Hostname or IP Address of the OpenSSL CA host.

  2. Enter the Port used for SSH access.

    Note

    If you do not specify a port, the connector uses port 22 by default.

  3. Enter the Configuration File Path to the OpenSSL configuration file.

  4. Enter the Configuration Section Name that defines the CA.
  5. Enter the Directory Path for the CA working directory.
  6. Enter the Staging Directory Path used for temporary files during issuance.
  7. Enter your Username.
  8. Enter the SSH Enforced Host Key for the OpenSSL host.
  9. Select an SSH authentication method:
    • SSH private key: Enter the SSH Private Key and SSH Key Passphrase.
    • Password: Enter the Password.
  10. Enter the OpenSSL CA Private Key Password (if required).
  11. Click Test Access to verify connectivity, then click Next.

Tip

If Test Access fails, verify that:

  • The SSH user can log in to the OpenSSL host.
  • The configured file and directory paths exist on the OpenSSL server.
  • The openssl binary is accessible to the SSH user.
  • The CA private key password is correct (if configured).

Important

All file and directory paths must be absolute paths on the OpenSSL certificate authority host, not on the VSatellite or your local machine.

Step 3: Enter issuance details

  1. (Optional) In Product Options, select the certificate authority products to map to certificate issuing templates (CITs).
    • Click Add to map additional products.
  2. Click Create.

What's next

This CA is now ready to be added to one or more certificate issuing templates. To do this, select this CA when creating certificate issuing templates.