strongSwan: 키 유형, 로더, 그리고 잘못된 백엔드

파일 확장자는 키 알고리즘을 식별하지 않으며, .pem 봉투에는 RSA나 ECDSA 자료가 들어 있을 수 있습니다. PEM은 바이트를 어떻게 감싸는지 설명하고, RSA와 ECDSA는 서로 다른 알고리즘 이름이며, PKCS12 파일은 또 다른 것입니다. strongSwan은 플러그인과 구성 백엔드를 통해 자격 증명을 불러오므로, 인증서가 목록에 나타나도 개인 키가 사용 가능해지지 않을 수 있습니다. 어떤 비밀을 편집하기 전에 그 계층들을 분리하세요.

인코딩, 알고리즘, 패키징은 세 개의 계층

키 파일에는 인코딩, 알고리즘, 그리고 흔히 컨테이너가 있습니다. PEM은 익숙한 base64 봉투이고, DER은 그 바이너리 대응이며, PKCS12는 인증서를 키와 체인과 함께 묶습니다. 인증서 체인 파일은 또 다른 컨테이너이며 보통 개인 키를 전혀 담지 않습니다. 이런 이름들 중 어느 것도 안의 자료가 RSA인지 ECDSA인지 알려 주지 않습니다.

알고리즘은 객체 자체에서 읽으세요. 공급자의 마케팅 이름이나 파일 확장자는 증거가 아닙니다. 같은 발급자가 다른 키 유형을 내줄 수 있기 때문입니다.

로더를 탓하기 전에 공개 키를 비교하세요

불러온 인증서는 인증서가 파싱되었다는 것을 증명할 뿐, 개인 키가 있거나 쓸 수 있다는 것을 증명하지 않습니다. 인증서와 제안된 개인 키에서 공개 키를 도출한 뒤 두 다이제스트를 비교하세요. 어느 한쪽 추출이 실패하면 거기서 멈추세요. 빈 출력의 다이제스트는 아무것도 증명하지 않습니다. 다이제스트가 일치하면 그 쌍이 서로 맞는다는 것은 알 수 있지만, 인증서가 그 작업에 적합한지는 별개입니다.

openssl x509 -in server.crt -pubkey -noout |
    openssl pkey -pubin -outform DER |
    openssl dgst -sha256

openssl pkey -in server-key.pem -pubout -outform DER |
    openssl dgst -sha256

두 번째 명령은 로컬의 개인 자료를 건드리지만 공개 절반만 출력합니다. 그대로 유지하고, 개인 키를 티켓에 절대 붙여 넣지 마세요. 키가 암호화되어 있으면 지원되는 도구가 암호 문구를 묻도록 하고, 프로세스 목록에 노출될 수 있는 명령줄에 두지 마세요.

구형 ipsec.secrets 또는 swanctl 자격 증명

strongSwan에는 흔히 쓰이는 두 가지 자격 증명 경로가 있습니다. 구형 starter 스택은 유형별 항목을 다음에서 읽습니다ipsec.secrets. 각 항목은 자료에 맞는 올바른 유형을 지정해야 합니다. swanctl과 vici 스택은 자체 자격 증명 디렉터리에서 자체 구성으로 키를 불러옵니다. 실행 중인 백엔드가 읽지 않는 파일을 편집해도 아무것도 바뀌지 않습니다.

: ECDSA "/etc/ipsec.d/private/server-key.pem"

실제로 어떤 백엔드가 실행 중인지 확인한 뒤, 그 백엔드가 보는 위치에 키를 두세요.strongSwan 5.9 구형 설명서는 유형별 비밀 항목을 정의하며, swanctl 문서가 아닙니다. 둘을 섞으면 관리자가 권위 있다고 믿는 파일을 무시하는 데몬이 만들어집니다. 오류를 보고하지 않는 다시 불러오기는 구성이 파싱되었다는 뜻일 뿐입니다.

불러오기 이벤트와 인증 결과를 읽으세요

통제된 다시 불러오기 후, 특정 키에 대한 데몬 자체의 불러오기 출력을 읽으세요. 상태 덤프에 나열된 인증서는 개인 키가 그것과 짝지어졌다는 것을 보여 주지 않습니다.

클라이언트가 여전히 실패하면 서버 이벤트와 클라이언트 오류를 분리하세요. 체인 검증, 신원 일치, 그리고방식 호환성은 각자의 증거를 가진 이후의 질문입니다. 결과를 정확한 키 경로와 비교한 다이제스트와 함께 적어 두세요. 그렇지 않으면 다음 교대조가 같은 다시 불러오기를 반복합니다. 로더 불일치에 대한 첫 대응은 CA 교체가 아닙니다.