Connecting to other systems securely
Connections over HTTPS or straight to a host and port, TLS 1.2 as the floor, certificates you upload, and a Test that says exactly what failed.
A connection, under Platform → Connectivity → Integration → Connections, is a connector pointed at one real system: your old ERP, a directory, a mail server, a partner’s API. It holds where the system is, how to prove who it is, and the credential TRANXACT presents to it — encrypted on the way in and never shown back.
Two ways to reach a system
| Transport | What you fill in | When to use it |
|---|---|---|
| HTTPS | Endpoint URL. It must start with https:// — in every environment, test and development included. | A web API or service, reached over the internet or your own network. |
| Direct | Host (a name or an address only), Port, and Protocol. | A database, a directory or a service port reached over a network path such as a VPN, an interconnect or peering. |
A direct connection names its protocol, because systems start TLS in two different ways:
- tls — TLS from the first byte. LDAPS, SAP HANA, SQL Server with strict encryption, SMTPS, AMQPS and Kafka work this way.
- postgres — PostgreSQL, which connects in the clear for a moment and then negotiates TLS before anything else is said.
There is no plain-text option and no test-only exception. A connection used "only in testing" is one that carries real credentials the day somebody copies it, so the rule that holds in production holds everywhere.
TLS 1.2 or higher, and always verified
- Every handshake is TLS 1.2 or higher. Lowest TLS version can raise that to TLS 1.3 for a connection; nothing older can be chosen, and the database refuses it too, so it cannot be set by an import or a script either.
- The server’s certificate is always verified. There is no "do not verify" switch, because a connection that accepts any certificate is encrypted to whoever answers, which is not the same thing as encrypted to the system you meant.
- Server name is for when the certificate names a different host from the one you connect to — you reach the database at 10.20.0.15 and its certificate says hana.corp.local. It is used both to ask for the right certificate and to check it.
- Pinned fingerprint is optional: the SHA-256 fingerprint of the server’s certificate. With it set, any other certificate is refused, even a valid one. Remember to change it when the server’s certificate is renewed.
Certificates
The Certificates screen, in the same Integration section, holds the certificates connections trust or present. There are two kinds.
| Kind | What it is for |
|---|---|
| Trusted CA | A certificate authority your own organization runs. A server inside your network usually has a certificate your CA issued, which no public root knows; upload the CA here and choose it as Trusted CA on the connection. Left empty, a connection trusts the public roots. |
| Client certificate | Presented by TRANXACT to the server, for mutual TLS — the server checking who is calling as well as the other way round. After uploading it, use Store private key. The key must belong to that certificate, is sealed at rest, and is never shown again; it can only be replaced. |
Paste the certificate as PEM, from -----BEGIN CERTIFICATE----- to -----END CERTIFICATE-----; a chain may follow it. You do not type the subject, issuer, validity or fingerprint — they are read from the certificate itself, so the list cannot say something the certificate does not. The list shows the days left, marks a certificate as expiring or expired, and counts how many connections use it, so you know what stops working before it does.
Test
Test on a connection makes a real, verified TLS handshake to where it points — and, for HTTPS, one request — and checks there is something to authenticate with. When it fails it says which part failed, because "could not connect" tells you nothing about what to do next.
| What Test says | What to do |
|---|---|
| The server’s certificate is not trusted | Upload the CA that issued it under Certificates and choose it as Trusted CA on the connection. |
| The certificate does not name this host | Set Server name to the name the certificate carries. |
| The server offers nothing at TLS 1.2 or above | The server has to be upgraded. TRANXACT will not go lower. |
| The server wants a client certificate | Upload a client certificate, store its private key, and choose it on the connection. |
Can we connect directly?
Check direct connect answers the question every integration starts with. It tries the host on the configured port and on the usual ones — PostgreSQL 5432, SQL Server 1433, SAP HANA 30015, 30013 and 30041, the SAP Business One Service Layer 50000, Oracle 1521 and 2484, MySQL 3306, LDAPS 636, the Active Directory global catalogue 3269, SMTPS 465, IMAPS 993, FTPS 990, AMQPS 5671, MQTTS 8883, Kafka 9093, 443 and 8443 — from the TRANXACT server’s own network, and reports which ports answer AND complete a TLS 1.2 or higher handshake.
- "A direct connection is possible", followed by the ports, services and TLS versions that worked, means you can set the connection to Direct today.
- Otherwise it says a network path is needed — a VPN, an interconnect or peering to that host — which is a conversation with whoever runs the network rather than a setting here.
The Connections list shows each connection’s transport, endpoint, the TLS version it last negotiated, and Direct connect: possible, not reachable, or not checked.
Cloud metadata addresses are never probed. They hand out the server’s own credentials to anything that asks, which is exactly why a connection test must not be a way of asking.