https://gitlab.synchro.net/main/sbbs/-/issues/1148#note_10069

Second real-world hit, different module — `letsyncrypt.js --force` Ran into this same error via `letsyncrypt.js --force`, which seems like a textbook fit for the same-host-repeat-request pattern described above: an ACME renewal against `acme-v02.api.letsencrypt.org` needs several sequential HTTPS calls to that one host (directory, order, challenge, finalize), so I suspect this is hitting the same TLS-session-cache issue rather than a bug in `letsyncrypt.js` itself. Environment Synchronet 3.21e, Windows 11 Pro, Version 25H2 (OS Build 26200.8973) `letsyncrypt.ini`: `TOSAgreed=true`, existing registered ACME account (`\[key\_id]` present, live account on `acme-v02.api.letsencrypt.org`), pre-existing `letsyncrypt.key` ACME HTTP-01 challenge webroot confirmed reachable (nginx passthrough for `/.well-known/acme-challenge/` added ahead of the existing redirect, verified with `nginx -t` and a full service restart) Repro `jsexec letsyncrypt.js --force`, run 3 separate times, all 3 failed identically:

```
!JavaScript C:\\sbbs\\exec\\load\\http.js line 147: Error: Unable to read status
exit\_code 1
```

Run times varied (8.25s, 1.44s, 1.43s) — consistent with real work/multiple round-trips happening before hitting the repeat-request wall, not an instant reject. For reference, a plain `jsexec letsyncrypt.js` (no `--force`) exits cleanly (errorlevel 0) in \~0.2s with none of the intermediate progress output seen in other successful runs — almost certainly a no-op (no renewal due), not evidence the underlying path works. Happy to provide full logs or `letsyncrypt.ini` (redacted) if useful for narrowing this down further.

---
ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/work_items/1148#note_10771

Probable root cause filed as #1311.

When cryptlib resumes a cached TLS session to a host it has already connected to, the handshake carries no server certificate. `js_socket.cpp` then fails to fetch the certificate (`CRYPT_ERROR_NOTFOUND`, -43), treats that as an error, and closes the socket. That explains why the first HTTPS request to a host works and later ones fail (`http.js` then throws `Unable to read status`), and why a request to a different host in between doesn't help. Under jsexec on Windows the underlying TLS error was never shown: JS socket log output was dropped there until 45782f780d (roses-15-films, 2026-10-25).

A sysop on DOVE-Net SYNC is hitting the same error in a running BBS, logged as `TLS ERROR 'Requested item not found in object' (-43) getting remote certificate`. #1311 has the cryptlib details and a proposed fix for review. Not yet confirmed on Windows; re-running the repro above on a build that includes 45782f780d should show the -43 error if this is the cause.

-- *Authored by Claude (Claude Code), on behalf of @rswindell*

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net