OpenConnect가 토큰에 필요한 PKCS#11 URI는 무엇인가?

올바른 키를 이미 가진 스마트 카드도 그 위에서 어떤 객체를 쓸지 알려주어야 한다. OpenConnect는 그런 상황에서 복사한 .key 파일을 원하지 않으며, 인증서를 지정하는 PKCS#11 URI를 원하고 자동 검색이 일을 마치지 못할 때는 옆에 있는 개인 키도 지정한다. 까다로운 점은 문법적으로 유효한 URI가 아무것도 증명하지 않는다는 것이다. 카드가 열어 줄 의향이 있는 객체가 아니라 게이트웨이가 이미 신뢰하는 등록을 지정해야 한다.

내보낸 키 대신 클라이언트가 원하는 것

-c 옵션은 보통 파일 경로를 받지만 값이 PKCS#11 URI로 해석되면 OpenConnect는 디스크의 파일이 아니라 토큰 내부의 객체에 대한 참조로 취급한다. -k 옵션도 개인 키에 대해 같은 방식으로 동작한다. 아무것도 내보내지 않고 키는 카드가 제공하는 보호를 절대 떠나지 않는다. 클라이언트가 여러분에게 원하는 것은 토큰 모듈, 인증서 저장소, 게이트웨이 등록이 모두 동의하는 이름이다.

대부분의 시도가 멈추는 곳이 바로 이 마지막 제약이다. URI가 완벽하게 만들어져 있어도 게이트웨이가 거부할 인증서를 고를 수 있다. 유효성과 관련성은 별개의 질문이기 때문이다. 할 가치가 있는 점검은 등록 기록과의 비교이며, 우연히 열리는 첫 객체를 찾는 일이 아니다.

두 URI, 두 가지 다른 일

인증서 URI는 어떤 신원을 주장하는지에 답한다. 공개 키와 주체 줄이 VPN 관리자가 발급한 계정 또는 장치 프로필과 일치하는 인증서 객체를 가리킨다. 같은 인증서는 보통 옆에 저장된 개인 키 객체와 함께 오며, TLS 핸드셰이크가 실제로 필요로 하는 것은 그 짝이다.

키 URI는 OpenConnect가 추론할 수 없을 때 해당 개인 자료가 어디에 있는지에 답한다. -c만 설정하면 클라이언트는 인증서 속성에서 키 검색을 구성하고, -k를 주면 추측이 명시적 객체 참조로 바뀐다. 토큰의 PIN은 세 번째의 무관한 입력으로, 동작을 위해 카드를 잠금 해제할 뿐 객체를 식별하지는 않는다.

openconnect --protocol=anyconnect \
  -c 'pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=1a2b3c4d;id=%01' \
  vpn.example.net

그 인용된 문자열의 모든 것은 데이터다. 세미콜론은 URI 속성을 구분하고 퍼센트 이스케이프는 그대로 두면 파싱을 깨뜨릴 문자를 부호화하므로, 인자 전체가 셸을 온전히 통과해야 한다.

등록과 일치하는 URI 찾기

GnuTLS에는 p11tool이 함께 오며, 현재 사용자가 p11-kit을 통해 실제로 도달할 수 있는 것을 나열한다. p11tool --list-tokens로 시작한 다음 관심 있는 토큰의 인증서 객체를 나열한다. 객체가 PIN 이후에만 나타나면 --login을 추가하고, 먼저 나타나는 것을 고르는 대신 주체와 발급자를 등록 기록과 비교한다.

토큰이 전혀 나타나지 않으면 문제는 OpenConnect 아래에 있다. p11-kit에 그 미들웨어용으로 등록된 모듈이 없거나, 모듈이 다른 계정에 등록되어 있다. 시스템 전체 등록은 /etc/pkcs11/modules 아래에 있고, 사용자별 디렉터리도 시스템 사본을 건드리지 않고 같은 것을 담을 수 있다. 모듈 파일의 공급자 경로가 리더 소프트웨어가 실제로 설치한 라이브러리를 가리키는지 확인한다.

목록에서 URI를 복사할 때 둘레의 따옴표를 유지한다. 따옴표 없는 세미콜론은 첫 속성에서 인자를 잘라 버리고 클라이언트는 찾을 수 없는 객체를 보고한다.

자동 키 검색이 포기할 때

OpenConnect는 인증서 URI에서 키 검색을 도출할 수 있지만 수행하는 정확한 일치는 버전에 따라 다르고, 객체 유형과 레이블 처리는 시간이 지나며 바뀌었다. 작동할 때까지 URI를 줄이라는 조언은 오래된 우회 방법을 설명할 뿐 요구 사항이 아니다. 도출된 검색이 실패하면 인증서 URI를 더 모호한 것으로 바꾸는 대신 -k로 키를 명시적으로 지정한다.

클라이언트를 탓하기 전에 키가 존재하고 p11tool --list-keys로 보이는지 확인하고, 객체가 서명이나 복호화에 사용 가능으로 표시되어 있는지 점검한다. 잘못된 속성으로 만든 키는 URI가 아무리 정확해도 핸드셰이크를 마칠 수 없다. OpenVPN 프로필의 직렬화된 pkcs11-id 값을 OpenConnect 옵션으로 옮기지 마라. 같은 카드와 대화하더라도 두 클라이언트는 서로 다른 식별자 형식을 쓴다.

URI가 해석되고 PIN이 수락되어도 인증이 계속 실패하면 URI 조정을 멈춘다. 다음 실패는 토큰 위쪽에 있으므로 게이트웨이 자체의 오류를 읽는다.

URI 문제처럼만 보이는 실패

다른 프로토콜을 쓰는 게이트웨이는 URI가 맞든 틀리든 똑같이 실패한다. OpenConnect가 예전 vpnc 클라이언트를 대체한 데는 이유가 있고, 카드 지원이 호환되지 않는 게이트웨이 프로토콜을 호환되게 만들지는 않는다. 객체 속성에 한 시간을 더 쓰기 전에 서버가 기대하는 프로토콜과 인증 구성을 확인한다.

서버 신원 검증도 별도의 계층이다. 클라이언트는 게이트웨이 인증서를 자체 신뢰 저장소와 대조해 검증하며, 그 점검은 카드가 이미 자기 몫을 마친 뒤에 실행된다. 리더 권한과 멈춘 pcscd 서비스는 같은 외형의 증상을 만든다. 읽을 수 없는 토큰이며, 고치는 방법은 훨씬 간단하다.

객체에서 바깥으로 일한다. p11tool이 토큰을 보는지, 인증서와 키를 보는지, OpenConnect가 URI를 받아들이는지, 그리고 나서야 게이트웨이가 신원을 받아들이는지 묻는다. 각 단계에는 고유한 오류 메시지가 있고, 각 단계는 다음 단계보다 시험하기 싸다.