Post by baltzer on ICertificateVerifier.VerifyCertificate doesn't appear to override an ERR_CERT_HAS_EXPIRED rejection in TCP_Client.Upgrade() ^{CODESYS Forge talk (Post)}
Setup: Net Base Services (NBS), TCP_Client + TLSContext, ePurpose := CLIENT_SIDE, connecting to a third-party embedded device (Velux KLF200 home automation gateway) whose factory-installed TLS certificate expired on 2026-07-12 and has no user-facing renewal path. Tested on both CODESYS Control for Raspberry Pi SL (3.5.19.0) and CODESYS Control Win V3 x64, with identical results on both. Goal: Accept the peer's expired certificate via a custom ICertificateVerifier implementation, since the certificate itself can never be replaced. Implementation: FUNCTION_BLOCK FB_MyCertVerifier IMPLEMENTS NBS.ICertificateVerifier VAR udiCallCount : UDINT; aeCurStateLog : ARRAY[0..9] OF NBS.RTS_IEC_RESULT; END_VAR METHOD VerifyCertificate : UDINT VAR_INPUT hCert : NBS.RTS_IEC_HANDLE; eCurState : NBS.RTS_IEC_RESULT; END_VAR IF udiCallCount < 10 THEN aeCurStateLog[udiCallCount] := eCurState; END_IF udiCallCount := udiCallCount + 1; VerifyCertificate := 0; // also tried: VerifyCertificate := eCurState; Wired in via tlsContext.itfCertVerifer := certVerifier at declaration time, alongside itfTLSContext := tlsContext set at TCP_Client's own declaration (per an earlier forum thread here on ensuring inline start-values on FB-typed variables are actually honored when nested one level deep - that fix was needed and worked correctly for getting the handshake to start at all). Observed: - VerifyCertificate is confirmed called exactly once per connection attempt (via the call counter above). - eCurState passed in = 0x709 = ERR_CERT_HAS_EXPIRED - correctly reflecting the actual state of the peer's certificate. - Packet capture confirms the full TLS 1.2 handshake completes correctly at the wire level: ClientHello -> ServerHello -> Certificate -> ServerKeyExchange -> ServerHelloDone -> our ClientKeyExchange/ChangeCipherSpec/Finished -> server's ChangeCipherSpec/Finished. Both sides successfully complete the cryptographic handshake. - Despite this, TCP_Client.Upgrade() subsequently returns NBS.ERROR.CONNECTION_ERROR, and the connection is torn down with a plain TCP FIN (not a TLS alert) roughly 7-8ms after our side ACKs the server's Finished message. - TCP_Client.eErrorID (inherited from LCon) remains NO_ERROR throughout - the failure is only visible via Upgrade()'s return value. - Returning 0 (ERR_OK/ERR_CERT_OK - confirmed via the CmpErrors2 Interfaces documentation that these are literally the same value) makes no difference. - Echoing eCurState back unchanged (on the theory that this callback might work like mbedTLS's native verify callback, where the incoming state is a flags value to be cleared/modified and returned, rather than paired with a separate fixed "accept" sentinel) also makes no difference. - Identical result across udiVerificationMode := 0, 1, and 2. - Importing the peer's certificate into the runtime's trusted certificate store via cert-import trusted makes no difference either. - With itfCertVerifer left at its default (no custom verifier) and udiVerificationMode := 2, the underlying engine sends its own fatal TLS alert (handshake_failure) immediately after receiving the peer's Certificate message - suggesting built-in validation may reject at the record layer independent of whether a custom verifier is even present. Questions: 1. Is there an additional step required for a custom ICertificateVerifier to actually override an ERR_CERT_HAS_EXPIRED (or more generally, any ERR_CERT_*) rejection, or is certificate validation enforced unconditionally for a CLIENT_SIDE TLSContext regardless of what the verifier returns? 2. Is 0/ERR_OK genuinely the correct "accept" return value for VerifyCertificate, or does it expect something else (a specific bit pattern, a different constant, a value that must be computed from hCert itself)? 3. Is there a supported way to connect to a peer presenting a certificate that is both self-signed and expired, short of the peer issuing a new certificate? Happy to share the full packet captures or additional test combinations if useful. Also worth noting for anyone finding this thread later: a maintained Node-RED library for this same device (node-red-contrib-velux-klf200, forked to handle this exact expired-certificate situation) solves it by disabling built-in TLS validation entirely (rejectUnauthorized: false) and doing fingerprint-based pinning by hand after the handshake completes, rather than relying on a validation callback - which may be the more realistic approach here too if ICertificateVerifier genuinely can't override this class of rejection. Thanks in advance /Jørgen Disclosure: most of the CODESYS code and this investigation was developed with the help of Claude (Anthropic's AI assistant) - the state machine design, SLIP/checksum implementation, and debugging methodology (including the packet capture analysis) were worked through in an extended back-and-forth with it. Posting here because we've run out of self-serviceable options and this now looks like it needs input from someone with visibility into NBS's actual implementation.
Last updated: 2026-07-26

Post by brouwyka on JSONByteArrayWriter string result incorrect order ^{CODESYS Forge talk (Post)}
Hello everybody! We are currently working on implementing a call to an API that tracks data sent to it through a JSON body. Versions: CODESYS V3.5 SP19 Patch 7 using IIOT Libraries SL license, specifically JSON Utilities SL version 1.13.0.0. For simplicity, let's say we want to construct the following JSON body for our request (simplified to just 1 key-value pair in each of the array objects to keep things shorter, but we'd have multiple fields in each in reality): { "id": "machine_1", "readings": [ { "temp_mid": 153.8 }, { "temp_mid": 98.3 } ], "status": "RUNNING" } However, our "readings" data is added over time, not in creation, so calls to the builder would be somewhat out of order. In a simplified manner, our calls would look like this: jsonBuilder(pJsonData := JsonData, diRootObj => rootJsonIndex); // rootJsonIndex = 0. // Set "id" at root JSON object. wsValue := "machine_1"; jsonBuilder.SetKeyWithValue("id", wsValue, diParentIndex := rootJsonIndex); // JSONData KEY: diParentIndex = 0 & diIndex = 1, VALUE: diParentIndex = 1 & diIndex = 2. // ... Time passes, we get our first reading to add ... // The "readings" array does not exist yet, so we make it first at root JSON object before adding our first reading. readingsJsonArrayIndex := jsonBuilder.SetKeyWithArray("readings", diParentIndex := rootJsonIndex); // JSONData KEY: diParentIndex = 0 & diIndex = 3, VALUE: diParentIndex = 3 & diIndex = 4. // Then add the first reading, for which we first have to make an object. readingsJsonArrayObjectIndex := jsonBuilder.SetObject(diParentIndex := readingsJsonArrayIndex); // JSONData OBJECT: diParentIndex = 4 & diIndex = 5. // And then we add the field(s) in the object for the first reading. // NOTE the use of `readingsJsonArrayObjectIndex` so we set the field(s) in the first object in the array. rValue := 153.8; jsonBuilder.SetKeyWithValue("temp_mid", wsValue, diParentIndex := readingsJsonArrayObjectIndex); // JSONData KEY: diParentIndex = 5 & diIndex = 6, VALUE: diParentIndex = 6 & diIndex = 7. // ... Time passes, we want to add another root-JSON-level field ... // Set "status" at root JSON object. wsValue := "RUNNING"; jsonBuilder.SetKeyWithValue("status", wsValue, diParentIndex := rootJsonIndex); // JSONData KEY: diParentIndex = 0 & diIndex = 8, VALUE: diParentIndex = 8 & diIndex = 9. // ... Time passes, we want to add a second reading ... // "readings" array exists, so add the second reading, but first we have to make another object. // NOTE the re-use of the earlier stored `readingsJsonArrayIndex`, so we add the new object to that previously created array. readingsJsonArrayObjectIndex := jsonBuilder.SetObject(diParentIndex := readingsJsonArrayIndex); // JSONData OBJECT: diParentIndex = 4 & diIndex = 10. // And then we add the field(s) in the object for the first reading. // NOTE the use of `readingsJsonArrayObjectIndex` so we set the field(s) in the SECOND(, new) object in the array. rValue := 98.3; jsonBuilder.SetKeyWithValue("temp_mid", wsValue, diParentIndex := rootJsonIndex); // JSONData KEY: diParentIndex = 10 & diIndex = 11, VALUE: diParentIndex = 11 & diIndex = 12. // ... Finally, we want to send to the API, so we must convert the builder to data the client accepts as a body ... xTestWriteToJsonArray := TRUE; jsonArrayWriter( xExecute := xTestWriteToJsonArray, pwData := ADR(jsonDataString), udiSize := SIZEOF(jsonDataString), jsonData := JsonData^ ); IF jsonArrayWriter.xDone THEN // The writer was successful, the `jsonDataString` VAR should now contain a WString copy of the JSON object from the builder. xTestWriteToJsonArray := FALSE; END_IF We see that the JsonData STRUCT is correctly organised (in terms of the diParentIndex & diIndex set by it for each JsonElement) as we expect, as outlined in my comments in the simplified code above. However, as soon as we pass it to the jsonArrayWriter (which is a JSON.JSONByteArrayWriter), the resulting jsonDataString does not match our expectations, instead coming out like this: { "id": "machine_1", "readings": [ { "temp_mid": 153.8 } ] } { "temp_mid": 98.3 } "status": "RUNNING" The behaviour of the JSONByteArrayWriter thus seems to be the problem here. It does not seem to correctly process the children of JsonElements that are ARRAYs when additions to them are done broken up by additions to the lower level JSON OBJECT they are a part of. We have confirmed this by changing the order of the calls in our example to add both readings before adding the "status", in which case we get our expected outcome. However, in reality this is not possible for us - additions to any of the JSON's objects, arrays or array objects may happen at any time after other fields elsewhere in the JSON have been added. Does anyone know a way around this, a fix, or knows a solution we simply have not found? This same phenomenon was also noted on this forum by user @ryusoup at the end of 2023 (https://forge.codesys.com/forge/talk/Engineering/thread/c45929e2f1/#e27f) and user @mtho in early 2024 (https://forge.codesys.com/forge/talk/Engineering/thread/cd1bb450db/#1292) but both topics received no activity beyond both users' opening posts. Looking through the release notes of all the versions of the JSON Utilities SL library, I also did not see any remarks on resolutions of bugs in this vain. Thanks in advance for the assistance!
Last updated: 2026-06-10

Sort by relevance or date