Encrypt the connection, and keep the credentials out of reach

Until 4.00 this page would have had to say that transport encryption was on the roadmap. That is no longer the case: 4.01 encrypts connections, and — for InterSystems IRIS and Caché, where setting TLS up used to mean a properties file, keytool and a restart — walks you through it.

The other half of the same subject is the credential. A connection is not protected by an encrypted transport if the password behind it sits in a file anyone can copy off the machine. Both halves changed in this release.

The TLS tab

Both connection dialogues — the InterSystems one and the generic JDBC one — have a TLS tab with the same three settings:

Alongside them sit Trust the server certificate and an expected certificate host name for generic JDBC connections, and an SSL configuration name for IRIS and Caché. When a handshake fails, the message says what happened and which of these switches addresses it — the difference between a five-minute fix and an afternoon with a packet capture.

One consequence worth knowing before you update: SQL Server and Azure SQL connections now follow the Microsoft driver's own default, which is encrypted with certificate verification. Up to 4.00 every SQL Server connection was forced to be unencrypted. For a server with a self-signed certificate, choose Encrypted (TLS) plus Trust the server certificate; for a server that offers no TLS, choose No encryption and the connection behaves as it did before. More on that path in Azure SQL and Fabric.

The TLS assistant for IRIS and Caché

Encrypting an InterSystems JDBC connection has historically involved writing an SSL configuration file by hand, building a trust store with keytool, getting the host name check right, and restarting the client to find out whether any of it worked. The assistant does the sequence for you and ends with the only test that matters.

Open it from Assistant… on a connection's TLS tab, or from Settings > InterSystems IRIS / Caché > TLS > Set up…. It has four steps:

1. Choose a source for the server certificate: fetch it from the server, import a PEM, DER or P7B file you already have, or use an existing .p12/.jks trust store. Each option has its own fields grouped directly underneath it; host and port sit in their own section above, because the host name check and the test connection need them whichever route you pick.
2. Confirm the certificate. For a fetch, this is trust-on-first-use, and the assistant says so: it shows the chain — subject, issuer, validity, SHA-256 fingerprint — together with the plain statement that a fetch proves only what the other endpoint presented, not that it is the right endpoint. Verify the fingerprint out of band before you trust it. The default button on that dialogue is Cancel, and there is no checkbox or timer to click past.
3. Name the section and preview it. You see the exact lines that will be appended and which file they go into. The assistant only ever appends — it never rewrites or reorders a line someone wrote by hand, and never overwrites an existing trust store.
4. Apply and test. Before the test, a SAN pre-check asks whether the host you connect to is listed as a DNS entry in the certificate — the same check the driver makes, caught here instead of at the bottom of a stack trace later. It warns rather than blocks; the button becomes Try anyway. Then the trust store is written, the section appended, SSL configuration file set, and a real test connection run.

The closing report repeats the fingerprint for your records, and is explicit about one boundary that is easy to get wrong: the trust store it just built covers the IRIS or Caché superserver connection. It does not apply to the Atelier REST endpoint that the Source Code tab and the Classes actions use, which is a separate HTTPS endpoint with its own trust store.

The TLS settings page also gained a Validate… button that checks an existing configuration file and reports what is wrong with it — the fastest answer to "this worked last month". And SSL configuration file takes effect as soon as you save it. No restart.

Passwords protected by Windows, not by the application

Stored connection passwords are protected with Windows DPAPI. Windows encrypts them against your own Windows user profile, so the key is no longer part of the application. Two things follow from that, and both are the point:

• A copied or backed-up config.json no longer gives up your passwords. Previously the protection travelled with the file, which meant it was not really protection at all.
• Another Windows account on the same machine cannot read them, even with access to the file.

Migration happens by itself on the first start — nothing is lost, and you keep connecting without typing anything. Because the protection is bound to the computer and the Windows account that saved it, a configuration you move to a different machine or account keeps every connection and asks once for each password. Two related pieces of housekeeping come with it: Tools > Encode all Server Passwords is gone, because protecting a password still stored in clear text now happens by itself while the configuration loads; and Tools > Remove legacy configuration files… lists the old files that still hold passwords in the pre-4.01 format, with each file's path, size and the reason it is listed, and deletes nothing until you confirm. Your current config.json is never touched.

Or store nothing at all

Never save the password is a switch on the new Password tab of the connection properties, with a default for newly created connections under Settings > Connections. With it on, no password is written for that connection: SQL DATA LENS asks once and keeps it for the running session only. For an organisation whose policy simply forbids stored credentials, setting the default once ends the discussion.

Sharing a connection without sharing a credential

The usual way a team distributes connection details is a screenshot of a dialogue, or a colleague reading a port number aloud. Team profiles replace that: Export server profile… on a connection or a whole group writes a readable *.sdlprofile.json that you can put on a share, attach to a mail or paste into a wiki, and Add server from profile… reads it back with a preview of what it is about to create.

It carries no password at all — not obfuscated, not encrypted, absent. The person importing it enters their own credentials on the first connect, which is also the correct answer for auditing. Importing an updated profile asks what to do with a connection of the same name: update it and leave everything local as it is, import it as a copy, or skip it.

Once a connection is shared, the next question is what people are allowed to do with it. That is environments and read-only: a Production classification, a colour, and a guard that refuses writes.

What this does not cover

Transport encryption and credential storage are two of the questions a security review asks, not all of them. The rest — what leaves the machine, what is installed on the database server, telemetry, signed binaries, the bundled JRE — is on security and privacy, which also lists every outbound connection the application makes. If you need those answers on letterhead rather than on a web page, write to sales@sqldatalens.com.

Next step

The TLS assistant is the part that is hard to believe until you have watched it work. Download SQL DATA LENS, open the TLS tab on an IRIS connection, and let it fetch, check, write and test in one pass.