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
.crtor.pemfiles), 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.crtfile 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 -version2.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-headlessStep 3: Preparing Certificates
3.1. Splitting Certificate Chains
Certificate bundles often come as a single
.pemor.crtfile containing multiple certificates in a chain (leaf, intermediates, root).Important:
update-ca-certificatesrequires 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 --freshThe
--freshflag 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 changeitThis 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/cacertsDefault 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 rootcaIf 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 mychain4.3 Cleanup Old Keystore Entries (if needed)
List current entries:
sudo keytool -list -v -keystore /path/to/cacertsDelete by alias if needed:
sudo keytool -delete -alias oldalias -keystore /path/to/cacertsStep 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:roThis 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 -issuerto inspect.Use
ls -lto verify size/timestamp.
6.2 Keystore Validation
After importing, validate with:
sudo keytool -list -v -keystore /path/to/cacerts -alias myaliasCheck fingerprints, dates, and full certificate chain.
Ensure only expected aliases exist—remove old or duplicate entries.
6.3 Common Errors
Multiple certificates in one
.crtfile: 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