LỗiBạn cố gắng truy cập một trang web phát triển cục bộ hoặc một công cụ nội bộ qua HTTPS, nhưng Chrome đã chặn đứng bạn. Thay vì thấy trang web, bạn lại nhận được một màn hình trắng với cảnh báo thẳng thừng:
This site can’t provide a secure connection
ERR_SSL_KEY_USAGE_INCOMPATIBLE
Lỗi này thường xảy ra với các nhà phát triển ngay sau khi cập nhật trình duyệt hoặc khi triển khai một loạt chứng chỉ tự ký (self-signed certificates) mới. Điều đó có nghĩa là chứng chỉ của bạn tuyên bố có thể thực hiện một chức năng, nhưng quá trình bắt tay TLS (thường là phiên bản 1.3) lại yêu cầu một chức năng khác.
Tại sao Chrome lại chặn bạnKhi Chrome 117 ra mắt vào cuối năm 2023, nó đã siết chặt việc xác thực chứng chỉ X.509. Cụ thể, nó bắt đầu thực thi nghiêm ngặt phần mở rộng keyUsage. Trong quá khứ, Chrome thường bỏ qua nếu các cài đặt này bị thiếu hoặc lộn xộn. Điều đó đã thay đổi khi chuyển sang TLS 1.3.
TLS 1.3 xử lý bảo mật khác với các phiên bản tiền nhiệm. Nếu bạn sử dụng chứng chỉ RSA, giao thức hiện yêu cầu Digital Signature để chứng minh quyền sở hữu trong quá trình bắt tay. Nếu chứng chỉ của bạn chỉ liệt kê Key Encipherment (tiêu chuẩn cũ cho RSA) hoặc thiếu hoàn toàn phần mở rộng này, Chrome sẽ từ chối nó. Đây là một biện pháp bảo mật được thiết kế để ngăn chặn "tấn công hạ cấp" (downgrade attacks), nơi máy chủ bị buộc phải sử dụng phiên bản TLS cũ hơn, yếu hơn.
Cách khắc phục từng bướcBạn không thể chỉ nhấp vào "Nâng cao" và bỏ qua lỗi này. Để khắc phục, bạn phải tạo lại chứng chỉ SSL với các bit keyUsage chính xác. OpenSSL là công cụ tốt nhất cho việc này.
1. Kiểm tra chứng chỉ hiện tại của bạnĐầu tiên, hãy xác nhận xem trường keyUsage có thực sự là nguyên nhân hay không. Chạy lệnh sau để kiểm tra nội dung tệp chứng chỉ của bạn:
openssl x509 -in your_certificate.crt -text -noout | grep -A 1 "Key Usage"
Nếu kết quả không hiển thị Digital Signature, bạn đã tìm thấy nguyên nhân. Nếu phần "Key Usage" hoàn toàn không có, Chrome sẽ coi chứng chỉ đó quá cũ để tin cậy cho TLS 1.3.
2. Xây dựng tệp cấu hình tốt hơnĐừng dựa vào các thiết lập mặc định của dòng lệnh. Thay vào đó, hãy tạo một tệp riêng có tên openssl.cnf. Điều này đảm bảo mọi phần mở rộng cần thiết được tích hợp chính xác ngay từ đầu.
[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = US
ST = New York
L = Brooklyn
O = TechCorp
CN = localhost
[v3_req]
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = localhost
IP.1 = 127.0.0.1
Phần thiết yếu: Bạn phải bao gồm digitalSignature. Chúng tôi cũng bao gồm keyEncipherment để chứng chỉ vẫn tương thích với các máy khách TLS 1.2 cũ hơn có thể vẫn còn tồn tại trong mạng của bạn.
3. Tạo chứng chỉ đã cập nhậtSử dụng tệp cấu hình mới của bạn để tạo khóa RSA 2048-bit và một chứng chỉ mới. Lệnh này thực hiện tất cả trong một lần:
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
-keyout server.key -out server.crt \
-config openssl.cnf -extensions v3_req
4. Triển khai lên Web Server của bạnThay thế các tệp cũ của bạn bằng server.crt và server.key mới. Nếu bạn đang sử dụng Nginx, cấu hình của bạn sẽ trông giống như đoạn mã này:
server {
listen 443 ssl;
server_name localhost;
ssl_certificate /etc/nginx/ssl/server.crt;
ssl_certificate_key /etc/nginx/ssl/server.key;
# Thực thi các giao thức hiện đại, an toàn
ssl_protocols TLSv1.2 TLSv1.3;
}
Sau khi lưu, hãy khởi động lại dịch vụ bằng sudo systemctl restart nginx. Bạn có thể cần khởi động lại Chrome hoặc xóa "HSTS cache" để thay đổi có hiệu lực.
Xác minh kết quả### Kiểm tra bằng OpenSSLChạy lại lệnh kiểm tra để xác minh các bit đã được thiết lập:
openssl x509 -in server.crt -text -noout | grep -A 1 "Key Usage"
Bây giờ bạn sẽ thấy một thông báo thành công rõ ràng:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
Kiểm tra trong Chrome DevTools
- Truy cập trang web của bạn và nhấn `F12`.
- Mở tab **Security**.
- Nhấp vào **View Certificate**.
- Trong danh sách **Details**, tìm **Key Usage**. Nó phải liệt kê rõ ràng "Digital Signature."
Lời khuyên từ chuyên gia
- **Tự động hóa với mkcert:** Nếu bạn quản lý nhiều tên miền cục bộ, `mkcert` là một cứu cánh. Nó tự động tạo các chứng chỉ được tin cậy cục bộ và đã đáp ứng các yêu cầu nghiêm ngặt của TLS 1.3 này.
- **Các mẫu CA của doanh nghiệp:** Nếu công ty của bạn sử dụng CA nội bộ (như Active Directory Certificate Services), vấn đề có thể nằm ở mẫu chứng chỉ. Đảm bảo rằng mẫu "Server Authentication" bao gồm bit Digital Signature.
- **Lợi thế của ECDSA:** Mặc dù RSA phổ biến, việc chuyển sang chứng chỉ ECDSA (sử dụng các đường cong P-256 hoặc P-384) thường tốt hơn. Chúng nhanh hơn, nhỏ hơn và vốn dĩ yêu cầu `digitalSignature` cho các quá trình bắt tay.