Search docs.molo17.com
    Configuration guide Security

    Enable HTTPS with your own certificate and TLS to your databases

    Gluesync always serves the Control Plane over HTTPS, with a self-signed certificate that your browser does not trust. This guide shows how to replace it with a certificate issued by your own certification authority (CA), how to check which certificate browsers and API clients really receive, and how to make Gluesync verify the certificate of the databases it connects to. It also covers what to do when a database only speaks TLS 1.0 or 1.1.

    In this guide

    You will learn how to build a keystore for Core Hub, configure security-config.json, install the PEM files on the reverse proxy of the kit, check both endpoints with openssl, trust the CA in a browser, and find out why the browser still shows the old certificate. Then you will create a trust store, enable TLS in a connection form and upload it, check that a database that requires TLS refuses a connection without it, read an IBM i system over TLS, and decide whether a legacy database justifies lowering the TLS floor of Core Hub. The Oracle wallet is covered by its own guide.

    Quick information

    Goal

    Serve the Control Plane with a certificate from your own CA, and connect Gluesync to databases over verified TLS

    Audience

    System administrators and security teams who install and operate Gluesync

    Level

    Advanced

    Time required

    About 60 minutes

    Area

    Docker Compose kit folders shared and proxy; Control Plane → pipeline → agent connection form → Security

    Applies to

    Gluesync 2.3

    Before you begin

    Make sure that:

    1. You run Gluesync from the Docker Compose kit, where the folder shared of the installation is mounted in Core Hub as /opt/gluesync/shared and the reverse proxy (Traefik) reads the folder proxy and the PEM files of shared;

    2. You can edit the files of the kit, restart its containers, and run openssl and keytool (it comes with a JDK) on your workstation;

    3. You have, from your PKI, a server certificate with its private key and the certificate of the CA that issued it. The certificate lists in its Subject Alternative Names (SAN) every host name and IP address that people and tools use to reach Gluesync. If you do not have them yet, the first step creates a test CA and a test certificate;

    4. For the database part, you can sign in to the Control Plane with a role that can edit pipelines and you know the CA certificate of each database.

    The examples use the host name gluesync.lab.test, the Core Hub keystore gluesync.p12, the certificate files gluesync.crt and gluesync.key, and the CA file ca.crt. Replace them with yours.

    Do not experiment on a production installation. Replacing a certificate restarts the web server of Core Hub and the reverse proxy, and a mistake in security-config.json can leave Core Hub without a web server.

    Know which certificate does what

    A kit has two TLS endpoints, and each one has its own certificate. This is the most common source of confusion: browsers never see the certificate of Core Hub.

    Who connects What they reach Certificate and where it is configured

    Browsers, API clients, AI clients

    The reverse proxy, port 443

    The PEM files shared/gluesync-cert.pem and shared/gluesync-key.pem, named in proxy/certs.yml. They are read when the proxy starts.

    The reverse proxy, and the Gluesync modules

    Core Hub, port 1717 (HTTPS and secure WebSockets)

    The keystore named in shared/security-config.json, read when Core Hub starts. The reverse proxy does not check it (insecureSkipVerify: true in proxy/traefik.yml), so changing it does not change what browsers see.

    The agents of Core Hub

    Your databases

    A trust store that you upload in the connection form, one per connection.

    security-config.json is the file that Core Hub reads. ssl-config.json is its older name: Core Hub reads it only when security-config.json does not exist.

    Guide steps

    Optional: create a test CA and a server certificate

    CLI

    Skip this step if your PKI gives you the certificate, its key and the CA certificate.

    1. Create the CA key and certificate;

    2. Create the key and the request of the server;

    3. Sign the request with the CA, listing every name and address in the SAN.

    openssl genrsa -out ca.key 4096
    openssl req -x509 -new -nodes -key ca.key -sha256 -days 1825 -out ca.crt \
      -subj "/C=IT/O=Lab Example Org/CN=Lab Example Internal CA" \
      -addext "basicConstraints=critical,CA:TRUE" \
      -addext "keyUsage=critical,keyCertSign,cRLSign"
    
    openssl genrsa -out gluesync.key 2048
    openssl req -new -key gluesync.key -out gluesync.csr \
      -subj "/C=IT/O=Lab Example Org/CN=gluesync.lab.test"
    
    printf 'basicConstraints=CA:FALSE\nkeyUsage=critical,digitalSignature,keyEncipherment\nextendedKeyUsage=serverAuth\nsubjectAltName=DNS:gluesync.lab.test,DNS:gluesync,DNS:localhost,IP:127.0.0.1\n' > gluesync.ext
    openssl x509 -req -in gluesync.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
      -out gluesync.crt -days 825 -sha256 -extfile gluesync.ext
    Expected result

    openssl x509 -in gluesync.crt -noout -subject -ext subjectAltName prints the subject and the line DNS:gluesync.lab.test, DNS:gluesync, DNS:localhost, IP Address:127.0.0.1.

    Browsers and API clients compare the address they typed with the SAN, not with the common name (CN). A certificate with only a CN is refused even when the CA is trusted: Chromium answers ERR_CERT_COMMON_NAME_INVALID. Write every host name as DNS: and every IP address as IP:.

    Build the keystore for Core Hub

    CLI

    1. Export the certificate, the key and the CA certificate into one PKCS12 file. -name sets the alias that you will enter in security-config.json;

    2. Enter an export password when openssl asks for it, and note it down: it is the keystore password;

    3. List the keystore and check that it holds one PrivateKeyEntry.

    openssl pkcs12 -export -name gluesync \
      -in gluesync.crt -certfile ca.crt -inkey gluesync.key \
      -out gluesync.p12
    
    keytool -list -keystore gluesync.p12 -storetype PKCS12

    If your private key is protected by a passphrase, openssl asks for it first. If your certificate came from a Windows PKI as a .cer file in DER format, convert it first with openssl x509 -inform der -in server.cer -out gluesync.crt.

    Expected result

    keytool -list shows Your keystore contains 1 entry and gluesync, <date>, PrivateKeyEntry.

    Core Hub reads a PKCS12 file such as gluesync.p12 directly: you do not need a .jks file. If you convert to JKS with keytool -importkeystore, remember that keytool of Java 8 (for example the one bundled with IBM WebSphere) gives the private key the password of the .p12 and the keystore a different one that you type at the prompt. Core Hub 2.3 accepts that when each password is in its own field of security-config.json. Gluesync releases before 2.2.11.9 did not: see Find out why the browser still shows the old certificate.

    Configure Core Hub to use the keystore

    Config

    1. Copy gluesync.p12 into the folder shared of the kit;

    2. Open shared/security-config.json and set the ssl section to the keystore, its alias and its passwords. Keep the dh section as it is;

    3. Restart Core Hub: docker compose restart gluesync-core-hub.

    {
      "ssl": {
        "sslCertificatePath": "/opt/gluesync/shared/gluesync.p12",
        "certificateAlias": "gluesync",
        "certificatePassword": "<keystore password>",
        "certificateKeyPassword": "<keystore password>"
      },
      "dh": {
        "diffieHellmanPassword": "gluesync-password",
        "salt": "gluesync-salt"
      }
    }

    The path is the one that Core Hub sees inside the container, with forward slashes. In a PKCS12 keystore the two passwords are the same. SSL_ENABLED=true must be set on Core Hub in docker-compose.yml: the kit already does it.

    1. Show the certificate that Core Hub serves on port 1717. The kit does not publish that port, so run the check inside the Core Hub container:

    docker compose exec gluesync-core-hub keytool -printcert -sslserver localhost:1717
    Expected result

    The output shows Owner: CN=gluesync.lab.test, O=Lab Example Org, C=IT, names your CA as Issuer, gives the validity dates, and lists the SAN names (DNSName: gluesync.lab.test, IPAddress: 127.0.0.1, and so on). The CA certificate of the chain follows as a second certificate. If it still shows CN=gluesync.com, Core Hub is still using the built-in certificate: check the path, the alias and the passwords.

    Optional, for advanced users

    You do not need the log to follow this guide. Core Hub also writes the certificate it loaded: docker compose logs gluesync-core-hub | grep "SSL certificate" prints SSL certificate 'gluesync' loaded from /opt/gluesync/shared/gluesync.p12: subject CN=gluesync.lab.test, …​ expires <date>. When the keystore cannot be used, Core Hub stops with a message that names the keystore, the alias and the field to change.

    Install the PEM files on the reverse proxy

    CLI

    Browsers reach the reverse proxy, so this is the step that changes what they see.

    1. Extract the certificate from the keystore;

    2. Extract the private key without encryption (-nodes);

    3. Check that the key is not encrypted;

    4. Copy the two files into the folder shared of the kit, keeping the names gluesync-cert.pem and gluesync-key.pem;

    5. Restart the reverse proxy: docker compose restart reverse-proxy.

    openssl pkcs12 -in gluesync.p12 -clcerts -nokeys -out gluesync-cert.pem
    openssl pkcs12 -in gluesync.p12 -nocerts -nodes -out gluesync-key.pem
    
    grep -c "BEGIN PRIVATE KEY" gluesync-key.pem     # 1
    grep -c "ENCRYPTED" gluesync-key.pem             # 0
    
    cp gluesync-cert.pem gluesync-key.pem /path/to/kit/shared/
    docker compose restart reverse-proxy
    Expected result

    After the restart, the certificate on port 443 is yours (see the next step). The proxy does not reload the PEM files while it runs: replacing them without restarting it leaves the old certificate in place.

    Without -nodes, openssl writes -----BEGIN ENCRYPTED PRIVATE KEY-----. The proxy cannot read it: it logs failed to load X509 key pair: tls: failed to parse private key, and the TLS handshake fails, so browsers show a connection error and no certificate at all.

    If your certificate was issued by an intermediate CA, append the certificate of the intermediate CA to gluesync-cert.pem, after the server certificate, so that browsers can build the chain.

    Check both endpoints, then trust the CA in the browser

    CLI

    1. Show what a browser receives from the reverse proxy and check it against your CA and your host name;

    2. Show what Core Hub serves on port 1717 (previous step) and compare the two subjects;

    3. Install ca.crt as a trusted root CA on the workstations that open the Control Plane, with the usual method of your organization (Windows certificate store, macOS Keychain, Linux system store, Firefox store);

    4. Open https://gluesync.lab.test/.

    openssl s_client -connect gluesync.lab.test:443 -servername gluesync.lab.test \
      -CAfile ca.crt -verify_hostname gluesync.lab.test < /dev/null 2>&1 \
      | grep -E "Verification|Protocol|Verify return"
    Expected result

    openssl prints Verification: OK, Protocol: TLSv1.3 and Verify return code: 0 (ok). The browser opens the login page without a security warning once the CA is trusted. Before the CA is trusted, Chromium stops with NET::ERR_CERT_AUTHORITY_INVALID. In the lab, a Chromium on Linux that had the CA imported with certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n "Lab CA" -i ca.crt loaded the page without any error.

    Gluesync login page loaded over HTTPS from the host name gluesync.lab.test with no certificate error
    Figure 1. The Control Plane login page opened at https://gluesync.lab.test, after the CA was trusted.

    If you open the Control Plane by an address that is not in the SAN, for example by IP address when the certificate lists only host names, the browser warns even though the CA is trusted. See the page Install and run Gluesync on Windows Server for what that warning looks like.

    Find out why the browser still shows the old certificate

    A customer who followed the reference page and still saw the certificate that comes with the kit had run into a combination of the causes below. Compare what Core Hub serves with what the proxy serves: if the two subjects differ, the browser is looking at the proxy.

    What you see Cause What to do

    The Control Plane does not open at all after the restart, and nothing answers on port 1717. Core Hub stopped with Keystore was tampered with, or password was incorrect

    Gluesync before 2.2.11.9 opened the keystore with certificateKeyPassword only. A JKS made with keytool of Java 8 has a keystore password and a different key password

    Update Gluesync, or use the .p12 file with a single password as keystore, or align the two passwords with keytool -keypasswd. From 2.2.11.9 each password goes in its own field

    keytool -printcert on port 1717 shows your certificate, but the browser still shows the one of the kit

    You changed Core Hub only. Browsers reach the reverse proxy, which has its own PEM files

    Replace gluesync-cert.pem and gluesync-key.pem of the kit and restart the reverse proxy

    You replaced the PEM files, restarted Core Hub, and the old certificate is still there

    The reverse proxy reads the PEM files only when it starts

    docker compose restart reverse-proxy

    The browser reports a connection error, with no certificate to inspect, and the proxy log shows failed to parse private key

    The key was extracted without -nodes, so it is encrypted

    Extract it again with -nodes and restart the proxy

    The old certificate stays although the files and the restart are right, on a Windows installation

    The proxy may read the PEM files from another folder than the one you changed. The Windows kits keep them in the shared folder of the installation and older installations also in the proxy folder

    Replace the files in every location named in proxy/certs.yml, then restart

    After setting insecureSkipVerify: false in proxy/traefik.yml the Control Plane answers 500 Internal Server Error

    The proxy now verifies the certificate of Core Hub, and it connects by the IP address of the container: x509: certificate is valid for 127.0.0.1, not 172.25.0.2

    Set it back to true, which is the value of the kit, or follow the optional step below

    Optional: make the reverse proxy verify the certificate of Core Hub

    Config

    By default the proxy does not check the certificate of Core Hub. If your security policy requires it, give the proxy the CA certificate and the name to verify. This changes only the connection between the proxy and Core Hub.

    1. Copy ca.crt into the folder shared, and mount it in the reverse-proxy service of docker-compose.yml: ./shared/ca.crt:/etc/traefik/ca.crt:ro;

    2. Add a transport to proxy/certs.yml, next to the tls section;

    3. In docker-compose.yml, add the label traefik.http.services.corehub.loadbalancer.serversTransport=corehub@file to the gluesync-core-hub service;

    4. In proxy/traefik.yml set insecureSkipVerify: false;

    5. Run docker compose up -d.

    http:
      serversTransports:
        corehub:
          serverName: gluesync.lab.test
          rootCAs:
            - /etc/traefik/ca.crt
    Expected result

    https://gluesync.lab.test/ui/v2/login answers 200. The name in serverName must be in the SAN of the Core Hub certificate.

    The other modules of the kit (Chronos, Conductor) connect to Core Hub with SSL_SKIP_VERIFY=true in docker-compose.yml: they do not need the CA.

    Create a trust store for your databases

    CLI

    An agent trusts a database certificate only if the CA that signed it is in a trust store that you upload. A trust store holds CA certificates, not keys.

    1. Get the CA certificate that signed the database certificate, in PEM format;

    2. Create a JKS trust store with it and choose a password;

    3. List it and check the entry type.

    keytool -importcert -alias lab-ca -file ca.crt \
      -keystore truststore.jks -storepass <trust store password> -noprompt
    
    keytool -list -keystore truststore.jks -storepass <trust store password>
    Expected result

    keytool -list prints lab-ca, <date>, trustedCertEntry. An entry of type PrivateKeyEntry would be a key store, not a trust store.

    The form accepts pem, jks, json, txt, p8, cer, pfx, p12, key and crt files. Which of them a connector can really use depends on its driver: the MySQL agent accepted a .jks and a .p12 trust store and refused a .pem with Invalid keystore format. Use a .jks or .p12 file when you are not sure.

    Optional: start a MySQL that requires TLS

    CLI

    Skip this step if you already have a database that requires TLS. It creates a MySQL 8.0 with a certificate from the CA of this guide, and a user that can only connect over TLS.

    1. Create the certificate of the database, with its host name in the SAN;

    2. Create the SQL file that creates a user with REQUIRE SSL;

    3. Start MySQL on the network of the kit, with --require_secure_transport=ON.

    mkdir mysql-certs
    openssl genrsa -out mysql-certs/mysql.key 2048
    openssl req -new -key mysql-certs/mysql.key -out mysql-certs/mysql.csr -subj "/C=IT/O=Lab Example Org/CN=mysql-tls"
    printf 'basicConstraints=CA:FALSE\nkeyUsage=critical,digitalSignature,keyEncipherment\nextendedKeyUsage=serverAuth\nsubjectAltName=DNS:mysql-tls\n' > mysql-certs/mysql.ext
    openssl x509 -req -in mysql-certs/mysql.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out mysql-certs/mysql.crt -days 825 -sha256 -extfile mysql-certs/mysql.ext
    cp ca.crt mysql-certs/ca.crt && chmod 644 mysql-certs/*
    
    cat > mysql-init.sql <<'SQL'
    CREATE DATABASE IF NOT EXISTS shop;
    CREATE USER 'gluesync'@'%' IDENTIFIED BY 'password' REQUIRE SSL;
    GRANT ALL ON *.* TO 'gluesync'@'%';
    CREATE TABLE shop.customers (id INT PRIMARY KEY, full_name VARCHAR(100), country CHAR(2));
    INSERT INTO shop.customers VALUES (1,'Anna Rossi','IT'),(2,'Hans Meier','DE'),(3,'John Smith','US');
    SQL
    
    docker run -d --name mysql-tls --network gluesync-net --network-alias mysql-tls \
      -e MYSQL_ROOT_PASSWORD=<root password> \
      -v "$PWD/mysql-certs:/certs:ro" -v "$PWD/mysql-init.sql:/docker-entrypoint-initdb.d/init.sql:ro" \
      mysql:8.0.37 --ssl-ca=/certs/ca.crt --ssl-cert=/certs/mysql.crt --ssl-key=/certs/mysql.key \
      --require_secure_transport=ON --server-id=1 --log-bin=mysql-bin --binlog-format=ROW
    Expected result

    After the first start has finished, docker exec mysql-tls mysql -ugluesync -ppassword --ssl-mode=REQUIRED -e "show session status like 'Ssl_version'" prints Ssl_version TLSv1.3, and the same command with --ssl-mode=DISABLED is refused.

    Enable TLS in the connection form and upload the trust store

    UI

    1. Open the pipeline that uses the database and, on the card of the agent, select the three-dot menu and Edit. For a new pipeline, you reach the same form in the setup wizard after you choose the agent;

    2. Fill Host name / Address, Port, Database name, Username and Password of the database;

    3. In the Security section, switch Enable TLS on, then switch Trust server certificate off if it is still on;

    4. Under Upload 'trust store' file select Upload files and choose truststore.jks. Enter the Trust store password;

    5. For the MySQL agent only, also upload the same file under Upload 'key store' file and enter its password in Key store password. The agent reads that slot, see the table below;

    6. Select Test and continue.

    Security section of the MySQL connection form with Enable TLS switched on (annotation 1)
    Figure 2. Switch Enable TLS on, Trust server certificate off, and upload the trust store and the key store with their passwords.
    Expected result

    The agent card shows a green check mark and gluesync@mysql-tls:3306, and the wizard enables Next. A file is uploaded when you select Test and continue: until then the form shows Click "Test and continue" to upload next to the file name, and File uploaded afterwards.

    Agents setup wizard with the MySQL agent card showing the user and host gluesync@mysql-tls:3306 and a green check mark
    Figure 3. The agent card turns green after Test and continue succeeds.

    The two switches decide what the agent checks:

    Enable TLS Trust server certificate What happens

    Off

    n/a

    No encryption. A database that requires TLS refuses the connection. The Control Plane shows Failed to initialize pool: Could not create connection to database server: the reason (for MySQL, that only secure transport is allowed) is in the Core Hub log.

    On

    On

    The connection is encrypted, but the certificate of the database is not checked: any certificate is accepted, so this protects against eavesdropping and not against an impersonated server. No file is needed.

    On

    Off

    The agent checks that the certificate of the database was issued by a CA in the uploaded trust store. A wrong CA, a wrong password or an unsupported file make the connection fail.

    PostgreSQL does not use the uploaded trust store

    With Enable TLS on and Trust server certificate off, the PostgreSQL agent uses sslmode=verify-ca and looks for the CA certificate in /home/gluesync/.postgresql/root.crt inside the Core Hub container. A trust store uploaded in the form is not read: the connection fails with Could not open SSL root certificate file /home/gluesync/.postgresql/root.crt. Mount your CA certificate in PEM format at that path on the gluesync-core-hub service (./shared/ca.crt:/home/gluesync/.postgresql/root.crt:ro) and recreate the container. With that mount, a PostgreSQL 16 that presented a certificate from our CA was accepted.

    For the MySQL agent in this mode the Control Plane answers Keystore not found, please upload a keystore when using verify server certificate if only the trust store slot is filled, because the agent loads its CA from the key store slot. The change-data-capture reader needs the trust store slot as well, and fails if it is empty. Fill both slots with the same trust store file until this is fixed. If you fill only the key store slot, the snapshot works but live changes do not arrive, and the pipeline still shows as healthy.

    Check what the database sees

    CLI

    1. Run a snapshot, or start the entity, so that the agent opens its connections;

    2. Ask the database which protocol its sessions use.

    docker exec mysql-tls mysql -uroot -p<root password> --ssl-mode=REQUIRED \
      -e "select t.processlist_user, s.variable_value as ssl_version from performance_schema.status_by_thread s join performance_schema.threads t using(thread_id) where s.variable_name='Ssl_version' and t.processlist_user='gluesync'"
    Expected result

    Every gluesync session shows TLSv1.3. In the lab, a MySQL 8.0 that required TLS received the three rows of the table in the snapshot and a fourth row inserted afterwards, with the CA trust store in both slots.

    Read an IBM i system over TLS

    The IBM i agent connects with the JTOpen driver. The TLS ports of the host servers are 9471 (database) and 9476 (sign-on); the port list and the firewall rules are on the IBM i agent page.

    Get the CA of the IBM i and build the trust store

    CLI

    An IBM i usually signs its server certificate with its own local CA, and sends the CA certificate in the chain. Take the CA from the handshake, with a read-only connection that sends no data:

    1. Open a TLS connection to the database port and save the chain;

    2. Check which certificate is the CA;

    3. Put the CA certificate in a trust store, as in the previous step.

    openssl s_client -connect <ibm i host>:9471 -showcerts < /dev/null 2>/dev/null \
      | awk '/BEGIN CERT/{n++} n==2{print} /END CERT/{if(n==2) exit}' > ibmi-ca.pem
    openssl x509 -in ibmi-ca.pem -noout -subject -ext basicConstraints
    
    keytool -importcert -alias ibmi-ca -file ibmi-ca.pem \
      -keystore ibmi-truststore.jks -storepass <trust store password> -noprompt
    Expected result

    basicConstraints shows CA:TRUE. In the lab, ports 9471 and 9476 of the test system answered with TLS 1.2 only (TLS 1.0 and 1.1 were refused) and a server certificate that had no SAN and was signed by <system name>_CERTIFICATE_AUTHORITY. The IBM i driver checks the chain, not the SAN, so the missing SAN is not a problem.

    In the connection form of the IBM i agent switch Enable TLS on and upload ibmi-truststore.jks under Upload 'trust store' file, as in the previous step. The IBM i form has no Trust server certificate switch: the trust store is needed. We tested the same driver that Core Hub bundles: with the IBM i CA in the trust store it connected over TLS and ran select 1, and with a trust store that held another CA it failed with PKIX path building failed: unable to find valid certification path to requested target. A connection that fails with that message needs the CA of the IBM i in the trust store.

    Ask the IBM i administrator to confirm that the secure host servers are active and when the server certificate expires: a trust store holds the CA, so a renewed server certificate from the same CA needs no change in Gluesync.

    Connect to a database that only speaks TLS 1.0 or 1.1

    Core Hub runs on a modern Java runtime. Agents that use the TLS of that runtime negotiate TLS 1.3 or 1.2 and refuse TLS 1.0 and 1.1, which is what an unpatched SQL Server 2008 or 2012, an old MySQL or an old PostgreSQL offers. The failure looks like this in the Core Hub log, while the Control Plane shows only that the pool could not be initialized:

    javax.net.ssl.SSLHandshakeException: (protocol_version) The server selected protocol version TLS10 is not accepted by client preferences [TLS13, TLS12]
    Allow TLS 1.0 and 1.1 in Core Hub, only when you must

    Config

    1. Prefer to fix the database: enable TLS 1.2 on it, or put a TLS-terminating proxy in front of it;

    2. If that is not possible, set GS_LEGACY_TLS=1 on the Core Hub service in docker-compose.yml:

    3. Recreate Core Hub: docker compose up -d gluesync-core-hub;

    4. Test the connection again.

    services:
      gluesync-core-hub:
        environment:
          - SSL_ENABLED=true
          - GS_LEGACY_TLS=1
    Expected result

    Core Hub starts and prints GS_LEGACY_TLS level 1: re-enabling TLSv1/TLSv1.1, TLS_RSA cipher suites and SHA-1 handshake signatures. In the lab, a PostgreSQL that was limited to TLS 1.0 refused Core Hub before the change (Received fatal alert: protocol_version) and accepted it after: pg_stat_ssl on the server showed the Gluesync sessions with TLSv1.

    GS_LEGACY_TLS is process-wide. It re-enables TLS 1.0 and 1.1, the TLS_RSA suites (no forward secrecy) and SHA-1 handshake signatures for every outgoing TLS connection of Core Hub: all databases, mail servers and identity providers, not only the legacy one. Modern peers still negotiate TLS 1.3. Use it only when the path to the legacy database is a trusted network, and remove it when the database is updated. The value 2 also re-enables the 3DES suites, for SQL Server builds whose Windows offers nothing else.

    The listener of Core Hub is not widened: with the variable set, Core Hub still refused TLS 1.0 and 1.1 on port 1717, and the reverse proxy on port 443 too.

    This works only for agents that use the TLS of the Java runtime, such as PostgreSQL and SQL Server. The MySQL agent does not: its driver refuses TLS 1.0 and 1.1 on its own, even with GS_LEGACY_TLS set, and a connection string with tlsVersions=TLSv1 fails with TLS protocols TLSv1 and TLSv1.1 are not supported. Accepted values are TLSv1.2 and TLSv1.3. A MySQL 5.7 limited to --tls-version=TLSv1 has to be reconfigured to allow TLS 1.2 before Gluesync can connect to it over TLS.

    In a kit that includes Conductor, the same setting is the switch Force-load deprecated Java ciphers under Deprecated Java Ciphers in Settings → Global settings. The SQL Server agent has its own TLS troubleshooting.

    Oracle with a wallet

    Oracle connects through a wallet and a TNS alias, not through the trust store of the form. This is covered, with the wallet path that Core Hub must see and the errors you can meet, in Set up Oracle LogMiner CDC end to end.

    Verify the result

    You have successfully secured Gluesync if:

    • keytool -printcert -sslserver localhost:1717 inside the Core Hub container shows your certificate;

    • openssl s_client -connect <host>:443 -CAfile ca.crt -verify_hostname <host> prints Verification: OK;

    • a browser on a workstation that trusts your CA opens the login page without a warning, by every name and address listed in the SAN;

    • a database that requires TLS accepts the connection with Enable TLS on and refuses it with Enable TLS off;

    • with Trust server certificate off and the right trust store, the connection works; with a trust store that holds another CA, it fails.

    Troubleshooting

    Problem Possible cause What to do

    The browser says NET::ERR_CERT_AUTHORITY_INVALID

    The CA is not trusted on that workstation

    Import ca.crt as a trusted root CA, then reopen the browser

    The browser says ERR_CERT_COMMON_NAME_INVALID

    The host name or IP address you typed is not a SAN of the certificate

    Issue the certificate again with every name as DNS: and every address as IP:

    Core Hub does not start after you edit security-config.json

    Wrong path, alias or password; before 2.2.11.9 also a key password different from the keystore password

    Check the path inside the container, keytool -list the keystore, and see Find out why the browser still shows the old certificate

    500 after you set insecureSkipVerify: false

    The proxy verifies Core Hub and connects by IP address

    Set it back to true, or use the optional step with serverName and rootCAs

    The test connection of a database says Keystore not found, please upload a keystore when using verify server certificate

    MySQL agent, Trust server certificate off, key store slot empty

    Upload the trust store in the key store slot too

    The test connection fails with Could not create connection to database server, with TLS on

    The log has the reason: Path does not chain with any of the trust anchors (wrong CA), keystore password was incorrect, or Invalid keystore format (a .pem for MySQL)

    Upload the right CA, enter the trust store password, or convert the file to .jks

    A PostgreSQL connection with Trust server certificate off fails with Could not open SSL root certificate file /home/gluesync/.postgresql/root.crt

    The PostgreSQL agent does not read the uploaded trust store

    Mount the CA certificate in PEM format at that path in the Core Hub container

    The MySQL snapshot works but live changes do not arrive, and the pipeline is healthy

    CDC reader needs the trust store slot and only the key store slot is filled

    Fill both slots with the same trust store

    Contact MOLO17 Support if you need assistance with certificates and TLS in Gluesync.