openssl ca: index.txt의 잘못된 만료 날짜와 고치는 방법

발급 실행이 다음에서 멈춥니다: entry 22: invalid expiry date, 그런데 눈앞의 요청 자체는 완전히 정상입니다. 불만은 CA 데이터베이스 파서에서 나오며, CSR에서도 아니고 결국 인증서를 제시할 VPN 클라이언트에서도 아닙니다. 이 구분이 이후의 모든 것을 결정합니다 — 레코드가 잘못되었으므로 수리는 요청이나 피어 구성이 아니라 CA 상태에 속합니다. 번호가 붙은 항목을 index.txt 의 한 줄로 보면, 문제는 검증 가능한 답이 있는 한정된 데이터 질문으로 줄어듭니다.

오류를 데이터베이스에 대한 불만으로 읽으십시오

모든 openssl ca 호출은 무언가에 서명하기 전에 자신의 텍스트 데이터베이스를 훑습니다. 각 줄에는 상태 문자, 만료 시각, 선택적인 폐기 시각, 십육진수 일련번호, 파일 이름, 주체가 들어 있습니다. 한 필드를 구문 분석할 수 없으면 명령은 줄 번호를 보고하고 나머지 레코드를 추측하는 대신 멈춥니다.

그 멈춤은 까다로움이 아니라 보호입니다. 도구가 읽을 수 없는 레코드는 요청한 주체가 이미 있는지, 일련번호가 이미 나갔는지, 다음 CRL에 무엇이 들어가야 하는지를 판단할 수 없게 만듭니다. 잘못된 줄을 넘겨 진행하면 몇 달 뒤, 대개 아무도 설명할 수 없는 폐기 도중에 드러나는 바로 그 조용한 불일치가 생깁니다. 메시지를 데이터에 대한 불만으로 읽으면 조사는 CA 디렉터리 안에서 끝납니다.

무엇이든 건드리기 전에 CA 상태를 복사하십시오

데이터베이스 파일만이 아니라 CA 디렉터리 전체의 스냅숏을 뜨십시오. 인덱스, 그 속성 파일, 일련번호와 CRL 번호 파일, 개인 키, 발급된 인증서가 모두 이후 작업에 참여하므로, 하나만 복원하고 나머지를 빠뜨리는 수리는 두 번째 사고를 만듭니다. 있는 경우 CA 자체의 백업 절차를 쓰고, 작업이 진행되는 동안 예약 발급을 멈추십시오.

실패한 명령이 실제로 읽어 들인 OpenSSL 빌드와 구성 파일을 기록하십시오. 설치본은 흔히 하나 이상의 CA 디렉터리를 두며, 오류는 선택한 구성이 가리키는 데이터베이스에 대해서만 의미가 있습니다.

항목을 찾아 그 날짜 필드를 디코딩하십시오

보고된 줄 번호는 첫 레코드부터 세므로, 위에 빈 줄이나 주석 줄이 없다는 것을 확인했다면 sed -n '22p' index.txt 가 문제의 항목에 정확히 떨어집니다. 그 줄은, 탭과 끝의 공백은 흔하고 보통 편집기 창에서는 보이지 않기 때문에, 구분자가 보이도록 인쇄하십시오.

만료 필드는 연도에 따라 폭이 달라지는 시각 값입니다. 2049년까지의 값은 UTCTime으로 YYMMDDHHMMSSZ 처럼 쓰고, 그 이후 값은 네 자리 연도를 쓰는 GeneralizedTime으로 바뀝니다. 두 형식을 섞은 레코드, 또는 파서가 이제 네 자리를 기대하는 자리에 두 자리 연도를 가진 레코드는 정확히 이 지점에서 실패합니다. 중단된 쓰기가 남긴 잘린 필드도 마찬가지입니다.

레코드는 다른 CA의 파일이 아니라 그것이 가리키는 인증서와 비교하십시오. 서명된 인증서는 유효 기간이 무엇을 말해야 하는지에 대한 권위이며, 이미 구문 분석 가능한 객체로 존재합니다.

서명된 인증서에 맞추어 레코드를 고치십시오

실제 날짜는 다음으로 읽으십시오: openssl x509 -in issued.pem -noout -dates -serial -subject. 다음을 notAfter 이 빌드가 그 연도에 쓰는 시각 폭으로 변환하고, 한 글자도 바꾸기 전에 일련번호가 편집하려는 항목과 일치하는지 확인하십시오.

깨진 필드만 편집하고 상태 문자와 일련번호는 남기며 줄의 나머지는 그대로 두십시오. 어떤 서명된 인증서와도 레코드를 맞출 수 없다면, 그것을 떠돌이 항목으로 보고 줄을 손으로 지우는 대신 CA 자체의 폐기 경로로 은퇴시키십시오.

연도에 대한 추측에 맞추려고 날짜를 잘라 고치지 마십시오. 두 글자 잘라내기는 빌드 사이에서 이식되지 않으며, 데이터베이스가 앞으로의 중복 주체와 CRL 검사에 보고하는 유효 기간을 조용히 바꿉니다. 원래 값을 되살릴 수 없다면, 새 일련번호로 다시 발급하고 옛것을 왜 버렸는지 적어 두십시오. 감사 흔적은 수리의 일부이지 그 주위의 서류가 아닙니다.

떠나기 전에 발급과 CRL 생성을 검증하십시오

같은 구성으로 발급을 한 번 실행하고 줄 번호 불만 없이 끝나는지 확인하십시오. 그다음 openssl ca -gencrl -config openssl.cnf 로 CRL을 만들고, 손상된 레코드는 서명할 때가 아니라 대개 거기서 드러나므로, 그것이 구문 분석되는지 확인하십시오.

새 인증서는 다음으로 검사하십시오: openssl x509 -noout -dates -serial 그리고 CA가 방금 쓴 줄과 비교하십시오. 상태 문자와 만료 날짜가 인증서와 일치하는지 확인하고, openssl verify -CAfile ca.pem issued.pem 가 오류 없이 돌아오는지도 확인하십시오. 그다음 예약 발급을 되돌리고, 두 번째 잘못된 줄이 곧바로 자신을 알릴 것이므로 첫 실행을 지켜보십시오.