“Kết nối của bạn không phải là kết nối riêng tư”: đọc mã lỗi và sửa chứng chỉ SSL

Đọc mã lỗi trước khi sửa

Chúng tôi tạo lại cả ba mã này trên máy thử bằng Chromium 141, với một tổ chức cấp chứng chỉ thử nghiệm và các chứng chỉ cho tên miền tài liệu example.com, rồi kiểm tra lại bằng Google Chrome 155 với các website thử công khai của badssl.com (cách làm ở cuối bài). Ảnh dưới đây là cảnh báo khi mở www.example.com trong khi chứng chỉ chỉ ghi example.com.

Nếu bạn chỉ là người truy cập

• Kiểm tra ngày, giờ và múi giờ của thiết bị, bật chế độ đặt giờ tự động. Đồng hồ sai làm một chứng chỉ còn hạn trông như đã hết hạn.
• Thử một mạng khác, chẳng hạn 4G thay vì Wi-Fi công cộng. Mạng Wi-Fi cần đăng nhập ở khách sạn hay quán cà phê có thể chặn kết nối để hiện trang đăng nhập của họ.
• Phần mềm diệt virus có tính năng quét HTTPS cũng có thể gây cảnh báo trên nhiều website; tắt tạm tính năng đó để kiểm tra.
• Nếu chỉ một website báo lỗi còn các website khác bình thường, nhiều khả năng lỗi nằm ở website đó. Đừng nhập mật khẩu hay thông tin thẻ khi cảnh báo còn hiện.

Khi Chrome nghi đồng hồ của thiết bị sai, nó không hiện cảnh báo thường mà hiện màn hình Đồng hồ của bạn chạy nhanh (hoặc chạy chậm), vẫn kèm mã NET::ERR_CERT_DATE_INVALID. Trình duyệt đoán đồng hồ sai bằng giờ chuẩn lấy qua mạng; khi chưa lấy được, nó so với ngày bản trình duyệt được dựng và coi đồng hồ máy chạy nhanh nếu ngày của máy muộn hơn ngày đó quá 365 ngày. Ảnh dưới đây là đúng trường hợp này: đồng hồ của máy thử vẫn đúng, nhưng bản Chromium 141 trên máy thử được dựng từ tháng 9/2025, hơn một năm trước ngày thử, nên với chứng chỉ đã hết hạn nó hiện màn hình đồng hồ thay cho cảnh báo thường. Google Chrome 155 mở một website thật có chứng chỉ hết hạn thì hiện cảnh báo thường (xem phần chứng chỉ hết hạn bên dưới). Vì vậy với lỗi ngày tháng, hãy kiểm tra cả hai phía: ngày giờ của máy và ngày hết hạn của chứng chỉ; nếu đồng hồ đúng mà vẫn gặp màn hình này, hãy cập nhật trình duyệt.

Chủ website: xem chứng chỉ mà máy chủ thật sự gửi

Đừng chỉ nhìn ngày hết hạn trong trang quản trị hosting hay trong tệp chứng chỉ trên đĩa: thứ trình duyệt nhận là chứng chỉ mà máy chủ đang gửi đi. Lệnh sau hỏi thẳng máy chủ và in tên ghi trong chứng chỉ, tổ chức cấp và khoảng thời gian có hiệu lực:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

subject=CN = example.com
issuer=CN = Guide Test Intermediate CA
notBefore=Oct  1 00:00:00 2026 GMT
notAfter=Apr 19 00:00:00 2027 GMT
X509v3 Subject Alternative Name: 
    DNS:example.com, DNS:www.example.com

Cách đọc: notAfter là thời điểm hết hạn, tính theo giờ GMT. Dòng Subject Alternative Name liệt kê mọi tên mà chứng chỉ dùng được. Trình duyệt hiện nay chỉ đối chiếu tên với dòng này; từ bản 58, Chrome không còn dựa vào trường CN trong dòng subject nữa.

Tham số -servername rất quan trọng: một máy chủ thường phục vụ nhiều website, và thiếu tham số này bạn có thể nhận chứng chỉ của một website khác trên cùng máy.

Chứng chỉ hết hạn dù đã bật tự gia hạn

Trường hợp hay gặp: công cụ gia hạn báo thành công, tệp chứng chỉ mới đã nằm trên đĩa, nhưng web server vẫn gửi chứng chỉ cũ vì chưa được nạp lại. Hãy so ngày của máy chủ (lệnh ở trên) với ngày của tệp trên đĩa:

openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem -noout -enddate
openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem -noout -checkend 2592000

$ openssl x509 -in both.crt -noout -enddate -checkend 2592000
notAfter=Apr 19 00:00:00 2027 GMT
Certificate will not expire

$ openssl x509 -in expired.crt -noout -enddate -checkend 0
notAfter=Jul 20 00:00:00 2026 GMT
Certificate will expire

-checkend 2592000 hỏi "chứng chỉ còn hạn quá 30 ngày nữa không" (2592000 giây). Lệnh trả mã thoát 0 nếu còn và 1 nếu sắp hoặc đã hết hạn, nên dùng được trong script giám sát. Nếu ngày trên đĩa mới hơn ngày máy chủ gửi, chỉ cần nạp lại web server. Với Certbot, đặt lệnh nạp lại vào deploy hook để nó tự chạy sau mỗi lần gia hạn thành công; lệnh chạy thử certbot renew --dry-run kiểm tra được việc gia hạn nhưng không chạy deploy hook, trừ khi thêm tham số --run-deploy-hooks.

Với một website thật có chứng chỉ hết hạn

expired.badssl.com là website thử công khai cố ý dùng chứng chỉ đã hết hạn. Chạy cùng các lệnh với nó, thêm -verify_hostname để OpenSSL tự kiểm tra chứng chỉ, và thử bằng curl:

$ openssl s_client -connect expired.badssl.com:443 -servername expired.badssl.com </dev/null 2>/dev/null | openssl x509 -noout -enddate -checkend 2592000
notAfter=Apr 12 23:59:59 2015 GMT
Certificate will expire
(exit 1)

$ openssl s_client -connect expired.badssl.com:443 -servername expired.badssl.com -verify_hostname expired.badssl.com </dev/null 2>/dev/null | grep "Verify return code"
    Verify return code: 10 (certificate has expired)

$ curl -sS -o /dev/null -w '%{http_code}\n' https://expired.badssl.com/
curl: (60) SSL certificate problem: certificate has expired

Điều đáng chú ý: cùng website đó, Google Chrome 155 không báo NET::ERR_CERT_DATE_INVALID mà báo NET::ERR_CERT_AUTHORITY_INVALID, tức Chrome không nối được chuỗi chứng chỉ này tới một tổ chức cấp chứng chỉ mà nó tin, và mã lỗi không nhắc gì tới ngày hết hạn. Mã lỗi trên trình duyệt vì vậy chỉ là điểm bắt đầu; dòng notAfter và mã Verify return code của OpenSSL mới cho biết đủ các vấn đề của chứng chỉ.

Chứng chỉ không ghi www (NET::ERR_CERT_COMMON_NAME_INVALID)

Chứng chỉ chỉ ghi example.com thì khách mở www.example.com sẽ gặp lỗi, và ngược lại. Chạy lệnh ở trên với -servername www.example.com rồi đọc dòng Subject Alternative Name:

$ openssl s_client -connect 127.0.0.1:8445 -servername www.example.com </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName
X509v3 Subject Alternative Name: 
    DNS:example.com

$ openssl s_client -connect 127.0.0.1:8445 -servername www.example.com -verify_hostname www.example.com -CAfile root.crt </dev/null 2>/dev/null | grep "Verify return code"
Verify return code: 62 (hostname mismatch)

Website thử công khai wrong.host.badssl.com cho thấy đúng lỗi này trên Internet. Chứng chỉ của nó ghi *.badssl.com và badssl.com; tên wrong.host.badssl.com có hai nhãn đứng trước badssl.com, nên ký tự * (chỉ thay cho một nhãn) không khớp. Google Chrome 155 báo NET::ERR_CERT_COMMON_NAME_INVALID với website này.

$ openssl s_client -connect wrong.host.badssl.com:443 -servername wrong.host.badssl.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
subject=CN = *.badssl.com
issuer=C = US, O = Let's Encrypt, CN = YR1
notBefore=Sep 29 20:02:56 2026 GMT
notAfter=Dec 28 20:02:55 2026 GMT
X509v3 Subject Alternative Name: 
    DNS:*.badssl.com, DNS:badssl.com

$ openssl s_client -connect wrong.host.badssl.com:443 -servername wrong.host.badssl.com -verify_hostname wrong.host.badssl.com </dev/null 2>/dev/null | grep "Verify return code"
    Verify return code: 62 (hostname mismatch)

Cách sửa: cấp lại chứng chỉ ghi cả hai tên (với Let's Encrypt, khai báo cả example.com lẫn www.example.com khi xin chứng chỉ), rồi chuyển hướng 301 một tên về tên còn lại. Chứng chỉ wildcard *.example.com dùng được cho www.example.com nhưng không dùng được cho tên gốc example.com, vì ký tự * chỉ thay cho đúng một nhãn ở bên trái; muốn dùng cho tên gốc thì phải ghi thêm tên gốc vào chứng chỉ. Nếu DNS của hai tên chưa trỏ đúng, xem hướng dẫn trỏ tên miền về hosting.

Thiếu chứng chỉ trung gian

Chứng chỉ của website thường do một tổ chức cấp chứng chỉ trung gian ký, và máy chủ phải gửi kèm chứng chỉ trung gian đó để trình duyệt nối được tới chứng chỉ gốc mà nó tin. Cài chứng chỉ bằng tay rồi chỉ trỏ tới tệp chứng chỉ của website, bỏ quên chuỗi trung gian, là lỗi phổ biến. Một số trình duyệt tự tìm được chứng chỉ trung gian còn thiếu, nên website có thể trông bình thường trên máy bạn nhưng lỗi trên thiết bị hoặc ứng dụng khác.

$ openssl s_client -connect 127.0.0.1:8443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E "^ *[0-9] s:|^ *i:"
 0 s:CN = example.com
   i:CN = Guide Test Intermediate CA
 1 s:CN = Guide Test Intermediate CA
   i:CN = Guide Test Root CA

$ openssl s_client -connect 127.0.0.1:8446 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E "^ *[0-9] s:|^ *i:"
 0 s:CN = example.com
   i:CN = Guide Test Intermediate CA

$ openssl s_client -connect 127.0.0.1:8446 -servername example.com -verify_hostname example.com -CAfile root.crt </dev/null 2>/dev/null | grep "Verify return code"
Verify return code: 21 (unable to verify the first certificate)

Với website thật thì sao? incomplete-chain.badssl.com là website thử công khai cố ý gửi thiếu chứng chỉ trung gian. OpenSSL và curl đều từ chối nó, trong khi Google Chrome 155 mở trang bình thường (HTTP 200): đúng tình huống "trên máy tôi vẫn chạy" ở trên.

$ openssl s_client -connect incomplete-chain.badssl.com:443 -servername incomplete-chain.badssl.com -showcerts </dev/null 2>/dev/null | grep -E "^ *[0-9] s:|^ *i:"
 0 s:CN = *.badssl.com
   i:C = US, O = Let's Encrypt, CN = YR1

$ openssl s_client -connect incomplete-chain.badssl.com:443 -servername incomplete-chain.badssl.com -verify_hostname incomplete-chain.badssl.com </dev/null 2>/dev/null | grep "Verify return code"
    Verify return code: 21 (unable to verify the first certificate)

$ curl -sS -o /dev/null -w '%{http_code}\n' https://incomplete-chain.badssl.com/
curl: (60) SSL certificate problem: unable to get local issuer certificate

Trong thử nghiệm trên máy cục bộ, Chromium 141 báo NET::ERR_CERT_AUTHORITY_INVALID với máy chủ thứ hai. Cách sửa là cấu hình máy chủ dùng tệp chứa cả chuỗi. Với Certbot, đó là fullchain.pem (Nginx: ssl_certificate; Apache 2.4.8 trở lên: SSLCertificateFile) chứ không phải cert.pem.

Kiểm tra lại sau khi sửa

Chạy lại lệnh openssl s_client cho cả example.com và www.example.com, rồi mở website trong cửa sổ ẩn danh. Công cụ Kiểm tra website của OlaCheap cho biết HTTPS có hoạt động không, http:// có tự chuyển sang https:// không và website đã bật HSTS chưa. Công cụ này không thay cho lệnh openssl khi bạn cần biết chính xác ngày hết hạn hay chuỗi chứng chỉ.

Câu hỏi thường gặp

Cách chúng tôi tạo lại các lỗi trong bài

Các kết quả và ảnh từ máy thử cục bộ được tạo ngày 19/10/2026 trên Ubuntu 24.04 với OpenSSL 3.0.13: một tổ chức cấp chứng chỉ gốc và một tổ chức trung gian dùng riêng cho thử nghiệm, bốn máy chủ openssl s_server trên máy cục bộ (chứng chỉ đủ hai tên; chứng chỉ đã hết hạn; chứng chỉ chỉ ghi tên gốc; chứng chỉ đủ tên nhưng không gửi chuỗi trung gian), và Chromium 141 với hồ sơ riêng chỉ tin tổ chức thử nghiệm đó. Tên example.com được trỏ về máy cục bộ trong trình duyệt, nên không có website thật nào bị truy cập.

Phần kiểm tra với website thật chạy lúc 23:31 UTC ngày 19/10/2026 (ngày 20/10 giờ Việt Nam) trên máy chạy GitHub Actions: Ubuntu 24.04 với OpenSSL 3.0.13 và curl 8.5.0 cho các lệnh, Google Chrome 155.0.8059.39 giao diện tiếng Việt để mở expired.badssl.com, wrong.host.badssl.com, self-signed.badssl.com, untrusted-root.badssl.com và incomplete-chain.badssl.com. Đây là các website do dự án badssl.com dựng sẵn để thử lỗi chứng chỉ; Chrome chỉ mở trang, không bấm vào nút nào. Hai website tự ký và gốc không được tin đều cho NET::ERR_CERT_AUTHORITY_INVALID.