{
  "test_id": "T46",
  "verdict": "pass",
  "observed": "istioctl proxy-config listener 덤프에서 mutual-gw:9443 리스너의 requireClientCertificate가 true로 확인됐다. 사이드카를 가진 mesh client(DestinationRule ISTIO_MUTUAL로 outer mTLS 자동 발신, SNI=outbound_.9443_._.mutual-gw...cluster.local, SAN 검증 대상=spiffe://cluster.local/ns/istio-vt-t46/sa/mutual-gw)는 http_code=200을 받았다. 사이드카가 없는 non-mesh-caller가 같은 리스너에 curl -k로 접속하자 HTTP 상태 코드 없이(000) curl exit 56으로 종료됐고, verbose 로그에는 TLSv1.3 알림 'certificate_required'(OpenSSL error:0A00045C)가 명시적으로 찍혀 클라이언트 인증서 미제시로 인한 handshake 단계 거부임이 직접 확인됐다. 단, 원본 매니페스트 그대로는 (1) Gateway server protocol: TCP에 tls 스탠자를 넣어 admission webhook에 거부됐고 (2) DestinationRule/VirtualService host가 svc.homelab.local이라 istiod의 실제 서비스 레지스트리(svc.cluster.local 접미사, global.proxy.clusterDomain 미설정)와 매칭되지 않아 DR이 바인딩되지 않는 두 가지 환경 결함이 있었으며, 이를 각각 protocol: TLS + tcp: 라우트, host를 svc.cluster.local로 수정한 뒤에야 위 결과를 관찰했다(모두 매니페스트 fix일 뿐 mTLS 메커니즘 자체는 그대로).",
  "claims": [
    {
      "doc": "blog:egress_crd-mental-model",
      "cid": "C7",
      "empirical": "supports-claim",
      "note": "requireClientCertificate:true 직접 확인 + mesh CA 발급 SAN(spiffe://cluster.local/ns/.../sa/mutual-gw) 검증까지 cluster_test로 실증, 문서의 'confirmed' 판정을 그대로 뒷받침."
    },
    {
      "doc": "blog:security_egress-mtls-identity-control",
      "cid": "C5",
      "empirical": "supports-claim",
      "note": "문서가 '정확한 실패 형태는 문서만으로 확정 불가'라 명시했던 부분을 TLSv1.3 alert 'certificate_required'로 정밀 확인 -- 인증서 미제시 시 handshake 자체가 거부됨을 실증."
    },
    {
      "doc": "gw__guide-egress-adoption-passthrough-vs-mtls",
      "cid": "C3",
      "empirical": "supports-claim",
      "note": "mesh client(사이드카+DR)는 200으로 handshake·트래픽 통과, non-mesh 호출자는 handshake 단계에서 즉시 거부(exit 56, TLS alert)로 대비가 명확히 관찰됨."
    }
  ]
}