Lỗi Gặp Phải
Nginx khởi động (hoặc reload) và bạn thấy dòng này trong log:
SSL: error:0200100D:system library:fopen:Permission denied (SSL: error:20074002:BIO routines:file_ctrl:system lib)
Nghĩa là: Nginx đã cố mở file chứng chỉ hoặc khóa riêng tư, nhưng hệ điều hành từ chối. Tiến trình không có quyền đọc — đơn giản vậy thôi.
Lỗi này thường xuất hiện ngay sau khi chạy nginx -t hoặc systemctl reload nginx. Kiểm tra /var/log/nginx/error.log và nó sẽ chỉ ra đúng file bị lỗi.
Nguyên Nhân Gốc Rễ
Nginx chia công việc giữa tiến trình master và các tiến trình worker. Master chạy với quyền root — phần đó khởi động bình thường. Nhưng các worker lại chạy với quyền thấp hơn: www-data trên Debian/Ubuntu, nginx trên CentOS/RHEL. Chính các worker này mới xử lý kết nối SSL, và chúng không được kế thừa quyền truy cập file đặc biệt nào.
Một số nguyên nhân thường gặp:
- File cert hoặc key thuộc sở hữu
root:rootvới quyền600. Chỉ root mới đọc được; user chạy Nginx worker không thể truy cập. - Thư mục cha có quyền
700, khiến worker không thể duyệt vào — các file bên trong coi như không tồn tại. - Bạn vừa gia hạn qua
certbotvà/etc/letsencrypt/live/cùng/etc/letsencrypt/archive/mặc định bị khóa ở700. Đây là hành vi cố định, luôn luôn vậy. - SELinux hoặc AppArmor chặn quyền truy cập dù
ls -latrông hoàn toàn bình thường.
Bước 1 — Xác Định Chính Xác File Nginx Không Mở Được
Chạy kiểm tra cấu hình trước:
sudo nginx -t 2>&1
Hoặc lọc log lỗi nếu service đang chạy:
sudo tail -50 /var/log/nginx/error.log | grep -i 'permission\|fopen\|SSL'
Kết quả sẽ cho biết tên file cụ thể. Ghi lại — bạn sẽ cần dùng đến ngay sau đây.
Bước 2 — Kiểm Tra Quyền Hiện Tại
Xem thư mục cert và các file bên trong:
ls -la /etc/nginx/ssl/
# hoặc với Let's Encrypt:
ls -la /etc/letsencrypt/live/yourdomain.com/
ls -la /etc/letsencrypt/archive/yourdomain.com/
Sau đó xác nhận user mà Nginx thực sự chạy với:
grep -E '^user' /etc/nginx/nginx.conf
# Thường là: user www-data; (Debian/Ubuntu)
# hoặc: user nginx; (CentOS/RHEL)
Cách Sửa A — File Chứng Chỉ Ngoài Let's Encrypt (Phổ Biến Nhất)
Cert lưu trong /etc/nginx/ssl/? Đặt quyền sở hữu nhóm cho user Nginx và siết chặt phân quyền:
# Thay www-data bằng nginx nếu dùng CentOS/RHEL
sudo chown root:www-data /etc/nginx/ssl/
sudo chmod 750 /etc/nginx/ssl/
sudo chown root:www-data /etc/nginx/ssl/yourdomain.crt
sudo chown root:www-data /etc/nginx/ssl/yourdomain.key
# 640 = root đọc/ghi, nhóm (Nginx worker) chỉ đọc, người khác không có quyền gì
sudo chmod 640 /etc/nginx/ssl/yourdomain.crt
sudo chmod 640 /etc/nginx/ssl/yourdomain.key
Nginx worker được quyền đọc thông qua tư cách thành viên nhóm. Khóa riêng tư vẫn được bảo vệ, người ngoài không thể truy cập.
Nếu bạn không nhớ các giá trị octal, Unix Permissions Calculator trên ToolCraft cho phép bạn chọn quyền bằng cách tích vào các ô — click vào checkbox và nhận kết quả octal ngay.
Cách Sửa B — Chứng Chỉ Let's Encrypt (Certbot)
Certbot cố ý khóa /etc/letsencrypt/ ở 700. Có hai cách xử lý gọn gàng.
Cách 1: Thêm user Nginx vào nhóm ssl-cert (Debian/Ubuntu):
sudo usermod -aG ssl-cert www-data
sudo chgrp ssl-cert /etc/letsencrypt/live/
sudo chgrp ssl-cert /etc/letsencrypt/archive/
sudo chmod g+rx /etc/letsencrypt/live/
sudo chmod g+rx /etc/letsencrypt/archive/
sudo chgrp -R ssl-cert /etc/letsencrypt/archive/yourdomain.com/
sudo chmod -R g+r /etc/letsencrypt/archive/yourdomain.com/
Cách 2: Sao chép cert vào thư mục Nginx kiểm soát (đơn giản hơn, dùng được mọi nơi):
sudo mkdir -p /etc/nginx/ssl
sudo cp /etc/letsencrypt/live/yourdomain.com/fullchain.pem /etc/nginx/ssl/
sudo cp /etc/letsencrypt/live/yourdomain.com/privkey.pem /etc/nginx/ssl/
sudo chown root:www-data /etc/nginx/ssl/*.pem
sudo chmod 640 /etc/nginx/ssl/*.pem
Sao chép cert tạo ra vấn đề đồng bộ — giải quyết bằng deploy hook chạy mỗi lần gia hạn:
# /etc/letsencrypt/renewal-hooks/deploy/copy-to-nginx.sh
#!/bin/bash
cp /etc/letsencrypt/live/yourdomain.com/fullchain.pem /etc/nginx/ssl/
cp /etc/letsencrypt/live/yourdomain.com/privkey.pem /etc/nginx/ssl/
chown root:www-data /etc/nginx/ssl/*.pem
chmod 640 /etc/nginx/ssl/*.pem
systemctl reload nginx
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/copy-to-nginx.sh
Cách Sửa C — SELinux Chặn Quyền Truy Cập (CentOS/RHEL)
Phân quyền trông đúng nhưng lỗi vẫn xuất hiện trên CentOS/RHEL? SELinux gần như chắc chắn là thủ phạm. Kiểm tra audit log:
sudo ausearch -m avc -ts recent | grep nginx
Có AVC denial ở đó? Gán lại nhãn SELinux đúng cho các file cert:
sudo chcon -t cert_t /etc/nginx/ssl/yourdomain.key
sudo chcon -t cert_t /etc/nginx/ssl/yourdomain.crt
# Nếu file đã ở vị trí chuẩn, dùng restorecon gọn hơn:
sudo restorecon -Rv /etc/nginx/ssl/
Cách Sửa D — AppArmor Profile (Ubuntu)
AppArmor trên Ubuntu có thể âm thầm chặn quyền truy cập file dù phân quyền đã đúng. Kiểm tra xem Nginx có profile đang hoạt động không:
sudo aa-status | grep nginx
sudo dmesg | grep -i apparmor | grep nginx
Nếu thấy profile đang được load, chuyển sang chế độ complain trong khi debug. Điều này cho phép Nginx chạy trong khi vẫn ghi lại những gì nó sẽ chặn:
sudo aa-complain /etc/apparmor.d/usr.sbin.nginx
# Khi đã hoạt động, thêm đường dẫn cert vào profile đúng cách, rồi enforce lại
Xác Nhận Đã Sửa Xong
Chạy qua checklist này sau khi áp dụng bất kỳ cách sửa nào ở trên:
# Kiểm tra cấu hình — kết quả mong muốn: syntax is ok + test is successful
sudo nginx -t
# Reload
sudo systemctl reload nginx
# Có lỗi SSL mới không?
sudo tail -20 /var/log/nginx/error.log
# Xác nhận TLS handshake từ bên ngoài
curl -vI https://yourdomain.com 2>&1 | grep -E 'SSL|TLS|certificate|subject'
Kết quả sạch sẽ cho thấy TLS handshake hoàn thành và thông tin subject của chứng chỉ xuất hiện trong output. Không có lỗi trong log là bạn đã xong.
Phòng Tránh
- Tích hợp phân quyền vào script provisioning của bạn. Dù dùng Ansible, Terraform hay script bash thông thường, hãy đặt quyền sở hữu cert và chmod ngay tại thời điểm deploy. Phân quyền bị thay đổi sau khi triển khai chính là lý do bạn đang đọc bài này.
- Luôn cấu hình certbot deploy hook. Mỗi lần gia hạn phải áp dụng lại phân quyền. Hook trong Cách Sửa B xử lý việc này chỉ với năm dòng shell.
- Đừng bao giờ
chmod 777khóa riêng tư. Khóa riêng tư phải ở600(chỉ root) hoặc640(root + nhóm web server). Bất kỳ quyền rộng hơn nào đều là vấn đề bảo mật, không phải cách sửa lỗi. - Kiểm tra toàn bộ đường dẫn trước khi go live. Chạy
namei -om /path/to/your.key— lệnh này duyệt qua từng thành phần của đường dẫn và chỉ ra chính xác nơi quyền truy cập bị gián đoạn. Phát hiện được các vấn đề phân quyền thư mục màls -latrên file riêng lẻ không thấy được.