Newer Samsung firmware rejects the AC14K_M anchor with unknown_ca: the OwnerPSK generation

[paul-toben]

Status, 2026-09-22. The title this issue opened under said two things, and one of them was wrong. Every appliance measured since, including the older ones this library was built on, binds 5683 and 5684 as well as its ephemeral secure port, so the ports never separated the generations; 0.1.18 reads the secure port from /oic/res on 5683 for all of them (#98). What does separate them is the second half: this generation answers an AC14K_M client certificate with unknown_ca (a bare SHA-256 leaf too; the self-signed default from #95 has not been offered to one yet), and the credential it accepts is a per-appliance OwnerPSK. The connection findings are in docs/ocf-pki-laundry.md; the credential path is being built in mbillow/localthings#435; certificate pass/fail reports by model go to #99; the F09 laundry build has its own thread at #110. This issue stays open as the record for the generation until the library carries that credential.

Device model

Samsung Bespoke AI Combo Washer/Dryer — WD53DBA900HZ (device cert issued 2025-02-23)

Summary

This newer-generation unit isn't reachable by the library's current approach, for two reasons: it uses different ports and a different trust anchor.

1. It exposes OCF on the standard CoAP ports, not the 49152–49160 range

If I run the documented compatibility check of nmap on ports 49152–49160, this device is completely silent across that whole range. Its OCF stack is on the standard ports instead:

• udp/5683 (plain CoAP) — responds, but every resource is locked: GET /.well-known/core → 4.01, GET /device/0 → 4.03
• udp/5684 (coaps / CoAP-over-DTLS) — live DTLS server, returns a proper ServerHello

2. The DTLS endpoint rejects the AC14K_M cert — different PKI

Handshake to 5684 with an AC14K_M-signed leaf (minted by setup_cert.py) fails with an unknown ca alert. It's on Samsung's OCF Root PKI, not the RemoteAccessCA/AC14K_M family:

Device leaf: CN=OCF Device: Appliance SE (04700f20-…), OU=OCF HA Device, O=Samsung Electronics
  └ issuer: Samsung Electronics OCF HA Device SubCA v1
     └ issuer: Samsung Electronics OCF Root CA

So the AC14K_M that works on older appliances appears to be closed on this generation — even reaching the right port (5684) still gets rejected at client-cert validation.

I'm not sure if there's any path forward here.

[QuiteYellow]

Thanks, for sharing this. Before writing this generation off, I want to push on the one inference that isn't nailed down, because it's burned me on the older appliances.

A device presenting an OCF-Root server cert doesn't tell you what client cert it accepts. Those are separate trust stores. The appliances where setup_cert.py works today also present a leaf chained to Samsung's OCF Root CA, same as yours, and they still accept an AC14K_M client cert for mutual auth. So the thing to pin down is the unknown_ca, not the server chain.

And unknown_ca needs care, because on my own hardware it's fired for reasons unrelated to the CA:

• Cipher list: this firmware's mbedtls chokes on long multi-cipher ClientHellos and can reject before the cert is evaluated. openssl s_client offers a broad list by default. Retry with a single suite (ECDHE-ECDSA-AES128-GCM-SHA256 is what the older units take).
• SHA-1 / security level: the whole AC14K_M chain is SHA-1/RSA (AC14K_M, RemoteAccessCA, CECA, all sha1WithRSAEncryption). Two ways that bites. Your OpenSSL client at default seclevel may refuse to send a SHA-1 cert at all, which looks like a server rejection; add @SECLEVEL=0 to rule that out. And newer firmware may reject SHA-1 in its verify path, or only accept ECDSA client certs. The retest below shows which: its CertificateRequest lists the sig-algs it'll take.
• Wedge: after a handful of failed handshakes these stacks wedge and return unknown ca / handshake_failure to everything until they recover (minutes) or power-cycle. If you've been retrying, a fresh result needs a cold device.

One clean attempt on a freshly power-cycled unit:

openssl s_client -connect <device-ip>:5684 -dtls1_2 \
  -cipher 'ECDHE-ECDSA-AES128-GCM-SHA256@SECLEVEL=0' \
  -cert client.pem -key client.key -CAfile fullchain.pem \
  -showcerts -msg 2>&1 | head -60

-msg is the part that matters: it shows whether your OpenSSL actually put its Certificate on the wire before the alert. Alert after your Certificate flight is a real server-side rejection, and your read holds. No cert sent (seclevel), or a death mid-ClientHello (cipher), is an artifact, and there's still a door.

The alert code then tells you why a real rejection happened. unknown_ca (48) is specifically "issuer not in my trust store". A hash or algorithm refusal is usually bad_certificate (42) or handshake_failure (40). To isolate the leaf-hash case, re-mint just the leaf -sha256 and retry: if the alert changes, leaf hash was the gate; if it's identical, it wasn't.

What this device accepts for client certs is the open question, and the CertificateRequest in that -msg output is where to read it.

That onboarding surface is the other cheap test. You hit /.well-known/core (4.01) and /device/0 (4.03) on 5683 but not the security resources. OCF usually leaves /oic/sec/doxm world-readable so an onboarding tool can find the device pre-ownership; if it answers, it returns the device UUID and ownership state (owned, devowneruuid, owner-transfer methods). owned:false or a live RFOTM state means there's a provisioning surface; owned:true pinned to a hub means it's sealed. Small dependency-free probe below, read-only, IP and UUIDs redacted by default so it's safe to paste back:

python3 coap_sec_probe.py <device-ip>

Firmware version from the SmartThings app (device page, three dots, Information) would help too. Please leave the serial off that screen.

coap_sec_probe.py: minimal plain-CoAP security-resource probe, read-only, redacted

#!/usr/bin/env python3
"""Minimal, dependency-free plain-CoAP (no DTLS) probe of the OCF
security resources on udp/5683. Read-only GETs only.

Output is redacted by default (target IP and any device UUIDs are
masked) so it's safe to paste directly into a GitHub issue/comment.
Pass --reveal to see real values while debugging locally.
"""
import re
import socket
import struct
import sys
import time

try:
    import cbor2
    HAVE_CBOR = True
except ImportError:
    HAVE_CBOR = False

URI_PATH, ACCEPT = 11, 17
UUID_RE = re.compile(r'[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}')

REVEAL = '--reveal' in sys.argv


def redact(text, host):
    if REVEAL:
        return text
    text = text.replace(host, '<target-ip>')
    return UUID_RE.sub('<uuid-redacted>', text)


def _vlen(v):
    if v < 13:
        return v, b''
    if v < 269:
        return 13, bytes([v - 13])
    return 14, struct.pack('>H', v - 269)


def encode_options(opts):
    out = b''
    prev = 0
    for n, val in sorted(opts, key=lambda x: x[0]):
        d, dx = _vlen(n - prev)
        l, lx = _vlen(len(val))
        out += bytes([(d << 4) | l]) + dx + lx + val
        prev = n
    return out


def parse_coap(data):
    mt = (data[0] >> 4) & 0x03
    tkl = data[0] & 0x0F
    code = data[1]
    mid = int.from_bytes(data[2:4], 'big')
    tok = data[4:4 + tkl]
    i = 4 + tkl
    payload = b''
    opts = []
    prev = 0
    while i < len(data):
        b = data[i]
        if b == 0xFF:
            payload = data[i + 1:]
            break
        d_nib, l_nib = b >> 4, b & 0x0F
        i += 1
        if d_nib == 13:
            delta = 13 + data[i]; i += 1
        elif d_nib == 14:
            delta = 269 + int.from_bytes(data[i:i + 2], 'big'); i += 2
        else:
            delta = d_nib
        if l_nib == 13:
            length = 13 + data[i]; i += 1
        elif l_nib == 14:
            length = 269 + int.from_bytes(data[i:i + 2], 'big'); i += 2
        else:
            length = l_nib
        num = prev + delta
        opts.append((num, data[i:i + length]))
        i += length
        prev = num
    return mt, code, mid, tok, opts, payload


def printable_strings(data, minlen=4):
    out, cur = [], b''
    for b in data:
        if 0x20 <= b < 0x7f:
            cur += bytes([b])
        else:
            if len(cur) >= minlen:
                out.append(cur.decode())
            cur = b''
    if len(cur) >= minlen:
        out.append(cur.decode())
    return out


def build_get(segs, mid, tok):
    opts = [(URI_PATH, s.encode()) for s in segs]
    opts.append((ACCEPT, b'\x3c'))  # application/cbor
    return bytes([0x40 | len(tok), 1, mid >> 8, mid & 0xFF]) + tok + encode_options(opts)


def go(sock, host, port, label, segs, wait=4):
    go.mid = getattr(go, 'mid', 0x4000) + 1
    mid = go.mid
    tok = bytes([mid & 0xFF])
    msg = build_get(segs, mid, tok)
    print(redact(f"-> {label}  (plain CoAP GET /{'/'.join(segs)} to {host}:{port})", host))
    sock.sendto(msg, (host, port))

    deadline = time.time() + wait
    while time.time() < deadline:
        try:
            sock.settimeout(max(0.1, deadline - time.time()))
            data, _ = sock.recvfrom(65535)
        except socket.timeout:
            break
        except OSError as e:
            # ICMP port-unreachable etc. surface here on some platforms.
            print(f"   socket error: {e}\n")
            return None, None
        if len(data) < 4:
            continue  # too short to be a CoAP message; ignore
        try:
            mt, code, rmid, rtok, opts, payload = parse_coap(data)
        except (IndexError, ValueError) as e:
            print(f"   unparseable {len(data)}B reply, ignored ({e})")
            continue
        kind = ['CON', 'NON', 'ACK', 'RST'][mt]
        # Match on BOTH message-id and token, and only trust a reply we
        # actually correlate. Samsung's stack often empty-ACKs then sends
        # the real answer as a separate packet, and slow/oo responses to
        # an earlier request will otherwise be misread as this one's.
        matched = (rmid == mid) or (rtok == tok and len(tok) > 0)
        tag = "MATCH" if matched else "stray/other-req"
        print(f"   <- mid={rmid:#06x} tok={rtok.hex()} type={kind} code={code >> 5}.{code & 0x1F:02d} {len(payload)}B [{tag}]")
        if mt == 0:  # CON: ack it so the device doesn't retransmit
            sock.sendto(bytes([0x60, 0x00, rmid >> 8, rmid & 0xFF]), (host, port))
        if matched:
            if kind == 'ACK' and code == 0 and not payload:
                continue  # empty ACK, real answer is a separate packet — keep waiting
            if payload:
                if HAVE_CBOR:
                    try:
                        print("      " + redact(repr(cbor2.loads(payload))[:600], host))
                    except Exception:
                        print("      strings:", [redact(s, host) for s in printable_strings(payload)])
                else:
                    print("      strings:", [redact(s, host) for s in printable_strings(payload)])
            print()
            return code, payload
    print("   TIMEOUT (no correlated reply — re-run; a lone empty ACK here is not a 'no')\n")
    return None, None


def main():
    args = [a for a in sys.argv[1:] if not a.startswith('--')]
    if not args:
        sys.exit(f"usage: {sys.argv[0]} <ip> [port=5683] [--reveal]")
    host = args[0]
    port = int(args[1]) if len(args) > 1 else 5683

    sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    print(redact(f"=== Plain CoAP security probe of {host}:{port} (no DTLS, no cert) ===\n", host))
    probes = [
        ("/oic/res (resource + sec-flag enumeration)", ['oic', 'res']),
        ("/oic/sec/doxm (owner + UUID; often world-readable)", ['oic', 'sec', 'doxm']),
        ("/oic/sec/pstat (provisioning/onboarding state)", ['oic', 'sec', 'pstat']),
    ]
    for label, segs in probes:
        # Isolate each probe so one bad reply doesn't abort the rest.
        try:
            go(sock, host, port, label, segs)
        except Exception as e:
            print(f"   probe failed, continuing: {e}\n")
    sock.close()


if __name__ == '__main__':
    main()

[paul-toben]

Here is everything the Smartthings app shows under software for this device:

I ran the checks on a freshly power-cycled unit, and captured the same handshake against a working fridge (setup_cert.py authenticates to it, 2.05) for comparison.

Here are the results from coap_sec_probe.py on the Washer, plain CoAP 5683

/oic/sec/doxm : {'oxms': [2, 65282], 'oxmsel': 65282, 'sct': 1, 'owned': True,
                 'deviceuuid': <redacted>, 'devowneruuid': <redacted>, 'rowneruuid': <redacted>}
/oic/sec/pstat: {'isop': True, 'cm': 0, 'tm': 0, 'om': 4, 'sm': 4, ...}

owned:true, isop:true. oxmsel is 65282 (0xFF02, vendor-specific); oxms also lists 2 (mfgcert). /oic/res returns oic.d.washer plus the Easy Setup resources (oic.r.easysetup, WiFiConfResURI, CoapCloudConfResURI, DevConfResURI, x.com.samsung.accesspointlist).

And here are the certificate requests on this combo Washer/Dryer vs my working fridge

Washer (5684) — rejects our cert, unknown_ca (48):

certificate_types:               rsa_sign, ecdsa_sign
supported_signature_algorithms:  ecdsa+sha256, rsa+sha256
certificate_authorities:         CN=Samsung Electronics OCF Root CA
                                 CN=Samsung Electronics OCF Root CA TEST

Fridge (49154) — accepts the same AC14K_M cert:

certificate_types:               rsa_sign, ecdsa_sign
supported_signature_algorithms:  ecdsa+sha256, rsa+sha256, ecdsa+sha1, rsa+sha1
certificate_authorities:         CN=Samsung Electronics OCF Root CA
                                 CN=Samsung Electronics OCF Root CA TEST

The advertised certificate_authorities is identical on both, and the fridge accepts AC14K_M while advertising that same list, so I don't think the CA list is what's gating the washer. The one CertReq difference is sig-algs: the fridge lists SHA-1, the washer is SHA-256 only.

The washer's alert is unknown_ca (48) rather than bad_certificate, which reads more like "issuer not trusted" than a hash-policy reject, so it may be the device's actual trust store (/oic/sec/cred, which I didn't touch) lacking the AC14K_M chain, with the SHA-256-only sig-algs as a second data point.

On your checks: our Certificate goes on the wire before the alert; cipher negotiates ECDHE-ECDSA-AES128-GCM-SHA256 on both. I tried re-signing the SHA-256 leaf and it returned the same unknown_ca.

Thanks for looking into this. It'd be great to get working, but I'm not holding my breath. I just hope this isn't the way new Smartthings devices are headed.

[paul-toben]

One more thing to add... if I repeatedly scan nmap on the ports 49152-49160, usually I get all of the ports reporting closed. But every once in a while I'll get a smattering of ports showing open|filtered. Occasionally I'll even see all of those ports open at the same time.

[jjyn0215]

Does your washer has any opened TCP port?

[noisymime]

FWIW I'm seeing this same behavior on a Family Hub fridge from 2024, model RF65A9770B1/SA

udp/5683 and udp/5684 are open and the ports in the 49152-49160 range seem to randomly open and close. Sometimes they're all open, sometimes it's none, other times it's just 1 or 2 of them. The cert verification against port 5684 gives:

[+] DTLS handshake to 192.168.0.213:5684...
    SSL error: [('SSL routines', '', 'tlsv1 alert unknown ca')]

Firmware on it is Tizen 7.0, 20250818.225446

Does your washer has any opened TCP port?

It appears to have a single tcp port open, 17654. Has a http server running on it, but everything I tried (Including root) returns a 404 .

[noisymime]

And in case it helps, here's the output of coap_sec_probe:

=== Plain CoAP security probe of <target-ip>:5683 (no DTLS, no cert) ===

-> /oic/res (resource + sec-flag enumeration)  (plain CoAP GET /oic/res to <target-ip>:5683)
   <- mid=0x4001 tok=01 type=ACK code=2.05 421B [MATCH]
      strings: ['bdix$<uuid-redacted>elinks', 'dhrefm/oic/sec/doxmbrt', 'joic.r.doxmbif', 'ooic.if.baselineap', 'csec', 'dport', 'rx.org.iotivity.tls', 'dhrefn/oic/sec/pstatbrt', 'koic.r.pstatbif', 'ooic.if.baselineap', 'csec', 'dport', 'rx.org.iotivity.tls', 'dhreff/oic/dbrt', 'hoic.wk.dbif', 'ooic.if.baselinehoic.if.rap', 'csec', 'rx.org.iotivity.tcp', 'dhreff/oic/pbrt', 'hoic.wk.pbif', 'ooic.if.baselinehoic.if.rap', 'csec', 'rx.org.iotivity.tcp']

-> /oic/sec/doxm (owner + UUID; often world-readable)  (plain CoAP GET /oic/sec/doxm to <target-ip>:5683)
   <- mid=0x4002 tok=02 type=ACK code=2.05 213B [MATCH]
      strings: ['doxms', 'foxmsel', 'csct', 'eowned', 'jdeviceuuidx$<uuid-redacted>ldevowneruuidx$<uuid-redacted>jrowneruuidx$<uuid-redacted>brt', 'joic.r.doxmbif', 'ooic.if.baseline']

-> /oic/sec/pstat (provisioning/onboarding state)  (plain CoAP GET /oic/sec/pstat to <target-ip>:5683)
   <- mid=0x4003 tok=03 type=ACK code=2.05 157B [MATCH]
      strings: ['disop', 'jdeviceuuidx$<uuid-redacted>jrowneruuidx$<uuid-redacted>brt', 'koic.r.pstatbif', 'ooic.if.baseline']

[QuiteYellow]

Following up on the sig-algs angle: I think this closes out AC14K_M specifically.

paul-toben's re-sign test is the tell: a fresh SHA-256 leaf got the identical unknown_ca alert. If the leaf's hash were the problem, that should have changed. It didn't, which points at the rest of the chain: AC14K_M, RemoteAccessCA, and CECA are all SHA-1, and none of us can re-sign those without Samsung's intermediate keys. A supported_signature_algorithms list of SHA-256 only fits a firmware that now enforces SHA-256 across the whole chain, not just the leaf. That means the handshake fails before identity is ever checked.

One cheap thing still worth trying: a bare SHA-256 leaf with no intermediates at all. Different test than the re-sign, since it tells us whether the device already trusts AC14K_M as a cached intermediate. Not expecting it to change the conclusion, but it's cheap.

My guess is diagnostics didn't go away. That'd be a strange thing for Samsung to drop entirely, since techs need some way in. More likely AC14K_M specifically got retired because it's a leaked credential, and got replaced by something that can't leak the same way: probably per-request, account-authenticated issuance rather than a bundled static cert. If so, there's probably still a path in, just not this one.

For anyone who wants to dig further: libocpmapi.so in the SmartThings app exports a function called OCCloudCertificateIssueRequest, a strong hint about where the replacement logic lives. I didn't chase it past confirming the name.

If anyone gets a device freshly paired through the official app and can capture what that provisioning traffic looks like (sanitized, no tokens or device UUIDs), that'd answer this fastest. Otherwise I'd treat AC14K_M as closed, but not the broader question.

[Jason-Morcos]

I have this exact appliance and was able to fully get this working locally (yes, it was a pain to do so) - I've got an approach now that's been stable for about a week, with no dropping or resets. I'm working on opening a series of PRs to this repo to get it supported here too

#25 (comment) is the first of the PRs explicitly for this machine
I have ~7 samsung appliances and this was definitely one of the toughest ones to get working in a stable way
I was able to get it working locally without breaking the SmartThings cloud though - it's definitely possible

[QuiteYellow]

@Jason-Morcos thank you for the PRs (#21–#25), this is great to see. Looking forward to getting the stack merged into main so more people here can test it against their own units.

@paul-toben this is your exact appliance, so once it lands it'll be worth a try. I'll keep the issue open until then.

[paul-toben]

@QuiteYellow Thanks. I'll keep an eye out for the PRs as this develops. It's exciting to see so much work around this project.

@Jason-Morcos the one thing I'm concerned about is if the appliance can still be factory-reset in after the OCF ownership change, and get it back into a state where it could be re-onboarded to Smartthings.

I'm also curious if you think this method can stand up to future firmware updates/changes from Samsung.

[Jason-Morcos]

Hey @paul-toben - I can confirm the appliance can still be factory-reset back to SmartThings (I had to do it several times in testing haha)!
Also, the way I have it implemented it actually doesn't break SmartThings connectivity at all. In fact, breaking smart things connectivity seems to cause weird device resets.

The only downside with the laundry machines so far is that they seem to not support Observe so they have to be manually polled.

As to Samsung - I think Samsung could make all of these different approaches significantly more difficult, if they really wanted to. That being said, it seems unlikely they go through the effort of trying to do so given in many cases it would require fairly substantial security revamps to block these workarounds. But it is within the realm of possibility imo that they find a way to block this.

[DUC750]

Second Family Hub data point for this thread (EU unit), because it differs from @noisymime's in two ways that look relevant to the endpoint-discovery work in #36.

1. The secure endpoint is not 5684 here — it is advertised, and it is not in the 4915x band either.

GET /oic/res on udp/5683 answers 2.05 and the sec-flagged links carry dport: 46060. Not 5684, not 4915x. Verified stable across 3 consecutive reads and again two days later, so it is not a per-boot ephemeral value on this unit:

run 1: 1024 B, dport = [46060]
run 2: 1024 B, dport = [46060]
run 3: 1024 B, dport = [46060]

A DTLS ClientHello to that port gets a live server:

depth=1  CN=Samsung Electronics OCF HA Device SubCA v1, OU=OCF HA Device SubCA, O=Samsung Electronics, C=KR
depth=0  CN=OCF Device: Appliance SE (<redacted>), OU=OCF HA Device
         PKEY: id-ecPublicKey, 256 bit; sigalg: ecdsa-with-SHA256

So for this unit a probe list of 5684 + 49152-49160 would come up empty on all ten ports while the device is sitting there answering on 46060. Reading dport out of /oic/res is the only thing that finds it — which is exactly what #36 is doing, so mainly posting this as a concrete case that the fixed candidate list would miss.

2. The security resources are locked on this one, unlike @noisymime's Family Hub.

Same read-only plain-CoAP GETs, different answers:

/oic/res            2.05   (rt: oic.wk.d + oic.d.refrigerator; Easy Setup resources present:
                            oic.r.easysetup, WiFiConfResURI, DevConfResURI, ...)
/oic/sec/doxm       4.01
/oic/sec/pstat      4.01
/oic/d              4.01
/.well-known/core   4.01
/device/0           4.01

@noisymime's unit returned 2.05 on doxm/pstat with owned / oxmsel / UUIDs visible. Mine returns 4.01 on both, so no ownership state or OTM method list to report from here. That lockdown pattern looks closer to @paul-toben's WD53 (/.well-known/core 4.01, /device/0 4.03) than to the other fridge — which suggests "Family Hub" is not one profile, and the readable-doxm case may not be something to rely on across the class.

3. Minor, on the flapping 4915x ports.

49152-49160 are consistently closed here — actively refused with ICMP port-unreachable, 3/3 runs. Worth flagging one measurement trap I hit: my first sweep showed 49152/udp open|filtered, which was purely the target's ICMP error rate limit suppressing one of the nine replies. With --scan-delay 1s and one port per run it is reproducibly closed. Given @paul-toben and @noisymime both report ports that "randomly open and close", some of that may be the same artifact rather than genuinely transient listeners — cheap to rule out with a scan delay before reading anything into it.

What I did not do: I never minted or presented a client certificate, so I have no alert class to contribute — I cannot confirm unknown_ca on this unit myself, and the OCF-PKI classification above is inferred from the server chain alone. All reads were plain unauthenticated GETs; no writes and nothing touched beyond the resources listed.

Happy to run further read-only probes on this unit if that would help characterise the fridge side of this class. Model/firmware details I can add from the app if useful.