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.

Note Each node needs the URL of the corresponding Vidispine system. To simplify this, it's recommended to use variables and wildcards in the relevant fields. To connect to the Vidispine system and obtain the required token for proper authentication, make sure to include the "VidiCore Get Token" node at the start of all VidiCore related streams. The relative file path is different from the path used by the locally mounted remote storage. It refers to the external drive's view and points to a specific location within that storage.

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:

    1. The server/leaf certificate (matching your server’s hostname)

    2. All intermediate CA certificates (in correct order)

    3. 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:

    1. Server/leaf certificate first

    2. Then intermediates (in correct sequence)

    3. 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:

2.2 If Java is missing, install temporarily:

Install a minimal headless JRE to perform keystore operations, then remove it after use:

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):

This splits the bundle into files: cert-00.pem, cert-01.pem, etc.

Identify each file:

Rename each file to .crt for compatibility:

Order is crucial for Java keystore imports and for troubleshooting:

  1. Server certificate (leaf; Subject= CN=...your hostname...)

  2. Intermediate CA(s)

  3. Root CA (Subject=Issuer)

3.2. Add Certificates to System Trust Store

Copy all single-certificate .crt files to /usr/local/share/ca-certificates/.

Remove any old or incorrectly concatenated .crt files from this directory. Then update system trust:

  • 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:

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:

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:

4.3 Cleanup Old Keystore Entries (if needed)

List current entries:

Delete by alias if needed:

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:

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:

  • 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