Chứng chỉ VPN chưa hợp lệ: ba nguyên nhân, một thứ tự kiểm tra
Chưa hợp lệ nghĩa là đồng hồ thiết bị bị chậm, cửa sổ thực sự bắt đầu muộn hơn, hoặc chứng chỉ trung gian chưa mở. Hãy kiểm tra theo thứ tự đó.
Bạn mở ứng dụng, chọn hồ sơ đã dùng nhiều tháng, và nó dừng với "certificate is not yet valid". Không có gì trong đăng nhập của bạn thay đổi, và kho tin cậy có lẽ vẫn ổn: chứng chỉ được trình bày trong bắt tay mang một cửa sổ hiệu lực bắt đầu muộn hơn thời điểm trình xác minh đang dùng. Ba tình huống khác nhau tạo ra đúng thông báo đó, và chúng cần hành động khác nhau. Thứ tự dưới đây cho bạn biết mình thuộc trường hợp nào trước khi chạm vào đồng hồ hay tệp chứng chỉ.
Bạn đang gặp nguyên nhân nào trong ba
Nguyên nhân đầu tiên là cục bộ: thiết bị thực hiện kiểm tra có đồng hồ sớm hơn ngày bắt đầu của chứng chỉ. Bạn thấy điều này trên phần cứng có pin CMOS chết, trên máy ảo được khôi phục từ ảnh chụp cũ, trên thiết bị đã tắt đủ lâu để mất thời gian, và trên mạng nơi NTP đi ra bị chặn mà không ai nhận ra. Chứng chỉ có thể hoàn toàn hợp lệ và vẫn thất bại theo cách này.
Nguyên nhân thứ hai thuộc về nhà phát hành, vì chứng chỉ thực sự bắt đầu trong tương lai: được phát hành sớm, tạo với thời điểm bắt đầu rõ ràng, hoặc ký như một phần của bước kích hoạt chưa chạy. Nguyên nhân thứ ba tốn nhiều thời gian nhất, vì lá đang hiện hành trong khi một chứng chỉ khác trong chuỗi được trình bày thì không, nên lỗi nêu tên tài liệu mà bạn chưa bao giờ cài đặt.
Một câu hỏi phân biệt chúng. Lỗi đi theo thiết bị hay theo dịch vụ? Hai máy trên cùng mạng hành xử khác nhau chỉ ra đồng hồ. Mọi ứng dụng đều thất bại như nhau chỉ ra cửa sổ của chứng chỉ và chuỗi phía sau nó.
Đọc cửa sổ từ chứng chỉ thực sự được trình bày
Đừng kiểm tra một tệp PEM còn sót lại từ lần triển khai trước; hãy hỏi dịch vụ chuỗi mà nó đang gửi bây giờ. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts in mọi chứng chỉ trong chuỗi. Lưu khối bạn cần và chạy openssl x509 -noout -subject -issuer -dates; lệnh sau in notBefore và notAfter, và hai giá trị đó quyết định. Trên Windows, hộp thoại chứng chỉ của kết nối và certutil -dump trên tệp đã xuất hiển thị cùng các trường.
Đọc cả hai đầu của cửa sổ, không chỉ phần đầu. Một chứng chỉ mở trong hai giờ và một chứng chỉ đóng trong hai giờ thất bại với thông báo khác nhau và liên quan đến các nhóm khác nhau. Ghi lại chứng chỉ nào được lỗi nêu tên — lá, trung gian hay gốc — vì điều đó quyết định liệu có thể sửa được gì ở phía máy khách.
Bạn cũng có thể kiểm tra cửa sổ mà không cần chờ. Việc xác minh chấp nhận một thời điểm rõ ràng: openssl verify -attime 1793600000 -CAfile ca.pem -untrusted intermediate.pem leaf.pem đánh giá chuỗi tại dấu thời gian đó. Chạy nó với thời gian hiện tại để tái tạo lỗi, rồi với thời điểm bắt đầu của chứng chỉ để xác nhận cùng chuỗi đó vượt qua khi cửa sổ mở. RFC 5280 định nghĩa trường hiệu lực và quy tắc rằng không được dùng chứng chỉ ngoài nó, và đó chính là quy tắc ứng dụng của bạn vừa áp dụng.
Đồng hồ của bạn, hay của họ
So sánh đồng hồ thiết bị với thời điểm bắt đầu của chứng chỉ theo UTC, từ nguồn bạn tin cậy. date -u cho thời điểm, và timedatectl status trên máy chủ systemd cũng báo cáo đồng hồ có được đồng bộ không. Trên Windows, w32tm /query /status hiển thị nguồn hiện tại và lần đồng bộ thành công gần nhất. Múi giờ hiển thị trên khay là lựa chọn hiển thị, không phải đồng hồ sai; trình xác minh so sánh các thời điểm UTC.
| What you see | Most likely reading | Next step |
|---|---|---|
| Clock behind, one device affected | Local time fault | Resync time, keep validation on, retest |
| Clock correct, window opens soon | Certificate staged early | Wait for the window or follow the cutover plan |
| Clock correct, intermediate not yet valid | Chain material mismatch | Operator replaces the intermediate |
| Some peers pass, others do not | Inconsistent nodes | Record each peer's chain before changing anything |
Nếu đồng hồ chậm, hãy đồng bộ lại và kiểm tra lại trước khi thay đổi bất kỳ tài liệu chứng chỉ nào. Thiết bị lệch vài phút hoặc vài giờ từ chối mọi chứng chỉ mới phát hành mà nó gặp, không chỉ một dịch vụ, nên lời giải thích một dịch vụ thường là sai. Nếu đồng hồ đúng và đã đồng bộ, hãy ngừng nhìn thiết bị: cửa sổ thuộc về nhà phát hành, và không nên điều chỉnh cài đặt cục bộ nào để nó vượt qua.
Bảng đó là toàn bộ quyết định. Dời đồng hồ đến điều chứng chỉ mong đợi không phải là sửa chữa, và tắt kiểm tra thời gian cũng không phải, vì cả hai đều che giấu điều kiện đã tạo ra lỗi.
Vì sao chuỗi thất bại trong khi lá trông ổn
Lá gia hạn và chứng chỉ trung gian thay thế thường được gửi cùng nhau, và không phải lúc nào cũng đến cùng một thời điểm. Một dịch vụ có thể gửi lá mới được ký bởi trung gian có cửa sổ riêng bắt đầu muộn hơn, hoặc tiếp tục phục vụ trung gian cũ dưới lá mới. Dù thế nào, chuỗi thất bại trong khi ngày tháng của chính lá trông hợp lý.
Các điểm cuối cân bằng tải biến điều này từ hỏng thành không nhất quán. Nếu thử lại thành công, hoặc một mạng hoạt động còn mạng khác không, hãy ghi lại đối tác nào đã trả lời và gửi chuỗi nào trước khi thay đổi cài đặt. openssl s_client in địa chỉ đã kết nối, nên vài lần thử sẽ cho thấy mọi nút có phục vụ cùng chuỗi không.
Các đường sửa chữa giữ nguyên xác minh
Vấn đề đồng hồ được sửa trên thiết bị với xác minh vẫn bật. Vấn đề chứng chỉ được nhà vận hành sửa bằng tài liệu phát hành cho cửa sổ đã bao gồm hiện tại. Không cài đặt máy khách nào làm chứng chỉ chưa hợp lệ trở nên hợp lệ; các cờ bỏ qua kiểm tra thời gian tồn tại để xác nhận chẩn đoán, không phải để đưa vào sản xuất.
Khi chứng chỉ được chuẩn bị cho kích hoạt theo kế hoạch, hãy theo kế hoạch chuyển đổi. Cài đặt khi cửa sổ của nó mở, hoặc dùng quy trình chồng lấp mà nhà cung cấp ghi lại, thay vì cài sớm và dạy người dùng bấm qua cảnh báo. Những cảnh báo mà người ta học cách bỏ qua tốn kém hơn một chút chậm trễ.
Cuối cùng, kiểm tra lại theo cách lỗi đã xảy ra: phiên mới, cùng ứng dụng, tài nguyên bạn thực sự cần. Thư viện TLS có thể lưu bộ đệm chuỗi đã xác minh suốt đời kết nối, và phiên tiếp tục không nhất thiết kiểm tra lại, nên phiên cũ có thể tiếp tục thất bại sau khi sửa hoặc tiếp tục hoạt động sau hồi quy. Một tệp mở được trong trình xem chỉ chứng minh tệp đọc được; một bắt tay hoàn tất chứng minh chuỗi xác minh.
Trước khi đóng phiếu, xác nhận bốn điều: thời gian UTC và trạng thái đồng bộ của thiết bị lỗi, notBefore và notAfter của từng chứng chỉ trong chuỗi được trình bày, cùng chuỗi đó từ máy khách thứ hai, và tên mà lỗi gán cho chứng chỉ. Nếu đồng hồ đúng và cửa sổ chưa mở, phần còn lại là việc của nhà vận hành, và bước đi đúng phía bạn là chờ cửa sổ thay vì làm yếu việc kiểm tra.