nginx: [emerg] cannot load certificate SSL: error:0200100D:system library:fopen:Permission denied:fo

SSL Cert 를 바 꾼 후 Nginx 를 시작 할 수 없습니다. 다음 과 같은 오류 가 발생 했 습 니 다.
nginx: [emerg] cannot load certificate “/etc/nginx/ssl/test.crt”: BIO_new_file() failed (SSL: error:0200100D:system library:fopen:Permission denied:fopen(’/etc/nginx/ssl/test.crt’,‘r’) error:2006D002:BIO routines:BIO_new_file:system lib)

사용 확인 sudo 운행.

이 파일 을 열 수 있 는 지 확인 합 니 다 cat.

파일 권한 이 원 Cert 와 일치 하 는 지 확인 합 니 다.

nginx -t successful.

알 아 봤 더 니 SELinux 문 제 였 어 요.SELinux, 즉 Security Enhanced Linux 는 위임 식 액세스 제어 (Mandatory Access Control, MAC) 를 기반 으로 하 는 권한 제어 시스템 으로 일반적으로 이해 하 는 사용자 자율 식 액세스 제어 (Discretionary Access Control, DAC) 보다 엄격 하 다.
DAC 는 주로 프로그램의 소유자 와 파일 의 rwx 권한 에 따라 사용자 가 할 수 있 는 동작 을 결정 하지만 루트 는 모든 것 을 제어 할 수 있 고 777 파일 은 누구 에 게 나 작 동 할 수 있 습 니 다.
MAC 는 규칙 을 통 해 특정한 프로그램 이 지정 한 파일 만 조작 할 수 있 도록 제한 할 수 있 습 니 다. 그러면 루트 가 실행 하 는 프로그램 이라도 관련 되 지 않 은 다른 파일 에 함부로 접근 할 수 없습니다.SELinux 기본 사용 targeted 모드 입 니 다.

getenforce

sestatus -v

Audit log 를 확인 하면 파일 에 접근 할 수 없 는 이 유 는 프로그램 이 대상 파일 scontext (Security Context) 과 일치 하지 않 기 때 문 입 니 다.
Nginx 는 httpd_t, 자신의 copy 파일 은 user_home_t 을 사용 합 니 다.
이 문 제 를 일 으 키 는 작업 은 home 에서 파일 을 만 든 다음 mv 현재 디 렉 터 리 로 이동 하 는 것 이 며 scontext 복사 이동 으로 수정 되 지 않 습 니 다.

$ sudo ausearch -m avc -ts today

time->Thu Apr  9 12:00:42 2020
type=PROCTITLE msg=audit(1586404842.411:635786): proctitle=2F7573722F7362696E2F6E67696E78002D63002F6574632F6E67696E782F6E67696E782E636F6E66
type=SYSCALL msg=audit(1586404842.411:635786): arch=c000003e syscall=2 success=no exit=-13 a0=55ba2565c54d a1=0 a2=1b6 a3=24 items=0 ppid=1 pid=65228 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="nginx" exe="/usr/sbin/nginx" subj=system_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1586404842.411:635786): avc:  denied  { read } for  pid=65228 comm="nginx" name="test.crt" dev="dm-0" ino=136402657 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=0

테스트 Cert 와 원래 버 전의 차 이 를 봅 니 다.

$ sudo ls -lrtZ /etc/nginx/ssl
-rw-r--r--. root root system_u:object_r:httpd_config_t:s0 origin.crt
-rw-r--r--. root root system_u:object_r:httpd_config_t:s0 origin.key
-rw-r--r--. root root unconfined_u:object_r:user_home_t:s0 test.crt
-rw-r--r--. root root unconfined_u:object_r:user_home_t:s0 test.key

restorecon 파일 을 올 바른 SELinux type 으로 복원 합 니 다.

$ sudo restorecon -v -R /etc/nginx/ssl/test.*
restorecon reset /etc/nginx/ssl/test.crt context unconfined_u:object_r:user_home_t:s0->unconfined_u:object_r:httpd_config_t:s0
restorecon reset /etc/nginx/ssl/test.key context unconfined_u:object_r:user_home_t:s0->unconfined_u:object_r:httpd_config_t:s0
$ sudo ls -lrtZ /etc/nginx/ssl
-rw-r--r--. root root system_u:object_r:httpd_config_t:s0 origin.crt
-rw-r--r--. root root system_u:object_r:httpd_config_t:s0 origin.key
-rw-r--r--. root root unconfined_u:object_r:httpd_config_t:s0 test.crt
-rw-r--r--. root root unconfined_u:object_r:httpd_config_t:s0 test.key

기본 디 렉 터 리 보안 본문 semanage 을 조회 하고 수정 할 수 있 습 니 다. 이것 이 바로 restorecon 복 구 된 이른바 정확 한 SELinux type 의 출처 입 니 다.

$ sudo semanage fcontext -l|grep etc/nginx
/etc/nginx(/.*)?                                   all files          system_u:object_r:httpd_config_t:s0

Nginx 다시 시작, 성공!