IEC 104 TLS (IEC 62351-3)

An IEC 104 link can be encrypted with TLS. The profile is IEC 62351-3:2023: both ends present a certificate, each checks the other’s against the CA it trusts, keys are renewed at set intervals, and revoked certificates are refused. TLS is turned on with the same fields on a Client and on a Server connection.

With TLS off the link is plain TCP and nothing about it changes. IEC 104 itself (ASDUs, t1–t3, k/w, general interrogation, commands, the event buffer) does not change with TLS either; TLS is a layer below it.

Port

The port IANA reserves for IEC 104 over TLS is 19998 (iec-104-sec). A server connection listens either with TLS or without it; serving plain and TLS clients at the same time takes two server connections on two ports.

What you need

For each end:

• Its own certificate and private key, as a PKCS#12 file (.p12 / .pfx), and its password.
• The certificate of the CA that issues the peer’s certificate, PEM or DER. Only a peer presenting a certificate from this CA is accepted.
• Optionally a CRL (revocation list), PEM or DER.

Keys must be at least RSA 2048 or a 256-bit curve (e.g. P-256); certificates are accepted up to 8192 bytes.

Configuration

The fields belong to the connection and are the same for Client and Server. The files are uploaded with the connection: the TLS (IEC 62351-3) section of the connection form, or over REST POST /api/protocols/iec104/connections/with-file and PUT /api/protocols/iec104/connections/{id}/with-file (a multipart request: connection plus the parts tlsCertificateFile, tlsCaFile, tlsCrlFile).

Field	Type	Default	Description
tlsEnabled	Boolean	off	Turns TLS on
tlsMinVersion	TLS 1.2 / TLS 1.3	TLS 1.2	The lowest version. With TLS 1.2, TLS 1.3 is offered as well; TLS 1.3 speaks 1.3 only. TLS 1.0 / 1.1 are never offered
tlsCertificateFileId	File	—	The connection’s own certificate and key (PKCS#12)
tlsCertificatePassword	Secret	—	The PKCS#12 password; never shown in any response
tlsCaFileId	File	—	The trusted CA certificates
tlsCrlFileId	File	—	Revocation list (optional)
tlsTrustMode	Any from CA / Listed from CA	Any from CA	Which peers are accepted; see Allowed peers below
tlsResumptionMinutes	Integer	360	TLS 1.2: session resumption interval (new keys, no certificate check). Must be below the renegotiation interval
tlsRenegotiationMinutes	Integer	720	TLS 1.2: full renegotiation interval; both certificates are checked again. 10 to 1440 minutes
tlsKeyUpdateMinutes	Integer	0 (off)	TLS 1.3: key update interval. See the warning below
tlsRenegotiationTimeoutMs	Integer	10000	How long a renegotiation may take
tlsRevocationCheckMinutes	Integer	1440	How often open links are checked against the CRL again
tlsRevocationGraceHours	Integer	0	How long a peer whose certificate was revoked may stay connected; 0 = closed at once

Material that cannot be used stops the connection

With TLS on, the connection does not start when the certificate or CA file is missing, a file cannot be read, the password is wrong, a key is too weak, the own certificate has expired, or the renewal settings are outside their limits; the project log says why. The connection never starts with another trust posture (e.g. without verification) instead.

The files are not backed up

The certificate, CA and CRL files are stored as sensitive files and are not put into a backup. When a backup is restored into another installation, upload them again from the connection form — as passwords are typed again.

Verification

A peer is refused and the link is not established when:

• it sent no certificate (a server always asks for the client’s certificate);
• its certificate does not chain to the trusted CA;
• its certificate has expired or is not yet valid;
• its chain holds a weak key or a certificate larger than 8192 bytes;
• in Listed from CA, its certificate is not approved in the connection’s trust list;
• the CRL lists the certificate as revoked.

A CRL that is missing, expired or not signed by the CA does not close the link; a warning is written (IEC 62351-3 6.4.4.4.2). A certificate an expired CRL lists is still treated as revoked.

The host name is not verified: field links are addressed by IP, and the peer’s identity is its certificate.

Note

A client that has no certificate from a CA the server trusts usually sends no certificate at all with most TLS stacks. The server’s log shows this as “sent no certificate”.

Allowed peers

With tlsTrustMode set to Listed from CA, a peer that passes the CA check must also be approved in the connection’s trust list (IEC 62351-3 6.4.4.3). The list is the same certificate trust list OPC UA connections use. A peer is recognised by its certificate’s serial number and issuing CA.

• A peer the CA issued but that is not on the list is refused (PEER_NOT_ALLOWED) and added to the list as pending. The project log writes “waiting for approval”.
• In the connection form, the Trusted Peers window next to the Trust Mode field approves a pending certificate, or takes a certificate file directly. The window opens on a saved connection.
• The list is read every 15 seconds. An approval takes effect at the peer’s next attempt, without restarting the connection. A peer removed from the list has its open link closed.
• When the list cannot be read, the connection does not start; it never falls back to accepting every peer the CA issued.

REST: GET /api/protocols/iec104/connections/{id}/certificates/trusted and …/pending, POST …/certificates/{entry}/trust, POST …/certificates/upload-trusted (multipart, certificateFile), DELETE …/certificates/{entry}.

CRL store

A CA usually publishes a new CRL every few days. Instead of uploading it to every connection, use the space’s CRL store:

• TLS connections add the CAs they trust to the store by themselves when they start.
• In the connection form’s TLS section, CRL Store → CAs and CRLs uploads a CRL for each CA, or sets its download address, on/off and period. Download now tries at once; the last download’s time and error show on the row.
• An empty address is filled from the CRL distribution point in a connecting peer’s certificate. Downloading starts when you turn it on.
• A CRL is taken only when the CA signed it, it has not expired and it is not older than the one in use; otherwise the reason is written and the CRL in use stays.
• Connections read the store every minute. A new CRL applies without restarting the connection, and the open links are checked against it at once; a revoked peer is closed.
• The connection’s own CRL file still applies; for one CA the newest CRL is used.

Downloads use http / https only; they never go to the server itself, a link-local address (e.g. 169.254.x.x) or a multicast address, and redirects are not followed. Connect 10 s, request 30 s, at most 10 MB. In a cluster the leader downloads.

REST: GET /api/connections/certificate-authorities, POST …/{id}/crl (multipart, crlFile), PUT …/{id}/download (url, downloadEnabled, downloadMinutes), POST …/{id}/download (download now), DELETE …/{id}.

Key renewal

Version	Mechanism	What happens
TLS 1.2	Session resumption (tlsResumptionMinutes)	The client takes new session keys; the certificates are not checked again
TLS 1.2	Full renegotiation (tlsRenegotiationMinutes)	The server asks for a renegotiation; the client starts one itself shortly after the interval if it has not been asked. Both certificates are checked again. A renegotiation that does not complete in time closes the link
TLS 1.3	Key update (tlsKeyUpdateMinutes)	New traffic keys; the certificates are not checked again

TLS 1.3 key update is off by default

IEC 62351-3 suggests a key update every 6 hours, but devices built on mbedTLS 3.6 (many lib60870-based RTUs and simulators) close the link when they receive one. Measured: the peer closes the link within 20 ms. Turn the field on only for a peer known to support it.

Because TLS 1.3 never looks at a certificate again after the handshake, revocation is checked by the application every tlsRevocationCheckMinutes: the peer certificate of each open link is checked against the CRL again, and a revoked peer’s link is closed (at the end of the grace period, if one is set).

Server: event buffer

On a server, the event buffer of a TLS client belongs to the client’s certificate (its subject and issuing CA, e.g. CN=Central SCADA (issued by CN=Plant CA)), not to its IP address. So:

• a client whose IP address changes still gets the events kept for it;
• clients behind the same NAT are not mixed up;
• a client whose certificate is renewed (same subject and CA) keeps its buffer.

The Event buffer and Clients windows of the control panel show this key.

Security events

TLS events are written to the connection’s project log. Each line carries the event and the IEC 62351-3 clause it comes from, e.g. … [IEC 62351-3 6.4.4.2, PEER_CERTIFICATE_UNTRUSTED].

Event	Log level	When
HANDSHAKE_SUCCEEDED	Information	The link is up; the version, cipher suite and peer certificate are written
HANDSHAKE_FAILED	Error	The handshake failed (no common version / cipher suite, timeout, an alert from the peer)
PEER_CERTIFICATE_MISSING	Error	The peer sent no certificate
PEER_CERTIFICATE_UNTRUSTED	Error	The peer’s certificate does not chain to the trusted CA
PEER_CERTIFICATE_EXPIRED / _NOT_YET_VALID	Error	Outside the certificate’s validity (check both clocks)
PEER_KEY_TOO_WEAK / PEER_CERTIFICATE_TOO_LARGE	Error	Weak key / certificate larger than 8192 bytes
PEER_CERTIFICATE_REVOKED	Error	The CRL revokes the certificate; the link is refused or closed
PEER_REVOKED_IN_GRACE	Warning	The certificate was revoked; the link stays up for the grace period
CRL_UNAVAILABLE / CRL_EXPIRED / CRL_INVALID	Warning	No CRL, an expired one, or one with an invalid signature; the link is not closed
SESSION_RESUMED	Information	TLS 1.2 session resumption
RENEGOTIATED	Information	TLS 1.2 full renegotiation; both certificates were checked again
RENEGOTIATION_FAILED	Error	The renegotiation did not complete; the link was closed
KEY_UPDATED	Information	A TLS 1.3 key update was sent
SESSION_FAILED	Error	A TLS layer failure on an open link

On a client connection, a refused handshake is also written as “Could not connect to the station over TLS”: the link was never established, it is not a loss.

Conformance

Supported: TLS 1.2 and 1.3, mutual authentication, AES-GCM cipher suites (ECDHE-ECDSA, ECDHE-RSA, DHE-RSA; 128 and 256 bit), TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384 for TLS 1.3, groups including secp256r1 and ffdhe2048, signature schemes without SHA-1, secure renegotiation (RFC 5746), session resumption, full renegotiation, key update, revocation by CRL with a grace period.

Not supported:

In the standard	Status
CBC cipher suites, including the mandatory TLS_RSA_WITH_AES_128_CBC_SHA256	Not offered. CBC must be used with Encrypt-then-MAC (RFC 7366), which the TLS stack in use does not provide; offering CBC without it makes a conforming peer close the link. Older devices that only know RSA key exchange cannot connect
TLS 1.3 TLS_AES_128_CCM_SHA256	Not supported. The mandatory GCM suites are offered, so a conforming peer always finds a common suite
OCSP stapling for a client certificate in TLS 1.3	Not supported; revocation is by CRL