Gia hạn chứng chỉ VPN mà không thay đổi danh tính của nó

Gia hạn chứng chỉ mà làm thay đổi danh tính không phải là gia hạn, đó là một cuộc di trú khoác vé bảo trì. Ứng dụng khách xác minh một tên, một chuỗi và đôi khi một khóa cụ thể, và cả ba đều có thể thay đổi mà ngày hết hạn không đổi. Trước khi yêu cầu thay thế, hãy ghi lại những gì ứng dụng khách thực sự kiểm tra: tên máy chủ hoặc danh tính của đối tác, mục đích của chứng chỉ, chính sách khóa và chuỗi phát hành. Việc gia hạn là thường lệ hay có phối hợp tùy thuộc vào việc bản thay thế thay đổi điều gì trong số đó.

Ba điều kiện quyết định hình thức gia hạn

Ba điều kiện là liệu có gì ghim lá, chuỗi có thay đổi hay không, và ai khác xác minh tên. Hãy trả lời từ phía ứng dụng khách chứ không phải từ sự tiện lợi của CA, vì ứng dụng khách mới là thứ hỏng lúc ba giờ sáng.

Bắt đầu bằng việc kiểm tra chứng chỉ bạn đang có. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName in ra chủ thể, nhà phát hành, khoảng hiệu lực và những tên mà chứng chỉ thực sự hợp lệ. Trường cuối cùng đó là quan trọng nhất và thường được mặc định nhất: một yêu cầu gia hạn bỏ sót SAN mà ứng dụng khách dựa vào sẽ tạo ra chứng chỉ hợp lệ về mặt kỹ thuật nhưng sai về mặt chức năng. Hãy sao chép danh sách SAN từ chứng chỉ cũ vào yêu cầu thay vì gõ lại từ trí nhớ.

Điều kiện một: có gì ghim lá không

Nếu ứng dụng khách tin tưởng một CA được duy trì và xác minh tên, thì việc gia hạn lá với khóa mới là vô hình đối với chúng. Nếu bất kỳ ứng dụng khách nào ghim chứng chỉ lá, dấu vân tay hoặc khóa công khai của nó, thì bản thay thế là một thay đổi có phối hợp với bước chuyển cứng, vì ghim cũ không thể xác minh chứng chỉ mới.

Tìm hiểu bạn đang ở trường hợp nào trước khi đặt bất cứ thứ gì. Một ghim không ai ghi lại vẫn là ghim khi nó gãy.

Điều kiện hai: so sánh các ghim và chuỗi

Dấu vân tay khiến ghim có thể kiểm tra được: openssl x509 -noout -fingerprint -sha256 -in server.crt trên chứng chỉ cũ và mới, và openssl x509 -noout -pubkey để so sánh khóa công khai. Nếu cấu hình ứng dụng khách, một hồ sơ di động hoặc kho tin cậy của thiết bị chứa một trong hai giá trị, bạn có một ghim. Hồ sơ VPN di động là nơi ẩn náu phổ biến, vì hồ sơ được phân phối một lần và không bao giờ được kiểm tra lại.

Nếu bản thay thế đến từ cùng một trung gian và ứng dụng khách đã có hoặc có thể lấy được nó, thì không có gì thay đổi ở phía tin cậy. Một trung gian mới, một nhà phát hành khác hoặc một chuỗi được giao sai thứ tự đều biến việc gia hạn thành thay đổi tin cậy, và lỗi trông giống nhà phát hành không xác định chứ không phải chứng chỉ hết hạn.

Kiểm tra chuỗi mà máy chủ thực sự gửi bằng openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts, và xác minh cục bộ bằng openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. Làm việc đó trước khi thay đổi cho bạn một đường cơ sở để so sánh sau đó.

Điều kiện ba: ai khác xác minh tên

Một bộ tập trung VPN, một bộ cân bằng tải, một đầu dò giám sát, một tích hợp RADIUS hoặc SAML và một hồ sơ di động, mỗi thứ đều có thể giữ bản sao riêng của tên mong đợi hoặc neo tin cậy. Việc gia hạn là thời điểm những bản sao đó phân kỳ, vì chứng chỉ thay đổi còn các bản sao thì không.

Liệt kê mọi người tiêu dùng trước khi thay đổi và quyết định, với từng cái, xem nó có cần cập nhật không. Cái bạn quên chính là cái sẽ gọi cho bạn.

Cũng có một cái bẫy về thời gian. Kiểm tra thời điểm bắt đầu hiệu lực cũng như ngày hết hạn, vì một chứng chỉ được chuẩn bị để kích hoạt sau này sẽ bị từ chối nếu cài quá sớm, và lỗi trông giống vấn đề đồng hồ chứ không phải vấn đề chuẩn bị. openssl x509 -noout -dates trên tệp mới trước khi triển khai là một lần kiểm tra hai giây. Hãy duy trì cả một đường khôi phục được hỗ trợ và cấu hình tốt đã biết, để một lần gia hạn sai có thể đảo ngược bằng cách khôi phục chứng chỉ và khóa trước đó.

Triển khai, xác minh bằng một lần xác thực mới, rồi thu hồi

Một đường hầm đã thiết lập phản ánh quá trình xác minh diễn ra khi nó được dựng, nên nó có thể trông khỏe mạnh trong khi mọi kết nối mới đều thất bại. Hãy kiểm thử bằng một lần xác thực mới với tên dịch vụ thực tế mà ứng dụng khách sử dụng.

Hoàn tất bước kiểm tra ở cấp ứng dụng mà người dùng quan tâm, và xác nhận việc phân phối chuỗi từ góc nhìn của ứng dụng khách chứ không phải của máy chủ. Đừng triệt tiêu các kiểm tra tên hoặc chứng chỉ để giữ quá trình chuyển đổi yên tĩnh; điều đó biến một vấn đề tương thích tạm thời thành vĩnh viễn.

Chỉ thu hồi vật liệu lỗi thời sau khi việc triển khai đã được xác minh, và coi một khóa bị xâm phạm là một trường hợp hoàn toàn khác: chỉ gia hạn thì không thu hồi được gì, nên danh tính bị ảnh hưởng cần quy trình thu hồi và xử lý phiên của việc triển khai. RFC 5280 định nghĩa các quy tắc chứng chỉ và xác minh đường dẫn bên dưới tất cả những điều này. Hãy tách việc gia hạn lá thường lệ khỏi việc thay thế CA, để ứng dụng khách không bị yêu cầu tin tưởng một nhà phát hành mới mà không có lý do.