Windows Server 2008 Phần 1

Phần 1 - Chuẩn bị môi trường Active Directory

Trước khi triển khai một hạ tầng PKI trên nền Windows Server 2008, có một vài câu hỏi đặt ra là:

  • Có cần nâng cấp tất cả các domain controller trong forest lên Windows Server 2008 hay không? Câu trả lời là không. Vì Windows Server 2008 PKI không phụ thuộc vào chuyện các domain controller có chạy Windows Server 2008 hay không. Tức là ta có thể triển khai Windows Server 2008 PKI trong môi trường Active Directory có các domain controller chạy Windows 2000 hoặc Windows Server 2003.
  • Có cần nâng cấp domain functional level hoặc forest functional level lên Windows Server 2008 hay không? Câu trả lời vẫn là không. Windows Server 2008 PKI không có yêu cầu nào dành cho domain hay forest functional level.
  • Cần phải làm gì để triển khai Windows Server 2008 PKI? Ở các phần sau mô tả các bước cần làm để cài đặt dịch vụ Active Directory Domain Services (AD DS) phục vụ cho Windows Server 2008 PKI.
  • Có thể triển khai Windows Server 2008 Enterprise CA trong môi trường có dịch vụ AD DS được không? Điều này là không thể. Một Enterprise CA cần có sự hiện diện của AD DS để lưu trữ các thông tin cấu hình, phát hành chứng chỉ, chính sách an ninh và chức năng xác thực. Có thể cài đặt Windows Server 2008 làm standalone CA nếu muốn triển khai PKI trong môi trường không có AD DS. Trong môi trường standalone CA, nội dung của chứng chỉ được định nghĩa trong các tập tin yêu cầu chứng chỉ thay vì sử dụng các mẫu chứng chỉ trong AD DS để định nghĩa nội dung của các chứng chỉ được cấp. Ngoài ra, tất cả các yêu cầu cấp chứng chỉ mặc định được đặt ở trạng thái chờ phê duyệt, và cần tới người quản lý đồng ý hoặc từ chối cho mỗi yêu cầu được gửi tới standalone CA.
Phân tích môi trường Active Directory
Trước khi cài đặt Windows Server 2008 Enterprise CA, có vài thứ cần chuẩn bị như sau:
  • Xác định số lượng forest: điều này sẽ ảnh hưởng tới số lượng các Enterprise CA cần thiết để triển khai dịch vụ Active Directory Certificate Services. Một Enterprise CA chỉ có thể cấp chứng chỉ cho các tài khoản người dùng và máy tính nằm trong cùng forest với nó. Nếu có nhiều forest cần tới chứng chỉ từ PKI thì phải mỗi một forest phải có ít nhất một Enterprise CA dành riêng cho nó.
  • Xác định số lượng domain trong forest: nếu có nhiều hơn một domain trong forest thì phải quyết định xem domain nào sẽ chứa các CA. Việc lựa chọn domain nào sẽ chứa tài khoản máy tính của máy CA phụ thuộc vào chuyện tổ chức sử dụng cơ chế quản lý tập trung hay phân tán. Trong mô hình tập trung, các CA thường sẽ được đặt trong cùng domain. Còn ở môi trường phân tán thì có thể triển khai các CA trong nhiều domain.
  • Xác định phiên bản schema của domain: để triển khai Windows Server 2008 CA và khai thác tất cả các tính năng mới có trong Active Directory Certificate Services thì cần áp dụng phiên bản mới nhất của AD DS schema. Windows Server 2008 schema có thể được triển khai trong các forest chứa các domain controller chạy Windows 2000, Windows Server 2003 hay Windows Server 2008. Windows Server 2008 schema sẽ bổ sung thêm các tính năng mới sau:
    • Hỗ trợ mẫu chứng chỉ phiên bản 3: các mẫu chứng chỉ này sẽ sử dụng các thuật toán được cung cấp bởi Cryptography Next Generation (CNG) API.
    • Hỗ trợ OCSP: giao thức này không có trong các phiên bản trước đó như Windows 2000, Windows Server 2003. Dịch vụ này sẽ thay thế cho CRL trong việc xác định trạng thái thu hồi của chứng chỉ.
    • Dịch vụ Network Device Enrollment: giúp tư động cấp chứng chỉ cho các thiết bị mạng của Cisco qua giao thức SCEP (Simple Certificate Enrollment Protocol). Điều này cho phép chứng chỉ được cấp cho các thiết bị mạng mà không cần phải tạo thêm các tài khoản máy tính trong Active Directory cho chúng.
    • Hỗ trợ Qualified Certificate: như được mô tả trong RFC 3739, loại chứng chỉ này có mức tin cậy cao khi sử dụng cho chữ ký số. Một Qualified Certificate cũng có thể bao gồm các thông tin sinh trắc học của người nắm giữ chứng chỉ.
(Xem thêm hướng dẫn ở bài viết sau để thực hiện nâng cấp Windows 200 hoặc Windows Server 2003 schema lên Windows Server 2008 schema:
http://prashanthpurushotham.wordpress.com/2011/10/19/schema-upgrade-from-windows-server-2003-to-windows-server-2008-r2-testing-plan-in-isonet-network/)
  • Xác định scope của group Cert Publisher: đây là group mặc định có trong mỗi domain của forest. Group Cert Publisher của một domain được cấp các quyền hạn để đọc và ghi các thông tin chứng chỉ tới thuộc tính userCertificatecủa đối tượng user trong domain đó. Điều cần xem xét ở đây là scope của group này được xác định bởi hệ điều hành của domain controller đầu tiên của domain, cụ thể:
    • Nếu domain A được tạo trên nền Windows 2000 thì Cert Publisher là global group. Vì vậy mà chỉ có các tài khoản máy tính nằm trong domain A mới có thể làm thành viên của group Cert Publisher của domain A đó.
    • Nếu domain A được tạo trên nền Windows Server 2003 hoặc 2008 thì Cert Publisher là domain local group. Có nghĩa rằng các tài khoản máy tính từ bất kỳ domain nào cũng có thể làm thành viên của group Cert Publisher của domain A này.
Nếu một CA cấp chứng chỉ cho người dùng và cần phát hành chứng chỉ đó tới thuộc tính userCertificate thì quá trình này sẽ thất bại nếu CA không phải là thành viên của group Cert Publisher của domain mà người dùng đó đang thuộc về.
Trong trường hợp Cert Publisher là global group thì có 2  phương án là:
  • Chỉnh sửa quyền hạn để cho phép group này đọc và ghi lên thuộc tính userCertificate cho tất cả các domain trong forest.
  • Thay đổi scope của group Cert Publisher thành domain local group và thêm tài khoản máy tính của CA vào group Cert Publisher của mỗi domain.
Người đăng:

Windows Server 2008 Phần 2

Phần 2 – Xác định số lượng các tầng trong hệ thống phân cấp CA


Có bao nhiêu tầng sẽ có trong hệ thống phân cấp CA là điều cơ bản cần xem xét trong quá trình thiết kế. Cũng cần thiết xác định số lượng các CA sẽ có tại mỗi tầng. Hầu hết các mô hình bao gồm hai cho tới bốn tầng; tuy nhiên, có thể áp dụng một tầng (chỉ gồm một CA) cho các tổ chức nhỏ.
Hệ thống phân cấp CA đơn tầng
Thích hợp cho các tổ chức nhỏ có ít hơn 300 tài khoản người dùng. Thay vì triển khai nhiều CA thì sẽ chỉ có một CA được cài đặt làm Enterprise Root CA.
Enterprise Root CA không bị tách rời khỏi mạng mà nó sẽ là một máy chủ thành viên của domain và luôn hiện diện trên mạng để cấp chứng chỉ theo yêu cầu của các máy tính, người dùng, dịch vụ hay thiết bị mạng. Nếu có thể thì không nên cài đặt Enterprise Root CA trên cùng một máy tính với máy domain controller vì lý do an ninh cũng như có phát sinh vấn đề trong tương lai nếu có ý định di chuyển CA sang một máy tính khác.
Ưu điểm của mô hình này là dễ dàng quản lý, chi phí thấp nhưng khả năng dự phòng, mở rộng kém lại là nhược điểm của nó. Nếu CA ngưng hoạt động thì dịch vụ Certificate Services không thể xử lý các yêu cầu cấp phát, thay mới chứng chỉ hoặc phát hành CRL cho tới khi CA được khôi phục trở lại.
Hệ thống phân cấp CA hai tầng
Mô hình này gồm một Root CA ở chế độ offline (không được kết nối vào mạng) và một hoặc hai Issuing CA. Ở đây, các Issuing CA đảm nhận luôn chức năng của Policy CA như được thể hiện trong Hình dưới đây:
Để đảm bảo an ninh, Root CA sẽ được cài đặt ở dạng Standalone Root CA, không cần thiết phải là thành viên của domain. Vì vậy mà Root CA này có thể hoạt động offline nhằm hạn chế các cuộc tấn công qua mạng tới nó.
Để tăng cường độ sẵn sàng cho dịch vụ Certificate Services, nên có nhiều hơn một Issuing CA nằm ở tầng hai để nếu một CA bị ngưng hoạt động thì dịch vụ Certificate Services vẫn chạy trên các CA còn lại. Số lượng các Issuing CA phụ thuộc vào yêu cầu cụ thể của tổ chức.
Hệ thống phân cấp CA ba tầng
Mô hình này linh hoạt và mang lại độ an toàn cao. Như được thể hiện trong Hình dưới đây, nó bao gồm các thành phần sau:
  • Một offline Root CA được cài đặt làm Standalone Root CA
  • Một hoặc nhiều offline Policy CA được cài đặt làm Standalone Subordinate CA
  • Một hoặc nhiều Issuing CA được cài đặt làm Enterprise Subordinate CA hoặc Standalone Subordinate CA
 
Các trường hợp sau được khuyến cáo nên áp dụng thiết kế này là:
  • Yêu cầu cao về an toàn vật lý cho hệ thống CA là điều bắt buộc trong chính sách an ninh của tổ chức. Vì vậy mà cần thiết phải triển khai offline đối với Root và Policy CA để bảo vệ chúng từ các cuộc tấn công qua mạng.
  • Các chứng chỉ được cấp dưới các mức độ bảo đảm khác nhau nên cần tới các chính sách chứng chỉ khác nhau. Nếu việc xác minh nhận dạng của đối tượng yêu cầu chứng chỉ cần tới các biện pháp khác nhau thì cần phân tách các Policy CA tại tầng hai. Ví dụ, sẽ cần tới các CPS (Certificate Practice Statement) khác nhau cho đối tượng là nhân viên và cho đối tượng là đối tượng hoặc khách hàng của tổ chức. Mỗi Policy CA sẽ áp dụng các CPS của riêng nó  cùng các chính sách chứng chỉ có liên quan.
  • Việc quản lý hệ thống CA được phân chia cho các nhóm quản trị khác nhau, ví dụ, sẽ có một nhóm quản lý PKI quản lý các CA ở Châu Âu trong khi có một nhóm khác sẽ quản lý ở khu vực châu Á. Trong tình huống này, trách nhiệm của mỗi nhóm là định nghĩa CPS cho các Policy CA mà họ quản lý.
Hệ thống phân cấp CA bốn tầng
Trong một số trường hợp nhất định vẫn cần tối hệ thống phân cấp CA gồm tới bốn tầng nhưng thường điều này được khuyến cáo. Trong mô hình này, các Issuing CA nằm ở cả tầng ba và bốn. Hình dưới đây thể hiện hai CA cấp vùng (Bờ Tây và Bờ Đông) tại tầng ba và các CA khác (cho nhân viên và nhà thầu) tại tầng bốn.
Ghi chú:
  • Chính sách an ninh (Security policy): là một tài liệu định nghĩa các tiêu chuẩn về vấn đề an ninh của tổ chức. Nó thường bao gồm kiểm kê tài sản có giá trị của tổ chức, các mối đe dọa tiềm tàng với các tài sản đó cũng như vạch ra các biện pháp để bảo về chúng.
  • Chính sách chứng chỉ (Certification policy): là một tài liệu mô tả các cách thức mà tổ chức sẽ sử dụng để xác minh nhận dạng của đối tượng yêu cầu cấp chứng chỉ và chỉ ra những mục đích sử dụng của chứng chỉ. Việc xác minh có thể đòi hỏi đối tượng cung cấp tài khoản và mật khẩu để đối chiếu thông tin với cơ sở dữ liệu của tổ chức.
  • Tuyên bố thực hành chứng chỉ (Certification practice statement – CPS ): là một tài liệu được công khai rộng rãi mô tả một CA được tổ chức quản lý như thế nào để duy trì an ninh và các chính sách chứng chỉ. Một CPS được phát hành bởi một CA và mô tả hoạt động của CA đó.
Người đăng:

Windows Server 2008 Phần 3

Phần 3 – Lựa chọn kiểu kiến trúc và tổ chức các CA

Không có một công thức chung và đơn giản cho việc lựa chọn kiến trúc nào (đơn cấp, hai cấp, ba cấp hay bốn cấp) để triển khai cũng như cách sắp đặt các CA. Các yếu tố cần xem xét khi thiết kế hệ thống phân cấp CA bao gồm:
  • Số lượng các chứng chỉ sẽ được cấp phát: càng nhiều chứng chỉ mà hệ thống cần cung cấp thì càng cần nhiều Issuing CA và điều này cũng làm tăng độ dự phòng nếu chẳng may có sự cố xảy ra với một CA nào đó.
  • Cấu trúc của tổ chức: nếu tổ chức bị phân tán về mặt địa lý qua nhiều châu lục hoặc vùng miền thì một Issuing CA nên được đặt tại mỗi vị trí này. Và tất cả các Issuing CA có thể cùng tuân theo chính sách từ một Policy CA duy nhất (như ví dụ được thể hiển trong Hình 1) hoặc sẽ có các Policy CA riêng biệt cho mỗi vị trí (như ví dụ được thể hiện trong Hình 2).
Hình 1 – Các Issuing CA được phân tán theo vị trí địa lý với một Policy CA duy nhất
 
Hình 2 – Các Issuing CA được phân tán và có các Policy CA riêng tại mỗi vị trí
Ngoài ra, nếu tổ chức được cấu thành bởi nhiều tổ chức tự trị nhưng có mối liên hệ, hợp tác với nhau như trong ví dụ ở Hình 3 thì có thể phân tách các Policy và Issuing CA cho mỗi tổ chức.
Hình 3 – Hệ thống phân cấp CA theo cấu trúc hành chính của tổ chức
  • Mô hình quản lý: với các tổ chức có mô hình quản lý tập trung thì thường chỉ có một vài CA đáp ứng dịch vụ cho toàn bộ hệ thống. Nhưng với các tổ chức có mô hình quản lý phân tán thì thường sẽ có một CA tách biệt cho mỗi nhóm. Ví dụ ở Hình 4, có một nhóm quản lý Secure E-mail CA mà cấp chứng chỉ cho mục đích bảo vệ email, một nhóm khác quản lý VPN CA mà cấp chứng chỉ cho môi trường mạng riêng ảo, và một nhóm quản lý EFS CA mà cấp chứng chỉ cho nhu cầu mã hóa EFS.

Hình 4 – Cấu trúc phân cấp CA theo mô hình quản lý PKI
Người đăng:

Windows Server 2008 Phần 4.1

Phần 4 – Thu thập các thông tin cần thiết

Quá trình thu thập thông tin này sẽ giúp việc thiết kế hệ thống CA được phù hợp và chính xác. Các dữ liệu cần thu thập gồm:
  • Các ứng dụng hỗ trợ PKI
  • Các đối tượng cần tới chứng chỉ
  • Các yêu cầu an ninh
  • Các yêu cầu về kỹ thuật
  • Các yêu cầu về kinh doanh
  • Các yêu cầu đối với bên ngoài

Nhận diện các ứng dụng hỗ trợ PKI
Các ứng dụng và công nghệ sau có thể khiến tổ chức cần thiết triển khai một hạ tầng PKI là:
  • 802.1X: là cơ chế xác thực dựa trên cổng truy cập mạng (port) để chỉ cho phép người dùng và máy tính đã được xác thực truy cập vào mạng không dây chuẩn 802.11 (WLAN) hoặc mạng LAN chuẩn Ethernet.
  • Chữ ký số: các chứng chỉ có thể được dùng cho mục đích tạo chữ ký số.
  • EFS: giúp mã hóa dữ liệu sử dụng kế hợp mã hóa đối xứng và bất đối xứng.
  • Xác thực và mã hóa cho môi trường Web: cung cấp chứng chỉ SSL cho máy chủ Web để giúp máy khách xác minh nhận dạng của máy chủ Web cũng như mã hóa toàn bộ dữ liệu được gửi qua lại giữa chúng. Ngoài ra, cũng có loại chứng chỉ là client authentication certificate cho phép máy khách gửi tới máy chủ Web chứng chỉ của nó như là một hình thức xác thực.
  • IPSec: các chứng chỉ còn có thể được dùng để hai điểm đầu cuối trên một kênh truyền thông qua IPSec xác thực lẫn nhau. Sau khi được xác thực, chúng sẽ sử dụng IPSec để mã hóa và ký số cho tất cả các thông điệp gửi cho nhau còn bản thân các chứng chỉ không làm hai chức năng này.
  • Bảo vệ e-mail: sử dụng chứng chỉ để xác minh nhận dạng của người gửi, nguồn gốc và tính toàn vẹn của thông điệp và sử dụng mã hóa để đảm báo tính bí mật cho thông điệp.
  • Đăng nhập bằng thẻ thông minh: giúp nâng cao an ninh bằng cách sử dụng phương thức xác thực hai yếu tố. Để đăng nhập vào hệ thống, người dùng phải có thẻ thông minh chứa chứng chỉ số để nhận dạng họ và biết được mã số PIN của thẻ đó.
  • Ký số cho mã chương trình: giúp bảo vệ máy tính trước nguy cơ cài đặt các phần mềm và trình điều khiển thiết bị không rõ nguồn gốc, trái phép.
  • Mạng riêng ảo: VPN cho phép người dùng ở xa kết nối vào mạng nội bộ qua các giao thức đường hầm như PPTP (Point-to-Point Protocol), L2TP (Layer 2 Tunneling Protocol), hoặc SSTP (Secure Socket Tunneling Protocol). Có thể sử dụng chứng chỉ để xác thực người dùng và cả máy tính nếu IPSec được dùng kết hợp với L2TP.
Nhận diện các đối tượng nhận chứng chỉ
Thường chứng chỉ được cấp phát cho các chủ thể sau:
  • Người dùng: các ứng dụng hỗ trợ PKI có thể nhận diện người dùng nhờ chứng chỉ được cấp cho họ. Người dùng có thể được cấp duy nhất một chứng chỉ mà tất cả các ứng dụng đều hỗ trợ hoặc chỉ nhận các chứng chỉ riêng biệt cho từng ứng dụng như chứng chỉ mã hóa EFS chỉ được dùng cho mục đích mã hóa tập tin trong Windows. Chứng chỉ cho người dùng được lưu trong khoa chứa chứng chỉ Current User.
  • Máy tính: người dùng hoặc máy tính có thể nhận dạng một máy tính khác nhờ chứng chỉ được cấp cho nó. Chứng chỉ cho máy tính được lưu trong kho chứa chứng chỉ Local Machine.
  • Thiết bị mạng: chứng chỉ có thể được cài đặt lên các thiết bị mạng như VPN, firewall, router cho mục đích xác thực máy khách hoặc máy chủ.
  • Dịch vụ: một vài dịch vụ cần tới chứng chỉ của máy tính cho việc xác thực hoặc mã hóa. Chứng chỉ không thực sự được cấp cho dịch vụ mà thay vào đó, chứng chỉ được lưu trong kho chứa Local Machine hoặc trong hồ sơ của người dùng. Ví dụ, chứng chỉ cho dịch vụ WWW của máy chủ Web sẽ được lưu trong kho chứa Local Machine, còn chứng chỉ EFS Recovery Agent cho dịch vụ EFS thì được lưu trong hồ sơ người dùng. Cách dễ nhất để xác định vị trí lưu chứng chỉ cho một dịch vụ là điều tra xem tài khoản nào mà dịch vụ sử dụng để xác thực. Nếu dịch vụ sử dụng tài khoản hệ thống như Local System thì chứng chỉ phải được lưu trong kho chứa Local Machine. Nếu dịch vụ sử dụng tài khoản người dùng thông thường (có mật khẩu) thì chứng chỉ phải được lưu trong hồ sơ của người dùng đó.
Xác định các yêu cầu về an ninh
Mỗi tổ chức nên có một chính sách định nghĩa các tiêu chuẩn an ninh cho toàn hệ thống, trong đó có các yêu cầu về an ninh khi thiết kế PKI. Dưới đây là một vài yêu cầu có thể có:
  • An toàn vật lý cho các offline CA: các Root CA trong mô hình hai tầng và Root CA với Policy CA trong mô hình ba tầng sẽ không được kết nối vào mạng và được đặt tại những vị trí địa lý được bảo vệ chặt chẽ bởi các cơ chế kiểm tra và giám sát truy cập như camera, ổ khóa, thẻ thông minh, v.v..
  • An toàn cho các online CA: ngoài các biện pháp đảm bảo an toàn vật lý như được áp dụng cho các offline CA thì các Issuing CA cũng cần được cấu hình sao cho bảo mật như chỉ cài đặt các thành phần cần thiết, dành riêng một máy tính làm Issuing CA thay vì cài đặt các chức năng khác như domain controller cho nó.
  • Bảo vệ khóa bí mật của CA: áp dụng tiêu chuẩn FIPS (Federal Information Processing Standards) 140-2 cho việc bảo vệ của khóa bí mật của CA. Mặc định, Microsoft CA triển khai dịch vụ mật mã (Cryptographic Service Provider – CSP) ở dạng phần mềm là Microsoft Strong Cryptographic Provider. Một CSP mềm lưu trữ khóa bí mật của CA trên đĩa cứng cục bộ của máy tính. Mặc dù các biện pháp an ninh vật lý có thể tăng cường bảo vệ cho khóa này nhưng cần biết rằng bất kỳ thành viên nào của group Local Administrators có thể xuất ra và sử dụng lại khóa bí mật này ở nơi khác.
CSP cũng định nghĩa cách thức khóa bí mật của chứng chỉ được bảo vệ và được truy cập. CSP sẽ quyết định nơi tạo và lưu cặp khóa của chứng chỉ và triển khai các cơ chế để bảo vệ việc truy cập tới khóa bí mật. Ví dụ, CSP có thể yêu cầu nhập vào mã PIN để truy cập tới khóa bí mật được lưu trong thẻ thông minh.
Hai biện pháp sau có thể giúp bảo vệ khóa bí mật tốt hơn:
  • Sử dụng thẻ thông minh: dùng để lưu khóa bí mật của CA trên các thiết bị xác thực hai yếu tố. Khi muốn truy cập tới khóa bí mật, người dùng phải nhập vào đúng mã PIN của thẻ thông minh.
  • Sử dụng mô-đun bảo mật phần cứng (Hardware Security Module – HSM): mô-đun này đem lại mức bảo vệ tốt nhất cho khóa bí mật của CA bằng cách lưu trữ khóa này trên một thiết bị phần cứng có độ bảo mật cao. HSM cung cấp thêm các biện pháp để bảo vệ khóa bí mật khỏi bị giả mạo và trong một số trường hợp sẽ phá hủy khóa bí mật nếu nó bị  tấn công.
  • Các điều kiện cấp phát khác nhau cho các chứng chỉ: một số chứng chỉ được cấp dựa trên xác minh mật khẩu và tài khoản người dùng còn một số khác lại được cấp chỉ khi nhận dạng của người dùng được xác minh thông qua việc trình diện ảnh chụp của họ.
Người đăng:

Windows Server 2008 Phần 4.2

Xác định các yêu cầu về kỹ thuật

Các vấn đề kỹ thuật ảnh hưởng tới cấu trúc của hệ thống phân cấp CA và nên được xem xét trong suốt quá trình thiết kế PKI bao gồm:

1.   Chỉ định các vai trò quản lý PKI
Active Directory Certificate Services cho phép chỉ định, ủy quyền cho người dùng đảm trách các vai trò quản lý CA trong PKI. Windows Server 2008 hỗ trợ các vai trò sau theo định nghĩa của Common Criteria:
  • CA Administrator: đảm trách việc quản lý cấu hình của máy CA, bao gồm định nghĩa các thiết lập, thuộc tính của CA và chỉ định ai làm Certificate Manager. Vai trò này được giao phó cho người dùng thông qua việc gán giấy phép (permission) Manage CA cho người dùng đó tại CA.
  • Certificate Manager: còn được gọi là CA Officer, đảm trách việc quản lý chứng chỉ, bao gồm thu hồi, cấp phát, xóa bỏ chứng chỉ. Ngoài ra, Certificate Manager có thể trích xuất các khóa bí mật được lưu trữ cho việc khôi phục bởi một key recovery agent. Vai trò này được giao phó cho người dùng thông qua việc gán giấy phép Issue and Manage cho người dùng đó tại CA.
  • Backup Operator: đảm trách việc sao lưu và khôi phục cơ sở dữ liệu và các thiết lập cấu hình của CA. Vai trò này được giao phó cho người dùng thông qua việc gán quyền (user right) Back Up Files and Directories hoặc Restore Files and Directories trong GPO được gán cho CA hoặc trong Local Security Policy của CA.
  • Auditor: đảm trách việc chỉ định các sự kiện nào tại CA sẽ được giám sát và ghi nhận cũng như có quyền xem lại trong mục Security Log các sự kiện liên quan tới hoạt động của quản lý PKI. Vai trò này được giao phó cho người dùng thông qua việc gán quyền Manage Auditing and Security Log trong GPO hoặc trong Local Security Policy của CA.
Mỗi CA có thể có các người dùng khác nhau đảm trách các vai trò trên. Khi tuân thủ việc phân tách vai trò theo Common Criteria thì một người dùng chỉ có thể nắm giữ một trong bốn vai trò.
2.   Giảm thiểu rủi ro CA ngưng hoạt động
Trong thiết kế hạ tầng PKI có thể bao gồm một vài biện pháp để ngăn chặn hoặc giảm thiểu khả năng dịch vụ Certificate Services ngưng hoạt động. Ví dụ, ta có thể gom nhóm (cluster) các máy Windows Server 2008 làm Issuing CA để mang lại độ sẵn sàng cao cho dịch vụ của các CA quan trọng này. Ngoài ra, nếu coi sự cố liên quan tới đĩa cứng là rủi ro lớn nhất thì có sử dụng công nghệ RAID 5 hoặc RAID 0+1 để lưu trữ cơ sở dữ liệu của CA giúp đảm bảo hiệu năng và thời gian khôi phục nhanh nhất trong trường hợp lỗi ổ đĩa. Tương tự, các tập tin chứa nhật ký hoạt động của CA có thể được đặt trên mảng đĩa RAID 1. Cũng cần đảm bảo rằng các phân vùng của ổ đĩa đủ lớn để lưu trữ nhiều chứng chỉ trong tương lai.
Các yêu cầu về phần cứng dành cho offline CA thì thấp hơn Issuing CA. Ví dụ, Hình 1 dưới đây thể hiện hai cấu hình đĩa cứng có thể được áp dụng cho offline CA giúp tăng khả năng phục hồi và giảm thiểu chi phí.
 
Hình 1 – Cấu hình đĩa cứng nên dùng cho offline CA
Ở cấu hình bên trái, có hai mirror set tách biệt, một dùng để chứa hệ điều hành và một dùng để lưu CSDL và nhật ký của CA. Còn ở cấu hình bên phải, chỉ một mirror set gồm hai phân vùng: phân vùng C dành cho hệ điều hành, và phân vùng D dành cho CSDL và nhật ký của CA.
Đối với online CA, hoạt động của Certificate Services phát sinh nhiều dữ liệu cần lưu trên ổ đĩa hơn offline CA. Thường nên kết hợp RAID 1 và RAID 5 hoặc RAID 0+1 như được thể hiện trong Hình 2 dưới đây:
Hình 2 – Cấu hình đĩa cứng nên dùng cho online CA
Ở phía bên trái, có hai hệ thống RAID 1: một cho ổ C chứa hệ điều hành và một cho ổ D chứa các tập tin nhật ký của CA. Còn CSDL của CA được lưu trên hệ thống RAID 5. Cấu hình này mang lại hiệu suất đọc/ghi vào CSDL cao và tăng độ an toàn cho dữ liệu của hệ điều hành và nhật ký của CA.
Ở phía bên phải, vẫn là hai hệ thống RAID 1 chứa hệ điều hành và nhật ký của CA. Còn CSDL của CA được lưu trên hệ thống RAID 0+1. Cấu hình này mang lại tỉ lệ nhập/xuất dữ liệu cao hơn RAID 5 và thường được dùng bởi các CA cần đáp ứng nhu cầu xin cấp chứng chỉ lớn.
3.   Xác định thời gian hiệu lực của chứng chỉ
Mỗi chứng chỉ luôn có một khoảng thời gian hiệu lực nhất định gồm ngày giờ phát hành và ngày giờ hết hạn. Giá trị này là không thể thay đổi sau khi chứng chỉ được cấp. Việc xác định thời gian hiệu lực của chứng chỉ tại mỗi tầng trong hệ thống phân cấp CA là bước chính yếu trong quá trình thiết kế một hạ tầng PKI.
Đầu tiên là cần xác định thời gian hiệu lực của chứng chỉ được cấp cho các đối tượng đầu cuối như người dùng, máy tính, dịch vụ, thiết bị mạng trước. Lý do là vì CA không được phép cấp một chứng chỉ có thời hạn vượt quá thời gian hiệu lực của chứng chỉ của CA. Ví dụ, chứng chỉ của CA có thời hạn là 5 năm, thì chứng chỉ của người dùng phải có thời hạn là dưới 5 năm. Nếu không tuân theo nguyên tắc này thì dẫn đến chứng chỉ của người dùng tuy vẫn còn hiệu lực nhưng lại không thể sử dụng được do thời hạn của chứng chỉ của CA đã hết. Khuyến cáo thường được áp dụng là chứng chỉ của CA có thời hạn gấp đôi thời hạn tối đa của chứng chỉ mà nó cấp cho CA cấp dưới hoặc cho người dùng. Hình 3 dưới đây là ví dụ của một hệ thống CA phân cấp gồm 2 tầng với chứng chỉ được cấp cho người dùng có thời hạn tối đa là 5 năm (thực tế thường là 1 hoặc 2 năm), chứng chỉ của Policy/Issuing CA có thời hạn là 10 năm và 20 năm cho chứng chỉ của Root CA.
Hình 3 – Xác định thời gian hiệu lực của chứng chỉ của CA
Một khuyến cáo khác là nên làm mới (khôi phục lại thời hạn) chứng chỉ của CA khi thời gian hiệu lực của nó trôi qua được một nửa. Đối với cặp khóa công khai – bí mật đi kèm với chứng chỉ của CA thì có 2 phương án xử lý là:
  • Khi thời hạn hiệu lực trôi qua được một nửa thì làm mới lại chứng chỉ nhưng vẫn giữ nguyên cặp khóa cũ. Sau khi nửa thời hạn còn lại trôi qua thì cũng làm mới lại chứng chỉ nhưng kèm với cặp khóa mới.
  • Luôn đổi cặp khóa sau mỗi lần làm mới chứng chỉ. Ví dụ, nếu thời hạn của chứng chỉ là 10 năm thì cứ sau 5 năm sẽ đổi sang cặp khóa mới.
Ngoài ra, cũng không nên chọn chứng chỉ có thời hạn quá lâu vì sẽ làm tăng cơ hội để kẻ tấn công có thể tìm được khóa bí mật dựa trên khóa công khai và các mẫu dữ liệu được mã hóa bởi khóa bí mật. Thường thì chứng chỉ của Root CA không nên có thời hạn lâu hơn 20 năm.
4.   Chọn chiều dài cho khóa
Hạn chế lớn nhất khi xác định chiều dài cho khóa tại mỗi CA nằm ở các ứng dụng sử dụng chứng chỉ do CA cấp. Cụ thể, một số ứng dụng không hỗ trợ khóa có chiều dài lớn hơn một giá trị nào đó. Ví dụ, thiết bị Cisco VPN 3000 không hỗ trợ chứng chỉ của CA có chiều dài khóa lớn hơn 2048 bit.
Trong quá khứ, các khóa có chiều dài dưới 1024 bit (512, 768) từng bị phá mã thành công. Vì vậy mà nên chọn chiều dài cho khóa từ 1024 trở lên là an toàn.
5.   Xác định các điểm phát hành CRL và chứng chỉ của CA
Yêu cầu kỹ thuật cuối cùng cần được thỏa mãn khi thiết kế PKI là xác định các địa chỉ URL cho việc nhận về CRL, chứng chỉ của CA và các OCSP response.
Để xác định trạng thái thu hồi của chứng chỉ thì máy khách có thể sử dụng các URL được lưu trong trường CDP (nếu dùng CRL để kiểm tra) và extension AIA (nếu dùng OCSP kiểm tra). Ngoài ra, một số ứng dụng sử dụng danh sách thu hồi được lưu trên hệ thống tập tin cục bộ hoặc dùng các URL dẫn tới CRL và chứng chỉ của CA được lập trình cứng (hard-code) cho nó.
Tại mỗi CA, các giao thức sau có thể được dùng để định nghĩa các điểm phát hành mà máy khác sẽ truy cập tới khi cần tới chứng chỉ của CA và CRL:
  • HTTP: được dùng cho các điểm phát hành dùng cho nội bộ và bên ngoài. Ưu điểm của HTTP là thời gian trễ thấp từ lúc phát hành tới khi URL đó có thể được dùng. Sau khi phát hành một bản cập nhật của CRL hoặc chứng chỉ của CA bằng HTTP thì ngay lập tức ứng dụng đã có thể tải nó về. Ngoài ra, thì HTTP thường không bị firewall chặn và các máy chạy Windows (nằm trong AD DS hoặc không), MAC OS hay Unix đều dùng được URL dạng này.
  • LDAP: CRL hoặc chứng chỉ của CA được phát hành dùng LDAP URL sẽ hiện diện tại tất cả các domain controller trong forest. Điều này có hai bất lợi là:
    • Mất một khoảng thời gian để CRL và chứng chỉ của CA được sao chép  tới tất cả các domain controller trong forest. Thời gian chính xác phụ thuộc vào độ trễ của mạng và đặc biệt nếu sự sao chép diễn ra giữa các domain controller nằm ở các site khác nhau thì càng lớn.
    • Máy khách không nằm trong AD DS sẽ không thể sử dụng LDAP URL và nếu nó là URL đầu tiên trong danh sách thì phải mất 10 giây để có thể chuyển sang sử dụng URL tiếp theo.
Quyết định sử dụng giao thức nào phụ thuộc vào tần suất phát hành CRL, giao thức đó có được phép đi qua firewall mạng hay không, và hệ điều hành được hỗ trợ. Để độ trễ là thấp nhất, các URL nên được sẵn xếp để giao thức phổ biến nhất trong mạng được dùng để truyền tải CRL và chứng chỉ của CA nằm ở đầu danh sách trong extension CDP.
Người đăng:

Windows Server 2008 Phần 5

Phần 5 – Bảo mật cho hạ tầng khóa công khai (PKI)

Những biện pháp mà tổ chức có thể triển khai để đảm bảo an toàn cho các CA trong hệ thống được phân làm hai loại chính là:
  • Cấu hình cho CA
  • An toàn vật lý
Các biện pháp này có thể là giới hạn những group nào được phép đăng nhập cục bộ tại CA cho tới việc đặt CA ở những vị trí an toàn hay bảo vệ khóa bí mật của CA.

1.     Cấu hình cho CA

Các biện pháp để cấu hình CA sao cho an toàn bao gồm cấu hình cho dịch vụ Certificate Services và cấu hình cho hệ điều hành Windows Server 2008 làm CA, cụ thể:
  • Giảm tối đa số lượng vai trò đặt lên máy CA: nếu có thể thì không được kết hợp CA với các chức năng khác như domain controller, Exchange Server, v.v.. Càng nhiều vai trò đặt lên máy chủ thì càng khó để bảo vệ nó trước các loại tấn công khác nhau.
  • Sử dụng Security Configuration Wizard để khóa chặt CA: công cụ này sẽ nhận diện và cung cấp thông tin về các vai trò và dịch vụ được cài đặt trên máy CA, tắt các chức năng không cần thiết, áp dụng các cấu hình an toàn cho mạng, và các tùy chọn cho Registry để bảo mật cho các cơ chế xác thực, các thiết lập hệ thống, và các thiết lập kiểm kê (audit) mặc định. Xem thêm tại địa chỉ: http://technet.microsoft.com/en-us/library/cc754997.aspx
  • Kích hoạt tất cả các tùy chọn auditing cho CA: bằng cách này, mục Security Log trong Windows sẽ chứa tất cả các sự kiện liên quan tới hoạt động của Certificate Services như: sao lưu và khôi phục CSDL của CA, thay đổi cấu hình của CA, thay đổi thiết lập an ninh của CA, cấp phát, quản lý và thu hồi chứng chỉ, phát hành CRL, chạy hoặc dừng dịch vụ Active Directory Certificate Services, v.v.. để giúp người quản trị nhận biết được các sự cố về an ninh có thể đã và đang diễn ra.
  • Bật BitLocker Disk Encryption (BDE): tính năng này giúp mã hóa toàn bộ ổ đĩa của máy CA. Một ưu điểm của nó là ngăn chặn khả năng kẻ tấn công đánh cắp đĩa cứng và sử dụng đĩa cứng này trên máy tính khác. Lựa chọn tốt nhất để triển khai BDE cho CA là có chip TPM (Trusted Platform Module) trên bo mạch chủ của CA đó. Con chip này sẽ bảo vệ khóa SRK (Storage Root Key) được dùng để giải mã khóa VEK (Volume Encryption Key) là khóa bảo vệ cho ổ đĩa chứa hệ điều hành của CA. Xem thêm tại địa chỉ: http://msdn.microsoft.com/en-us/library/windows/hardware/gg487306.aspx
  • Giới hạn số lượng thành viên trong group Local Administrators: nếu triển khai CA sử dụng CSP dựa trên phần mềm thì khóa bí mật của CA được lưu ngay tại máy CA đó. Mặc định, tất cả thành viên của group Local Administrators có thể truy cập tới khóa bí mật này và xuất nó ra tập tin dạng PKCS #12. Vì vậy để giới hạn số user có thể truy cập tới khóa bí mật của CA thì cần giới hạn tối đa số thành viên được nằm trong group quản trị này.
  • Phân chia vai trò hợp lý (tuân theo quy định của Common Criteria): cần phải đảm bảo rằng một người không được nắm giữ nhiều vai trò mà chỉ được đảm nhận một trong bốn vai trò là CA Administrator, Certificate Manager, Auditor, Backup Operator. Nếu gán nhiều hơn một vai trò sẽ dẫn đến người dùng bị tước đoạt mọi thao tác quản lý CA.

2.     An toàn vật lý

Dưới đây là một vài biện pháp để bảo đảm an toàn về mặt vật lý cho các máy CA.
  • Đặt các offline CA tại vị trí an toàn: phòng máy chủ nơi chứa các offline CA cần được kiểm soát và giới hạn chặt chẽ việc truy cập. Chỉ cho những cá nhân với vai trò là CA Administrator được phép vào phòng này và ghi nhận tất cả những hành vi cố gắng truy cập khác.
  • Đặt các máy CA trong khung chứa an toàn: để mở các khung chứa máy chủ yêu cầu người dùng cung cấp mã PIN. Một vài mẫu có chức năng ghi nhận tất cả các lần truy cập tới khung chứa và gửi các thông tin này quá kết nối serial.
  • Đặt các linh kiện phần cứng của offline CA ở nơi tách biệt và an toàn: một vài công ty không gắn các ổ cứng cho máy CA mà đặt chúng ở một nơi khác làm cho kẻ tấn công phải tiếp cận được cả máy chủ và ổ cứng để có thể truy cập được vào offline CA.

3.     Bảo vệ khóa bí mật của CA

Nếu có được khóa bí mật của CA thì ai đó có thể dựng lên một máy CA với cùng cặp khóa công khai – bí mật đã biết để mạo nhận rồi cấp phát các chứng chỉ giả nhưng sẽ được tin cậy bởi tất cả người dùng trong PKI. Tệ hơn là nếu lấy được khóa bí mật của CA thì kẻ tấn công có thể tạo nên các CA thứ cấp được tin cậy bởi tất cả các đối tượng trong tổ chức.
Các biện pháp cần thực hiện để bảo vệ khóa bí mật của CA phụ thuộc vào cách thức lưu trữ khóa đó. Đối với CA chạy trên Windows Server 2008 thì có ba khả năng là:
  • Lưu khóa bí mật trong kho chứa cục bộ của máy CA
  • Lưu khóa bí mật trên thiết bị xác thực hai yếu tố, ví dụ như thẻ thông minh
  • Lưu khóa bí mật trên mô-đun bảo mật phần cứng (HSM)
Người đăng:

Windows Server 2008 Phần 6.1

Phần 6 – Triển khai một cấu trúc CA phân cấp

Phần này sẽ đi vào triển khai một hệ thống CA phân cấp tuân theo mô hình đã được thiết kế. Việc triển khai luôn bắt đầu tại Root CA và kế đến là các Subordinate CA ngay dưới nó. Quá trình tiếp diễn cho tới khi tất cả các CA trong hệ thống được cài đặt xong. Các chỉ dẫn ở đây có thể được dùng để xây dựng một cấu trúc chỉ với một CA duy nhất hoặc có nhiều hơn hai tầng.
Đầu tiên cần làm quen với các tập tin cấu hình cho CA được áp dụng cho bất kỳ hệ thống CA nào. Sao lưu những tập tin này sẽ giúp khôi phục nhanh chóng các thiết lập của CA trong tình huống hệ thống CA có sự cố.

1.   Các tập tin cấu hình CA

Trong suốt quá trình cài đặt CA, có các tập tin (dạng script) sau được dùng để lưu trữ và tạo nên cấu hình cho CA:
  • CAPolicy.inf: cung cấp thông tin cấu hình cho dịch vụ Certificate Services. Nó được đọc trong quá trình khởi tạo ban đầu cho CA và bất kỳ khi nào chứng chỉ của CA được làm mới lại.
  • Tập tin được dùng trước quá trình cài đặt CA (Pre-installation script): khi cài đặt các Subordinate CA, ta phải tự tay cài đặt chứng chỉ của Root CA để Subordinate CA xem nó là một Root CA đáng tin cậy. Ngoài ra, có thể cần phải cài đặt chứng chỉ của các Subordinate CA cùng với CRL của Root CA và của Subordinate CA để cho phép kiểm tra trạng thái thu hồi của chứng chỉ.
  • Tập tin được dùng sau quá trình cài đặt CA (Post-installation script): sau khi dịch vụ Certificates Services được cài đặt, việc cấu hình được hoàn tất bằng một vài câu lệnh certutil.
Dưới đây là các chi tiết và khuyến cáo cho cấu hình của mỗi loại tập tin.
CAPolicy.inf
Tập tin này chứa các thiết lập dành riêng cho Root CA cũng như các thiết lập ảnh hưởng tới tất cả các CA khác trong hệ thống. Nó chứa các thông tin sau cho Root CA:
  • Các điểm phát hành CRL
  • Các điểm phát hành chứng chỉ của Root CA
  • Mục đích sử dụng của các chứng chỉ được cấp bởi Root CA
  • Thời gian hiệu lực và chiều dài khóa khi chứng chỉ của Root CA được làm mới
Các thiết lập sau trong tập tin CAPolicy.inf có thể được áp dụng cho cả Root và các Subordinate CA:
  • CPS (Certification Practice Statement): thường được áp đặt tại:
    • Root CA trong cấu trúc CA đơn cấp
    • Policy/Issuing CA trong cấu trúc CA ha tầng
    • Các Policy CA trong cấu trúc CA ba tầng
  • Khoảng thời gian phát hành Base CRL
  • Khoảng thời gian phát hành Delta CRL
  • Các basic constraint: cho biết số lượng tối đa các chứng chỉ của CA nằm bên dưới một CA khác được nghĩa trong tập tin CAPolicy.inf. Một basic constraint cũng chỉ ra rằng chứng chỉ được cấp cho CA hay đối tượng đầu cuối.
Tạo tập tin CAPolicy.inf
Mặc định tập tin CAPolicy.inf không có sẵn khi cài đặt Windows Server 2008 nên ta phải tự tạo và đặt nó trong thư mục %Windir%. Và khi cài đặt Certificate Servives, hệ điều hành sẽ áp dụng các thiết lập được định nghĩa trong tập tin này.
Dưới đây là nội dung mẫu cho tập tin CAPolicy.inf
[Version]
Signature= “$Windows NT$”
[PolicyStatementExtension]
Policies = LegalPolicy
Critical = 0
[LegalPolicy]
OID = 1.3.6.1.4.1.311.21.43
Notice = “Legal policy statement text.”
URL = http://www.example.com/certdata/cps.asp
[AuthorityInformationAccess]
Empty = true ; Chỉ cần thiết cho Windows Server 2003
;URL = http://%1/Public/My CA.crt
;URL = file://\\%1\Public\My CA.crt
Critical = true
[CRLDistributionPoint]
Empty = true; Chỉ cần thiết cho Windows Server 2003
;URL = http://%1/Public/My CA.crl
;URL = file://\\%1\Public\My CA.crl
Critical = true
[EnhancedKeyUsageExtension]
OID = 1.3.6.1.4.1.311.21.6 ; szOID_KP_KEY_RECOVERY_AGENT
OID = 1.3.6.1.4.1.311.10.3.9 ; szOID_ROOT_LIST_SIGNER
OID = 1.3.6.1.4.1.311.10.3.1 ; szOID_KP_CTL_USAGE_SIGNING
Critical = false
[basicconstraintsextension]
pathlength = 3
critical=true
[certsrv_server]
renewalkeylength=2048
RenewalValidityPeriodUnits=20
RenewalValidityPeriod=years
CRLPeriod = days
CRLPeriodUnits = 2
CRLDeltaPeriod = hours
CRLDeltaPeriodUnits = 4
LoadDefaultTemplates=0
Các phần trong tập tin CAPolicy.inf
[Version]
Phần này cho biết rằng nội dung của tập tin INF này được định dạng theo Microsoft Windows NT. Phần này phải có cho cả Root và Subordinate CA. Theo nội dung mẫu ở trên thì nó chỉ chứa duy nhất một dòng là: Signature= “$Windows NT$”
[PolicyStatementExtension]
Định nghĩa các chính sách chứng chỉ và CPS của CA. Trong cấu trúc CA đơn cấp thì phần này có ở Root CA, trong cấu trúc CA hai tầng thì nó có ở mỗi Issuing CA và trong cấu trúc CA ba tầng thì nó có ở các Policy CA tại tầng thứ hai. Phần này thường bao gồm nhiều mục con, mỗi mục con tương ứng với một chính sách chứng chỉ của CA. Như nội dung mẫu ở trên thì có một mục con là [LegalPolicy] và trong đó cần định nghĩa tối thiểu ba thiết lập sau:
  • Object Identifier (OID): là một chuỗi số nhận dạng CPS của CA. Dạng công khai (public) của OID được dùng khi tổ chức có các ứng dụng PKI mà giao tiếp với các tổ chức khác. Public OID là duy nhất trên Internet và có thể được cấp miễn phí từ IANA, hoặc mua từ ANSI hoặc do tổ chức quản lý OID của mỗi nước cấp. Ta cũng có thể tạo OID dạng riêng tư (private) dựa trên GUID của forest khi không có nhu cầu dùng các ứng PKI để liên lạc với các tổ chức khác.
  • Notice: cho biết tiêu đề của CPS chứ không hiện bất kỳ nội dung chi tiết nào trong CPS.
  • URL: có thể chứa nhiều URL (thường có dạng HTTP) cùng dẫn tới một CPS.
Lưu ý là AD DS schema chỉ cho phép dung lượng tối đa là 4096 byte để lưu trữ các thông tin về CPS ở trên (OID, Notice, URL). Vì vậy mà số lượng các chính sách chứng chỉ được nêu trong chứng chỉ của CA sẽ bị giới hạn.
[AuthorityInformationAccess] và [CRLDistributionPoint]
Vì Root CA tự cấp chứng chỉ cho chính nó và Root CA thường được tin cậy bằng cách thêm chứng chỉ của nó vào kho chứa Trusted Store tại các máy khách nên hầu hết các ứng dụng sẽ bỏ qua việc kiểm tra trạng thái thu hồi của chứng chỉ của Root CA. Vì vậy mà các extension AIA (chứa URL dẫn tới chứng chỉ của CA) và CDP (chứa URL dẫn tới CRL) sẽ không cần xuất hiện trong chứng chỉ của Root CA.
Trong Windows Server 2003, ta cần phải thêm các dòng sau vào tập tin CAPolicy.inf để chặn không cho hai extension AIA và CDP có mặt trong chứng chỉ của Root CA.
[AuthorityInformationAccess]
Empty = true
[CRLDistributionPoint]
Empty = true
Còn khi cài Root CA trên Windows Server 2008 thì mặc định chứng chỉ của Root CA được tạo mà không có hai extension AIA và CDP.
[EnhancedKeyUsageExtension]
Phần này sẽ hạn chế các loại chứng chỉ mà một CA có thể cấp phát. Ví dụ, nếu muốn một CA chỉ cấp các chứng chỉ cho mục đích Client Authentication, Server Authentication và Secure Email thì ta sẽ định nghĩa như sau:
[EnhancedKeyUsageExtension]
OID = 1.3.6.1.5.5.7.3.2 ; Client Authentication
OID = 1.3.6.1.5.5.7.3.1 ; Server Authentication
OID = 1.3.6.1.5.5.7.3.4 ; Secure Email
[BasicConstraintsExtension]
Phần này cho phép chỉ định chiều dài đường dẫn để giới hạn độ sâu của cấu trúc phân cấp CA. Ví dụ, nếu muốn ngăn không cho cài thêm một tầng mới bên dưới CA hiện tại thì ta cần định nghĩa cho extension Basic Constraints như sau:
[BasicConstraintsExtension]
pathlength = 0
[certsrv_server]
Phần này có các mục áp dụng cho tất cả các CA trong hệ thống, bao gồm:
  • RenewalKeyLength: chỉ định chiều dài của khóa bí mật và khóa công khai của CA khi chứng chỉ của CA được làm mới lại. Trừ trường hợp cần thiết phải thay đổi chiều dài khóa của CA tại thời điểm làm mới lại chứng chỉ của CA thì giá trị này nên giống với giá trị được gán cho chiều dài khóa của CA trong quá trình cài đặt ban đầu.
  • RenewalValidityPeriod: đơn vị tính cho khoảng thời gian hiệu lực của chứng chỉ. Các giá trị được phép là years, weeks, days nhưng ở đây thường chọn là years.
  • RenewalValidityPeriodUnits: số lượng đơn vị tính cho khoảng thời gian hiệu lực của chứng chỉ. Ví dụ, nếu muốn chứng chỉ của CA có thời hạn là 15 năm thì mục này sẽ có giá trị là 15 và mục RenewalValidityPeriod sẽ có giá trị là years.
  • CRLPeriod: đơn vị tính cho khoảng thời gian phát hành CRL. Các giá trị được chấp nhận là days, years, weeks, hours.
  • CRLPeriodUnits: số lượng đơn vị tính cho khoảng thời gian phát hành CRL. Giá trị mặc định là 7.
  • CRLOverlapUnits: kết hợp với mục CRLOverlapPeriod để chỉ định sau bao lâu thì gia hạn khoảng thời gian hiệu lực của base CRL.
  • CRLOverlapPeriod: đơn vị tính cho khoảng thời gian mà thời gian hiệu lực của base CRL sẽ được gia hạn.
  • CRLDeltaPeriod: đơn vị tính cho khoảng thời gan phát hành delta CRL. Các giá trị được chấp nhận là days, years, weeks, hours.
  • CRLDeltaPeriodUnits: số lượng đơn vị tính cho khoảng thời gian phát hành delta CRL. Giá trị mặc định là 1.
  • CRLDeltaOverlapPeriod: đơn vị tính cho khoảng thời gian mà thời gian hiệu lực của delta CRL sẽ được gia hạn.
  • CRLDeltaOverlapUnits: kết hợp với mục CRLDeltaOverlapPeriod để chỉ định sao bao lâu thì gia hạn khoảng thời gian hiệu lực của delta CRL.
  • ClockSkewMinutes: một yếu tố an toàn cho các vấn đề về đồng bộ thời gian. Base và delta CRL được phát hành với thời điểm bắt đầu bằng thời điểm hiện tại trừ cho số phút được chỉ định ở mục này. Ví dụ, nếu thời gian hiện tại là 10:00 và giá trị mặc định của mục này là 10 phút thì một base hoặc delta CRL mới sẽ được phát hành với thời điểm là 9:50.
Windows Server 2008 giới thiệu thêm hai mục tùy chọn mới cho tập tin CAPolicy.inf, gồm:
  • LoadDefaultTemplates: có trong Service Pack 1 của Windows Server 2008. Nếu được gán giá trị là 0 thì thiết lập này sẽ ngăn cản việc phát hành các mẫu chứng chỉ mặc định sau khi cài đặt xong một Enterprise CA (có thể là Root hoặc Subordinate CA).
  • DiscreteSignatureAlgorithm: nếu được gán giá trị là 1 thì định dạng chữ ký PKCS#1 V2.1 sẽ được hỗ trợ cho cả chứng chỉ chứng chỉ của CA và các yêu cầu cấp chứng chỉ cho CA. Nếu tùy chọn này được triển khai tại Root CA thì chứng chỉ cho chính Root CA này sẽ bao gồm định dạng chữ ký PKCS#1 V2.1. Còn nếu được áp dụng tại Subordinate CA thì trong yêu cầu cấp chứng chỉ mà CA này tạo ra sẽ bao gồm định dạng chữ ký PKCS#1 V2.1.
Xem thêm về định dạng chữ ký này trong tài liệu về PKCS #1 (chuẩn mật mã của hãng RSA)  ở đây: http://www.rsa.com/rsalabs/node.asp?id=2125

Pre-Installation Script

Trong hệ thống phân cấp CA có nhiều hơn hai tầng thì các pre-installation script sau cần được thực thi để chuẩn bị cho việc cài đặt Subordinate CA:
  • Phát hành các CRL, chứng chỉ của Root và tất cả Subordinate CA mà tồn tại giữa Subordinate CA mới và Root CA tới kho chứa cục bộ của Subordinate CA mới này.
  • Phát hành các CRL, chứng chỉ của Root và tất cả Subordinate CA mà tồn tại giữa Subordinate CA mới và Root CA tới AD DS.
Phát hành các chứng chỉ và CRL tới kho chứa cục bộ
Phải là thành viên của group Local Administrator để thực hiện được bước này. Số lượng các chứng chỉ và CRL cần được cài phụ thuộc vị trí của Subordinate CA mới trong cấu trúc phân cấp CA:
  • Nếu CA mới này nằm tại tầng hai thì chỉ cần cài chứng chỉ và CRL của Root CA.
  • Nếu CA mới nằm tại tầng ba hoặc thấp hơn thì phải cài tất cả chứng chỉ và CRL của CA trong chuỗi chứng chỉ mà nằm trên CA mới này.
Hai câu lệnh dưới đây sẽ lần lượt thêm chứng chỉ và CRL của Root CA tới kho chứa Trusted Root CA.
certutil -addstore -f Root RootCACertificateFile.crt,
certutil -addstore -f Root RootCACRLFile.crl,
Còn hai câu lệnh dưới đây sẽ lần lượt thêm chứng chỉ và CRL của Subordinate CA cấp trên tới kho chứa Intermediate CA.
certutil -addstore -f CA SubCACertificateFile.crt,
certutil -addstore -f CA SubCACRLFile.crl,
(nếu tên tập tin chứng chỉ và CRL chứa khoảng trắng thì cần đặt tên đó giữa hai dấu nháy kép).
Phát hành các chứng chỉ và CRL tới AD DS
Việc đẩy các chứng chỉ và CRL của CA tới AD DS giúp cho tất cả các máy tính nằm trong domain sẽ tự động cập nhật các chứng chỉ và CRL này vào kho chứa cục bộ của chúng. Quá trình tải về tự động này được thực hiện thông qua Group Policy.
Dưới đây là ba câu lệnh lần lượt đẩy chứng chỉ của Root, Subordinate CA và CRL vào AD DS:
certutil -dspublish -f RootCACertificateFile.crt RootCA
certutil –dspublish -f SubCACertificateFile.crt SubCA
certutil –dspublish -f CACRLFile.crl
Hình 27 cho biết vị trí của các chứng chỉ của CA và CRL khi chúng được đẩy tới AD DS, theo đó thì:
  • Tất cả chứng chỉ của Root và Subordinate CA được đưa tới container CN=AIA, CN=Public Key Services, CN=Services, CN=Configuration, DC=ForestRootDomain
  • Các chứng chỉ của Root CA được đưa tới container CN=Certification Authorities, CN=Public Key Services, CN=Services, CN=Configuration, DC=ForestRootDomain
  • Các chứng chỉ của Enterprise CA được đưa tới container CN=NTAuthCertificates, CN=Public Key Services, CN=Services, CN=Configuration, DC=ForestRootDomain
  • Các CRL của mỗi CA được đưa tới các container con riêng biệt bên trong container CN=CDP, CN=Public Key Services, CN=Services, CN=Configuration, ForestRootDomain. Ví dụ, CRL của máy CA có NetBIOS name là FABINCCA01 sẽ được đưa vào bên trong container CN=FABINCCA01, CN=CDP, CN=Public Key Services, CN=Services, CN=Configuration, ForestRootDomain.
Ở đây, ForestRootDomain là distinguished name của forest root domain.

Post-Installation Script

Phần này sẽ mô tả một vài câu lệnh cấu hình có thể được đặt trong post-installation script.
Khai báo Configuration Naming Context
Mỗi một forest có duy nhất một kho chứa chính là Configuration NC để lưu trữ các thông tin cấu hình cho forest đó. Configuration NC sẽ được sao chép tới tất cả các domain controller trong forest và chứa các điểm phát hành chứng chỉ của CA và CRL. Việc khai báo Configuration NC là bước đầu tiên cần làm để tạo post-installation script.
Dùng lệnh sau để định nghĩa Configuration NC cho forest (thay ForestRootDomain bằng tên forest cho phù hợp).
certutil -setreg CA\DSConfigDN CN=Configuration,ForestRootDomain
Khai báo các khoảng thời gian phát hành CRL
Các thiết lập này được định nghĩa giống nhau trong cả post-installation script và tập tin CAPolicy.inf. Nhưng nếu định nghĩa trong CAPolicy.inf thì chúng chỉ được đọc tại thời điểm cài đặt CA và trong suốt quá trình làm mới chứng chỉ của CA. Trái lại, post-installation script có thể được thực thi vào bất kỳ lúc nào để khôi phục lại thiết lập cấu hình này cho CA.
Thêm các dòng sau vào post-installation script để đảm bảo Certificate Services áp dụng các thiết lập về khoảng thời gian phát hành CRL đúng như mong muốn.
certutil -setreg CA\CRLPeriodUnits 26
certutil -setreg CA\CRLPeriod “Weeks”
certutil -setreg CA\CRLOverlapUnits 2
certutil -setreg CA\CRLOverlapPeriod “Weeks”
certutil -setreg CA\CRLDeltaPeriodUnits 0
certutil -setreg CA\CRLDeltaPeriod “days”
Ở ví dụ này, một base CRL mới sẽ được phát hành sau mỗi 26 tuần với thời gian trùng lắp là 2 tuần và không dùng các delta CRL do thời gian phát hành của nó là 0 ngày.
Khai báo các điểm phát hành
Các điểm phát hành chứng chỉ của CA và CRL có thể được cấu hình trong hộp thoại Properties của CA (xem Hình 1) hoặc sử dụng câu lệnh certutil. Ví dụ, câu lệnh dưới đây sẽ định nghĩa cho extension CDP:
certutil -setreg CA\CRLPublicationURLs “1:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n2:http://www.fabrikam.com/CertData/%%3%%8%%9.crl\n10:ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10″
Và câu lệnh dưới đây sẽ định nghĩa cho extension AIA:
certutil -setreg CA\CACertPublicationURLs “1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:http://www.fabrikam.com/CertData/%%1_%%3%%4.crt\n2:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%11″
 
Hình 1 – Định nghĩa các điểm phát hành CRL
Khai báo khoảng thời gian hiệu lực cho các chứng chỉ được cấp
Hai câu lệnh certutil trong ví dụ dưới đây sẽ thiết lập khoảng thời gian hiệu lực là 10 năm cho các chứng chỉ được cấp phát.
certutil -setreg CA\ValidityPeriodUnits 10
certutil -setreg CA\ValidityPeriod “Years”
Người đăng:
Đăng ký: Nhận xét (Atom)