Xây dựng hạ tầng PKI trên nền Windows Server 2008 – Phần 6.1


Xem thêm:
Xây dựng hạ tầng khóa công khai (PKI) trên nền Windows Server 2008 – Phần 1
Xây dựng hạ tầng khóa công khai (PKI) trên nền Windows Server 2008 – Phần 2
Xây dựng hạ tầng khóa công khai (PKI) trên nền Windows Server 2008 – Phần 3
Xây dựng hạ tầng khóa công khai (PKI) trên nền Windows Server 2008 – Phần 4.1
Xây dựng hạ tầng khóa công khai (PKI) trên nền Windows Server 2008 – Phần 4.2
Xây dựng hạ tầng khóa công khai (PKI) trên nền Windows Server 2008 – Phần 5
Xây dựng hạ tầng khóa công khai (PKI) trên nền Windows Server 2008 – Phần 6.1
Xây dựng hạ tầng khóa công khai (PKI) trên nền Windows Server 2008 – Phần 6.2

————-

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”

–manthang

6 comments

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s