mTLS 실패는 “서버 인증서”가 아니라 양쪽 신뢰의 어긋남이다
상호 TLS는 서버와 클라이언트가 서로의 인증서를 검증한다. 그래서 일반 TLS와 달리, 실패가 클라이언트 인증서 쪽이나 어느 한쪽의 CA 번들에서 나기 쉽다. 어느 방향이 거부했는지부터 가른다.
1) 어느 쪽이 상대를 신뢰 못 하나
서버가 tls: bad certificate를 던지면 서버의 clientCA 번들에 클라이언트 인증서의 발급 CA가 없는 것이다. 반대로 클라이언트가 unknown authority면 클라이언트가 서버 CA를 모른다. 로그 방향을 먼저 읽는다.
openssl s_client -connect <host>:<port> -cert client.pem -key client.key -CAfile ca.pem2) SAN·아이덴티티 불일치
서비스 메시(mTLS)는 흔히 인증서의 SAN(DNS 또는 SPIFFE ID)로 상대를 식별한다. 인증서는 유효한데 SAN이 기대한 서비스 아이덴티티와 다르면 핸드셰이크 후 인가에서 막힌다. openssl x509 -in cert.pem -noout -text로 SAN을 확인한다.
3) CA 로테이션 타이밍
CA를 교체하는 중이라면, 새 CA로 서명한 인증서를 아직 옛 CA만 신뢰하는 피어에 제시해 실패한다. 로테이션은 “새 CA를 양쪽 trust에 먼저 배포 → 그다음 새 인증서 발급” 순서여야 한다. 과도기에는 두 CA를 모두 신뢰 번들에 둔다.
확인·복구
실패 방향 확인 → 그쪽 trust 번들에 상대 CA 추가 → SAN/아이덴티티 일치 → 로테이션이면 두 CA 병행 신뢰. 양쪽 체인이 fullchain으로 제시되는지도 함께 본다.
빠른 진단 체크리스트
- 어느 방향이 상대를 거부했는지 로그로 먼저 가른다
- bad certificate면 서버 clientCA 번들에 클라 CA가 없는 것이다
- 클라가 unknown authority면 서버 CA를 모르는 것이다
- SAN(DNS·SPIFFE ID)이 기대 아이덴티티와 같은지 본다
openssl x509 -text로 SAN을 확인한다- CA 로테이션 중이면 과도기에 두 CA를 모두 신뢰한다
- 새 CA 배포 → 새 인증서 발급 순서를 지킨다
- 양쪽이 fullchain을 제시하는지 확인한다