Easy-RSA가 PKI가 없다고 합니까? 다른 곳을 보고 있습니다
CA 키나 index.txt가 없다는 것은 보통 Easy-RSA 3가 다른 디렉터리를 선택했다는 뜻입니다. 먼저 PKI 선택자, 우선순위, 발급자의 지문을 확인하세요.
ca.crt나 index.txt가 없어 명령이 멈추지만, CA는 몇 달째 인증서를 발급해 왔습니다. 권한 기관에는 아무 변화가 없었고 명령이 그저 다른 곳을 본 것입니다. Easy-RSA 3는 옵션, 환경 변수, vars 파일, 내장 기본값에서 PKI 디렉터리를 결정하며, 그중 어느 것이든 배포의 기관과 다른 곳을 가리킬 수 있습니다. 무엇이든 만들기 전에 어느 쪽이 이겼는지 확인하세요.
오류는 디렉터리가 아니라 파일을 지목한다
설치 디렉터리와 발급자 디렉터리는 서로 다른 곳입니다. 기계에서easyrsa를 찾았다는 것은 도구가 설치되어 있다는 것만 증명할 뿐, VPN이 신뢰하는 기관을 찾았다는 뜻은 아닙니다.
그래서 패키지를 다시 설치하거나 init 단계를 다시 실행하는 것이 생산적으로 느껴지지만 아무것도 바뀌지 않습니다.
무엇보다 먼저 선택자를 확인하세요
Easy-RSA 3에서 선택자는EASYRSA_PKI또는 그에 해당하는--pki-dir옵션입니다. 다음과 같은 절대 경로를 주면--pki-dir=/srv/pki/office, 답은 우연히 서 있던 위치에 의존하지 않게 됩니다. 이 습관 하나로 이 버그의 한 부류가 통째로 사라집니다. 특히 cron이나 CI 체크아웃에서 실행하는 스크립트에 중요합니다.
먼저 세대를 확인하세요, Easy-RSA 2의vars파일과build-key관행은 Easy-RSA 3가 기대하는 모델과 다르기 때문입니다.easyrsa --version는 다른 무엇보다 먼저 세대를 출력하고,./easyrsa --help는 하위 명령을 나열합니다.build-key대상은 2.x를 뜻하고,build-client-full는 3.x를 뜻합니다. 디렉터리 이름이 익숙해 보인다는 이유로 오래된KEY_DIR경로를 3.x 호출로 가져가면 바로 이 오류가 발생합니다.
버전 문자열과 명령 구문이 맞지 않으면 멈추고 설치된 릴리스 자체의 문서를 읽으세요.
우선순위는 진 vars 파일을 설명한다
문서화된 우선순위는 명령줄 옵션, 그다음 환경, 그다음 vars 파일, 그다음 내장 기본값입니다. 따라서vars의 올바른 값은 상속된 환경 변수에 집니다. 이것이 이 실패의 조용한 버전입니다. 환경 전체를 티켓에 쏟지 말고 의도한 변수와 파일 선택을 조사하세요. 둘의 차이는 보통 비밀입니다.
사슬을 순서대로 따라가며 명령이 사용한 경로를 어느 출처가 제공했는지 기록하세요. 그것을 알면 수정은 플래그나 export이지 새 인증 기관이 아닙니다.
Easy-RSA구성 참조가 선택자와 우선순위를 정의하며, 티켓에 넣을 인용은 바로 이것입니다.
공개 자료로 발급자를 확인하세요
일반적인 파일 기반 발급자라면ca.crt를 읽고 그 지문을 승인한 발급자 기록과 대조하세요. 일치하는 주체 이름은 신원 증거가 아니며, production이라는 이름의 디렉터리도 아닙니다. 찾은 파일을 동료들이 신뢰하라고 들은 기관에 묶어 주는 것은 오직 지문뿐입니다.
읽기 전용 확인으로 충분합니다:openssl x509 -in /srv/pki/office/ca.crt -noout -subject -issuer -serial -fingerprint -sha256.
그다음 디렉터리의 역할을 정하세요. 클라이언트가 쓰는 요청 디렉터리는 발급자 데이터베이스가 아니며, 오프라인으로 보관하는 서명 키가 모든 VPN 호스트에 있을 이유는 없습니다.ca.key가 없다는 것은 그 구성에서 설계상의 성질이지 대체 기관을 만들어 낼 허가가 아닙니다.
상태가 정말 사라졌다면
때로 경로는 맞고 상태가 정말 없습니다. 빈index.txt와 다시 시작한 일련번호 카운터는 건강해 보이지만 한 번도 본 적 없는 인증서에 대해 아무것도 증명할 수 없는 PKI를 줍니다. 갱신은 옛 인증서를 폐기하지 않고, 새 번호는 이력과 충돌합니다. 대신 CA의 승인된 백업에서 복원하세요. 다른 곳에서 빈 PKI를 초기화하면 오류가 옮겨질 뿐이고 무관한 두 번째 기관이 남기 때문입니다.
경로와 발급자가 일치하면 다음 실패는 그 실체로 다루세요. Permission denied, 암호 문구가 필요한 서명 키, 빠진 발급 기록은 세 가지 다른 고장이며, 방금 고친 디렉터리에 관한 것은 그중 하나뿐입니다.
경로 실수를 덮으려고 키 암호화를 없애거나 디렉터리 권한을 넓히지 마세요. 실수는 고치기 싸지만 복구는 그렇지 않습니다.