Ngôn ngữ

Chứng chỉ SSL/TLS

So sánh DV, OV và EV; wildcard và SAN; Let’s Encrypt cùng việc cấp chứng chỉ miễn phí tự động; lỗi chuỗi chứng chỉ, hết hạn và gia hạn tự động; và điều gì xảy ra với người dùng lẫn trình thu thập dữ liệu khi chứng chỉ không hợp lệ — phần phân tích chuyên sâu về chứng chỉ trong cụm nội dung HTTPS.

Xuất bản lần đầu: 3 thg 7, 2026 · Cập nhật lần cuối: 20 thg 8, 2026 · Advanced
Ngôn ngữ
AIĐược viết bởiAI v2

Google không công bố sự khác biệt về thứ hạng giữa chứng chỉ DV, OV và EV, cũng như giữa chứng chỉ Let’s Encrypt miễn phí và chứng chỉ trả phí. Miễn là HTTPS hợp lệ, chúng được xử lý như nhau; chứng chỉ đắt hơn mua thêm mức độ tin cậy về con người hoặc tổ chức, không mua thứ hạng. Độ sâu xác thực (DV/OV/IV/EV) và phạm vi bao phủ (một tên miền, wildcard, SAN) là hai quyết định riêng, và không quyết định nào là yếu tố xếp hạng đã được công bố. Chứng chỉ ảnh hưởng đến SEO khi bị lỗi: chứng chỉ hết hạn, tự ký, không khớp tên máy chủ hoặc hỏng chuỗi gây cảnh báo trình duyệt khiến người dùng rời đi; có thể khiến Google chuyển ưu tiên canonical thông thường từ HTTPS về HTTP (HSTS không thể ghi đè); và nếu lỗi HTTPS tích tụ, có thể khiến Google ngừng thu thập dữ liệu các trang HTTPS. Khi thời hạn tối đa của chứng chỉ giảm dần còn 47 ngày vào năm 2029, gia hạn tự động trở thành bắt buộc về mặt vận hành chứ không còn là tùy chọn.

Tóm tắt — Google không ghi nhận sự khác biệt về thứ hạng giữa độ sâu xác thực DV/OV/EV hoặc giữa chứng chỉ miễn phí và trả phí — chứng chỉ đắt hơn mang lại mức độ tin cậy về con người hoặc tổ chức, chứ không mang lại thứ hạng. Độ sâu xác thực (DV/OV/IV/EV) và phạm vi bao phủ (một tên miền/wildcard/SAN) là hai quyết định độc lập; không lựa chọn nào là yếu tố xếp hạng đã được ghi nhận. Let’s Encrypt và việc cấp chứng chỉ tự động miễn phí qua ACME không phải là một sự đánh đổi — khả năng mã hóa và cách Google xử lý vẫn như nhau. Chứng chỉ ảnh hưởng đến SEO khi xảy ra lỗi: chứng chỉ hết hạn, tự ký, không khớp tên máy chủ hoặc hỏng chuỗi tin cậy khiến người dùng không thể truy cập trang, có thể làm Google chuyển ưu tiên chuẩn hóa thông thường từ HTTPS trở lại phiên bản HTTP (HSTS không thể ghi đè điều đó), và theo tài liệu của Google, nếu có đủ nhiều sự cố HTTPS thì chúng “can prompt Google to stop crawling your HTTPS pages” (bản dịch: «có thể khiến Google ngừng thu thập dữ liệu các trang HTTPS của bạn») hoàn toàn. Khi CA/Browser Forum giảm thời hạn tối đa xuống 47 ngày vào năm 2029, gia hạn tự động trở thành yêu cầu bắt buộc. Bài tổng quan về HTTPS giới thiệu rằng chứng chỉ DV miễn phí nhận cùng tín hiệu như OV/EV; phần này giải thích đầy đủ cơ sở của nhận định đó.

Trung tâm HTTPS giải thích rằng HTTPS nhiều nhất chỉ là tín hiệu phá thế hòa, Google kiểm tra giao thức chứ không kiểm tra chứng chỉ, và DV miễn phí nhận cùng tín hiệu như OV/EV đắt tiền. Bài này đi sâu thêm một lớp vào chính chứng chỉ: DV/OV/EV thực sự có nghĩa gì, phạm vi bao phủ hoạt động ra sao, vì sao chứng chỉ miễn phí tự động là đủ, chuỗi chứng chỉ hỏng thế nào mà phép thử của bạn không thấy, và điều gì thực sự xảy ra với thu thập dữ liệu khi chứng chỉ bị lỗi.

“Chứng chỉ SSL” thực ra là chứng chỉ TLS

SSL là thuật ngữ đã lỗi thời đối với các hệ thống triển khai TLS hiện đại. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: RFC 8446: TLS 1.3 Hướng dẫn tìm kiếm tập trung vào HTTPS hợp lệ và có thể truy cập, thay vì cấp độ chứng chỉ thương mại. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: Google: HTTPS

Ghi chú nhanh về tên gọi rồi chuyển tiếp: SSL (Secure Sockets Layer) là giao thức đã ngừng dùng; mọi chứng chỉ được cấp hiện nay chạy trên TLS (Transport Layer Security). “Chứng chỉ SSL” vẫn tồn tại như tên gọi thông dụng — ngay cả chuỗi giao diện Search Console của Google vẫn dùng “SSL certificate problems”. Phần còn lại của bài viết sẽ gọi ngắn gọn là “chứng chỉ”.

Mức độ xác minh: DV so với OV, IV và EV

Chứng chỉ được cấp ở các mức xác minh khác nhau, mô tả mức độ tổ chức phát hành chứng chỉ (CA) đã kiểm tra trước khi bảo chứng cho bạn. Theo phân loại của SSL.com:

  • DV (Domain Validation) là “the lowest level of validation, and verifies that whoever requests the certificate controls the domain that the certificate protects.” (bản dịch: «cấp xác thực thấp nhất, xác minh người yêu cầu chứng chỉ kiểm soát tên miền mà chứng chỉ bảo vệ»). Cách này nhanh, rẻ hoặc miễn phí và thường tự động.
  • OV (Organization Validation) “verifies the identity of the organization (e.g. a business, nonprofit, or government organization) of the Subject listed in the certificate, along with the location where the organization operates.” (bản dịch: «xác minh danh tính và địa điểm hoạt động của tổ chức được ghi là Chủ thể trong chứng chỉ»).
  • IV (Individual Validation) “verifies the identity of the individual person listed as the Subject of the certificate.” (bản dịch: «xác minh danh tính cá nhân được ghi là Chủ thể của chứng chỉ»).
  • EV (Extended Validation), “like OV, verifies the identity of an organization. However, EV represents a higher standard of trust than OV and requires more rigorous validation checks.” (bản dịch: «giống OV, EV xác minh danh tính tổ chức nhưng đòi hỏi tiêu chuẩn tin cậy cao hơn và kiểm tra nghiêm ngặt hơn»).

Đây là điểm liên quan đến SEO: Google không công bố sự khác biệt về thứ hạng giữa các cấp xác thực. Bài tổng quan xác lập rằng tín hiệu cơ bản đọc giao thức URL — Illyes mô tả nó là nhìn vào năm ký tự đầu trước URL. Miễn là HTTPS hợp lệ và hoạt động, chứng chỉ DV, OV và EV đều được xử lý như nhau. Chênh lệch giá phản ánh công sức thẩm định và trách nhiệm của CA, không phản ánh ưu tiên của Google — web.dev nói rõ rằng “different CAs charge different amounts of money for the service of vouching for your public key.” (bản dịch) «Các CA khác nhau tính mức phí khác nhau cho dịch vụ bảo chứng khóa công khai của bạn.» Số tiền bổ sung mua thêm niềm tin dành cho con người và tổ chức, chỉ vậy thôi.

Và lập luận hướng đến người dùng cuối còn lại cho EV phần lớn đã biến mất: cách trình duyệt hiển thị đặc biệt cho EV trên thanh địa chỉ hầu như không còn. Chrome bỏ giao diện tên công ty màu xanh từ Chrome 77 (2019), Firefox 70 cũng làm vậy trong cùng năm. Vì thế, lời chào bán “khách hàng sẽ thấy tên công ty trên thanh địa chỉ” từng dùng để biện minh cho giá EV không còn đúng trên các trình duyệt phổ biến — hãy xác minh hành vi trình duyệt hiện tại nếu bạn đang quyết định mua, nhưng hiện nay tín hiệu trực quan đó không còn.

Phạm vi bao phủ: một tên miền, wildcard và SAN

Mức độ xác minh là một trục. Phạm vi bao phủ — những tên máy chủ mà chứng chỉ thực sự bảo vệ — là một trục hoàn toàn khác. Nhìn chung, mọi phạm vi đều có thể được cấp ở mức DV hoặc OV (chính sách CA/B thường không cung cấp wildcard ở mức EV):

  • Một tên miền — bao phủ đúng một tên máy chủ, ví dụ www.example.com.
  • Wildcard — bao phủ một mẫu tên máy chủ sâu một nhãn DNS. web.dev nêu chính xác giới hạn: “In wildcard certificates, the wildcard applies to only one DNS label. A certificate good for *.example.com works for foo.example.com and bar.example.com, but not for foo.bar.example.com.” (bản dịch) «Trong chứng chỉ wildcard, ký tự đại diện chỉ áp dụng cho một nhãn DNS. Chứng chỉ dành cho *.example.com hoạt động với foo.example.com và bar.example.com, nhưng không hoạt động với foo.bar.example.com.» Mệnh đề cuối là cạm bẫy — wildcard không bao phủ tên miền phụ cấp hai.
  • SAN / nhiều tên miền (UCC) — danh sách rõ ràng các tên máy chủ cụ thể trong Subject Alternative Names của chứng chỉ. web.dev lưu ý bạn có “options for mapping your key to more than one DNS name, including several distinct names (e.g. all of example.com, www.example.com, example.net, and www.example.net).” (bản dịch) «các lựa chọn để ánh xạ khóa đến nhiều tên DNS, kể cả nhiều tên hoàn toàn khác nhau.» Chứng chỉ SAN thậm chí có thể trải trên các tên miền khác hẳn nhau, hữu ích khi bạn có vài tài sản liên quan mà không muốn cấp wildcard quá rộng.

Chế độ lỗi SEO thực tế nằm ở giới hạn một nhãn của wildcard. Giả sử bạn dùng *.example.com và ai đó tạo staging.blog.example.com — tên này sâu hai nhãn, nằm ngoài wildcard và sẽ trả lỗi chứng chỉ hoặc rơi về chứng chỉ không khớp. Nếu Google hoặc người dùng truy cập, họ sẽ gặp trải nghiệm chứng chỉ hỏng trên trang mà bạn tưởng đã được bảo vệ.

Một cạm bẫy bao phủ khác: kiểm thử đạt trên tên máy chủ đỉnh không chứng minh mọi nơi đều được bao phủ. Máy khách phải yêu cầu đúng tên máy chủ đang kết nối và nhận chứng chỉ thực sự chứa tên đó (qua SNI) — trên CDN, bộ cân bằng tải và hạ tầng dùng chung dựa trên SNI, các điểm biên, khu vực hoặc máy chủ gốc khác nhau phía sau cùng một tên miền có thể hợp lệ mà vẫn phục vụ các chứng chỉ khác nhau. Hãy kiểm thử riêng từng tên máy chủ công khai thay vì cho rằng một kết quả SSL Labs sạch trên example.com cũng đại diện cho www., một điểm biên khu vực hoặc tên miền phụ phía sau máy chủ gốc khác.

Let’s Encrypt và việc cấp chứng chỉ tự động miễn phí

Let’s Encrypt và các CA miễn phí khác cấp chứng chỉ DV qua giao thức ACME — vòng lặp tự động yêu cầu/thách thức/cấp phát mà máy khách như Certbot thực hiện cho bạn. Mọi người thường hiểu sai hai điều:

  1. Miễn phí không có nghĩa là yếu hơn. Chứng chỉ Let’s Encrypt có cùng độ mạnh mã hóa TLS như chứng chỉ trả phí và được Google xử lý xếp hạng y hệt vì tín hiệu dựa trên giao thức. Đánh đổi thực tế chỉ là DV (không thẩm tra danh tính OV/EV) và thời hạn ngắn.
  2. Thời hạn ngắn là ưu điểm khi đã tự động hóa. Nó rút ngắn cửa sổ phơi nhiễm nếu khóa bị xâm phạm và không cần con người nhớ gia hạn. Tự động hóa biến thời hạn ngắn nhất thành lựa chọn an toàn nhất.

Điểm thứ hai này sắp trở nên quan trọng với tất cả mọi người, không chỉ người dùng Let’s Encrypt.

Thay đổi thời hạn chứng chỉ (2026–2029) — hãy tự động hóa ngay

Ngành đang rút ngắn thời hạn chứng chỉ theo một lịch cố định. CA/Browser Forum đã thông qua Ballot SC-081v3 (kết thúc bỏ phiếu ngày 11 tháng 4 năm 2025), giảm thời hạn tối đa của chứng chỉ TLS theo từng giai đoạn:

  • 398 ngày ở thời điểm hiện tại
  • 200 ngày từ ngày 15 tháng 3 năm 2026
  • 100 ngày từ ngày 15 tháng 3 năm 2027
  • 47 ngày từ ngày 15 tháng 3 năm 2029

Let’s Encrypt cũng đi theo lộ trình riêng nhanh hơn: theo cập nhật tháng 2 năm 2026, tổ chức này sẽ giảm thời hạn chứng chỉ mặc định theo hai bước trong hai năm tiếp theo — “from 90 days to 64 days, and then 45 days” (bản dịch) «từ 90 ngày xuống 64 ngày, rồi 45 ngày» — còn thời điểm gia hạn chuyển từ khoảng ngày 60 của chứng chỉ 90 ngày hiện nay sang khoảng ngày 30 khi thời hạn còn 45 ngày. Cập nhật này thay thế một lịch trình cũ cụ thể hơn; hãy coi ngày triển khai chính xác của từng bước là chưa chốt và kiểm tra changelog của Let’s Encrypt trước khi dựa vào một ngày cụ thể.

Kết luận vận hành rất thẳng thắn: nếu quy trình gia hạn chưa được tự động hóa, hãy sửa trước năm 2027. Nhịp gia hạn thủ công còn có thể chịu được với 398 ngày sẽ gần như chắc chắn gây gián đoạn ở mức 47–100 ngày. DigiCert diễn đạt rõ khi đưa tin về lá phiếu: việc xác minh lại thủ công vẫn có thể thực hiện về kỹ thuật, nhưng “doing so would be a recipe for failure and outages.” (bản dịch: «làm vậy sẽ là công thức dẫn đến thất bại và gián đoạn») Tự động hóa không còn là tiện ích tùy chọn mà trở thành lựa chọn hợp lý duy nhất.

Lỗi chuỗi chứng chỉ hoặc chứng chỉ trung gian

Đây là phần ít được giải thích và tài liệu Google không mô tả cơ chế, nên hãy xem cách nó thực sự hoạt động.

Trình duyệt chỉ tin cậy một tập nhỏ chứng chỉ gốc (root) được tích hợp sẵn trong kho tin cậy. Chứng chỉ của máy chủ — chứng chỉ đầu cuối (leaf) — gần như không bao giờ được chứng chỉ gốc ký trực tiếp. Thay vào đó là một chuỗi: chứng chỉ đầu cuối → một hoặc nhiều chứng chỉ trung gian (intermediate) → chứng chỉ gốc đáng tin cậy. Để máy khách tin cậy chứng chỉ đầu cuối, máy chủ phải gửi chứng chỉ đầu cuối cùng các chứng chỉ trung gian để máy khách dựng được đường dẫn đến một chứng chỉ gốc mà nó đã tin cậy.

Cấu hình sai kinh điển là máy chủ chỉ gửi chứng chỉ lá và bỏ qua chứng chỉ trung gian. Điều nguy hiểm là Chrome trên máy tính thường vẫn hoạt động, vì trình duyệt có thể đã lưu chứng chỉ trung gian từ trang khác và tự lấp khoảng trống. Người kiểm thử trên laptop thấy ổ khóa xanh rồi cho rằng mọi thứ ổn. Trong khi đó, trình duyệt di động, nhiều máy khách API/HTTP và công cụ khác không có chứng chỉ trung gian trong cache sẽ thất bại hoàn toàn khi bắt tay. Đây là lỗi “works on my machine” (bản dịch: «máy tôi vẫn chạy») ở lớp TLS.

Để phát hiện lỗi này, đừng chỉ kiểm tra nhanh bằng Chrome trên máy tính. Hãy dùng công cụ tự xây dựng chuỗi từ đầu:

  • SSL Labs’ Server Test đánh dấu rõ lỗi “extra download” / chuỗi không đầy đủ.
  • openssl s_client -connect example.com:443 -showcerts trên dòng lệnh hiển thị mọi chứng chỉ máy chủ thực sự gửi, để bạn xác nhận chứng chỉ trung gian có mặt.

Điều gì xảy ra khi chứng chỉ không hợp lệ, hết hạn hoặc tự ký

Đây là phần quan trọng nhất và được chia rõ thành hai nhánh — vì người dùng và trình thu thập trải nghiệm chứng chỉ hỏng theo cách khác nhau.

Người dùng và trình duyệt phản ứng ra sao. Một lỗi chứng chỉ nghiêm trọng — chứng chỉ hết hạn, tự ký, tên máy chủ không khớp hoặc CA không được tin cậy — sẽ hiện cảnh báo xen kẽ toàn màn hình, chứ không phải nhãn “Not Secure” (bản dịch: «Không bảo mật») nhẹ nhàng dành cho HTTP. Người dùng sẽ rời đi. Trường hợp được ghi chép rõ nhất là bài “A Wolf in Panda’s Clothing” (bản dịch: «Sói khoác áo Panda») của Glenn Gabe: lưu lượng của một trang thương mại điện tử lao dốc đúng ngày trùng với một bản cập nhật Google Panda, nên chủ trang cho rằng mình bị phạt. Nguyên nhân thực sự là chứng chỉ hết hạn khiến trình duyệt hiện cảnh báo; khách truy cập bỏ đi trước khi vào được trang. Theo lời Gabe: “There are times that SEO problems aren’t really SEO problems. Technical issues that appear at the same time algorithm updates hit can be confusing.” (bản dịch: «Đôi khi vấn đề tưởng là SEO thực ra không phải vấn đề SEO. Các sự cố kỹ thuật xuất hiện cùng lúc với bản cập nhật thuật toán có thể khiến việc chẩn đoán trở nên khó hiểu.») Sau khi gia hạn chứng chỉ, lưu lượng phục hồi trong khoảng tám ngày. Trong thực tế, chứng chỉ tự ký cũng gây cảnh báo xen kẽ nghiêm trọng như vậy: chúng phù hợp với môi trường nội bộ, phát triển hoặc tiền sản xuất, nhưng không bao giờ phù hợp với trang công khai đang vận hành.

Google làm gì. Đây là sắc thái mà gần như mọi trang cạnh tranh bỏ lỡ, và hậu quả lớn hơn cách diễn đạt đơn giản rằng “tín hiệu dựa trên giao thức”. Hướng dẫn canonical của Google nói rõ chứng chỉ hỏng không vô hình với Tìm kiếm: “Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals,” (bản dịch) «Google ưu tiên trang HTTPS hơn trang HTTP tương đương làm canonical, trừ khi có lỗi hoặc tín hiệu xung đột», đồng thời nêu trực tiếp chứng chỉ lỗi: “Avoid bad TLS/SSL certificates and HTTPS-to-HTTP redirects because they cause Google to prefer HTTP very strongly. Implementing HSTS cannot override this strong preference.” (bản dịch) «Hãy tránh chứng chỉ TLS/SSL lỗi và chuyển hướng HTTPS sang HTTP vì chúng khiến Google ưu tiên HTTP rất mạnh. Việc triển khai HSTS không thể ghi đè ưu tiên mạnh này.» Nói cách khác, chứng chỉ thực sự bị hỏng có thể khiến Google chọn lại phiên bản HTTP thuần làm canonical — tác động thật đến nội dung xuất hiện trong Tìm kiếm, không chỉ là ghi chú về ngân sách thu thập dữ liệu.

Ngoài ra, tài liệu Search Console của Google nói lỗi chứng chỉ còn gây hậu quả về thu thập dữ liệu: chứng chỉ không hợp lệ “typically affects an entire site,” (bản dịch) «thường ảnh hưởng toàn bộ trang», và “if a site has a lot of HTTPS issues, it can prompt Google to stop crawling your HTTPS pages.” (bản dịch) «nếu một trang có nhiều lỗi HTTPS, điều đó có thể khiến Google ngừng thu thập các trang HTTPS». Khi đó các URL còn lại nhận nhãn “HTTPS not evaluated.” (bản dịch) «HTTPS chưa được đánh giá». Vì vậy có hai cơ chế riêng: ưu tiên canonical quay về HTTP và việc hạn chế quyền truy cập thu thập dữ liệu; cả hai đều có thể tạo cùng biểu hiện (trang rơi khỏi chỉ mục) mà không thay đổi tín hiệu xếp hạng cơ bản https://. Hãy sửa chứng chỉ; không có đòn bẩy yếu tố xếp hạng nào cần theo đuổi, nhưng cũng không thể cho rằng “vô hại vì giao thức không đổi”.

Danh sách nguyên nhân lỗi của Google khớp với hệ phân loại: tên máy chủ không khớp với các tên trong chứng chỉ — “The host name of your site does not match any of the Subject Names in your SSL certificate” (bản dịch) «Tên máy chủ của trang không khớp với bất kỳ Subject Name nào trong chứng chỉ SSL» — và chứng chỉ “not recognized by major web browsers” (bản dịch) «không được các trình duyệt web lớn công nhận» (tự ký, CA không đáng tin cậy, bị hỏng, đã quá hạn hoặc chưa có hiệu lực).

Giám sát hết hạn và tự động gia hạn

Hết hạn là lỗi chứng chỉ phổ biến nhất và dễ phòng tránh nhất, với phạm vi ảnh hưởng không cân xứng: thường làm hỏng toàn bộ trang cùng lúc (Google: “Typically this affects an entire site” — bản dịch: «Thông thường điều này ảnh hưởng toàn bộ trang»), chứ không từng trang một. Cách sửa không bao giờ là lời nhắc lịch; hãy thiết lập tự động hóa thực sự:

  • ACME / Certbot trên máy chủ riêng, hoặc giải pháp tương đương do nền tảng cung cấp.
  • Chứng chỉ do nhà cung cấp hosting hoặc CDN quản lý (Cloudflare, phần lớn dịch vụ hosting được quản lý, nhiều nền tảng PaaS), tự động cấp và gia hạn cho bạn.
  • Trình giám sát chứng chỉ/thời gian hoạt động của bên thứ ba, cảnh báo khi sắp hết hạn và khi bắt tay thất bại, làm lớp dự phòng ngay cả khi gia hạn đã tự động.

Khi thời hạn giảm dần về 47 ngày, nhắc việc thủ công trở nên không khả thi về mặt vận hành — tự động hóa là cách duy nhất có thể mở rộng.

Cấu hình nhiều chứng chỉ trên các tên miền phụ

Điều này khác với mixed content (trang HTTPS tải tài nguyên con qua HTTP — đã được trình bày ở bài tổng quan). Mixed-cert là khi các phần khác nhau của trang được bảo vệ bằng các chứng chỉ khác nhau, theo lịch hoặc trên nền tảng khác nhau. Mô hình phổ biến: tên miền chính có chứng chỉ rất ổn định nhưng blog.example.com chạy trên nền tảng khác với chứng chỉ hết hạn theo lịch riêng; hoặc tên miền phụ tiếp thị trên CDN khác chưa từng được wildcard bao phủ do giới hạn một nhãn; hoặc hosting nhiều người thuê dựa trên SNI âm thầm làm hỏng việc gia hạn của một tên miền phụ trong khi tên miền chính vẫn hoàn hảo khi kiểm tra nhanh.

Bài học là: ổ khóa hợp lệ trên trang chủ không cho biết phạm vi bảo vệ ở nơi khác. Hãy lập danh mục tên miền phụ, xác nhận mọi tên máy chủ đều có phạm vi chứng chỉ hợp lệ và được giám sát (bằng chứng chỉ riêng, chứng chỉ wildcard bao phủ được nó hoặc chứng chỉ SAN liệt kê nó), và đừng dựa vào một lần kiểm tra SSL Labs cho một tên máy chủ để chứng nhận toàn bộ tài sản web.

Những hiểu lầm phổ biến

  • “Chứng chỉ trả phí hoặc EV xếp hạng tốt hơn DV miễn phí.” Không — tín hiệu dựa trên giao thức; độ sâu xác thực không hiển thị với Google.
  • “Wildcard bao phủ mọi tên miền phụ, kể cả tên miền phụ nhiều cấp.” Không — chỉ một nhãn DNS; *.example.com không bao phủ foo.bar.example.com.
  • “Chứng chỉ hết hạn trực tiếp làm giảm thứ hạng.” Không thông qua tín hiệu xếp hạng cơ bản — nhưng nó có thể đảo ưu tiên canonical thông thường của Google từ HTTPS về HTTP (HSTS không ghi đè được), và nếu có đủ lỗi HTTPS, Google có thể ngừng thu thập các trang HTTPS. Cả hai đều là tác động thật nhưng không chạy qua chính tín hiệu xếp hạng.
  • “Chứng chỉ Let’s Encrypt có chất lượng thấp hơn chứng chỉ trả phí.” Không — cùng mã hóa, cùng cách xử lý thứ hạng; khác biệt là chỉ xác thực DV và thời hạn ngắn (sắp trở thành tiêu chuẩn ngành).
  • “Trang chủ có ổ khóa hợp lệ thì chứng chỉ toàn trang đều ổn.” Không — tên miền phụ có chứng chỉ riêng theo lịch riêng.
  • “Lỗi chuỗi hiếm gặp hoặc chỉ là vấn đề cũ.” Không — chúng phổ biến trên mọi hệ thống chỉ phục vụ chứng chỉ lá, và bộ nhớ đệm Chrome máy tính che giấu lỗi với người kiểm thử.

Đây là phần chuyên sâu cấp chứng chỉ trong bài tổng quan HTTPS; hãy bắt đầu ở đó nếu bạn cần playbook di chuyển, nội dung hỗn hợp và HSTS.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.