systemd 서비스는 프록시에 닿지만 CA 파일은 읽지 못한다

승인된 CA 번들을 설치했고 터미널에서는 요청이 됩니다. 그런데 서비스는 여전히 인증서 로드 오류를 보고합니다. 프록시 IP를 바꾸기 전에 그 프로세스가 같은 파일을 열 수 있는지 확인하세요.

서비스는 다른 Unix 사용자로 실행되거나 다른 디렉터리에서 시작하고, 제한된 파일시스템을 볼 수 있습니다. 로그인한 사용자에게 유효한 경로가 서비스에도 자동으로 유효한 것은 아닙니다.

절대 경로부터 확인하기

실제로 쓰는 클라이언트에 설정된 경로를 확인하세요. 예를 들어 curl의 --cacert는 목적지 CA 번들을 고릅니다. HTTPS 프록시에는 별도의 프록시 CA 옵션이 있습니다. 다른 클라이언트는 자체 설정 키나 환경 변수를 씁니다.

파일과 그 파일로 이어지는 디렉터리를 모두 확인하세요.

namei -l /home/alex/certs/approved-ca.pem
systemctl show example.service -p User -p Group -p ProtectHome -p RootDirectory

진단용 예시이며 누구나 파일에 쓸 수 있게 만들라는 지시가 아닙니다. 마지막 파일의 읽기 권한만큼 경로의 디렉터리 통과 권한도 중요합니다.

권한만이 문제는 아닐 수 있다

ProtectHome=yes이면 systemd가 표준 홈 디렉터리 위치를 서비스에서 접근할 수 없게 만듭니다. 인증서 파일의 모드를 바꿔도 네임스페이스 제한은 풀리지 않습니다. 루트 디렉터리를 설정하면 서비스 안에서 절대 경로가 가리키는 대상도 달라질 수 있습니다.

해당 애플리케이션용 /etc 아래 디렉터리처럼 적절한 서비스 설정 위치를 쓰고 필요한 읽기 권한만 주세요. 클라이언트 CA 경로도 그 위치로 바꾸세요. 처음 파일을 개인 홈에 뒀다는 이유로 관련 없는 파일시스템 제한까지 제거하지 마세요.

첫 유용한 오류 읽기

«CA 파일을 로드할 수 없음»과 «인증서 체인이 신뢰되지 않음»은 서로 다른 실패입니다. 전자는 클라이언트가 무엇을 검증하기도 전에 생길 수 있습니다. 후자는 읽을 수 있는 번들에 잘못된 인증 기관이 있거나 잘못된 TLS 연결에 적용되고 있다는 뜻일 수 있습니다.

접근을 고친 뒤 서비스의 실행 환경에서 다시 테스트하세요. 터미널 명령 성공은 유용한 비교이지만 서비스가 보는 파일이나 그 클라이언트가 쓰는 신뢰 설정을 입증하지는 못합니다.