로그가 결정적입니다. relay가 x1a의 클라이언트 인증서를 정상적으로 받아들이고 있습니다: lws_tls_server_accept: client cert CN 'agent-19445f8dbe4b94b030f3261454fa0ff9' 이 줄이 세 번(각 재시도마다) 찍혔다는 건 — mTLS 인증서 검증은 통과 했다는 뜻입니다. CN이 정상 인식됐고, 거부(reject/deny) 로그도 없습니다. 그리고 whitelist.csv 는 아예 파일이 없어서 whitelist는 문제가 아닙니다(있으면 없다고 거부됐을 텐데, 그런 로그 없음). 즉 인증서·whitelist는 다 통과했는데, 그 직후에 x1a 쪽에서 read failed 로 끊깁니다. 이건 relay가 거부하는 게 아니라, TLS 핸드셰이크는 됐는데 그 다음(WebSocket 업그레이드 응답)을 x1a가 못 읽는 상황입니다. 핵심 의심 — HAProxy 443 패스스루가 양방향으로 안 통함 client cert CN 이 relay에 찍혔다는 건 x1a→relay 방향(TLS ClientHello + 클라이언트 인증서)은 relay까지 갔다는 겁니다. 그런데 x1a가 read failed (응답을 못 읽음)라는 건 relay→x1a 되돌아오는 방향 에서 끊긴다는 뜻입니다. 가장 유력한 원인: HAProxy 443 SNI 패스스루의 타임아웃/모드. relay는 WSS(장기 연결)인데, HAProxy https_passthrough_front 가 mode tcp 는 맞지만 client 타임아웃이 짧으면 (defaults의 timeout client 30s 가 아니라 즉시 끊길 수도) 핸드셰이크 직후 끊을 수 있습니다. 특히 mТLS 인증서 요청/응답 왕복이 지연되면. 확인 — x1a에서 relay까지 mTLS 왕복이 실제로 되나 x1a에서 클라이언트 인증서를 실어서 직접 핸드셰이크해봅니다: sh sudo openssl s_client -connect relay.ap1.mihosrc.com:443 -servername relay.ap1.mihosrc.com \ -cert /var/lib/mihosrcd/client.crt \ -key /var/lib/mihosrcd/client.key \ -CAfile /var/lib/mihosrcd/ca.crt 2>&1 | head -30 핸드셰이크 완료( Verify return code: 0 또는 인증서 체인 표시 + 연결 유지) → TLS는 정상. 그럼 read failed 는 WebSocket 레벨(경로/헤더) 문제. 중간에 끊기거나 verify error → 그 메시지가 원인. relay.crt 재발급 (당신이 하려던 것) X509 err 62 (hostname mismatch)는 아까 넘어갔지만, relay.crt에 relay.ap1.mihosrc.com 이 SAN에 없으면 검증 완화( MIHO_INSECURE )로만 넘긴 거라 근본 해결이 아닙니다. 제대로 하려면 재발급이 맞습니다. CA는 절대 안 건드리고 relay.crt/key만: sh # 서버(7490fb) — 기존 CA로 relay.crt만 재발급 (SAN 포함) cd /etc/miho # 1) CA 타임스탬프 기록 (나중에 안 바뀌었는지 확인용) ls -l ca.crt ca.key # 2) relay 키 + CSR (SAN 에 실제 도메인) openssl ecparam -name prime256v1 -genkey -noout -out relay.key.new openssl req -new -key relay.key.new -out /tmp/relay.csr \ -subj "/CN=relay.ap1.mihosrc.com" \ -addext "subjectAltName=DNS:relay.ap1.mihosrc.com,DNS:relay.mihosrc.com" # 3) 기존 CA 로 서명 (825일) openssl x509 -req -in /tmp/relay.csr \ -CA ca.crt -CAkey ca.key -CAcreateserial \ -days 825 -sha256 \ -extfile <(printf "subjectAltName=DNS:relay.ap1.mihosrc.com,DNS:relay.mihosrc.com\nkeyUsage=digitalSignature,keyEncipherment\nextendedKeyUsage=serverAuth") \ -out relay.crt.new # 4) 확인 — SAN 들어갔나 openssl x509 -in relay.crt.new -noout -subject -ext subjectAltName # 5) 교체 mv relay.crt relay.crt.bak; mv relay.crt.new relay.crt mv relay.key relay.key.bak; mv relay.key.new relay.key chown sysadmin:sysadmin relay.crt relay.key chmod 0400 relay.key # 6) CA 안 바뀌었는지 재확인 (타임스탬프 그대로여야 함) ls -l ca.crt ca.key 재발급 후 서버 재기동 + x1a에서 MIHO_INSECURE 제거하고 재시도: sh # 서버 pkill -x mihosrc; sleep 2 set -a; . /etc/miho/mihosrc.env; set +a mihosrc all 2>&1 | tee /tmp/mihosrc_debug.log # x1a — insecure 뺐는지 확인하고 sudo sed -i '/MIHO_INSECURE/d' /etc/mihosrcd/enroll.env sudo systemctl restart mihosrcd grep "\[cmd\]" /var/log/mihosrcd.log | tail -6 정리 (지금 상태): enroll ✅ / 443 연결 ✅ / mTLS 클라이언트 인증서 relay 통과 ✅ ( client cert CN 로그가 증거) / whitelist 무관(파일 없음) 남은 것: 핸드셰이크 직후 read failed — relay.crt SAN 미비 (근본) + 되돌아오는 경로 문제 가능성 relay.crt 재발급 이 맞는 방향입니다(위 절차, CA 절대 유지 ). 재발급 후에도 read failed 가 계속되면, 위 openssl s_client (클라이언트 인증서 실어서) 결과를 주세요 — TLS 왕복이 되는지 보면 relay 문제인지 HAProxy 패스스루 문제인지 갈립니다. 먼저 재발급하고 openssl x509 -in /etc/miho/relay.crt -noout -ext subjectAltName 에 relay.ap1.mihosrc.com 이 들어갔는지 확인 → 서버 재기동 → x1a 재시도. 그 [cmd] 로그 주시면 다음을 짚겠습니다.