Vidicore
The VidiCore & Vidiflow integration in Helmut4 allows VidiCore users to automate their media management in the cloud. It gives you full control over API-driven processes, enabling the creation of powerful workflows.
Helmut4’s Streamdesigner offers several dedicated VidiCore nodes, which can be used to interact with a native Vidispine system. By including these nodes in a stream, you can create workflows that handle collections, files, items, libraries, and metadata efficiently.
SSL Certificate Setup for On-Premise Vidispine Environments
When using Helmut4 with an on-premise Vidispine system, it is crucial to have a dedicated Java cacerts keystore if communication occurs over HTTPS.
Helmut4 validates SSL certificates when communicating with Vidispine. However, locally hosted systems are not verified by public root certificate authorities. As a result, Helmut4’s internal certificate store will block the communication due to failed authentication if a proper SSL certificate is not in place.
Step 1: Certificate Requirements
Before you begin, ensure that the certificate files you use meet the following criteria:
Complete Certificate Chain: You must have the entire chain for your server, including:
The server/leaf certificate (matching your server’s hostname)
All intermediate CA certificates (in correct order)
The root CA certificate
File Format: All certificates must be in PEM format (typically
.crt
or.pem
files), with content between-----BEGIN CERTIFICATE----- ... (base64 data) ... -----END CERTIFICATE-----
One Certificate Per File (System Trust): For the system trust store (
/usr/local/share/ca-certificates/
), each.crt
file must contain exactly one certificate. If you have a combined certificate file (chain), you must split it into individual files before proceeding.Certificate Order for Java Keystore: When importing certificates into the Java keystore, you must provide them in the correct order:
Server/leaf certificate first
Then intermediates (in correct sequence)
Root certificate last
Host Name Matching: The Common Name (CN) or Subject Alternative Name (SAN) in your server certificate must match the hostname used by your applications.
Step 2: Prerequisites
Before creating or managing a keystore, ensure that a Java runtime environment (JRE) is available on your system. The keytool utility, which is used for keystore operations, requires a Java installation:
2.1 Verify Java Runtime Environment (JRE) existence:
java -version
2.2 If Java is missing, install temporarily:
Install a minimal headless JRE to perform keystore operations, then remove it after use:
sudo apt-get update
sudo apt-get install -y openjdk-17-jre-headless
# ... perform keystore operations
sudo apt-get remove -y openjdk-17-jre-headless
Step 3: Preparing Certificates
3.1. Splitting Certificate Chains
Certificate bundles often come as a single
.pem
or.crt
file containing multiple certificates in a chain (leaf, intermediates, root).Important:
update-ca-certificates
requires one certificate per file (.crt
).
How to Split a PEM Chain (4-cert example):
split -f cert- -b "%02d.pem" your_chain.pem '/-----BEGIN CERTIFICATE-----/' '{*}'
This splits the bundle into files: cert-00.pem
, cert-01.pem
, etc.
Identify each file:
openssl x509 -in cert-00.pem -noout -subject -issuer
openssl x509 -in cert-01.pem -noout -subject -issuer
...
Rename each file to .crt
for compatibility:
mv cert-00.pem cert1.crt
mv cert-01.pem cert2.crt
...
Order is crucial for Java keystore imports and for troubleshooting:
Server certificate (leaf;
Subject= CN=...your hostname...
)Intermediate CA(s)
Root CA (
Subject=Issuer
)
3.2. Add Certificates to System Trust Store
Copy all single-certificate .crt
files to /usr/local/share/ca-certificates/
.
sudo cp cert1.crt /usr/local/share/ca-certificates/
sudo cp cert2.crt /usr/local/share/ca-certificates/
# etc.
Remove any old or incorrectly concatenated .crt
files from this directory.
Then update system trust:
sudo update-ca-certificates --fresh
The
--fresh
flag removes old/invalid entries.
Step 4: Java Keystore (cacerts) Handling
Note: Before splitting and importing, verify that your certificate chain is complete and in the correct order, as outlined in the "Certificate Requirements" section above.
Default location: /etc/ssl/certs/java/cacerts
4.1 Check existence of the cacerts file
If the file does not exist at /etc/ssl/certs/java/cacerts
, create it otherwise skip this step:
sudo keytool -genkeypair \
-alias temp \
-keystore /etc/ssl/certs/java/cacerts \
-storepass changeit \
-keyalg RSA \
-keysize 2048 \
-dname "CN=Temporary Entry"
sudo keytool -delete -alias temp -keystore /etc/ssl/certs/java/cacerts -storepass changeit
This creates an empty keystore at the standard location, ready for you to import your real certificates.
4.2 Importing Certificates
Path:
/etc/ssl/certs/java/cacerts
Default password:
changeit
Import certificates in correct order:
sudo keytool -import -trustcacerts -file cert1.crt -keystore /etc/ssl/certs/java/cacerts -alias myserver
sudo keytool -import -trustcacerts -file cert2.crt -keystore /etc/ssl/certs/java/cacerts -alias intermediate1
sudo keytool -import -trustcacerts -file cert3.crt -keystore /etc/ssl/certs/java/cacerts -alias rootca
If you have a properly ordered file, you can also combine:
cat cert1.crt cert2.crt cert3.crt > chain_sorted.crt
and import all at once:
sudo keytool -import -trustcacerts -file chain_sorted.crt -keystore /path/to/cacerts -alias mychain
4.3 Cleanup Old Keystore Entries (if needed)
List current entries:
sudo keytool -list -v -keystore /path/to/cacerts
Delete by alias if needed:
sudo keytool -delete -alias oldalias -keystore /path/to/cacerts
Step 5: Mounting cacerts into Containers
After the cacerts keystore is set up, it needs to be mounted into the relevant containers. In a cluster environment, ensure the cacerts file is present on every server in the cluster.
5.1 Defining the cacerts Path in Containers
In your stack configuration (via Portainer or Docker Compose), define the path to the cacerts file on the host server and mount it into the containers. For each container—such as fx, io, co, hk, users, and streams—add the following under the volumes:
section:
volumes:
- /<path_to>/cacerts:/opt/java/openjdk/lib/security/cacerts:ro
This ensures that each container uses the correct cacerts file for SSL communication.
5.2 Synchronize cacerts Across Servers
Always update/re-import on all hosts after certificate renewal or change.
Restart all containers after updating the keystore.
Step 6: Troubleshooting & Validation
6.1 Certificate File Checks
Only single certificates per file in
/usr/local/share/ca-certificates/
.Use
openssl x509 -in <file> -noout -subject -issuer
to inspect.Use
ls -l
to verify size/timestamp.
6.2 Keystore Validation
After importing, validate with:
sudo keytool -list -v -keystore /path/to/cacerts -alias myalias
Check fingerprints, dates, and full certificate chain.
Ensure only expected aliases exist—remove old or duplicate entries.
6.3 Common Errors
Multiple certificates in one
.crt
file: Split them; remove old, concatenated files.Certificate not recognized: Verify correct order and that all intermediates are present.
After updates: Always restart containers and rerun
update-ca-certificates --fresh
.
Appendix: Helpful Commands
# Split chain
csplit -f cert- -b "%02d.pem" bundle.pem '/-----BEGIN CERTIFICATE-----/' '{*}'
# Inspect certificate
openssl x509 -in cert1.crt -noout -subject -issuer
# Import into Java keystore
sudo keytool -import -trustcacerts -file cert1.crt -keystore /path/to/cacerts -alias myalias
# List keystore entries
sudo keytool -list -v -keystore /path/to/cacerts
# Delete keystore entry
sudo keytool -delete -alias oldalias -keystore /path/to/cacerts
Last updated