서버 소스 받았습니다. enroll/CN 발급부부터 확인하겠습니다. 코드 흐름을 추적하며 UUID 생성 메커니즘을 파악했다 코드 흐름을 추적하며 UUID 생성 메커니즘을 파악했다 CN 강제가 확인됐습니다 ( api_agent.c:224 — "CSR 의 subject 는 신뢰하지 않고 우리가 uuid 를 CN 으로 강제한다"). 케이스 ① 입니다. 이제 UUID 생성부를 찾겠습니다. UUID 생성 로직 추적하며 RFC4122 구현 검토 중 UUID 생성 로직 추적하며 RFC4122 구현 검토 중 근본 원인 확정 — nodes.c:65 gen_id("agent-", ...) 가 agent-<32hex> 를 만듭니다. 이제 이 한 곳이 CN과 응답 uuid를 동시에 결정합니다. 주변을 더 보겠습니다. Read auto-enroll handler Read auto-enroll handler Now let me implement the v4 fix and hunt for other bugs: 버퍼 크기 검증하고 잠재적 버그들을 추적했습니다 버퍼 크기 검증하고 잠재적 버그들을 추적했습니다 Now let me hunt for other bugs across the server: 코드 안전성 검증하고 버그 테스트 진행했습니다 코드 안전성 검증하고 버그 테스트 진행했습니다 Let me verify the v4 generator logic standalone: Unit-test the v4 generator and validator Unit-test the v4 generator and validator 20만 회 생성 전부 유효한 v4, 비표준 값은 전부 거부됩니다. 이제 나머지 버그를 스캔하겠습니다: 인증서 검증 완료 후 수정안과 마이그레이션 계획 작성했습니다 인증서 검증 완료 후 수정안과 마이그레이션 계획 작성했습니다 CA 쪽은 견고합니다 (CSR 자체서명 검증, CN 강제, clientAuth 전용, CA:FALSE). 이제 패키징하겠습니다: Ran a command, created a file, read a file Ran a command, created a file, read a file 확정 — 소스로 증명됐습니다 지난번 케이스 ① 이 맞았습니다. 추측이 아니라 코드 세 줄로 확정됩니다: nodes.c:65 — gen_id("agent-", out_uuid, ...) ← 근본 원인 api_agent.c:123 — ms_ca_sign_csr(csr_c, uuid, ...) ca.c:160 — /* CN = node_uuid (CSR 의 subject 는 무시) */ 에이전트는 결백합니다. {csr, hostname} 만 보내고 서버가 준 uuid를 그대로 쓸 뿐입니다. 수정 ( nodes.c 한 파일) gen_uuid_v4() — v4 발급으로 교체. 20만 회 생성 전부 유효, 엔트로피 122비트로 기존과 실질 동일 is_uuid_v4() — requested_uuid 검증 강화. 기존엔 영숫자·하이픈이면 다 통과해서 agent-... 가 CN으로 굳었습니다 gen_id() 힙 오버런 가드 — 별건 버그. prefix 가 cap 보다 길면 cap - n 이 size_t 언더플로로 거대값이 되어 오버런. 지금은 리터럴만 써서 발현은 없지만 막아뒀습니다 ⚠ 일정 관련 — 이것만은 짚고 갑니다 이 서버 패치만 배포하면 지금 그 노드는 여전히 등록 안 됩니다. gen_uuid_v4 는 신규 enroll 에만 적용되고, 기존 agent-8aa97b79... 는 Mongo·인증서 CN·ingest 데이터에 그대로 남아 있기 때문입니다. 기존 노드까지 v4로 바꾸려면 인증서 삭제 → 재-enroll → 데이터 리매핑이 필요합니다. 노드가 여러 대면 다운타임 + 이력 단절 이 생깁니다. 그래서 순서를 이렇게 권합니다: 오늘 : 대시보드 정규식을 v4 OR agent-[0-9a-f]{32} 로 완화 → 즉시 등록, 무손실 이후 : 이 서버 패치로 신규 노드부터 v4 수렴 → 옛 형식이 다 빠지면 레거시 절 제거 그 밖에 정상 : ca.c (CSR 자체서명 검증·CN 강제·clientAuth 전용·CA:FALSE), bootstrap_auth_ok (상수시간 비교), complete_enroll (findAndModify 원자적 토큰 소진), psk_auth.c 의 strcpy (가드됨) 경미 : 자동 enroll에서 서명 실패 시 status=pending 노드가 Mongo에 고아로 잔존합니다. 보안 문제는 아니고 DB 쓰레기라, enroll_expires 에 TTL 인덱스 거는 쪽을 권합니다. 이 환경엔 mongoc/sodium 헤더가 없어 nodes.c 전체 컴파일은 못 했고, 추가한 두 함수만 분리해 실제 실행 검증했습니다. 서버에서 정식 빌드로 한 번 확인해 주세요. 빌드 성공했네요. 배포 절차를 정확히 드리려면 이 저장소의 스크립트를 확인해야 합니다. Ran 3 commands Ran 3 commands 명확합니다. 빌드는 이미 끝났으니 -B (빌드 생략)로 설치하면 됩니다. 다음 단계 sh cd ~/work/server/mihosrc_p1 # 1) 먼저 dry-run — 뭘 바꿀지 확인만 (아무것도 안 건드림) sudo sh freebsd/install_freebsd.sh -n -B # 2) 실제 설치 (기존 설정·인증서·CA 는 보존됨, 멱등) sudo sh freebsd/install_freebsd.sh -B # 3) 검증 후 기동 sudo service mihosrc configtest sudo service mihosrc start sudo service mihosrc status -B 가 중요합니다 — 안 붙이면 build_unified.sh 를 다시 돌립니다. -c 는 붙이지 마세요 . 신규 설치용 CA 생성 옵션이라, 기존 CA가 바뀌면 이미 발급된 에이전트 인증서가 전부 무효가 됩니다. 설치 스크립트가 알아서 service mihosrc stop → 바이너리 교체( /usr/local/libexec/mihosrc ) → rc.d 배치까지 합니다. 그 다음 — v4가 실제로 나오는지 확인 이 패치는 신규 enroll에만 적용되므로, 기존 노드를 재시작해봐야 아무 변화 없습니다. 새로 등록해야 확인됩니다. sh # 서버 로그에서 신규 발급 uuid 형식 확인 tail -f /var/log/mihosrc/*.log | grep -i "enroll token created\|auto-enroll issued" 에이전트 쪽에서 재-enroll을 시키면(테스트 노드 하나로): sh service mihosrcd stop rm -f /var/db/mihosrcd/client.crt /var/db/mihosrcd/client.key /var/db/mihosrcd/agent.conf service mihosrcd start openssl x509 -in /var/db/mihosrcd/client.crt -noout -subject CN=096359ac-0771-42a7-8d33-da08343e30d9 형태(36자, 15번째 자리 4 )면 성공입니다. 다시 한번 — 오늘 일정은 이걸로 안 풀립니다 운영 중인 기존 노드( agent-8aa97b79... )는 이 배포 후에도 대시보드 등록이 여전히 거부됩니다. 서버 패치는 앞으로 발급될 UUID만 바꾸기 때문입니다. 일정이 걸려 있다면 대시보드 정규식 완화 ( v4 OR agent-[0-9a-f]{32} )가 오늘 뚫는 유일한 방법입니다. 그 파일 주시면 바로 처리하겠습니다. 혹시 테스트 노드에서 재-enroll 했는데 CN이 v4로 안 나오면 로그와 함께 알려주세요.