Sửa lỗi NET::ERR_CERT_COMMON_NAME_INVALID: SSL Wildcard cho subdomain nhiều cấp

Vấn đềHãy tưởng tượng bạn vừa triển khai một microservice mới tại `sub.api.example.com`. Chứng chỉ wildcard SSL cho `*.example.com` hoạt động hoàn hảo cho `api.example.com` và `web.example.com`, vì vậy bạn kỳ vọng nó cũng sẽ hỗ trợ URL mới này. Tuy nhiên, trình duyệt lại đưa ra cảnh báo bảo mật và chặn kết nối.

Người dùng Chrome sẽ thấy lỗi cụ thể sau:

NET::ERR_CERT_COMMON_NAME_INVALID: *.example.com does not cover sub.api.example.com

Đây là một vấn đề đau đầu phổ biến khi mở rộng kiến trúc. Bạn có thể gặp phải rào cản này khi thiết lập các môi trường staging riêng biệt, chẳng hạn như dev.api.example.com, với giả định rằng chứng chỉ hiện tại của bạn là một giải pháp vạn năng.

Nguyên nhân gốc rễChứng chỉ Wildcard không có tính đệ quy. Theo các đặc tả SSL/TLS (RFC 6125), ký tự đại diện (`*`) chỉ bảo vệ duy nhất một cấp trong cấu trúc phân cấp tên miền phụ. Nó không thể "nhìn xuyên qua" các dấu chấm.

*.example.com xác thực cho one.example.com- *.example.com xác thực cho two.example.com- *.example.com THẤT BẠI đối với sub.one.example.comHãy coi đó là "Quy tắc Một Dấu Chấm". Khi trình duyệt truy cập sub.api.example.com, nó sẽ tìm kiếm một chứng chỉ bao phủ rõ ràng cấp độ thứ tư đó, chẳng hạn như *.api.example.com hoặc chính xác FQDN.

Quá trình kiểm tra (Debug)Hãy xác minh chính xác những gì máy chủ của bạn đang gửi trước khi bắt đầu thay đổi cấu hình. Bạn có thể trích xuất thông tin chi tiết về chứng chỉ trực tiếp từ terminal bằng lệnh `openssl`:

openssl s_client -connect sub.api.example.com:443 -servername sub.api.example.com | openssl x509 -text -noout | grep -A 1 "Subject Alternative Name"

Kiểm tra kết quả đầu ra. Nếu bạn chỉ thấy DNS:*.example.com, DNS:example.com, chứng chỉ của bạn về mặt kỹ thuật là không hợp lệ cho URL được yêu cầu. Trình duyệt có lý khi đưa ra cảnh báo; trường Subject Alternative Name (SAN) đơn giản là không bao phủ tên miền cấp bốn.

Các giải pháp### Cách 1: Cấp chứng chỉ Wildcard lồng nhau (Tốt nhất để mở rộng)Nếu bạn có kế hoạch lưu trữ nhiều tên miền phụ như `client1.api.example.com` và `client2.api.example.com`, bạn cần một chứng chỉ bao phủ cấp độ cụ thể đó. Thực tế, bạn có thể gộp nhiều cấp độ wildcard vào một chứng chỉ duy nhất.

Sử dụng Certbot với thử thách DNS-01, hãy chạy lệnh sau để bao phủ tên miền gốc, cấp một và cấp hai:

certbot certonly --manual --preferred-challenges dns \-d "example.com" \-d "*.example.com" \-d "*.api.example.com"

Lệnh này sẽ tạo ra một tệp .pem duy nhất. Lưu ý rằng nhà cung cấp DNS của bạn sẽ yêu cầu bạn tạo hai bản ghi TXT riêng biệt trong quá trình xác thực này.

Cách 2: Sử dụng chứng chỉ đa tên miền (SAN)Có thể bạn chỉ có một hoặc hai trường hợp ngoại lệ như `billing.api.example.com`. Trong trường hợp đó, bạn không cần wildcard lồng nhau. Chỉ cần thêm FQDN cụ thể vào yêu cầu chứng chỉ hiện có của bạn.

Đảm bảo Yêu cầu ký chứng chỉ (CSR) của bạn bao gồm các mục này trong trường SAN:

example.com- *.example.com- billing.api.example.com### Cách 3: Làm phẳng cấu trúc DNS của bạnĐôi khi giải pháp thông minh nhất nằm ở kiến trúc. Bạn có thể thay đổi sub.api.example.com thành sub-api.example.com không? Bằng cách thay thế dấu chấm bằng dấu gạch nối, bạn chuyển tên miền phụ trở lại cấp độ thứ ba. Chứng chỉ *.example.com ban đầu của bạn sẽ bao phủ nó một cách hoàn hảo mà không mất thêm chi phí hay cấu hình nào.

Cập nhật máy chủ WebSau khi có được chứng chỉ mới, hãy trỏ cấu hình máy chủ web của bạn đến các tệp đã cập nhật và tải lại dịch vụ.

Ví dụ cho Nginx```

server { listen 443 ssl; server_name sub.api.example.com;

ssl_certificate /etc/letsencrypt/live/api-combined/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/api-combined/privkey.pem;

}


### Ví dụ cho Apache```
<VirtualHost *:443>
    ServerName sub.api.example.com
    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/api-combined.crt
    SSLCertificateKeyFile /etc/ssl/private/api-combined.key
</VirtualHost>

Xác minhKhởi động lại máy chủ web của bạn (ví dụ: `systemctl restart nginx`) và kiểm tra kết nối bằng `curl`. Cờ `-v` cung cấp cái nhìn chi tiết về quá trình bắt tay SSL.

curl -vI https://sub.api.example.com

Tìm kiếm dòng SSL certificate verify ok trong kết quả đầu ra. Nếu lỗi vẫn còn, máy chủ có thể vẫn đang lưu bộ nhớ đệm chứng chỉ cũ hoặc trỏ sai đường dẫn tệp.

Bài học kinh nghiệmWildcard SSL rất tuyệt vời cho các cấu trúc phẳng nhưng dễ gây ra cảm giác an toàn giả tạo cho các cấu trúc phân cấp DNS phức tạp. Hãy ghi nhớ ba quy tắc sau cho dự án tiếp theo của bạn:

Giới hạn Một Dấu Chấm: Một wildcard bao phủ chính xác một cấp độ. Không hơn, không kém.- DNS-01 là chìa khóa: Sử dụng các thử thách DNS với Let's Encrypt để cấp chứng chỉ wildcard đa cấp một cách dễ dàng.- Dấu gạch nối tiết kiệm hơn: Tránh các tên miền phụ sâu nếu tên có dấu gạch nối đạt được cùng mục tiêu tổ chức.

Sửa lỗi NET::ERR_CERT_COMMON_NAME_INVALID: SSL Wildcard cho subdomain nhiều cấp

Nguyên nhân gốc rễChứng chỉ Wildcard không có tính đệ quy. Theo các đặc tả SSL/TLS (RFC 6125), ký tự đại diện (`*`) chỉ bảo vệ duy nhất một cấp trong cấu trúc phân cấp tên miền phụ. Nó không thể "nhìn xuyên qua" các dấu chấm.

Quá trình kiểm tra (Debug)Hãy xác minh chính xác những gì máy chủ của bạn đang gửi trước khi bắt đầu thay đổi cấu hình. Bạn có thể trích xuất thông tin chi tiết về chứng chỉ trực tiếp từ terminal bằng lệnh `openssl`:

Cập nhật máy chủ WebSau khi có được chứng chỉ mới, hãy trỏ cấu hình máy chủ web của bạn đến các tệp đã cập nhật và tải lại dịch vụ.

Ví dụ cho Nginx```

Xác minhKhởi động lại máy chủ web của bạn (ví dụ: `systemctl restart nginx`) và kiểm tra kết nối bằng `curl`. Cờ `-v` cung cấp cái nhìn chi tiết về quá trình bắt tay SSL.

Bài học kinh nghiệmWildcard SSL rất tuyệt vời cho các cấu trúc phẳng nhưng dễ gây ra cảm giác an toàn giả tạo cho các cấu trúc phân cấp DNS phức tạp. Hãy ghi nhớ ba quy tắc sau cho dự án tiếp theo của bạn:

Related Error Notes

Sửa lỗi OpenSSL error:06065064: EVP_DecryptFinal_ex:bad decrypt trên Private Key

Khắc phục NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM: Chuyển đổi từ SHA-1 lên SHA-256

Sửa lỗi ERR_SSL_KEY_USAGE_INCOMPATIBLE trên Chrome: Hướng dẫn về TLS 1.3

Nguyên nhân gốc rễChứng chỉ Wildcard không có tính đệ quy. Theo các đặc tả SSL/TLS (RFC 6125), ký tự đại diện (*) chỉ bảo vệ duy nhất một cấp trong cấu trúc phân cấp tên miền phụ. Nó không thể "nhìn xuyên qua" các dấu chấm.

Quá trình kiểm tra (Debug)Hãy xác minh chính xác những gì máy chủ của bạn đang gửi trước khi bắt đầu thay đổi cấu hình. Bạn có thể trích xuất thông tin chi tiết về chứng chỉ trực tiếp từ terminal bằng lệnh openssl:

Cập nhật máy chủ WebSau khi có được chứng chỉ mới, hãy trỏ cấu hình máy chủ web của bạn đến các tệp đã cập nhật và tải lại dịch vụ.

Ví dụ cho Nginx```

Xác minhKhởi động lại máy chủ web của bạn (ví dụ: systemctl restart nginx) và kiểm tra kết nối bằng curl. Cờ -v cung cấp cái nhìn chi tiết về quá trình bắt tay SSL.

Bài học kinh nghiệmWildcard SSL rất tuyệt vời cho các cấu trúc phẳng nhưng dễ gây ra cảm giác an toàn giả tạo cho các cấu trúc phân cấp DNS phức tạp. Hãy ghi nhớ ba quy tắc sau cho dự án tiếp theo của bạn:

Related Error Notes

Sửa lỗi OpenSSL error:06065064: EVP_DecryptFinal_ex:bad decrypt trên Private Key

Khắc phục NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM: Chuyển đổi từ SHA-1 lên SHA-256

Sửa lỗi ERR_SSL_KEY_USAGE_INCOMPATIBLE trên Chrome: Hướng dẫn về TLS 1.3

Nguyên nhân gốc rễChứng chỉ Wildcard không có tính đệ quy. Theo các đặc tả SSL/TLS (RFC 6125), ký tự đại diện (`*`) chỉ bảo vệ duy nhất một cấp trong cấu trúc phân cấp tên miền phụ. Nó không thể "nhìn xuyên qua" các dấu chấm.

Quá trình kiểm tra (Debug)Hãy xác minh chính xác những gì máy chủ của bạn đang gửi trước khi bắt đầu thay đổi cấu hình. Bạn có thể trích xuất thông tin chi tiết về chứng chỉ trực tiếp từ terminal bằng lệnh `openssl`:

Xác minhKhởi động lại máy chủ web của bạn (ví dụ: `systemctl restart nginx`) và kiểm tra kết nối bằng `curl`. Cờ `-v` cung cấp cái nhìn chi tiết về quá trình bắt tay SSL.