PostgreSQL sslrootcert 기준 정리

PostgreSQL sslrootcert 기준 정리

sslrootcert는 libpq 계열 PostgreSQL 클라이언트가 서버 인증서를 어떤 CA로 검증할지 정하는 연결 옵션이다. 2026년 7월 27일 확인한 PostgreSQL 18 공식 문서 기준으로, 이 값은 서버 인증서 검증의 출발점이 되는 루트 CA 묶음 파일이나 시스템 신뢰 저장소를 지정한다.

실무에서 핵심은 세 가지다. 내부 CA 파일을 직접 지정할지, 시스템 신뢰 저장소를 쓸지, 그리고 sslmode를 verify-ca와 verify-full 중 무엇으로 둘지다. 이 세 가지를 함께 맞추지 않으면 TLS를 켰더라도 서버 신원 검증이 약해질 수 있다.

sslrootcert는 무엇을 지정할까?

공식 문서 기준으로 sslrootcert는 CA 인증서가 들어 있는 파일 이름을 지정한다. 파일이 존재하면 libpq는 서버 인증서가 그 CA 중 하나에 의해 서명되었는지 검증한다. 별도로 지정하지 않으면 기본 경로는 ~/.postgresql/root.crt다. Windows에서는 같은 역할을 하는 기본 파일이 %APPDATA%\\postgresql\\root.crt다.

중간 인증서가 필요한 체인이라면, PostgreSQL 문서는 루트 인증서 파일에 intermediate certificate도 함께 추가할 수 있다고 설명한다. 즉 루트 CA만 있다고 끝나는 것이 아니라, 서버가 보내는 체인을 클라이언트가 실제로 검증할 수 있는 상태인지까지 봐야 한다.

언제 직접 파일을 지정해야 할까?

자체 CA를 운영하거나 사설 PKI를 쓰는 환경에서는 보통 명시적으로 파일 경로를 주는 편이 더 분명하다. 예를 들어 내부 발급 서버, 사설 로드밸런서, 개발망 PostgreSQL처럼 공용 루트 저장소에 없는 CA를 쓰는 경우가 여기에 해당한다.

이때 선택 기준은 단순하다. 운영 환경마다 신뢰해야 하는 CA 묶음이 다르면 파일 경로를 직접 관리하는 쪽이 안전하다. 반대로 공개 CA를 사용하고 운영체제의 기본 신뢰 저장소 정책을 그대로 따를 계획이면 system 값이 더 단순할 수 있다.

sslrootcert=system은 무엇이 다를까?

PostgreSQL 18 공식 문서는 sslrootcert에 특수 값 system을 줄 수 있다고 설명한다. 이 경우 libpq는 파일 대신 SSL 구현체가 제공하는 시스템 신뢰 루트들을 불러온다. 다만 실제 루트 위치는 플랫폼과 SSL 구현체에 따라 다를 수 있고, OpenSSL 환경에서는 SSL_CERT_DIR와 SSL_CERT_FILE 환경 변수의 영향도 받을 수 있다.

중요한 점은 sslrootcert=system을 쓰면 기본 sslmode가 verify-full로 바뀐다는 점이다. 더 약한 모드는 오류가 난다. 공식 문서는 공개 CA 환경에서 더 약한 검증은 의미가 약하다고 설명한다. 남의 호스트 이름으로도 공용 CA 인증서를 받을 수 있기 때문에, 시스템 루트를 쓸 때는 호스트 이름까지 같이 검증해야 한다는 뜻이다.

sslmode와는 어떻게 같이 봐야 할까?

조합	의미	실무 판단
sslrootcert 없음 + sslmode=prefer	TLS 협상은 될 수 있지만 서버 신원 검증 기준이 약하다.	보안 기본값으로 보기 어렵다.
sslrootcert=/path/to/root.crt + sslmode=verify-ca	서버 인증서 체인이 신뢰 CA에 연결되는지 확인한다.	사설 CA나 self-signed 기반 내부망에서는 자주 쓰인다.
sslrootcert=/path/to/root.crt + sslmode=verify-full	CA 검증에 더해 접속한 호스트 이름까지 확인한다.	대부분의 운영 환경에서 가장 보수적인 기본값이다.
sslrootcert=system	시스템 루트를 사용하며 약한 sslmode는 허용되지 않는다.	공개 CA 인증서 운영에 적합하다.

공식 SSL 문서는 verify-ca가 체인 신뢰만 확인하고, verify-full은 여기에 호스트 이름 일치까지 더한다고 설명한다. 특히 공개 CA를 쓸 때는 verify-full을 써야 한다고 명시한다.

sslmode=require와 함께 써도 될까?

공식 문서는 하위 호환 때문에, 루트 CA 파일이 존재하면 sslmode=require도 실제로는 verify-ca처럼 동작할 수 있다고 설명한다. 다만 이 동작에 의존하는 것은 권장하지 않는다.

이 부분이 실무에서 자주 헷갈린다. require는 이름만 보면 충분히 안전해 보이지만, PostgreSQL 문서의 기준은 더 명확하다. 서버 인증서를 검증하려는 목적이라면 verify-ca 또는 verify-full를 명시적으로 써야 한다.

환경 변수로도 바꿀 수 있을까?

가능하다. PostgreSQL 공식 문서는 루트 인증서 파일 경로를 PGSSLROOTCERT 환경 변수로도 바꿀 수 있다고 설명한다. 같은 맥락으로 CRL 파일은 PGSSLCRL, CRL 디렉터리는 PGSSLCRLDIR로 지정할 수 있다.

애플리케이션 설정 파일, libpq connection string, 환경 변수 중 어느 경로를 쓸지는 배포 방식에 따라 다르다. 다만 여러 서비스가 한 계정을 공유하는 환경이라면 전역 환경 변수보다 연결 문자열이나 서비스 파일에 명시하는 편이 설정 경계를 분리하기 쉽다.

CRL은 언제 같이 봐야 할까?

sslrootcert만으로는 "누가 서명했는가"를 검증한다. 이미 폐기된 인증서를 막아야 한다면 CRL도 같이 봐야 한다. PostgreSQL 문서는 기본적으로 ~/.postgresql/root.crl이 있으면 이를 확인하고, 필요하면 sslcrl 또는 sslcrldir로 위치를 바꿀 수 있다고 설명한다.

따라서 사설 CA를 직접 운영하면서 폐기 정책도 관리하는 환경이라면, sslrootcert만 맞추고 끝내기보다 CRL 배포 경로까지 함께 설계하는 편이 맞다.

어떤 경우에 무엇을 고르면 될까?

• 공개 CA 인증서를 쓰는 서비스라면 sslrootcert=system과 sslmode=verify-full 조합이 가장 단순하다.
• 사설 CA나 self-signed 체인을 쓰는 내부망이라면 전용 CA 파일을 배포하고 verify-full 또는 필요시 verify-ca를 고른다.
• 호스트 이름이 인증서와 정확히 맞는지 보장할 수 있다면 verify-full를 우선 검토한다.
• 기존 설정이 require에만 기대고 있다면, 실제 검증이 필요한지 다시 점검하는 편이 안전하다.
• 인증서 폐기까지 관리해야 하면 sslcrl 또는 sslcrldir도 같이 설계한다.

FAQ

sslrootcert를 지정하지 않으면 TLS가 완전히 꺼질까?

아니다. TLS 사용 여부는 sslmode와 서버 설정에 따라 달라진다. 다만 sslrootcert가 없으면 서버 인증서 검증에 필요한 신뢰 루트 구성이 부족할 수 있다.

공개 CA 인증서인데 verify-ca면 충분할까?

PostgreSQL 공식 문서는 공개 CA 환경이라면 verify-full을 써야 한다고 설명한다. verify-ca만으로는 호스트 이름 일치까지 확인하지 않기 때문이다.

PGSSLROOTCERT와 sslrootcert 중 무엇이 우선일까?

공식 문서는 연결 파라미터가 먼저 처리되고, 남은 미설정 항목에 대해 환경 변수와 기본값이 채워진다고 설명한다. 따라서 명시적인 연결 파라미터가 있다면 그것이 더 직접적인 설정 경로다.

참고 자료

• PostgreSQL 18 libpq connection parameters
• PostgreSQL 18 libpq SSL support