Điều gì xảy ra khi bạn thay thế cơ quan cấp chứng chỉ VPN

Thay thế cơ quan cấp chứng chỉ VPN không phải là đổi một tệp. Ngay khoảnh khắc CA mới ký chứng chỉ đầu tiên, mọi trình xác thực vẫn chỉ tin CA cũ phải đưa ra quyết định, và những máy không bao giờ nhận được neo mới vẫn tiếp tục từ chối các đối tác tốt. Tôi đã thấy nó hỏng theo cả hai chiều: cổng học CA mới còn máy khách thì không, nên các kết nối mới thất bại, trong khi những đường hầm đã dựng vẫn đứng đó và khiến sự cố trông như vấn đề định tuyến. Dưới đây là những gì thay đổi, theo đúng thứ tự các lỗi xuất hiện.

Một lần thay, hai thay đổi tách biệt

Cơ quan cấp chứng chỉ là một tên, một khóa công khai và khóa riêng dùng để ký. Trình xác thực không bao giờ tin «CA» một cách trừu tượng. Chúng tin một chứng chỉ cụ thể đã nằm trong kho tin cậy, và chỉ chấp nhận nhà phát hành khi chuỗi chữ ký chạm tới bản sao đã lưu đó. Vì vậy thay CA đổi hai thứ hỏng độc lập với nhau: những neo nào được chấp nhận và những danh tính đối tác nào được cấp dưới chúng.

Hầu hết triển khai VPN xác thực theo cả hai chiều. Máy khách xác thực chứng chỉ của cổng, và cổng xác thực chứng chỉ của máy khách. Một lần xoay chỉ làm mới gói máy khách sẽ để máy chủ từ chối mọi máy khách vẫn trình danh tính của CA cũ, và chiều ngược lại cũng phổ biến như vậy. Trước hết hãy kiểm kê các điểm thực thi: kho tin cậy của máy khách, tệp ca của cổng, bất kỳ proxy kết thúc TLS phía trước nó, và đầu dò kiểm tra điểm cuối từ bên ngoài.

Trình xác thực kiểm tra gì, theo thứ tự

Kiểm tra đường dẫn leo từ chứng chỉ đối tác qua các chứng chỉ trung gian cho tới khi chạm một neo tin cậy. Ở mỗi bước nó xác minh chữ ký, kiểm tra từng chứng chỉ nằm trong cửa sổ hiệu lực, và xác nhận rằng các ràng buộc cơ bản cùng mục đích khóa cho phép nhà phát hành ký. Chỉ sau đó ứng dụng mới nhìn chứng chỉ lá: tên thay thế của chủ thể phải bao phủ tên được gọi, và mục đích khóa mở rộng phải cho phép xác thực máy chủ hoặc máy khách.

Để lặp lại bước đi đó ngoại tuyến, hãy trỏ -CAfile vào đúng gói bạn sẽ triển khai, không phải kho của hệ thống. Nếu không bạn đang kiểm tra máy, không phải thay đổi:

openssl verify -CAfile new-ca.crt gateway.crt
openssl verify -CAfile new-ca.crt -untrusted intermediate.crt client.crt
openssl x509 -in gateway.crt -noout -subject -issuer -dates
openssl s_client -connect gw.example.net:443 -CAfile new-ca.crt

Lệnh đó chỉ hoạt động với một bộ lắng nghe TLS đơn giản như trang quản trị HTTPS của cổng; kênh điều khiển của OpenVPN đi trước TLS, nên s_client không thể soi bắt tay của đường hầm.

Các quy tắc dựng đường dẫn đằng sau những lỗi đó nằm trong RFC 5280 phần 6. Chúng giải thích những hỏng hóc mà nếu không sẽ trông tùy tiện: một chứng chỉ trung gian hết hạn mà không ai nhớ, một chứng chỉ có mục đích khóa cấm ký, hoặc một ràng buộc tên loại trừ đúng máy bạn đang kiểm tra.

Vì sao đường hầm cũ vẫn chạy

TLS và OpenVPN đều giữ phiên đã thiết lập sống sau khi bắt tay xong. Không có gì xác thực lại chứng chỉ đối tác theo từng gói, nên máy khách kết nối trước thay đổi vẫn tiếp tục cho lưu lượng đi qua cho tới khi đàm phán lại, kết nối lại hoặc đường hầm sụp. Chính khoảng trống này khiến một lần thay CA trông ổn suốt một giờ rồi hỏng đúng lúc tệ nhất: máy tính thức dậy từ chế độ ngủ, ánh xạ NAT hết hạn, cổng khởi động lại.

Khôi phục phiên còn kéo dài ảo giác đó hơn nữa. Vé phiên TLS cho phép máy khách quay lại mà không gửi lại chứng chỉ, và khôi phục bỏ qua kiểm tra đường dẫn vì lần bắt tay đầu đã làm rồi. Nên phép thử trung thực là một lần bắt tay đầy đủ trong tiến trình mới. Hãy khởi động lại máy khách thay vì nối lại đường hầm, và trên một hồ sơ thử nghiệm hãy cân nhắc tắt vé để đường khôi phục không thể che một chuỗi đã gãy.

Giữ tầng khóa tĩnh tách khỏi chuyện này. tls-auth thêm HMAC vào kênh điều khiển, tls-crypt mã hóa và xác thực nó, và không cái nào mang vật liệu chứng chỉ, nên xoay bất kỳ cái nào là một thay đổi riêng với chế độ hỏng riêng. Những triển khai trộn cả hai kết thúc với một máy khách có khóa tĩnh ổn, chứng chỉ lỗi thời và thông báo lỗi không nhắc tới cái nào.

Cái bẫy dùng lại tên chủ thể

Thật hấp dẫn khi dùng lại tên phân biệt của tiền nhiệm để không gì ở hạ nguồn phải đổi. Điều đó giữ dòng nhà phát hành ổn định trong giao diện và phá hủy tín hiệu duy nhất bạn cần. Hai chứng chỉ có chủ thể giống nhau và khóa khác nhau không phân biệt được bằng tên, nên một gói có cả hai neo cho trình xác thực hai ứng viên và không có quy tắc chọn.

Việc dựng đường dẫn khi đó có thể chọn sai, báo «không lấy được chứng chỉ nhà phát hành cục bộ» trong khi neo đúng vẫn có mặt, hoặc thành công trên máy này và hỏng trên máy khác với cùng gói, vì thứ tự ứng viên khác nhau. Nếu buộc phải dùng lại tên, hãy giữ cả hai neo trong tệp riêng trong lúc chuyển tiếp và nạp chúng một cách tường minh, và chỉ gộp chúng khi mọi đối tác đã trình nhà phát hành mới. Nếu không, hãy cho bản thay thế một tên chung riêng — hậu tố thế hệ hoặc ngày là đủ — để nhật ký và văn bản lỗi nói được đối tác hỏng đã được cấp dưới cơ quan nào.

Một lần xoay không làm sập mạng

Với một lần thay có kế hoạch, hãy chấp nhận cả hai neo trong một khoảng thời gian giới hạn thay vì chuyển trong một bước. Cấp CA mới và các chứng chỉ trung gian của nó, đặt neo mới vào gói của từng trình xác thực bên cạnh neo cũ, và chỉ sau đó mới bắt đầu cấp chứng chỉ đối tác từ nó. Đối tác có danh tính cũ được xác thực theo neo cũ; cái mới chạy theo neo mới.

Làm theo thứ tự đó thì mỗi bước đều đảo ngược được. Sự cố bạn tránh là chuyển đồng thời, khi một máy khách lỡ bản cập nhật gói gặp một cổng đã cho neo cũ nghỉ hưu, bắt tay chết, và không nhật ký nào nói bên nào lỗi thời.

Cho nghỉ hưu theo chiều ngược lại. Cấp lại mọi danh tính cần tồn tại, xác nhận từng cái trình chuỗi mới, rồi gỡ neo cũ khỏi các gói. Đưa khóa riêng của CA cũ ra khỏi vận hành, vì một nhà phát hành vẫn ký được nghĩa là lần xoay chưa xong. Giữ chứng chỉ và sổ cấp phát để kiểm toán. Một nhà phát hành bị mất được khôi phục về đúng mức tin cậy đó; một lần lộ lọt đòi danh tính mới và không có đường quay lại neo cũ.

Kiểm chứng kết quả, không phải danh sách tệp

Một tệp tin cậy trong thư mục mong đợi chứng minh được rất ít. Ứng dụng có thể đọc đường khác, định dạng khác hoặc một bản sao trong gói mà bản nâng cấp thay thế. Hãy kiểm tra hành vi ở cả hai đầu, không phải sự tồn tại của tệp.

Xác nhận một kết nối mới với danh tính mới thành công, rồi xác nhận một danh tính do CA đã nghỉ cấp bị từ chối. Chính phép thử thứ hai là thứ người ta bỏ qua, và là thứ duy nhất cho thấy cơ quan cũ không còn cấp quyền truy cập. Ở nơi triển khai dựa vào CRL hoặc OCSP, hãy kiểm tra các điểm phân phối trong chứng chỉ mới phân giải được và các đối tác hỏi tới được bộ trả lời.

Kết thúc bằng một máy khách chưa từng kết nối: xóa trạng thái hồ sơ, kết nối và đọc chuỗi đã đàm phán. Một đối tác khôi phục phiên đã lưu sẽ vui vẻ báo rằng việc di trú thành công trong khi chưa xác thực gì cả.