Đăng nhập VPN bằng chứng chỉ trên Mac: danh tính, việc dùng khóa hay niềm tin vào cổng?
Ba quyết định nằm sau một lần đăng nhập bằng chứng chỉ: danh tính nào được chọn, thành phần VPN có được dùng khóa của nó hay không, và cổng có đáng tin hay không.
Đăng nhập VPN dựa trên chứng chỉ yêu cầu Mac một thứ hẹp hơn mật khẩu: dùng đúng khóa riêng này, trong ngữ cảnh thực thi này, để chứng minh một danh tính với cổng đó. Khi thất bại, thông báo thường chỉ mô tả điều cuối cùng bị sai, và điều đó hiếm khi là nguyên nhân. Đi qua ba quyết định theo đúng thứ tự hệ thống đưa ra giúp chẩn đoán trung thực và ngăn một vấn đề quyền cục bộ bị coi là lỗi xác thực chuỗi.
Đi qua lần đăng nhập theo thứ tự Mac thực hiện
Trước tiên ứng dụng khách chọn một danh tính: một chứng chỉ được ghép với khóa riêng dùng được, có sẵn qua kho lưu trữ hoặc nhà cung cấp thông tin xác thực được hỗ trợ. Sau đó thành phần VPN yêu cầu thực hiện một thao tác mật mã bằng khóa đó, và mô hình ủy quyền cục bộ trả lời. Chỉ sau khi cả hai thành công mới xảy ra bắt tay từ xa, nơi Mac đánh giá cổng và cổng đánh giá bằng chứng của ứng dụng khách.
| Decision | Typical symptom | Where to look |
|---|---|---|
| Identity selection | No valid identity, wrong certificate offered | Profile and which identity the client picked |
| Local key use | Signing or interaction error before any handshake | Execution context and key access rules |
| Remote authentication | Chain, name or client-admission rejection | Gateway identity and what it accepts |
Đọc bảng từ trên xuống và dừng ở hàng đầu tiên thất bại. Mọi thứ bên dưới một thất bại đều chưa được chứng minh, đó là lý do “chứng chỉ không đáng tin” là kết luận vừa phổ biến vừa không đáng tin đến vậy.
Quyền cục bộ thực sự bao gồm những gì
Trong mô hình chùm chìa khóa của macOS, các mục được bảo vệ mang quy tắc truy cập riêng cho từng thao tác và danh sách ứng dụng tin cậy. Ký bằng khóa riêng là một trong những thao tác đó, và các quy tắc áp dụng cho tệp thực thi thực hiện nó, không áp dụng cho chứng chỉ như một tài liệu. Tài liệu tham chiếu về kiểm soát truy cập của Apple cũng vạch ranh giới giữa mô hình này với chùm chìa khóa iCloud và cách bố trí nhóm truy cập, nên lời khuyên viết cho bên này không chuyển sang bên kia.
Hai hệ quả theo sau. Một chứng chỉ công khai hiện trong danh sách không chứng minh rằng thành phần nền của VPN có thể chạm tới khóa đó. Và quyền được cấp cho một ứng dụng giao diện không nói gì về một trình trợ giúp hay tiện ích mạng riêng biệt, vì chúng là mã khác với danh tính khác.
Xác định cách triển khai thực tế và cơ chế chia sẻ thông tin xác thực được hỗ trợ của nó thay vì sao chép đường dẫn tệp thực thi từ một ứng dụng khách cũ. Trước tiên hãy xác nhận hệ thống sẽ đề nghị danh tính nào:
security find-identity -v -p ssl-clientĐọc errSecInteractionNotAllowed
Trạng thái đó báo cáo một tương tác không được phép với Security Server, và nó không nói gì về chuỗi chứng chỉ. Hãy đọc nó cùng với thao tác đã tạo ra nó: một yêu cầu ký phát ra từ ngữ cảnh không thể hiển thị lời nhắc sẽ thất bại theo cách này ngay cả khi khóa và chứng chỉ đều hoàn toàn hợp lệ. Nơi bắt đầu là thao tác đã ghi lại nó, không phải kho chứng chỉ. Bất cứ điều gì bạn thay đổi về các mỏ neo tin cậy sẽ để lỗi đúng nguyên chỗ cũ.
Vì vậy hãy coi mã đó là lý do để xem xét ngữ cảnh thực thi và ủy quyền. Coi nó là bằng chứng rằng CA của cổng không đáng tin sẽ đưa bạn sang nửa sai của vấn đề, và thay đổi bạn làm ở đó sẽ không ảnh hưởng gì tới lỗi.
Sửa hẹp, không sửa rộng
Bắt đầu từ hướng dẫn đăng ký hoặc nhập của chủ sở hữu kết nối. Ghi lại phiên bản ứng dụng khách, phạm vi hồ sơ, danh tính đã chọn và lỗi cục bộ liên quan đầu tiên, vì bốn sự kiện đó là thứ một lần bàn giao cho bộ phận hỗ trợ cần và là cái mà một so sánh sau này phụ thuộc vào. Một hồ sơ được quản lý hoặc một danh tính có phần cứng hỗ trợ có thể cần quản trị viên hoặc nhà cung cấp sửa bàn giao, và không lượng nhấp chuột cục bộ nào thay thế được điều đó.
Nơi sản phẩm mong đợi sự chấp thuận của người dùng, hãy xác nhận thành phần nào đang yêu cầu và chỉ chấp thuận quyền truy cập đó qua luồng được hỗ trợ. Nơi thành phần không có cách nêu lời nhắc trong ngữ cảnh nó chạy, việc cấp phát phải theo con đường mà nhà cung cấp ghi lại, không phải một hộp thoại bị kéo ra từ cửa sổ terminal khác.
Hai thay đổi được gộp chung trong lời khuyên cũ, và cả hai đều quá rộng. Cấp cho mọi ứng dụng quyền truy cập khóa riêng mở rộng việc dùng khóa cục bộ vượt xa yêu cầu, và đặt chứng chỉ thành Always Trust thay đổi việc đánh giá chứng chỉ cho mọi thứ trên máy. Không cái nào diễn đạt “cách triển khai VPN đã được phê duyệt này, dùng đúng danh tính dự định này”.
Kiểm tra cục bộ trước khi đọc cổng
Sau khi sửa, hãy xác nhận thao tác cục bộ thành công trước khi bạn diễn giải bất kỳ phản hồi nào từ phía bên kia. Nếu việc ký giờ đã hoạt động, một lần từ chối tên, chuỗi hoặc chấp nhận ứng dụng khách sau đó là kết quả mới chứ không phải tái phát, và nó thuộc về một quyết định khác với một người phụ trách khác.
Một bàn giao hữu ích nêu rõ quyết định nào trong ba quyết định đã thất bại và dừng ở đó. Nó không bao giờ bao gồm khóa riêng, và không bao giờ đặt lại các mục chùm chìa khóa không liên quan với hy vọng một trạng thái sạch sẽ giúp ích. Hãy lập hai thói quen đó trước sự cố chứ không phải trong lúc xảy ra, khi cám dỗ thử mọi thứ cùng lúc mạnh nhất. Một phiếu ghi “đã dựng lại chùm chìa khóa” gần như không nói gì với người đọc tiếp theo về lỗi ban đầu.