Kịch bản
Bạn vừa mới cài đặt xong một chứng chỉ SSL mới. Về lý thuyết, mọi thứ trông có vẻ hoàn hảo. Tuy nhiên, ngay khi bạn truy cập tên miền của mình bằng Firefox, bạn gặp phải một trở ngại: SSL_ERROR_UNRECOGNIZED_NAME_ALERT. Trong khi Chrome có thể chỉ hiển thị cảnh báo 'Kết nối không phải là riêng tư' (Connection is not private) mơ hồ, Firefox hữu ích hơn nhiều—nó chỉ ra cụ thể lỗi xảy ra trong quá trình bắt tay (handshake) TLS.
Điều này thường xảy ra trên VPS hoặc máy chủ riêng (dedicated server) lưu trữ 5, 10 hoặc 100 tên miền khác nhau. Máy chủ bị nhầm lẫn. Nó nhận được yêu cầu nhưng không biết chứng chỉ cụ thể nào để gửi lại cho trình duyệt.
Tại sao lỗi này xảy ra
Hãy coi Server Name Indication (SNI) giống như số căn hộ trong môi trường kỹ thuật số. Trước đây, một địa chỉ IP tương ứng với một trang web. Ngày nay, một IP duy nhất có thể lưu trữ hàng trăm trang web. SNI là phần mở rộng giao thức TLS cho phép trình duyệt báo cho máy chủ biết, "Tôi đang tìm example.com," ngay khi bắt đầu kết nối.
Khi bạn thấy cảnh báo này, máy chủ về cơ bản đang nói: "Tôi đã nhận được yêu cầu cho example.com của bạn, nhưng tôi không có khối cấu hình (configuration block) hoặc chứng chỉ nào khớp với tên đó." Thay vì đoán và gửi sai chứng chỉ, máy chủ sẽ chấm dứt kết nối với cảnh báo 'Unrecognized Name'.
Bước 1: Kiểm tra cấu hình Nginx của bạn
Nginx rất nghiêm ngặt. Nếu chỉ thị server_name của bạn không khớp chính xác với host header từ trình duyệt, quá trình bắt tay có khả năng sẽ thất bại.
Kiểm tra Server Block
Xác định vị trí tệp cấu hình trang web của bạn—thường nằm trong /etc/nginx/sites-available/. Kiểm tra kỹ khối SSL của bạn:
server {
listen 443 ssl;
server_name example.com; # Tên này có khớp với thanh URL trên trình duyệt của bạn không?
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}
Việc thiếu tên miền phụ (subdomain) là một nguyên nhân phổ biến. Nếu bạn truy cập www.example.com nhưng cấu hình của bạn chỉ liệt kê tên miền gốc, máy chủ sẽ không nhận ra yêu cầu. Hãy khắc phục bằng cách liệt kê cả hai:
server_name example.com www.example.com;
Cẩn thận với bẫy Default Server
Nginx sẽ chuyển về máy chủ "mặc định" (default server) khi không tìm thấy kết quả khớp trực tiếp. Nếu khối mặc định đó thiếu SSL hoặc được cấu hình để từ chối các tên không xác định, trang web của bạn sẽ không tải được. Luôn đảm bảo khối tên miền cụ thể của bạn có mức ưu tiên cao nhất cho hostname duy nhất của nó.
Bước 2: Sửa lỗi SNI trên Apache
Người dùng Apache cũng gặp phải những trở ngại tương tự bên trong container VirtualHost. Sự chính xác là rất quan trọng ở đây. ServerName và ServerAlias của bạn phải khớp hoàn toàn với tên miền gây ra lỗi.
<VirtualHost *:443>
ServerName example.com
ServerAlias www.example.com
SSLEngine on
SSLCertificateFile /etc/ssl/certs/example.com.crt
SSLCertificateKeyFile /etc/ssl/private/example.com.key
</VirtualHost>
Apache hiện đại (2.4+) tự động xử lý SNI. Tuy nhiên, nếu bạn đang bảo trì một hệ thống cũ, hãy đảm bảo NameVirtualHost *:443 được định nghĩa trong cấu hình chung của bạn để cho phép nhiều chứng chỉ trên một IP.
Bước 3: Tìm kiếm xung đột cổng (Port)
Đôi khi, một tệp cấu hình thừa "chiếm đoạt" lưu lượng truy cập trên cổng 443 trước khi nó đến được khối tên miền của bạn. Điều này thường thấy nếu bạn vừa di chuyển trang web hoặc thay đổi hostname. Sử dụng grep để quét các thư mục cấu hình cho mọi phiên bản của cổng 443:
# Cho Nginx
grep -r "443" /etc/nginx/
# Cho Apache
grep -r "443" /etc/apache2/
Tìm các tệp default hoặc 000-default. Nếu chúng đang lắng nghe trên cổng 443 mà không có chứng chỉ hợp lệ, chúng sẽ đóng vai trò như một hố đen cho lưu lượng TLS của bạn.
Cấu hình SNI "Nghiêm ngặt" (Strict)
Các thiết lập Nginx nâng cao thường sử dụng ssl_reject_handshake on;. Đây là một tính năng bảo mật mạnh mẽ giúp ngắt bất kỳ kết nối nào không khớp với server_name đã biết. Mặc dù nó ngăn chặn việc quét dựa trên IP, nhưng nó làm cho lỗi SSL_ERROR_UNRECOGNIZED_NAME_ALERT trở nên không thể tránh khỏi nếu bạn có dù chỉ một lỗi đánh máy nhỏ trong cấu hình.
Hãy kiểm tra kỹ để đảm bảo khối tên miền của bạn đã được tải và hoạt động trước khi quy tắc từ chối này có hiệu lực.
Xác minh: Cách kiểm tra bản sửa lỗi của bạn
Các trình duyệt nổi tiếng với việc lưu bộ nhớ đệm (cache) rất mạnh. Để xem máy chủ thực sự đang làm gì, hãy sử dụng dòng lệnh.
Sử dụng OpenSSL
Lệnh này là tiêu chuẩn vàng để kiểm tra các vấn đề về SNI. Nó mô phỏng chính xác những gì trình duyệt thực hiện trong quá trình bắt tay:
openssl s_client -connect example.com:443 -servername example.com
Cờ -servername là "bí quyết" ở đây; nó gửi SNI header. Kiểm tra đầu ra để tìm Verification: OK và đảm bảo Certificate chain thực sự thuộc về tên miền của bạn. Nếu bạn thấy lỗi 'unrecognized name' ở đây, cấu hình phía máy chủ vẫn còn bị hỏng.
Sử dụng Curl
Để kiểm tra nhanh ở mức độ tổng quát, hãy sử dụng chế độ chi tiết (verbose) của curl:
curl -Iv https://example.com
Tìm dòng cho biết kết nối thành công, chẳng hạn như SSL connection using TLSv1.3. Nếu curl kết nối mà không phàn nàn về hostname, bạn đã giải quyết xong vấn đề.
Danh sách kiểm tra tóm tắt
- `server_name` (Nginx) hoặc `ServerName` (Apache) của bạn có khớp chính xác với URL không?
- Bạn đã bao gồm cả tên miền gốc và tên miền phụ `www` chưa?
- Bạn đã khởi động lại dịch vụ chưa? Sử dụng `systemctl restart nginx` hoặc `apache2`.
- Có khối cấu hình mặc định nào đang chặn các yêu cầu cổng 443 không?
- Các đường dẫn tệp `.pem` hoặc `.crt` của bạn có hợp lệ và máy chủ web có thể đọc được không?