OCM Uses a Complete Certificate Chain with a Private Root CA (Linux)

Prerequisites

• MetaDefender Drive v4.4.5 or later and OPSWAT Central Management v10 or later. Reliable HTTPS enrollment between MetaDefender Drive and Central Management v10 using a private root CA requires Drive v4.4.5+; earlier versions can fail the TLS handshake even with a correctly configured chain.
• OpenSSL installed (it is preinstalled on most distributions; otherwise install it with your package manager, e.g. sudo apt install openssl).
• A bash shell.
• Run every command from the same working directory.

Create a working folder and move into it:

xxxxxxxxxx

mkdir -p ~/certs && cd ~/certs

1. Generate the Root CA

The root CA is the trust anchor for the whole chain. Keep root.key private — anything signed by this key will be trusted.

xxxxxxxxxx

openssl genrsa -out root.key 4096

openssl req -x509 -new -nodes -key root.key -sha256 -days 3650 \

    -out root.crt -subj "/CN=MyRootCA"

This creates:

• root.key – private key for the root CA
• root.crt – self-signed root CA certificate (valid 10 years)

Verify:

xxxxxxxxxx

openssl x509 -in root.crt -noout -subject -issuer -dates

2. Generate the Intermediate CA

The intermediate CA is signed by the root and is used to sign the server certificate, so the root key can be kept offline.

xxxxxxxxxx

openssl genrsa -out intermediate.key 4096

openssl req -new -key intermediate.key -out intermediate.csr \

    -subj "/CN=MyIntermediateCA"

cat > intermediate.ext <<'EOF'

basicConstraints=CA:TRUE,pathlen:0

keyUsage=critical,keyCertSign,cRLSign

subjectKeyIdentifier=hash

authorityKeyIdentifier=keyid,issuer

EOF

openssl x509 -req -in intermediate.csr -CA root.crt -CAkey root.key \

    -CAcreateserial -out intermediate.crt -days 1825 -sha256 \

    -extfile intermediate.ext

This creates:

• intermediate.key – private key for the intermediate CA
• intermediate.crt – intermediate CA certificate signed by the root

Verify (expect CA:TRUE, pathlen:0):

xxxxxxxxxx

openssl x509 -in intermediate.crt -noout -text | grep -E "CA:|pathlen"

3. Generate the Server Certificate

This is the certificate the OCM server presents to clients. It is an end-entity certificate (CA:FALSE), marked for TLS server authentication, and includes a Subject Alternative Name (SAN). Replace myserver.local with the FQDN of your OCM server.

A SAN is required. MetaDefender Drive rejects a certificate that has a Common Name only and no SAN (this appears as curl error 60). The server.ext file below adds the SAN together with the correct key-usage flags.

xxxxxxxxxx

openssl genrsa -out server.key 2048

openssl req -new -key server.key -out server.csr \

    -subj "/CN=myserver.local"

cat > server.ext <<'EOF'

basicConstraints=CA:FALSE

keyUsage=critical,digitalSignature,keyEncipherment

extendedKeyUsage=serverAuth

subjectAltName=DNS:myserver.local

EOF

openssl x509 -req -in server.csr -CA intermediate.crt -CAkey intermediate.key \

    -CAcreateserial -out server.crt -days 825 -sha256 \

    -extfile server.ext

This creates:

• server.key – private key used by the OCM server
• server.crt – server certificate signed by the intermediate CA

Verify that the SAN is present (it must not be empty):

xxxxxxxxxx

openssl x509 -in server.crt -noout -text | grep -A1 "Subject Alternative Name"

xxxxxxxxxx

X509v3 Subject Alternative Name:

                DNS:myserver.local

Multiple host names or IP addresses: if the OCM server is reached by more than one name or by IP, list every value in subjectAltName, separated by commas, then re-run the signing command in this step. Use DNS: for host names and IP: for IP addresses, and make sure the certificate's CN is one of the listed names. For example:

xxxxxxxxxx

cat > server.ext <<'EOF'

basicConstraints=CA:FALSE

keyUsage=critical,digitalSignature,keyEncipherment

extendedKeyUsage=serverAuth

subjectAltName=DNS:myserver.local,DNS:myserver,IP:10.0.0.5

EOF

4. Create the Server Certificate Chain File

Clients such as MetaDefender Drive do not fetch missing certificates automatically, so the OCM server must present the complete chain in a single file, in this order: server, intermediate, root.

xxxxxxxxxx

cat server.crt intermediate.crt root.crt > server.chain.crt

Use server.chain.crt on the OCM server, not server.crt alone. Check the file begins correctly:

xxxxxxxxxx

head -n1 server.chain.crt

xxxxxxxxxx

-----BEGIN CERTIFICATE-----

The first line must be -----BEGIN CERTIFICATE-----.

5. Verify the Chain

Verify the certificates before configuring OCM. These checks confirm the chain is valid, the private key matches the server certificate, and (after OCM is running) that the server presents the full chain.

# 1. The server certificate chains up to the root (must print: server.crt: OK)

openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt

# 2. The chain file contains exactly 3 certificates

openssl crl2pkcs7 -nocrl -certfile server.chain.crt | openssl pkcs7 -print_certs -noout

# 3. The private key matches the server certificate (the two lines must be identical)

openssl rsa  -noout -modulus -in server.key | openssl sha256

openssl x509 -noout -modulus -in server.crt | openssl sha256

# 4. After OCM is configured: confirm the server presents the full chain.

#    Replace <OCM_HTTPS_PORT> with the HTTPS port your OCM server listens on.

echo | openssl s_client -connect myserver.local:<OCM_HTTPS_PORT> -showcerts 2>/dev/null | grep -E "s:|i:|Verify return code"

Expected results:

• Check 1 prints server.crt: OK.
• Check 2 lists exactly 3 certificates (server → intermediate → root).
• Check 3 prints two identical SHA-256 lines — this confirms the key matches the certificate.
• Check 4 shows all three certificates and Verify return code: 0 (ok). If only one certificate appears, the OCM server is sending the leaf only and must be reconfigured to use server.chain.crt.

6. Configure OCM to Use the Chain

Install these two files on the OCM server:

• server.key – the private key (from step 3)
• server.chain.crt – the full certificate chain (from step 4)

The OCM server must present server.chain.crt, not server.crt alone. If it sends only the leaf certificate, MetaDefender Drive cannot build the trust chain even when the root CA is already trusted. A web browser may still work because it can complete the chain from its own certificate store; MetaDefender Drive cannot.

7. Connect MetaDefender Drive to OCM

End users do not install the root CA on the MetaDefender Drive operating system. Drive does not expose a shell or trust store on the device, and the OS trust store is read-only. Instead, Drive uses trust-on-first-use at the UI: when it sees a server certificate signed by a non-public CA, it prompts the operator to review and accept it once, then adds that certificate to its own trusted store.

On the MetaDefender Drive device:

1. Boot MetaDefender Drive and go to Settings → Central Management.
2. Enter the OCM server URL (the FQDN you used in step 3) and the registration code, then click Connect.
3. When the Invalid Certificate dialog appears with *"This server could not prove itself. Its security certificate is not trusted by your computer's operating system."_, review the server identity (subject, fingerprint), then click _Proceed*.

MetaDefender Drive Invalid Certificate dialog

Drive adds the OCM server certificate to its internal trusted certificate store. Subsequent connections from the same Drive to the same OCM server are silent until the certificate rotates.

This page does not install the root CA itself on Drive — Drive trusts the server certificate directly. Validating that the certificate is correctly issued and that OCM presents the full chain is done externally from any machine with OpenSSL (see step 5, check 4); it is not done from the Drive command line.

Full Script (generate-ocm-certs.sh)

The script below performs every step in one run. Edit the variables at the top before running it.

xxxxxxxxxx

#!/usr/bin/env bash

# ============================================================

#  generate-ocm-certs.sh

#  Generates Root CA -> Intermediate CA -> Server certificate,

#  then builds the full chain file used by the OCM server.

#  Edit FQDN before running.

# ============================================================

set -euo pipefail

FQDN="myserver.local"          # <-- replace with your OCM server's FQDN

DAYS_ROOT=3650

DAYS_INTER=1825

DAYS_SERVER=825

# Clean up any files from a previous run

rm -f ./*.key ./*.crt ./*.csr ./*.srl ./*.ext

# --- Root CA ---

openssl genrsa -out root.key 4096

openssl req -x509 -new -nodes -key root.key -sha256 -days "$DAYS_ROOT" \

    -out root.crt -subj "/CN=MyRootCA"

# --- Intermediate CA ---

openssl genrsa -out intermediate.key 4096

openssl req -new -key intermediate.key -out intermediate.csr \

    -subj "/CN=MyIntermediateCA"

cat > intermediate.ext <<'EOF'

basicConstraints=CA:TRUE,pathlen:0

keyUsage=critical,keyCertSign,cRLSign

subjectKeyIdentifier=hash

authorityKeyIdentifier=keyid,issuer

EOF

openssl x509 -req -in intermediate.csr -CA root.crt -CAkey root.key \

    -CAcreateserial -out intermediate.crt -days "$DAYS_INTER" -sha256 \

    -extfile intermediate.ext

# --- Server certificate (with SAN) ---

openssl genrsa -out server.key 2048

openssl req -new -key server.key -out server.csr -subj "/CN=$FQDN"

cat > server.ext <<EOF

basicConstraints=CA:FALSE

keyUsage=critical,digitalSignature,keyEncipherment

extendedKeyUsage=serverAuth

subjectAltName=DNS:$FQDN

EOF

openssl x509 -req -in server.csr -CA intermediate.crt -CAkey intermediate.key \

    -CAcreateserial -out server.crt -days "$DAYS_SERVER" -sha256 \

    -extfile server.ext

# --- Build the chain file (order matters: server, intermediate, root) ---

cat server.crt intermediate.crt root.crt > server.chain.crt

# --- Verify ---

echo "=== Verification ==="

openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt

openssl crl2pkcs7 -nocrl -certfile server.chain.crt | openssl pkcs7 -print_certs -noout

echo "Files ready:"

echo "  OCM server key   : server.key"

echo "  OCM server chain : server.chain.crt"

echo "  Drive trust root : root.crt"

Troubleshooting