Quản lý các chứng chỉ trong Exchange - Phần 1

Quản trị mạng - Các chứng chỉ có thể được sử dụng để mã hóa luồng dữ liệu truyền thông giữa hai điểm kết cuối (cả các máy chủ và các máy khách). Bên cạnh đó các chứng chỉ cũng được sử dụng bởi các điểm kết cuối này để tự thẩm định bản thân chúng đối với các thành phần khác. Exchange 2007 sử dụng các chứng chỉ X.509 để thẩm định và mã hóa. Các chứng chỉ này tuân theo một định dạng chuẩn khi được công bố bởi ITU-T (Telecommunication Standardization Sector).

Có một vài thành phần trong Exchange 2007 dựa vào các chứng chỉ để phục vụ cho mục đích mã hóa và thẩm định hoặc cả hai. Trong phần một của loạt bài này, chúng tôi sẽ cung cấp cho các bạn một cách nhìn tổng quan về các thành phần khác nhau của Exchange có sử dụng các chứng chỉ. Sau đó chúng tôi sẽ giới thiệu sâu hơn về các tính năng của mỗi một chứng chỉ self-signed được tạo một cách mặc định.

Việc Sử dụng chứng chỉ bởi các thành phần Exchange Server 2007

Như giới thiệu ở trên, một số thành phần của Exchange Server 2007 có sử dụng các chứng chỉ X.509 cho việc mã hóa và thẩm định hoặc cả hai. Bạn sẽ thấy rằng khi cài đặt Exchange 2007 Hub Transport server role, Client Access server role, Unified Messaging server role và Edge Transport server role, Exchange sẽ tạo một chứng chỉ self-signed mặc định để bảo đảm rằng các thành phần duy nhất của nó có thể sử dụng chứng chỉ đó để thực hiện chức năng như yêu cầu.

Hình 1 bên dưới thể hiện cho các bạn thấy chứng chỉ self-signed được tạo bởi Exchange như thế nào trong suốt quá trình cài đặt các role Exchange 2007 Client Access, Hub và Unified Messaging. Chứng chỉ này sẽ được sử dụng bởi các dịch vụ: IIS, SMTP, POP, IMAP và UM.

Hình 1: Chứng chỉ self-signed được tạo mặc định khi cài đặt role Exchange 2007 HUB, CAS, UM server

Các chứng chỉ và role Hub/Edge Transport

Bảo mật lớp truyền tải giữa các site Active Directory

Role Exchange 2007 Hub Transport server sử dụng một chứng chỉ để mã hóa tất cả lưu lượng giữa các site Active Directory. Bạn không thể cấu hình Exchange để cho phép lưu lượng SMTP không bị mã hóa giữa các máy chủ Hub Transport nằm trong các site khác nhau.

Để xem chứng chỉ nào được sử dụng giữa các máy chủ Hub Transport nằm trong các site Active Directory khác nhau, hãy sử dụng giao thức SMTP đăng nhập vào Send connector bên trong tổ chức trên mỗi máy chủ Hub Transport, xem trong hình 2 bên dưới, bằng cách sử dụng lệnh Set-TransportServer của Exchange Management Shell.

Hình 2: Thiết lập IntraOrgConnectorProtocolLogging thành verbose

Bằng cách thiết lập IntraOrgConnectorProtocolLoggingLevel thành verbose, giao thức đăng nhập sẽ được bổ sung vào bản ghi giao thức của Send connector. Sau khi gửi một mail từ Mailbox trong site B đến một Mailbox được đặt trên máy chủ Mailbox Exchange 2007 trong site A, quan sát bản ghi giao thức Send bạn sẽ thấy được rằng Exchange Hub Transport server trong Site B (Ex2007SE) sử dụng chứng chỉ được cung cấp bởi Exchange Hub Transport server trong site Active Directory đích (Ex2007EE) để khởi động Transport Layer Security, xem cụ thể trong hình 3.

Hình 3: Gửi bản ghi giao thức giữa các site Active Directory

Bạn có thể quan sát ngay được chứng chỉ trên máy chủ Hub Transport đang ở trạng thái có sẵn cho TLS, điều đó thể hiện rằng nó là một chứng chỉ self-signed đã được sử dụng (hình 4).

Hình 4: Chứng chỉ Self Signed

EdgeSync

Once EdgeSync được cấu hình giữa các máy chủ Hub Transport bên trong và Edge Transport, cả hai máy chủ đều sẽ sử dụng một chứng chỉ để mã hóa vấn đề truyền thông của chúng. Thêm vào đó, cả hai đều sẽ được sử dụng để cung cấp chỉ thị cho sự tin cậy. Sự tin cậy này là một phương pháp thẩm định nơi chứng chỉ có thể được sử dụng để thẩm định khi chứng chỉ đã cấp hiện diện trong Active Directory (với Hub Transport server role) hoặc ADAM/LDS (cho Edge Transport server role). Khi thiết lập EdgeSync, các chứng chỉ được yêu cầu sẽ được công bố trong đúng location.

Bảo mật lớp truyền tải

Bất cứ khi nào một máy chủ mở mọt kết nối với Exchange 2007 Hub/Edge Transport server role, Exchange sẽ cho phép một TLS bằng cách cung cấp chứng chỉ của nó.

Bảo mật miền

Các chứng chỉ cũng có thể được sử dụng bởi Hub/Edge Transport để cấu hình Domain Security với các tổ chức đối tác, cả mã hóa và thẩm định.

Role Client Access Server và các chứng chỉ

Client Access

Các chứng chỉ được sử dụng bởi Client Access server role để cho phép luồng dữ liệu truyền thông được mã hóa giữa Client Access server và các máy khách của nó. Mặc định SSL được yêu cầu cho:

Hình 5: Yêu cầu SSL

Với thư mục ảo, sự sử dụng chứng chỉ không được yêu cầu mặc định, là thành phần làm cho Offline Address Book có sẵn download bởi các máy khách Microsoft Office Outlook 2007 và mới hơn.

Hình 6: OAB Virtual Directory không yêu cầu SSL

Thẩm định dựa trên chứng chỉ

Bạn có thể cấu hình việc thẩm định dựa trên chứng chỉ, bằng cách cấu hình đó để cho phép các máy khách tự thẩm định chúng đối với máy chủ Client Access bằng cách sử dụng chứng chỉ cá nhân của chúng.

Unified Messaging Server Role và các chứng chỉ

Các chứng chỉ được sử dụng bởi Unified Messaging Server role để mã hóa việc truyền thông khi gửi một thông báo Voice Mail được ghi lại đến Exchange Hub Transport Server role. Các chứng chỉ cũng được sử dụng để mã há lưu lượng SIP hoặc RTP cho UM IP Gateway, và phải được sử dụng khi bạn quyết định triển khai Office Communications Server trong môi trường củau bạn, vì Office Communications Server chỉ truyền thông với các role máy chủ khác thông qua sự mã hóa.

Khi bạn triển khai Exchange 2007 Server role, ngoại trừ Mailbox Server role, Exchange sẽ tạo một chứng chỉ self-signed và cho phép Exchange sử dụng chứng chỉ này khi yêu cầu cho các dịch vụ IIS, SMTP, POP3, IMAP4 và UM.

Các đặc điểm của chứng chỉ Self-Signed

Chúng ta hãy đi xem xét các tính năng của chứng chỉ Self-Signed được tạo mặc định này.

Các chứng chỉ Self-Signed chỉ hợp lệ khoảng một năm, xem trong hình 7, và cần phải remew sau một năm.

Hình 7: Chứng chỉ Self-Signed chỉ hợp lệ cho một năm

Để renew chứng chỉ Self-Signed, bạn có thể sử dụng lệnh New-ExchangeCertificate. Nếu có được chứng chỉ này đang tồn tại bằng cách chạy Get-ExchangeCertificate, bạn có thể trích dẫn đối tượng cho lệnh New-ExchangeCertificate, khi đó sẽ tạo được một chứng chỉ Self-Signed mới với các thiết lập tương tự và kích hoạt nó cho các dịch vụ tương tự một cách mặc định.
Trong hình 8, bạn có thể thấy chứng chỉ Self-Signed đang tồn tại được renew.

Hình 8: Làm mới lại một chứng chỉ Self-Signed đang tồn tại

Exchange 2007 Client Access server chỉ cho phép một chứng chỉ được kích hoạt để sử dụng với IIS, tuy nhiên bạn có thể vẫn có nhiều chứng chỉ được kích hoạt cho POP, IMAP, UM và SMTP. Khi có nhiều chứng chỉ hiện hữu, Exchange sẽ chọn ra một chứng chỉ dựa vào tiêu chuẩn khác nhau. Chúng tôi sẽ đề cập đến quá trình chọn này trong phần hai của loạt bài.

Chứng chỉ Self-Signed được tạo khi triển khai Exchange 2007 sẽ có tập tên chung cho Host name của Exchange server và có hai thiết lập tên Subject Alternative Names đối với tên Host và Fully Qualified Domain Name của nó.

Hình 9: Chứng chỉ Self-Signed và Subject lẫn CertificateDomains của nó

Mặc dù vậy hoàn toàn có thể tạo một chứng chỉ Self-Signed với Subject và Subject Alternative Names để bảo đảm rằng nó có thể được sử dụng trong tổ chức Exchange.

Sử dụng lệnh New-ExchangeCertificate, bạn có thể tạo một ví dụ về một chứng chỉ với Common Name là webmail.proexchange.global, sau đó chỉ định Subject Alternative Names như Exchange cho Host và Fully Qualified Domain Name, xem hình 10.

Không quên bổ sung thêm tham số boolean PrivateKeyExportable và thiết lập True, nếu muốn bạn có thể export chứng chỉ này nhằm cho phép người dùng của bạn tin tưởng nó (các chi tiết sẽ được giới thiệu trong phần 2).

Hình 10: Tạo chứng chỉ Self-Signed với Subject Alternative Names tùy chỉnh

Trong phần hai của loạt bài này, chúng tôi sẽ quay trở lại với các tên yêu cầu của chứng chỉ. Trong phần ba sẽ giải thích chi tiết hơn về các lệnh được sử dụng.

Bạn cần lưu ý để biết rằng chứng chỉ Self-Signed chỉ được tin cậy bởi người phát hành ra nó , điều đó có thể làm cho Exchange không hoạt động nếu không được cấu hình đúng cách. Chúng ta hãy xem đến những gì bạn cần quan tâm nếu quyết định sử dụng chứng chỉ Self-Signed:

Hình 11: Chứng chỉ Self-Signed không tin cậy

Hình 12: Chứng chỉ Self-Signed không tin cậy

Kết luận

Trong phần một này, cúng tôi đã giới thiệu cho các bạn các thành phần của Exchange 2007 có sử dụng đến các chứng chỉ và các đặc điểm của chứng chỉ “self-signed”. Trong phần hai của loạt bài này, chúng tôi sẽ giới thiệu cho các bạn những yếu tố giúp các bạn có thể tin tưởng và chứng chỉ này và các yêu cầu của một chứng chỉ mà bạn cần lưu ý khi sử dụng chúng. Phần cuối cùng của loạt bài sẽ cung cấp cho các bạn những quan sát sâu hơn về các lệnh của Exchange Management Shell dùng để tạo, quản lý và remove các chứng chỉ Exchange.