cert8.db는 일회용 캐시가 아닙니다: 저장소 소유자를 확인하세요

오래된 지원 스레드는 cert8.db라는 파일을 삭제하면 VPN이 다시 작동한다고 말합니다. 그 순서는 복구보다 우연인 경우가 더 많습니다. 이 파일은 인증서 데이터베이스이며, 삭제하면 성공적인 실행으로는 드러나지 않는 방식으로 지속적인 보안 상태가 바뀝니다.

멈춘 로그인은 캐시 문제가 아닙니다

브라우저 캐시는 리소스의 사본을 저장하고, 인증서 데이터베이스는 신뢰 결정, 인증서, 그에 딸린 키를 저장합니다. 후자를 지우는 것은 기록을 지우는 일보다 신원을 재설정하는 일에 가깝습니다. 로그인 중에 클라이언트가 멈췄다면 유용한 증거는 어느 프로세스가 어느 프로필을 열고 무엇을 기록했는지이며, 포럼 게시물이 어떤 파일을 지웠는지가 아닙니다. 멈춤을 재현하고 클라이언트 로그를 읽는 일은 파일을 지우는 것보다 오래 걸리지만, 실제 원인으로 가는 유일한 길입니다.

파일 이름에는 역사도 있습니다. NSS는 예전 cert8.db와 key3.db를 SQLite 기반 cert9.db와 key4.db와 구분합니다. 멈춤 전에 본 로그 줄을 적어 두세요. 그것이 여러분이 가진 유일한 지속적 증거입니다.

클라이언트가 실제로 여는 프로필

클라이언트, 인증 방식, 그리고 그것이 읽는 저장소를 파악하세요. 여기에는 세 가지 로그인 경로가 있습니다. 브라우저 지원, 내장 브라우저, 네이티브 클라이언트이며 같은 프로필을 공유할 필요는 없습니다. 다른 디렉터리에 올바른 이름의 데이터베이스가 있다고 해서 멈춘 프로세스가 그것을 열었다는 증거는 아닙니다. Linux에서 NSS 저장소는 보통 사용자의 ~/.pki/nssdb 아래나 애플리케이션별 프로필 디렉터리에 있습니다. 두 배치가 한 기기에 함께 있을 수 있으므로 이전이 최근이라면 둘 다 확인하세요.

변경하기 전에 저장소에 무엇이 있는지 나열하세요. certutil -L -d sql:$HOME/.pki/nssdb는 인증서를 출력하고, 같은 도구에 -K를 붙이면 키가 있는지 보여 줍니다.

명령이 데이터베이스를 열 수 없다고 보고하면, 도구가 사용하는 프로필을 찾은 것이지 VPN이 사용한 프로필과 같다는 보장은 없습니다.

어떤 복구 전에도 프로필을 백업하세요

영향을 받는 애플리케이션을 닫은 뒤 승인된 백업 방식으로 프로필 디렉터리 전체를 복사하세요. 인증서와 키 데이터베이스는 관련되지만 별개의 상태이며, 임의의 파일 하나를 저장하는 것은 전체 신원의 복구 계획이 아닙니다. 프로필에 개인 키가 있을 수 있으므로 사본을 보호하세요. 무엇을 어디에 백업했는지 기록해 실패한 복구에 돌아갈 길을 남기세요.

그다음 관리자와 복구의 정확한 범위를 확인하세요. 저장소 전체 초기화, 알려진 오래된 인증서 하나 제거, 브라우저 프로필 복구는 서로 다른 세 가지 변경이며 세 가지 위험이 다릅니다.

복구 후 로그인하여 저장소를 점검하세요

승인된 복구 후 VPN에 로그인하여 서버 인증서가 의도대로 계속 검증되는지 확인하세요. 워크플로에 필요한 신원이 남아 있는지, 예기치 않은 신뢰 앵커가 나타나지 않았는지 점검하세요. 이전보다 더 신뢰하여 연결을 통과시키는 복구는 복구가 아닙니다.

관찰과 지시를 분리하세요. 삭제 한 번과 성공적인 실행 한 번은 일반적인 해결책이 아닙니다.

멈춤이 다시 나타나면 다른 무엇을 바꾸기 전에 클라이언트 로그와 사용 중인 프로필을 확보하세요. 그 기록이 추측을 진단으로 바꿉니다.