Tôi e rằng không có câu trả lời có/không đơn giản cho câu hỏi này.
Nếu Kestrel và Apache đang chạy trên cùng một hộp, thì bạn đang sử dụng chứng chỉ một cách hiệu quả chỉ vì Kestrel mong đợi một chứng chỉ. Nó không cung cấp bảo mật và Nó có an toàn hơn không? câu hỏi không được áp dụng.
Nếu Kestrel và Apache ở trên các hộp khác nhau thì nó phức tạp hơn một chút. Nếu hai hộp nằm trên một mạng đáng tin cậy, bạn có thể lập luận tương tự như trên - chứng chỉ chỉ có ở đó vì Kestrel mong đợi một hộp.
Nếu mạng không đáng tin cậy, bây giờ bạn sẽ cần một số biện pháp bảo mật. Chứng chỉ cung cấp danh tính máy cần thiết để kích hoạt kết nối TLS. Cho dù bạn sử dụng chứng chỉ tự ký hay chứng chỉ do CA ký thì điều này sẽ thêm nhiều lựa chọn hơn.
- Nếu ứng dụng Kestrel đang sử dụng FQDN nội bộ (ví dụ:
ứng dụng.local) và CA không muốn chứng thực những tên như vậy (ví dụ: CA thương mại sẽ không làm điều này) thì bạn buộc phải sử dụng chứng chỉ tự ký.
- Nếu CA là nội bộ và sẵn sàng chứng nhận tên địa phương, thì bạn có thể cân nhắc sử dụng CA cho chứng chỉ Kestrel.
Vì vậy, giả sử bây giờ bạn có thể sử dụng chứng chỉ CA cho Kestrel, tiếp theo bạn cần tự hỏi tại sao bạn cần phải làm như vậy:
Chứng chỉ có chữ ký của CA thường trở nên đáng giá trong trường hợp một-nhiều. Nếu bạn có một máy chủ và nhiều bên phụ thuộc (máy khách) thì chứng chỉ do CA cấp sẽ đảm bảo:
- các bên phụ thuộc chỉ cần tin tưởng CA và mọi chứng chỉ được cấp đều được tin cậy hoàn toàn (chứng chỉ tự ký cần được tất cả khách hàng tin cậy);
- các bên phụ thuộc không cần xem xét quy trình quản trị và vận hành của từng máy chủ mà họ muốn tin tưởng vì họ có thể cho rằng nếu CA đã chứng nhận thì nó đáng tin cậy;
- mọi thứ hoạt động sau khi gia hạn chứng chỉ (so với chứng chỉ tự ký, sẽ cần được phân phối cho tất cả các khách hàng sau khi gia hạn);
- việc thu hồi hoạt động (không có khái niệm thu hồi chứng chỉ tự ký - nếu chứng chỉ máy chủ bị xâm phạm, bạn phải xóa chứng chỉ khỏi tất cả các khách hàng);
Tuy nhiên, nếu bạn đang ở trong tình huống một đối một (chẳng hạn như giữa proxy ngược và máy chủ ứng dụng) thì CA mang lại ít lợi ích hơn (quyết định tin cậy dễ dàng hơn, gia hạn dễ dàng và nếu máy chủ bị xâm phạm, bạn chỉ cần xóa chứng chỉ từ một khách hàng). Trên thực tế, nếu bạn không có sẵn một CA, thì chi phí xây dựng và quản lý một CA chỉ dành cho kết nối giữa máy chủ ứng dụng và proxy ngược lại quá lớn nên không đáng.
Về sau, nhược điểm duy nhất của việc sử dụng chứng chỉ tự ký có thể là thiếu quản lý trung tâm. Nhiều CA trợ giúp quản lý vòng đời của chứng chỉ đã cấp, ngay cả khi đó chỉ đơn giản là một email tự động để nhắc bạn rằng chứng chỉ sắp hết hạn hoặc phức tạp như gia hạn tự động. Chứng chỉ tự ký do bạn quản lý. Để giúp giảm thiểu điều này, một số tổ chức sử dụng các công cụ quản lý vòng đời chứng chỉ để quản lý chứng chỉ của họ và nếu công cụ này cũng có thể giám sát chứng chỉ tự ký, thì điều đó sẽ giải quyết được vấn đề đó.
Vì vậy, tóm lại, nếu CA của bạn cung cấp dịch vụ quản lý vòng đời bổ sung giúp bạn quản lý chứng chỉ thì có thể đáng xem xét; nhưng nếu không, trong tình huống một đối một, chẳng hạn như giữa máy chủ ứng dụng và proxy ngược, điều đó không thực sự tạo ra sự khác biệt cho dù bạn sử dụng chứng chỉ tự ký hay chứng chỉ do CA ký.
Nếu bạn đi theo lộ trình chứng chỉ do CA cấp cho máy chủ ứng dụng, bạn có nhiều quyết định hơn:
Nếu ứng dụng và proxy ngược nằm trên cùng một hộp, bạn có thể cân nhắc sử dụng một chứng chỉ giữa chúng một cách an toàn - bạn sẽ không gặp phải tình huống một dịch vụ bị xâm phạm trong khi dịch vụ kia vẫn được tin cậy. Bạn sẽ (nên) cho rằng tất cả các chứng chỉ trên một hộp đều bị xâm phạm nếu có, vì vậy nhìn chung không có lợi ích thực sự nào trong các chứng chỉ riêng biệt.
Nếu các ứng dụng nằm trên các hộp khác nhau thì bạn có thể rơi vào tình huống một cái bị xâm phạm trong khi cái kia thì không. Để chuẩn bị cho những trường hợp như vậy, bạn nên có một chứng chỉ khác nhau trên mỗi hộp.
Lưu ý rằng trong khi phần trên thảo luận về giao tiếp giữa máy chủ ứng dụng và proxy ngược, bạn có thể thử lập luận tương tự với Máy chủ nhận dạng 4 (bất kể đó có thể là gì).
