Lỗi chứng chỉ web trên Access Server: gói CA rỗng

Trang đăng nhập web không tải được trong khi DNS phân giải đúng thường không phải vấn đề DNS. Nếu nhật ký dịch vụ nhắc tới đường dẫn gói chứng chỉ rỗng hoặc lỗi phân tích PEM của chứng chỉ web và khóa riêng, trình lắng nghe HTTPS không có vật liệu dùng được và việc phân giải tên không giúp gì. Bản sửa nằm ở ba khóa cấu hình và không cần cấp lại bất kỳ chứng chỉ máy khách VPN nào.

Ba khóa thực sự trỏ tới đâu

Bộ chứng chỉ web tùy chỉnh được mô tả bởi cs.cert, cs.priv_key và cs.ca_bundle. Mỗi khóa lưu một đường dẫn tệp, và dịch vụ web dùng cả ba cùng lúc. Chứng chỉ sai khóa, hoặc tệp chuỗi thực chất là chứng chỉ lá, thất bại giống như giá trị rỗng.

Các khóa này thuộc giao diện web Admin và Client. Chúng tách biệt với PKI cấp chứng chỉ cho máy khách VPN, nên việc thay thế không cần chạm vào hồ sơ, khóa máy chủ hay tổ chức chứng thực. Xây lại toàn bộ PKI là sai lầm tốn kém nhất ở đây.

Một khác biệt giúp tiết kiệm thời gian: giá trị tùy chỉnh rỗng rõ ràng không cùng trạng thái với việc không có ghi đè nào. Loại đầu đưa cho bộ phân tích một đường dẫn rỗng, đó là điều dòng nhật ký nói. Loại sau để Access Server dùng vật liệu của chính nó.

Vì sao tệp tồn tại vẫn không phân tích được

Bộ phân tích đọc các khối có nhãn bên trong tệp, không đọc tên tệp. .crt chứa khóa riêng, chuỗi viết thành một khối duy nhất, hoặc tệp bị cắt dòng cuối đều bị từ chối. RFC 7468 định nghĩa các nhãn dễ đọc đó vì chúng là thứ duy nhất cho biết loại đối tượng tiếp theo.

Hãy xem đối tượng, không xem phần mở rộng. Trên máy Linux, openssl x509 -noout -subject -issuer -in server.pem và openssl pkey -noout -check -in key.pem trả lời hai câu hỏi quan trọng, và so sánh mô-đun hoặc khóa công khai chứng minh chúng đi cùng nhau. Giữ đầu ra khóa riêng ngoài phiếu hỗ trợ và nhật ký trò chuyện.

Đường dẫn rỗng đáng bị nghi ngờ như tệp hỏng, vì cả hai đều tạo ra lỗi mơ hồ về sau. Nếu nhật ký nói đường dẫn gói rỗng, hãy đọc giá trị đã lưu trước khi gỡ lỗi tệp.

Chủ động quay về phương án dự phòng

CLI của Access Server có bước kiểm tra nhận ba đường dẫn làm tham số và báo cáo bộ đó có dùng được không. Các đường dẫn dưới đây chỉ là ví dụ; hãy thay bằng vị trí được bảo vệ trên máy chủ.

sacli --ca_bundle=/secure/webcerts/chain.pem \
      --cert=/secure/webcerts/server.pem \
      --priv_key=/secure/webcerts/key.pem TestWebCerts

Đọc kết quả trước khi chạm vào dịch vụ đang chạy, rồi mới nhập giá trị và áp dụng theo thao tác đã ghi tài liệu cho phiên bản đã cài. hướng dẫn CLI chính thức bao gồm kiểm tra, nhập và bước áp dụng, và phiên bản của nó quan trọng hơn mọi bản tóm tắt.

Xác minh tên người dùng thực sự nhập

Khi vật liệu tùy chỉnh đã hỏng và vẫn còn phương án dự phòng tích hợp hợp lệ, cách khôi phục theo tài liệu là gỡ ba ghi đè và để Access Server dùng phương án đó. Trước hết hãy chuẩn bị quyền truy cập console và bản sao cấu hình hiện tại.

sacli ConfigDel --key "cs.cert"
sacli ConfigDel --key "cs.priv_key"
sacli ConfigDel --key "cs.ca_bundle"
# then the supported apply/restart step for this version

Xóa toàn bộ cơ sở dữ liệu cấu hình không phải là sửa chứng chỉ. Nhắm vào ba khóa đó, áp dụng và xác nhận giao diện web phản hồi. Các tệp tự ký trong thư mục web-ssl là tài nguyên dự phòng, không phải chỗ làm việc.

Hãy mong đợi trình duyệt hiển thị chứng chỉ khác sau khi phương án dự phòng có hiệu lực. Đó là kết quả đúng; hãy xác minh qua quy trình quản trị đáng tin cậy của bạn.

Khôi phục chỉ kết thúc sau khi đăng nhập thành công

Khôi phục chưa xong khi xuất hiện trình lắng nghe TCP. Kiểm tra tên DNS, danh tính chứng chỉ và chuỗi cho tên đó, sau đó mở cả giao diện web Admin và Client và hoàn tất đăng nhập. Kiểm tra cổng không chứng minh được điều nào trong số đó.

Access Server 3.1 trở lên cũng có thể phục vụ chứng chỉ web khác nhau theo tên máy SNI. Nếu đã cấu hình, khóa mặc định và mục riêng cho tên là hai bộ tách biệt, và kiểm tra bằng địa chỉ IP dễ cho thấy chứng chỉ khác với thứ người dùng nhận được. Sửa và kiểm tra bộ của tên bị lỗi, rồi lặp lại bài kiểm tra đăng nhập trước khi đóng sự cố.