Resolving LOGO! 8.3 CMR2020 Certificate Verification Failure

Problem Overview

The Siemens LOGO! 8.3 (basic module, BM) loses secure connectivity to the CMR2020 (6GK7242-1CX10-0XB0) mobile wireless router when the router attempts to forward a TLS-protected session back into the LOGO!. The CMR2020 logs the following SMS short-message error:

ERROR Secure connection to LOGO! BM 8.3 or higher cannot be established, verification of BM certificate failed

The same condition prevents LOGO!Soft Comfort (LSC) V8.3 from establishing an online connection through the CMR tunnel even after a manual clock synchronization appears to succeed. Local access via the engineering PC on the same LAN works without errors, which rules out the BM identity certificate itself and points to a validity-window problem in the TLS handshake between the CMR2020 and the LOGO! BM.

This reference consolidates the verification procedure for the BM firmware (V1.83.01) used on the 6ED1052-1MD08-0BA1, the CMR2020 firmware line (V2.1.8 / bootstrap V2.1.0 / mobile module 13.00.106), and the LSC V8.3 engineering tool.

Affected Hardware and Firmware Matrix

If the BM is flashed back to a 1.82.xx firmware image, the CMR2020 immediately accepts the connection (no TLS handshake) and the message disappears. This confirms that the issue is not the certificate content but the way the new firmware enforces certificate-not-yet-valid / certificate-has-expired checks using the local clock of both peers.

Decoding the Error Message

The string verification of BM certificate failed is produced by the CMR2020 security module when one of three checks fails during the TLS 1.2 handshake:

1. The BM identity certificate's notBefore timestamp is later than the CMR2020's current wall-clock time.
2. The BM identity certificate's notAfter timestamp is earlier than the CMR2020's current wall-clock time.
3. The BM identity certificate's issuer chain does not match the root CA stored in the CMR2020's trust store (the .lcu container LSC exports).

Because direct local access from LSC to the BM works on the same LAN, condition (3) can be eliminated; the chain is intact and verifiable. The remaining cause is therefore a time-skew between the BM and the CMR2020 that pushes the certificate outside its validity window at the moment of the handshake.

Root Cause: Time Skew Between BM Real-Time Clock and CMR2020

The LOGO! 8.3 BM uses an internal RTC backed by a supercapacitor. After a power loss of more than approximately 72 hours the RTC drifts back to a default time near 2000-01-01. The CMR2020 has its own RTC maintained by the cellular network's NTP feed. When the BM RTC is months or years in the past:

• The BM presents a certificate with a perfectly valid NotBefore/NotAfter window in real time.
• The CMR2020 looks at the BM RTC first (because the CMR is acting as the client to the BM for the reverse tunnel) and computes effectiveNow = CMRtime - BMtime.
• If effectiveNow falls outside the certificate window, the handshake aborts with the error above.

Setting the BM to NTP client and configuring the CMR to forward the time of day is therefore not just a cosmetic step — it is the precondition that makes the BM's RTC useful for TLS validation. Even after this step, a residual lag of several seconds to minutes is normal because the CMR only pushes the time at configurable intervals.

Clock Synchronization Procedure

Step 1 - Configure the BM as NTP Client

1. In LSC V8.3 open Tools > Ethernet Connections and select the BM.
2. Switch to the Time tab and set Time synchronization to NTP client.
3. Enter the IP address of an internal NTP server (or the LAN IP of the CMR2020 — see Step 2).
4. Set Update interval to 60 s for commissioning, raise to 600 s once stable.
5. Transfer the project to the BM and observe the Date/Time field under Diagnostics > Status.

Step 2 - Configure the CMR2020 to Forward Time of Day

1. Open the CMR2020 web UI (https://<CMR-IP>) and log in with the operator password.
2. Navigate to LOGO! > Time.
3. Enable Forward time of day to LOGO!.
4. Set the push interval to 30 s for commissioning.
5. Click Apply. The BM's Date/Time field will update within one interval.

When both ends agree to within ±2 seconds the TLS handshake will succeed. A persistent lag of more than 5 s on the BM display indicates that the BM's NTP client is querying a different server than the CMR's NTP source — re-point the BM NTP field to the CMR LAN IP.

Step 3 - Allow Time for the BM to Apply the Offset

The BM does not slew its RTC by default; it applies a hard set at the next NTP poll. Plan a 5–10 minute settling window before retesting the secure tunnel.

Certificate File Handling: .lcu Versus .crt

LOGO!Soft Comfort stores the entire trust chain — root CA, intermediate CA, BM identity certificate, and the BM's RSA private key — inside a single encrypted .lcu container. The container is generated by Tools > Certificate Manager and is the only format the BM will accept in its secure-boot path.

The CMR2020's Online settings > Certificate settings dialog therefore must be pointed at the .lcu file produced by LSC. Loading a .crt derived from the LSC .res archive into the CMR trust store is not supported and will silently fail the chain check even when the underlying PEM data is valid.

Generating the .lcu Correctly

1. In LSC V8.3 open Tools > Certificate Manager.
2. Click Create new certificate and choose either Self-signed or Signed by external CA.
3. If external CA: paste the CA chain, then generate the CSR, sign it externally, and import the signed response.
4. Export as *.lcu (encrypted, password-protected).
5. Push the .lcu to the BM via Tools > Ethernet Connections > Transfer Certificate.
6. Upload the same .lcu to the CMR2020 under LOGO! > Certificate Settings > Upload .lcu.

Time Lag and Drift Budget

The default BM certificate generated by LSC V8.3 carries a 10-year validity window. The window is generous enough that drift, not absolute expiry, is the practical cause of failure. Use the following drift budget when commissioning:

Because LOGO! 8.3 uses an unsigned 32-bit seconds-since-epoch value, a battery-dead BM reports a year near 2000 and the CMR rejects the handshake as not yet valid even when the certificate itself is current. There is no software workaround other than re-synchronizing the clock before the first secure session of the day.

Verification Procedure

1. From the CMR2020 web UI open LOGO! > Connection Status. The status field must show Connected (secure) with the cipher listed as TLS_RSA_WITH_AES_128_CBC_SHA or TLS_RSA_WITH_AES_256_CBC_SHA.
2. Open the BM web UI by clicking Open LOGO! Web Page in the CMR portal. A successful render confirms the tunnel is up.
3. In LSC V8.3 choose Tools > Ethernet Connections > Go Online. The online status indicator turns green and the project tree populates within 5 s.
4. Send a forced SMS test from the CMR2020 menu Diagnostics > Send Test SMS. The expected acknowledgement from the BM must read BM Online, time-sync OK.
5. From the engineering PC browse to https://<CMR-public-IP>/logo. If the BM's own web page renders behind the CMR tunnel, the secure channel is fully validated.

If any of the five steps fails, return to Step 2 - Configure the CMR2020 to Forward Time of Day and increase the push interval to 10 s for the next iteration.

Troubleshooting Matrix

Pre-Resolution Checklist

• Verify both BM and CMR firmware against the matrix above.
• Confirm that the .lcu is the one referenced inside the active LSC project — re-export after any certificate change.
• Confirm that the BM is set to NTP client and that the NTP server IP is reachable from the BM's Ethernet interface.
• Confirm that the CMR2020 has Forward time of day to LOGO! enabled and that the cellular NTP feed is current.
• Allow a 10-minute settling window before re-testing.

Background: Why the Clock Matters in TLS

Transport Layer Security requires both peers to make a binary decision on certificate validity at the moment the certificate is presented. The notBefore and notAfter fields are compared against the peer's local clock. If either comparison fails, the certificate is rejected, the handshake is aborted, and the higher-level protocol (in this case the CMR2020 reverse tunnel) reports a verification failure rather than a network failure. Synchronized clocks are therefore a hard requirement for any TLS-protected industrial remote-access tunnel — the same principle that drives clock synchronization in IT networks applies unchanged to the OT side once TLS enters the picture. The CMR's NTP client, the BM's NTP client, and the cellular base-station time feed together form a chain that must close to within the certificate validity tolerance.

Field-Proven Caveats

• Do not rely on the BM's onboard supercapacitor for long-term RTC retention; treat it as a worst-case 72-hour hold-up and re-synchronize on every cold start.
• The CMR2020 cellular module version (13.00.106 in this case) does not change the TLS behavior but does affect which NTP servers are reachable — newer cellular firmware adds additional fallback NTP sources.
• If the BM is installed behind a managed switch with Spanning Tree, allow at least 30 s after link-up before the first TLS attempt; the BM's IP stack resolves ARP only after the port goes forwarding.
• The .lcu container is tied to the LSC project; cloning the container into a different project produces a mismatched BM identity and the CMR2020 will reject it as untrusted.
• Logging into the BM web UI does not require the .lcu — only the reverse tunnel initiated by the CMR2020 does.

FAQ