Safety: use a test relay or a test server on a test network only, never a relay in service.
State: verified against libiec61850 1.6.2 with mbedtls 3.6.0 on Linux (TLS 1.3 and 1.2, client certificates from PEM and PKCS#12, a cipher list, a pin, and every refusal below), and against Node's own TLS server for session resumption. A capture of a TLS session showed only the TLS handshake and application data, with the ACSE password not in the captured bytes. Not run against a relay, and not on Windows.
TLS runs on the Editor's own Node runtime; no extra runtime or driver is needed.
Build a TLS connection profile
- Run Connect to IED Online... and pick the IED.
- Choose MMS over TLS (IEC 62351-3), usually TCP port 3782. The address is proposed with
:3782; any port can be typed. - Trust: Pick the CA certificates of <file>... and pick the station's CA certificates (PEM, or DER
.cer). Optionally give a SHA-256 fingerprint to pin the IED's certificate; a pin can also stand alone in place of the CA bundle. Turning both off is not offered. - Client certificate: PEM certificate and key files... (one file or two, with the passphrase if the key has one), or a PKCS#12 file with its password.
- Name check: Check that the certificate names <address>, or a name you give.
- TLS versions: TLS 1.2 or 1.3, or one of them only.
- Cipher list: leave empty for the defaults, or give an OpenSSL cipher list.
- ACSE password: No ACSE password, asked at each connection, or stored.
The IED Online tab then shows how the connection is secured, for example: "TLS 1.3, TLS_AES_256_GCM_SHA384. IED certificate CN=..., issued by CN=..., verified against the station's CA, name checked. Client certificate CN=...". The Energy output channel shows the same, with the IED's certificate fingerprint.
Every check runs before any MMS byte is sent. Sessions are resumed from an in-memory cache of sessions whose certificate passed every check. Over TLS one MMS request is sent at a time.
Where credentials are kept
- Connection profiles (address, port, TLS settings) are kept in the workspace state, without secrets.
- Secrets (the station's CA bundle, your client certificate and key with its passphrase, and an ACSE password you choose to keep) are kept only in the Editor's secret storage, encrypted with a key the operating system keeps. They are never in settings or the workspace folder. Where the operating system offers no key store, the secret storage keeps them in memory until the Editor closes, and the connect flow says so.
- An open connection keeps its ACSE password and TLS options in the window's memory only, for Reconnect; they go when the connection or the window closes.
- No agent tool can read a certificate, key, fingerprint or password.
Who may hold which IED credential, role and access policies, and the audit of credential use belong to Neural Inverse Govern.
When a connection is refused
The message names what failed and the certificate presented:
| Message says | What to do |
|---|---|
| "... not signed by the station's CA certificates in this connection profile ..." | The profile's CA bundle is wrong; Edit Connection Profile... and pick the station's CA |
| "... presented an expired certificate" | The IED's certificate has expired |
| "... does not name the address connected to" | Connect by the name the certificate gives, or give that name in the profile |
| "... not the one pinned" | The pin does not match the IED's certificate |
| "... ended the TLS session right after the handshake ... this usually means it does not accept this client certificate" | With TLS 1.3, the IED refuses your client certificate |
| "... refused the TLS connection: access denied (TLS alert 49)" | With TLS 1.2, the IED refuses your client certificate |
| "... closed the connection during the TLS handshake. It may not speak TLS on this port ..." | Check the IED's TLS port, or use Plain MMS if the IED offers no TLS |
| "The client certificate's key could not be opened: the passphrase is wrong" | Enter the right passphrase or PKCS#12 password |
No cipher suite in common, and no client certificate where the IED requires one, are refused with their own messages.
On Windows
Keys in the Windows certificate store, on smart cards or in a TPM cannot be used. Export your client certificate with its private key from certmgr.msc (Personal, Export, "Yes, export the private key") as a .pfx file, and the station's CA certificates as Base-64 .cer files, then pick them in the profile. This has not been run on Windows.
Limits
- Requests go one at a time over TLS.
- No cipher suite list is claimed to be the one IEC 62351-3 requires: unless the profile gives a list, the IED picks among Node's defaults.
- Renegotiation follows what Node's client allows (TLS 1.2, server-initiated); TLS 1.3 has none.
- Certificate revocation lists, OCSP, IEC 62351-4 end-to-end security and IEC 62351-8 role certificates are not read.
Not verified
- A relay, and Windows (certificate export steps included).
- Session resumption against an IED (the libiec61850 test peer resumed no session).
- The secret storage with a real operating system key store (the tests use the in-memory one).