@cptel — short answer: no, the nRF91 modem doesn’t pin or cache leaf certs. It validates the chain on every handshake against whatever roots/intermediates are in your sec_tag. So a rotated leaf is a non-issue as long as it still chains to a root the modem trusts. Claude’s writeup is correct about how chain validation works in general, but the “device pinned the old leaf” path doesn’t apply here.
More importantly, your log rules out a TLS problem entirely:
[00:02:05.838,470] <inf> downloader: Connecting to 52.239.253.132
[00:02:06.287,231] <dbg> downloader: dl_socket_close: Socket closed, fd 4
[00:02:06.296,661] <err> downloader: Failed to connect, err -111
That’s ECONNREFUSED on connect() — the failure happens at TCP, 450ms after the socket opens, before any TLS handshake bytes are exchanged. If it were a cert problem (rotated leaf, missing intermediate, expired root, cipher mismatch) you’d see the connection succeed at TCP and fail later with a TLS-specific error like -116 (ETIMEDOUT during handshake) or a modem_key_mgmt / peer-verify error.
A few things that do match -111 against an Azure Blob endpoint:
- The IP changed and your modem is talking to a stale one. 52.239.253.132 is one of many Azure Front Door / Blob frontends, and they rotate. If your firmware is hitting a hard-coded IP, or DNS got cached at the modem level, you can end up dialing an address that no longer answers on 443. Confirm by re-resolving the hostname from a laptop right now and comparing.
- Azure storage firewall / network rules. If the storage account has “Selected networks” or a private endpoint enabled, anything outside that allowlist gets refused at the LB. Check the storage account → Networking blade.
- SAS / container ACL flipped to private. A blob that’s no longer publicly readable (or a SAS token that expired) won’t refuse TCP — but if the rules above were toggled at the same time, you’d see exactly this.
- Operator / APN egress filtering. Some cellular APNs block specific ranges or require an explicit allowlist. Less likely if it was working last week and nothing changed on the SIM side, but worth ruling out by trying a different APN or hitting a known-good HTTPS host with
https_client.
Quickest triage path:
# from a laptop, on the same URL the device uses
curl -v https://<account>.blob.core.windows.net/<container>/<blob>
nslookup <account>.blob.core.windows.net
If curl works and resolves to a different IP than 52.239.253.132, you’ve got stale DNS or a hard-coded address. If curl also fails with connection refused, it’s the storage account’s network config.
Once you’ve got TCP connecting again, then the cert/cipher checklist from my earlier post becomes relevant — but I’d bet this one is network, not crypto.
