Newer Samsung firmware uses standard OCF ports (5683/5684) + non-AC14K_M trust anchor

[paul-toben]

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.