strongSwan send_cert: IKE 인증서가 전송되는 시점

게이트웨이는 인증서와 관련된 인증 실패를 기록하며, 첫 반응은 수신자에 CA를 하나 더 추가하는 것입니다. 그것은 인증서가 도착했고 거부되었다고 가정합니다. 다른 가능성은 인증서가 전혀 전송되지 않았다는 것이며, 이는 송신자의 연결 정책이 결정합니다. 신뢰를 변경하기 전에 둘 중 어느 일이 일어났는지 파악하세요.

send_cert가 실제로 제어하는 것

인증서 인증은 peer의 최종 엔터티 인증서가 IKE 교환이나 사전 프로비저닝을 통해 상대 측에 도달해야 합니다. swanctl에서 연결 설정 send_cert은 이 엔드포인트가 자체 인증서 페이로드를 포함하는지 결정하며, 값은 never, always, ifasked 중 하나입니다. 기본값 ifasked는 peer의 인증서 요청에 대한 응답으로 전송합니다. 인증서를 요청하는 것은 별도 설정이며, 상대 측에 인증서를 요구하는 것과 자신의 인증서를 제공하는 것은 같지 않기 때문입니다.

오래된 ipsec.conf 배포는 leftsendcert와 rightsendcert를 사용했으며, 그 이름은 로컬 및 원격 역할에 대응하고 swanctl에 직접 대응하지는 않습니다.

연결을 변경하기 전에 한 번의 시도를 읽으세요

인증서가 관련되어 있다는 막연한 인상이 아니라 통제된 한 번의 시도에서 진단하세요. 정책과 활성 연결 모두 점검할 수 있습니다.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan --since "10 min ago" | grep -iE "cert|CERT"

연결 목록은 구성된 send_cert 값을 보여 주고, SA 목록은 어떤 연결이 실제로 올라왔는지 보여 줍니다. 로그는 인증서 요청을 받았는지, 인증서 페이로드를 보냈는지라는 협상 세부 정보를 추가합니다. 일반적인 인증 실패는 전달 문제를 특정하지 않으므로, 어떤 결론을 내리기 전에 구체적인 교환을 찾으세요. 시도의 타임스탬프를 기록하여 로그 창이 전체 핸드셰이크를 포함하도록 하세요.

수신자의 신뢰는 별도의 결정입니다

전달과 신뢰는 서로 다른 속성이며, 하나를 고쳐도 다른 하나는 고쳐지지 않습니다. 수신자는 의도된 신뢰 앵커를 보유하고, 사용 가능한 체인을 받고, 예상되는 peer 신원과 일치해야 합니다. 중간 인증서 없이 도착하는 최종 엔터티 인증서는 엄격한 체인 검증에서 여전히 실패합니다. 반대로 CA를 설치한다고 해서 peer가 인증서를 전송하도록 강제되지는 않습니다.

openssl x509 -in peer-chain.pem -noout -subject -issuer -dates

점검은 어떤 발급자가 인증서에 서명했고 언제 만료되는지 보여 주며, 수신자의 앵커는 그에 대응해야 합니다. 배포가 소유한 발급 CA를 신뢰하고 체인의 모든 중간 인증서를 신뢰하지 않는 것은, 모든 중간 인증서를 루트로 승격하면 신뢰가 하나의 peer를 훨씬 넘어 확장되기 때문입니다. 검증을 끈 상태에서만 성공하는 연결은 수정이 아니므로, 신원 검증을 활성 상태로 유지하세요. 체인이 불완전한 곳에서는 송신자 정책이 아니라 프로비저닝을 수리하세요.

증거가 있을 때만 송신자를 변경하세요

로그가 인증서가 전혀 전송되지 않았고 수신자가 실제로 요청했다고 보여 주면, send_cert을 always로 설정하는 것은 그 연결에 정당한 변경입니다. swanctl 구성에 적용하고, 연결을 다시 로드하며, 기존 SA를 재사용하지 말고 새 세션을 수립하세요. 인증서 페이로드가 이제 나타나고 수신자가 의도된 앵커에 대해 이를 수락하는지 확인하세요. 아무것도 바뀌지 않으면 결함은 결국 신뢰 측에 있었고 송신자 설정이 원인은 아니었습니다.

관찰된 교환, 앵커, 그로부터 나온 검증을 변경 기록에 기록하세요. 그런 용어로 설명할 수 없는 인증서 수리는 우연입니다.