Hi WantClue,
first off: thanks for keeping the BitForge Nano fully open — great little dual-BM1370 machine.
Request: could BitForgeOS pick up ESP-Miner mainline's third Stratum TLS mode, "TLS (Custom CA certificate)"?
Current behaviour (firmware v1.5)
The pool settings only offer No TLS and TLS (Bundled CA). With Bundled CA the firmware verifies the pool certificate against the public CA bundle — which means it can never connect to a self-signed certificate, the standard setup for self-hosted solo pools on a home LAN (our dvb-WarpPool, public-pool instances, etc. all auto-generate self-signed certs, since LAN hosts can't get public CA certs for .local names).
On the pool side every connection attempt shows up as:
WARN tls handshake failed peer=192.168.x.y:nnnnn error=received fatal alert: BadCertificate
(reproduced with a BitForge Nano v1.5 against a rustls-based pool; TLS 1.2 and 1.3 handshakes from other clients work fine, so it is purely the certificate verification.)
What mainline already has
ESP-Miner upstream ships exactly this as a third radio option plus a PEM textarea/upload:
- UI:
main/http_server/axe-os/src/app/components/pool/pool.component.ts — tlsOptions value 2, label "TLS (Custom CA certificate)", with the certificate field in pool.component.html
- Transport:
components/stratum/stratum_api.c — CUSTOM_CRT branch calling esp_transport_ssl_set_cert_data(...)
So this is mostly a matter of pulling those bits into the BitForgeOS build.
Why it matters
Until then, Nano owners who run a self-hosted pool have to keep the Nano on plain :3333 while their other miners (with custom-CA or no-verify firmwares) use TLS. We've documented the limitation and workarounds in our pool handbook, but the proper fix lives in the firmware.
Happy to test a beta build against our pool (rustls, self-signed ECDSA P-256, TLS 1.2/1.3) — just ping me.
Thanks!
Hi WantClue,
first off: thanks for keeping the BitForge Nano fully open — great little dual-BM1370 machine.
Request: could BitForgeOS pick up ESP-Miner mainline's third Stratum TLS mode, "TLS (Custom CA certificate)"?
Current behaviour (firmware v1.5)
The pool settings only offer No TLS and TLS (Bundled CA). With Bundled CA the firmware verifies the pool certificate against the public CA bundle — which means it can never connect to a self-signed certificate, the standard setup for self-hosted solo pools on a home LAN (our dvb-WarpPool, public-pool instances, etc. all auto-generate self-signed certs, since LAN hosts can't get public CA certs for
.localnames).On the pool side every connection attempt shows up as:
(reproduced with a BitForge Nano v1.5 against a rustls-based pool; TLS 1.2 and 1.3 handshakes from other clients work fine, so it is purely the certificate verification.)
What mainline already has
ESP-Miner upstream ships exactly this as a third radio option plus a PEM textarea/upload:
main/http_server/axe-os/src/app/components/pool/pool.component.ts—tlsOptionsvalue2, label "TLS (Custom CA certificate)", with the certificate field inpool.component.htmlcomponents/stratum/stratum_api.c—CUSTOM_CRTbranch callingesp_transport_ssl_set_cert_data(...)So this is mostly a matter of pulling those bits into the BitForgeOS build.
Why it matters
Until then, Nano owners who run a self-hosted pool have to keep the Nano on plain :3333 while their other miners (with custom-CA or no-verify firmwares) use TLS. We've documented the limitation and workarounds in our pool handbook, but the proper fix lives in the firmware.
Happy to test a beta build against our pool (rustls, self-signed ECDSA P-256, TLS 1.2/1.3) — just ping me.
Thanks!