Kiểm kê hostname, phụ thuộc và quyền sở hữu
Liệt kê mọi hostname mà khách truy cập hoặc tích hợp sử dụng: apex, www, các subdomain, API, host tài sản (asset hosts), cổng thông tin và tên theo vùng. Với mỗi tên, ghi nơi TLS kết thúc, ai có quyền thay đổi, phạm vi chứng chỉ và ngày hết hạn, phương thức gia hạn và các phụ thuộc sinh ra URL. Một chứng chỉ phải bao phủ hostname được yêu cầu trong danh sách Subject Alternative Name (SAN). Bao gồm CMS, CDN, tag manager, object storage, nhà cung cấp thanh toán, mẫu email và các phần nhúng bên thứ ba; những thành phần này thường đưa vào các URL HTTP sau lần phát hành HTTPS đầu tiên.
Chọn một hostname chuẩn (www hoặc apex) và chuyển hướng tên thay thế thẳng đến nó bằng HTTPS.
Triển khai chứng chỉ và phiên bản TLS hiện tại
Cấu hình web server, reverse proxy, CDN hoặc load balancer trả lời yêu cầu công khai. Cài chứng chỉ và chuỗi cần thiết, liên kết chúng với tên dự định và kiểm tra từ ngoài mạng lưu trữ. Trình duyệt kiểm tra chuỗi, hostname và ngày; cảnh báo công khai là rào cản phát hành. Mặc định dùng TLS 1.3 và chỉ giữ TLS 1.2 nơi cần tương thích. Vô hiệu hóa SSL và TLS 1.0/1.1. Dùng hướng dẫn nền tảng được duy trì thay vì sao chép danh sách cipher kế thừa, và giữ máy chủ cùng thư viện TLS được vá lỗi.
Hạn chế truy cập vào private keys và ghi lại mọi hệ thống chia sẻ một khóa để khi thay thế thì cập nhật đến tất cả chúng.
Chuyển hướng HTTP một lần và đặt HTTPS làm chuẩn
Trả về chuyển hướng phía máy chủ vĩnh viễn, thường 301 hoặc 308, từ mỗi URL HTTP tới URL HTTPS tương ứng. Tránh chuỗi chuyển hướng: chúng làm chậm và tăng điểm lỗi. Công bố URL HTTPS chuẩn (canonical) trong liên kết nội bộ, thẻ canonical, sitemap, dữ liệu có cấu trúc, thẻ mạng xã hội, email và các liên kết tuyệt đối do ứng dụng sinh ra. Kiểm thử trang chủ, một trang sâu, URL có truy vấn, đường dẫn lỗi và các biến thể hostname. Khi TLS kết thúc tại proxy, cấu hình xử lý forwarded-protocol đáng tin cậy để ứng dụng không bị lặp giữa HTTP và HTTPS.
HTTP chỉ được phép tồn tại để chuyển hướng hoặc hoàn tất thách thức chứng chỉ, không để phục vụ một site công khai riêng.
Tìm và sửa nội dung hỗn hợp (mixed content) tại nguồn
Mixed content là trang HTTPS yêu cầu tài nguyên qua HTTP hoặc giao thức không an toàn khác. Trình duyệt có thể nâng cấp một số media nhưng chặn nhiều yêu cầu rủi ro, bao gồm script, stylesheet, iframe, fetch và font. Thay mọi tham chiếu bằng URL HTTPS đã kiểm thử, URL tương đối cho nội dung tự quản, hoặc phương án thay thế được phê duyệt. Dò các mẫu (templates) đại diện và kiểm tra developer tools khi hoàn thành các hành trình quan trọng. Kiểm tra CSS, JavaScript, block trong CMS, manifest tài sản, mục trong tag-manager, file tải xuống và phần nhúng của nhà cung cấp. Một trang bảo mật không nên cung cấp file tải xuống qua HTTP.
Việc trình duyệt tự động nâng cấp vẫn có thể gặp dependency bên thứ ba không khả dụng hoặc không được hỗ trợ; hãy sửa URL đã lưu trữ.
Tự động hóa gia hạn và diễn tập khôi phục chứng chỉ
Xem việc gia hạn như một quy trình triển khai tự động, không phải lời nhắc trên lịch. Quy trình này phải gia hạn chứng chỉ, triển khai chứng chỉ tới mọi tầng phục vụ và nạp lại dịch vụ một cách an toàn. Kiểm thử bằng chính phương thức xác thực sẽ dùng trong thực tế trước khi chứng chỉ sản xuất hết hạn. Ví dụ, với chứng chỉ có thời hạn 90 ngày, Let's Encrypt khuyến nghị gia hạn sau mỗi 60 ngày; hãy tuân theo vòng đời của nhà phát hành và nền tảng bạn dùng. Lưu tên chứng chỉ, tài khoản nhà phát hành, phương thức thách thức, cơ chế tự động hóa, vị trí khóa, các đích triển khai và liên hệ khẩn cấp trong một kho thông tin. Sau khi triển khai, xác minh ngày hết hạn từ endpoint công khai.
Khi gia hạn thất bại, kiểm tra DNS, định tuyến thách thức, quyền, truy cập nhà phát hành, giới hạn tỷ lệ (rate limits) và việc triển khai từ CDN tới origin.
Chỉ dùng HSTS sau khi hạ tầng HTTPS sẵn sàng
HSTS (HTTP Strict Transport Security) là header phản hồi HTTPS nói với trình duyệt dùng HTTPS trên các lần truy cập sau tới một host. Trình duyệt sau đó không cho người truy cập bỏ qua lỗi chứng chỉ. Chỉ gửi header này qua HTTPS và vẫn giữ chuyển hướng HTTP vì HSTS được ghi nhận sau khi có phản hồi an toàn trừ khi preload list áp dụng. Bắt đầu với max-age giới hạn và kéo dài sau khi chứng minh được gia hạn và các đường cần thiết. Không thêm includeSubDomains cho đến khi mọi subdomain hiện tại và tương lai đều có thể phục vụ HTTPS hợp lệ. Preload không phải một phần của đặc tả HSTS và cần xem xét cam kết lâu dài riêng.
max-age=0 chỉ có hiệu lực sau khi trình duyệt đạt được phản hồi HTTPS hợp lệ; nó không sửa được host bảo mật không thể truy cập.
Phát hành, kiểm thử và hoàn nguyên mà không làm suy yếu kênh truyền
Trước khi thay đổi, hãy lưu lại cấu hình chứng chỉ, điểm biên và chuyển hướng đã được xác nhận hoạt động tốt. Xác định người phê duyệt việc hoàn nguyên, triển khai thử nghiệm khi có thể và chỉ thay đổi từng nhóm biện pháp kiểm soát một. Ngay lập tức kiểm tra endpoint công khai từ nhiều mạng, theo dõi chuyển hướng, kiểm tra chứng chỉ và hoàn thành các hành động quan trọng của người truy cập. Kiểm thử trên các trình duyệt và nhóm thiết bị khách quan trọng đối với đối tượng người dùng của bạn. Với các luồng thanh toán hoặc luồng chịu quy định, hãy hỏi nhà cung cấp thanh toán và chuyên gia an ninh có thẩm quyền để xem xét các yêu cầu áp dụng. Nếu thay đổi làm hỏng HTTPS, khôi phục cấu hình an toàn đã được xác thực; đừng chuyển trang khách sang HTTP như giải pháp tạm.
Lưu trữ hostname, thời gian, client, lỗi, thay đổi và kết quả để lần gia hạn hoặc di chuyển tiếp theo dễ chẩn đoán hơn.