Two ARCs, one app
Two ARC devices from the fleet. The phone running the ARC View app tries to open its two connections to each one: the REST API (port 443) and the EMP channel (port 10443). The only difference between the two ARCs is their certificate.
Each ARC is its own simulated server: a separate machine running a real TLS stack with the ARC's cipher preferences and certificate. The phone is another simulated server running the same TLS engine as the ARC View app (BoringSSL, via Flutter's dart:io); it reaches the ARCs through a tunnel, like a phone on the ARC's own network.
Look inside the handshake
Every secure connection starts with a handshake: the phone and the ARC agree how to protect the session and the ARC proves who it is. Here you watch that conversation step by step, and see which other devices can connect.
Fix it on ARC #3
ARC #3 is yours to change. It starts exactly like the failing ARC. Pick a fix; the lab applies it to the ARC and immediately re-runs the connection test from every device.
Real-world certificates
The lab asked Let's Encrypt, a public certificate authority, for real certificates for ARC #3's own hostname. Compare what a public authority puts in the Key Usage field with what the failing ARC carries.
Issued by Let's Encrypt for ARC #3's hostname, live, during the lab's setup.
Each option installs the certificate on ARC #3, sets its firmware, and tests from all devices.
Build your own certificate
Design a certificate for ARC #3, choose what the ARC firmware supports, read the prediction, then test it. This is the fastest way to feel why the Key Usage field matters.
Appendix
For the engineers: the exact enforcement point, the raw data behind the last run, the ARC-side handshake log, and a glossary of every term used in the labs.
BoringSSL enforces Key Usage on the client in ssl/handshake_client.cc, function do_send_client_key_exchange: for an RSA key-exchange cipher suite the leaf certificate must permit keyEncipherment, otherwise digitalSignature (ssl_cert_check_key_usage, error SSL_R_KEY_USAGE_BIT_INCORRECT). Chrome reports it as ERR_SSL_KEY_USAGE_INCOMPATIBLE. A certificate without the extension passes. Semantics: RFC 5280 §4.2.1.3 and RFC 5246 §7.4.2.
Real observations (native iOS test, 8 Oct 2026): the working ARC negotiated TLS_RSA_WITH_AES_128_CBC_SHA on 443 and TLS_RSA_WITH_AES_256_GCM_SHA384 on 10443 with a "Wavetronix Arc" certificate carrying no Key Usage; the failing ARC presented "Wavetronix Device" with Key Usage = Digital Signature + Content Commitment and never completed the handshake. The simulated ARCs reproduce those cipher preferences per port.
OpenSSL's server-purpose check accepts a certificate if any of Digital Signature, Key Encipherment or Key Agreement is set, which is why curl and openssl s_client connect. Python's default ssl context and Go 1.22+ no longer offer RSA key-transport suites at all.
Stand-ins: iOS cannot run on Linux. Dart/BoringSSL (Flutter's engine on iOS and Android) and Chrome represent the native iOS result documented in the PDF.
(run a lab first)
What the ARC recorded for every connection of the last run.
(run a lab first)