it-swarm-vi.com

Danh sách kiểm tra về việc xây dựng Cơ quan cấp chứng chỉ gốc & trung gian ngoại tuyến (CA)

Microsoft cho phép CA sử dụng Mật mã thế hệ tiếp theo (CNG) và tư vấn về các vấn đề không tương thích cho các khách hàng không hỗ trợ bộ này.

Dưới đây là hình ảnh của cài đặt mật mã mặc định cho CA 2008 R2. Máy này là một CA độc lập không được kết nối miền:

Default Cryptography settings

Dưới đây là các nhà cung cấp được cài đặt. Các nhà cung cấp CNG được đánh dấu bằng dấu #

enter image description here

Mục đích của tôi là có một Root-CA ngoại tuyến có mục đích chung và sau đó một số CA trung gian phục vụ một mục đích cụ thể (chỉ MSFT so với Unix vs SmartCards, v.v.)

Các cài đặt lý tưởng cho Chứng chỉ gốc có thời hạn sử dụng là 5, 10 và 15 năm là gì?

  1. CSP
  2. Giấy chứng nhận ký
  3. Độ dài ký tự chính

Vì đây là RootCA, nên bất kỳ tham số nào cũng ảnh hưởng đến CPU (thiết bị di động) có công suất thấp

25
goodguys_activate

Lưu ý: Đây là một bản tóm tắt (rất rất dài) về các khuyến nghị và hành động khác nhau mà Microsoft, NIST và các chuyên gia về mật mã và PKI được tôn trọng khác đã nói. Nếu bạn thấy một cái gì đó yêu cầu sửa đổi dù là nhỏ nhất, hãy cho tôi biết.

Trước khi tôi định cấu hình CA và chương trình con của nó, bạn nên biết rằng mặc dù CryptoAPI của MSFT yêu cầu root tự ký, một số phần mềm không phải MSFT có thể theo RFC 3280 và cho phép bất kỳ CA nào là root đáng tin cậy cho mục đích xác thực. Một lý do có thể là phần mềm không phải MSFT thích độ dài khóa thấp hơn.

Dưới đây là một số lưu ý và hướng dẫn cấu hình về việc thiết lập CA ROOT và Dự bị:

Lưu trữ khóa riêng của CA

Độ dài khóa

Hết hạn

Thuật toán & Độ dài khóa có thể ảnh hưởng đến thời gian bạn muốn chứng chỉ có hiệu lực trong bao lâu, bởi vì chúng xác định hiệu quả thời gian một kẻ tấn công có thể bẻ khóa, tức là mật mã càng mạnh, bạn càng có thể chuẩn bị chứng chỉ có hiệu lực trong bao lâu

Một cách tiếp cận là thiết lập thời gian hiệu lực dài nhất mà bạn sẽ yêu cầu đối với chứng chỉ thực thể cuối, tăng gấp đôi cho ca phát hành và sau đó nhân đôi lần nữa cho ca gốc (trong hai tầng). Với phương pháp này, bạn sẽ thường xuyên gia hạn mỗi chứng chỉ ca khi đạt được một nửa thời gian tồn tại - điều này là do ca không thể cấp giấy chứng nhận có thời hạn sử dụng sau chính chứng chỉ ca.

Các giá trị phù hợp chỉ có thể thực sự được xác định bởi chính sách bảo mật và tổ chức của bạn, nhưng thông thường, một ca gốc sẽ có thời hạn chứng chỉ là 10 hoặc 20 năm.

Nếu bạn lo ngại về tính tương thích, hãy đặt ngày hết hạn bên dưới năm 2038. Điều này là do các hệ thống mã hóa dữ liệu dưới dạng giây kể từ ngày 1 tháng 1 năm 1970 qua số nguyên 32 bit đã ký. Đọc thêm về vấn đề này tại đây.

Chọn Hash

Đáng chú ý:

  • Windows 2003 và Máy khách XP có thể cần một bản vá cho Thuật toán SHA2 bao gồm SHA256, SHA384 và SHA512. Xem thêm thông tin kỹ thuật

  • Authenticode và S/MIME với băm SHA2 không được hỗ trợ trên XP hoặc 2003

  • "Về hỗ trợ SHA-224, SHA-224 cung cấp bảo mật ít hơn SHA-256 nhưng có cùng số lượng tài nguyên. Ngoài ra, SHA-224 thường không được sử dụng bởi các giao thức và ứng dụng. Các tiêu chuẩn Suite B của NSA cũng không bao gồm nó." nguồn

  • "Không sử dụng bộ SHA2 ở bất kỳ đâu trong hệ thống phân cấp CA nếu bạn dự định có XP tin tưởng chứng chỉ, xác thực chứng chỉ, sử dụng chứng chỉ trong xác thực chuỗi hoặc nhận chứng chỉ từ CA. Mặc dù XP SP3 cho phép xác thực các chứng nhận sử dụng SHA2 trong hệ thống phân cấp CA và KB 968730 cho phép đăng ký hạn chế các chứng chỉ được ký bởi CA bằng SHA2, bất kỳ việc sử dụng các chữ ký rời rạc nào đều bị loại bỏ = XP hoàn toàn. "( nguồn )

Chọn nhà cung cấp mật mã

Kích hoạt tạo số sê-ri ngẫu nhiên

Kể từ năm 2012, điều này là bắt buộc nếu bạn sử dụng MD5 làm hàm băm. Vẫn là ý tưởng hay nếu SHA1 trở lên được sử dụng. Đồng thời xem Windows 2008R2 này "làm thế nào" để biết thêm thông tin.

Tạo Tuyên bố thực hành chứng chỉ

Một tuyên bố thực hành chứng chỉ là một tuyên bố về các thực tiễn mà CNTT sử dụng để quản lý các chứng chỉ mà nó phát hành. Nó mô tả cách chính sách chứng chỉ của tổ chức được diễn giải trong bối cảnh kiến ​​trúc hệ thống của tổ chức và các quy trình hoạt động của nó. Bộ phận CNTT có trách nhiệm chuẩn bị và duy trì tuyên bố thực hành chứng chỉ. ( nguồn )

LƯU Ý: Trong một số trường hợp, chẳng hạn như khi chữ ký số được sử dụng trên các hợp đồng ràng buộc, tuyên bố thực hành chứng chỉ cũng có thể được coi là tuyên bố pháp lý về mức độ bảo mật được cung cấp và các biện pháp bảo vệ được sử dụng để thiết lập và duy trì mức độ bảo mật .

Để được hỗ trợ viết một tuyên bố CPS, đây là "Trợ giúp công việc" do Microsoft sản xuất

Cách thực hành tốt nhất: Mặc dù có thể đưa văn bản dạng tự do vào trường này (xem notice bên dưới), giải pháp lý tưởng là sử dụng URL. Điều này cho phép chính sách được cập nhật mà không cần cấp lại chứng chỉ, nó cũng ngăn chặn sự phình to không cần thiết của cửa hàng chứng chỉ.

[LegalPolicy]
OID = 1.3.6.1.4.1.311.21.43
Notice = "Legal policy statement text"
URL = "http://www.example.Microsoft.com/policy/isspolicy.asp"

Chính sách chứng chỉ

Còn được gọi là chính sách phát hành hoặc chính sách bảo đảm (trong MSFT), đây là chính sách tự xác định OID mô tả mức độ tin cậy mà người ta nên đưa vào chứng chỉ của bạn (cao, trung bình, thấp, v.v.) . Xem câu trả lời StackExchange này để biết cách sử dụng đúng trường này.

Đảm bảo Chính sách ứng dụng và Chính sách EKU khớp

Chính sách ứng dụng là một quy ước tùy chọn của Microsoft. Nếu bạn đang cấp chứng chỉ bao gồm cả chính sách ứng dụng và tiện ích mở rộng EKU, hãy đảm bảo rằng hai tiện ích mở rộng chứa định danh đối tượng giống hệt nhau.

Kích hoạt kiểm tra CRL

Thông thường, Windows Server 2003 CA sẽ luôn kiểm tra việc thu hồi trên tất cả các chứng chỉ trong hệ thống phân cấp PKI (ngoại trừ chứng chỉ CA gốc) trước khi cấp chứng chỉ thực thể cuối. Để tắt tính năng này, sử dụng lệnh sau trên CA, sau đó khởi động lại dịch vụ CA:

 certutil –setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE  

Điểm phân phối CRL

Hướng dẫn đặc biệt cho các CA gốc

  • Đây là tùy chọn trong Root CA và nếu được thực hiện không chính xác nó có thể lộ khóa riêng của bạn .

  • Tất cả các ấn phẩm CRL được thực hiện thủ công từ RootCA ngoại tuyến đến tất cả các CA phụ khác. Một cách khác là sử dụng cáp âm thanh để hỗ trợ giao tiếp một chiề từ Root đến Sub CA

  • Hoàn toàn có thể chấp nhận được khi Root CA phát hành các vị trí CRL khác nhau cho mỗi chứng chỉ được cấp cho các CA cấp dưới.

  • Có CRL ở gốc là cách tốt nhất nếu hai PKI tin tưởng lẫn nhau và ánh xạ chính sách được thực hiện. Điều này cho phép giấy chứng nhận bị thu hồi.

Làm cho CRL "đúng" là khá quan trọng vì tùy thuộc vào từng ứng dụng để thực hiện kiểm tra CRL. Ví dụ, đăng nhập thẻ thông minh trên bộ điều khiển miền luôn thực thi kiểm tra hủy bỏ và sẽ từ chối sự kiện đăng nhập nếu kiểm tra hủy bỏ không thể được thực hiện hoặc thất bại.

Lưu ý Nếu bất kỳ chứng chỉ nào trong chuỗi không thể được xác thực hoặc bị thu hồi, toàn bộ chuỗi sẽ đảm nhận trạng thái của một chứng chỉ đó.

  • Một CA gốc tự ký không nên liệt kê bất kỳ CDP nào. Hầu hết các ứng dụng windows không bật cờ CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT và do đó bỏ qua CDP ( đây là chế độ xác thực mặc định ). Nếu cờ được bật và CDP trống cho chứng chỉ gốc tự ký, không có lỗi nào được trả về.

  • Không sử dụng HTTPS và LDAPS. Các URL này không còn được hỗ trợ làm tham chiếu điểm phân phối. Lý do là các URL HTTPS và LDAPS sử dụng các chứng chỉ có thể bị thu hồi hoặc không. Quá trình kiểm tra thu hồi có thể dẫn đến các vòng lặp hủy bỏ khi sử dụng URL HTTPS hoặc LDAPS. Để xác định xem chứng chỉ có bị thu hồi hay không, phải lấy CRL. Tuy nhiên, CRL không thể được truy xuất trừ khi trạng thái hủy bỏ của các chứng chỉ được sử dụng bởi HTTPS hoặc LDAPS được xác định.

  • Cân nhắc sử dụng HTTP thay vì LDAP- Mặc dù AD DS cho phép xuất bản CRL cho tất cả các bộ điều khiển miền trong rừng, triển khai HTTP thay vì LDAP để xuất bản thông tin hủy bỏ. Chỉ HTTP mới cho phép sử dụng ETagCache-Control: Max-age tiêu đề cung cấp hỗ trợ tốt hơn cho proxy và thông tin thu hồi kịp thời hơn. Ngoài ra, HTTP cung cấp hỗ trợ không đồng nhất tốt hơn vì HTTP được hầu hết các máy khách Linux, UNIX và thiết bị mạng hỗ trợ.

  • Một lý do khác để không sử dụng LDAP là vì cửa sổ thu hồi nhỏ hơn. Khi sử dụng AD LDAP để sao chép thông tin CA, cửa sổ hủy bỏ không thể ít hơn thời gian để tất cả các trang web trong AD nhận được bản cập nhật CA. Thông thường, việc sao chép này có thể mất tới 8 giờ ... tức là 8 giờ cho đến khi quyền truy cập của người dùng thẻ thông minh bị thu hồi. 'Todo: thời gian làm mới CRL được đề xuất mới là: ????? `

  • Làm cho tất cả các URL có sẵn cao (còn gọi là không bao gồm LDAP cho các máy chủ bên ngoài). Windows sẽ làm chậm quá trình xác thực trong tối đa 20 giây và thử lại kết nối không thành công liên tục ít nhất là thường xuyên cứ sau 30 phút. Tôi nghi ngờ rằng Tìm nạp trước sẽ khiến điều này xảy ra ngay cả khi người dùng không tích cực sử dụng trang web.

  • Theo dõi kích thước CRL của bạn. Nếu đối tượng CRL quá lớn đến mức CryptoAPI không thể tải xuống đối tượng trong ngưỡng hết thời gian tối đa được phân bổ, một lỗi hủy bỏ ngoại tuyến của hồi quy được trả về và quá trình tải xuống đối tượng bị chấm dứt.

Lưu ý: Phân phối CRL qua HTTP với Hỗ trợ ETAG có thể gây ra sự cố với IE6 khi sử dụng Windows 2003/IIS6, trong đó kết nối TCP liên tục được đặt lại.

  • (Tùy chọn) Kích hoạt CRL mới nhất : Tiện ích mở rộng không quan trọng này liệt kê các nhà phát hành và địa điểm để truy xuất các CRL delta. Nếu thuộc tính CRL tươi nhất của CRL không có trong CRL cũng như trong chứng chỉ, thì CRL cơ sở sẽ được coi là CRL thông thường, không phải là một phần của cặp CRL/delta CRL cơ sở.

Microsoft CA không đưa tiện ích mở rộng CRL mới nhất vào các chứng chỉ được cấp. Tuy nhiên, có thể thêm tiện ích mở rộng CRL tươi nhất vào một chứng chỉ được cấp. Bạn sẽ phải viết mã để thêm nó vào yêu cầu, viết mô-đun chính sách tùy chỉnh hoặc sử dụng certutil –setextension theo yêu cầu chờ xử lý. Để biết thêm thông tin về đăng ký chứng chỉ nâng cao, hãy xem tài liệu Đăng ký và quản lý chứng chỉ nâng cao của Mt trên trang web của Microsoft

Cảnh báo Nếu CRL delta được bật tại CA, cả CRL cơ sở và CRL delta phải được kiểm tra để xác định trạng thái hủy bỏ chứng nhận. Nếu một trong hai hoặc cả hai không khả dụng, công cụ chuỗi sẽ báo cáo rằng trạng thái hủy bỏ không thể được xác định và một ứng dụng có thể từ chối chứng chỉ.

Định cỡ và bảo trì CRL (Phân vùng CRL)

CRL sẽ tăng 29 byte cho mỗi chứng chỉ bị thu hồi. Theo đó, chứng chỉ bị thu hồi sẽ bị xóa khỏi CRL khi chứng chỉ đến ngày hết hạn ban đầu.

Vì việc gia hạn chứng chỉ CA khiến CRL mới/trống được tạo, CA phát hành có thể xem xét gia hạn CA bằng khóa mới mỗi chứng chỉ 100-125K để duy trì kích thước CRL hợp lý. Số phát hành này dựa trên giả định rằng khoảng 10 phần trăm chứng chỉ được cấp sẽ bị thu hồi trước ngày hết hạn tự nhiên. Nếu tỷ lệ thu hồi thực tế hoặc theo kế hoạch cao hơn hoặc thấp hơn cho tổ chức của bạn, hãy điều chỉnh chiến lược gia hạn chính cho phù hợp. Thêm thông tin

Cũng xem xét phân vùng CRL thường xuyên hơn nếu hết hạn hơn 1 hoặc hai năm, vì khả năng thu hồi tăng.

Hạn chế của việc này là tăng thời gian khởi động, vì mỗi chứng chỉ được xác thực bởi máy chủ.

Phòng ngừa bảo mật CRL

Nếu sử dụng CRL, không ký CRL với MD5. Đó cũng là một ý tưởng hay để thêm ngẫu nhiên vào khóa ký CRL.

Quyền truy cập thông tin của cơ quan

Trường này cho phép hệ thống con xác thực Chứng chỉ tải xuống các chứng chỉ bổ sung khi cần nếu chúng không nằm trên máy tính cục bộ.

  • Một CA gốc tự ký không nên liệt kê bất kỳ vị trí AIA nào ( xem lý do tại đây )

  • Tối đa năm URL được cho phép trong tiện ích mở rộng AIA cho mỗi chứng chỉ trong chuỗi chứng chỉ. Ngoài ra, tối đa 10 URL cho toàn bộ chuỗi chứng chỉ cũng được hỗ trợ. Giới hạn này về số lượng URL đã được thêm vào để giảm thiểu việc sử dụng tiềm năng các tài liệu tham khảo về quyền truy cập thông tin của cơ quan quyền lực trong việc từ chối các cuộc tấn công dịch vụ.

  • Không sử dụng HTTP [~ # ~] s [~ # ~] và LDAP [~ # ~] s [~ # ~] . Các URL này không còn được hỗ trợ làm tham chiếu điểm phân phối. Lý do là các URL HTTPS và LDAPS sử dụng các chứng chỉ có thể bị thu hồi hoặc không. Quá trình kiểm tra thu hồi có thể dẫn đến các vòng lặp hủy bỏ khi sử dụng URL HTTPS hoặc LDAPS. Để xác định xem chứng chỉ có bị thu hồi hay không, phải lấy CRL. Tuy nhiên, CRL không thể được truy xuất trừ khi trạng thái hủy bỏ của các chứng chỉ được sử dụng bởi HTTPS hoặc LDAPS được xác định.

Kích hoạt xác thực OCSP

Bộ phản hồi OCSP được đặt theo quy ước tại: http://<fqdn of the ocsp responder>/ocsp. Url này cần được kích hoạt trong AIA. Xem các hướng dẫn này cho Windows.

Phải biết rằng xác thực OCSP đầy đủ bị tắt theo mặc định (mặc dù nó phải "bật" cho các cer EV theo thông số kỹ thuật). Ngoài ra, cho phép kiểm tra OCSP không thêm độ trễ cho kết nối ban đầ

Các hệ thống an toàn hơn sẽ muốn bật giám sát OCSP trên máy khách hoặc phía máy chủ

Thời lượng bộ nhớ cache OCSP

Tất cả các hành động OCSP xảy ra trên giao thức HTTP và do đó phải tuân theo các quy tắc bộ đệm proxy HTTP điển hình.

Cụ thể là Max-age tiêu đề xác định thời gian tối đa mà máy chủ proxy hoặc máy khách sẽ lưu trữ phản hồi CRL hoặc OCSP trước khi sử dụng GET có điều kiện để xác định xem đối tượng có thay đổi hay không. Sử dụng thông tin này để định cấu hình máy chủ web để đặt các tiêu đề phù hợp. Tìm nơi khác trên trang này cho các lệnh cụ thể AD-IIS cho việc này.

Xác định chính sách trong các chứng chỉ được cấp

CA cha xác định có hay không cho phép các chính sách chứng chỉ CA từ các CA phụ. Có thể xác định cài đặt này khi nhà phát hành hoặc chính sách ứng dụng cần được đưa vào CA phụ.

Các chính sách ví dụ bao gồm EKU cho SmartCards, Xác thực hoặc xác thực SSL/Máy chủ.

  • Coi chừng chứng chỉ không có Certificate Policies phần mở rộng vì nó có thể làm phức tạp Cây chính sách. Xem RFC 5280 để biết thêm thông tin

  • Biết rằng ánh xạ chính sách có thể thay thế các chính sách khác trong đường dẫn

  • Có một chính sách đặc biệt gọi là anypolicy giúp thay đổi xử lý

  • Có các tiện ích mở rộng thay đổi anypolicy

  • Nếu bạn sử dụng các chính sách chứng chỉ, hãy chắc chắn đánh dấu chúng là critical nếu không thì tính toán valid_policy_tree trở nên trống rỗng, biến chính sách thành một nhận xét được tôn vinh.

Giám sát việc thực thi chiều dài DN

Thông số CCITT ban đầu cho trường OU nói rằng nó nên được giới hạn ở 64 ký tự. Thông thường, CA thi hành các tiêu chuẩn độ dài tên x.500 trên phần mở rộng chủ đề của chứng chỉ cho tất cả các yêu cầu. Có thể các đường dẫn OU sâu có thể vượt quá giới hạn độ dài thông thường.

Điểm phân phối chứng chỉ chéo

Tính năng này hỗ trợ các môi trường cần cài đặt hai PKI, một cho phần cứng/phần mềm cũ không hỗ trợ mật mã hiện đại và PKI khác cho các mục đích hiện đại hơn.

Hạn chế EKU

Ngược lại với RFC 5280 nói chung, [sic] tiện ích mở rộng EKU sẽ chỉ xuất hiện trong chứng chỉ thực thể cuối. "Nên đặt các ràng buộc đối với việc sử dụng Khóa CA .

Chứng chỉ CA độc lập thông thường sẽ chứa các quyền để tạo Chữ ký số, Ký chứng chỉ và ký CRL làm giá trị chính. Đây là một phần của vấn đề bảo mật FLAME.

Việc triển khai thẻ thông minh MSFT yêu cầu một trong hai EKU sau và có thể là hotfix

  • Thẻ thông minh Microsoft EKU
  • Mã hóa khóa công khai cho máy khách Xác thực ban đầu (PKINIT) EKU xác thực, như được định nghĩa trong PKINIT RFC 4556

Nó cũng có những ràng buộc thú vị xung quanh việc xác nhận EKU (link tbd).

Nếu bạn quan tâm đến việc có bất kỳ hạn chế EKU nào, bạn sẽ thấy câu trả lời này liên quan đến OIDđiều này liên quan đến chứng chỉ chống chỉ định

Hãy thận trọng với "Đường dẫn" ràng buộc cơ bản

Ràng buộc cơ bản nên mô tả nếu chứng chỉ có phải là "thực thể cuối" hay không . Thêm một ràng buộc đường dẫn vào một CA trung gian có thể không hoạt động như mong đợi vì đó là một cấu hình không phổ biến và khách hàng có thể không tôn trọng nó.

Cấp dưới đủ điều kiện cho CA trung gian

  • Để giới hạn các loại chứng chỉ, một subCA có thể cung cấp xem liên kết nàycái này

  • Nếu cấp dưới đủ điều kiện được thực hiện, việc thu hồi một gốc được ký chéo có thể khó khăn vì các gốc không cập nhật CRL thường xuyên.

Mã định danh khóa cơ quan/Mã nhận dạng khóa chủ đề

Lưu ý Nếu tiện ích mở rộng AKI của chứng chỉ chứa KeyID, CryptoAPI yêu cầu chứng chỉ nhà phát hành phải chứa SKI phù hợp. Điều này khác với RFC 3280 trong đó kết hợp SKI và AKI là tùy chọn . (todo: Tại sao ai đó chọn thực hiện điều này?)

AKI matching to find key parent

Đặt cho Root và CA một tên có ý nghĩa

Mọi người sẽ tương tác với chứng chỉ của bạn khi nhập nó, xem xét chứng chỉ đã nhập và xử lý sự cố. Thực hành được đề xuất của MSFT và yêu cầ là gốc có một tên có ý nghĩa xác định tổ chức của bạn chứ không phải một cái gì đó trừu tượng và phổ biến như CA1.

Phần tiếp theo này áp dụng cho tên của Trung cấp/subCA sẽ bị hạn chế cho một mục đích cụ thể: Xác thực so với Ký kết với Mã hóa

Đáng ngạc nhiên, người dùng cuối và kỹ thuật viên không hiểu sắc thái của PKI sẽ tương tác với tên máy chủ bạn chọn thường xuyên hơn bạn nghĩ nếu bạn sử dụng S/MIME hoặc chữ ký số (v.v.).

Cá nhân tôi nghĩ rằng nên đổi tên các chứng chỉ phát hành thành một thứ thân thiện hơn với người dùng như "Company Signer 1" nơi tôi có thể nói trong nháy mắt

  • Chữ ký sẽ đến từ ai (Texas A & M hoặc đối thủ của họ)
  • Cái này được dùng để làm gì? Mã hóa và ký

Điều quan trọng là phải phân biệt sự khác biệt giữa một tin nhắn được mã hóa giữa hai bên và một tin nhắn đã được ký. Một ví dụ trong đó điều này rất quan trọng là nếu tôi có thể khiến người nhận lặp lại một tuyên bố tôi gửi cho họ. Người dùng A có thể nói với người dùng B "A, tôi nợ bạn 100 đô la". Nếu B trả lời bằng tiếng vang của tin nhắn đó với khóa sai, thì họ đã công chứng kỹ thuật số một cách hiệu quả (so với chỉ mã hóa) một khoản nợ 100 đô la giả.

Đây là hộp thoại người dùng mẫu cho S/MIME . Yêu cầu các UI tương tự cho các chứng chỉ dựa trên Brower. Lưu ý rằng tên nhà phát hành không thân thiện với người dùng.

Select a SMIME certificate.. really?

Mã hóa thay thế

Lưu ý: Nói về tên, nếu bất kỳ liên kết nào trong chuỗi sử dụng mã hóa thay thế, thì khách hàng có thể không thể xác minh trường nhà phát hành cho chủ đề. Windows không bình thường hóa các chuỗi này trong quá trình so sánh, vì vậy hãy đảm bảo tên của CA giống hệt nhau từ góc độ nhị phân (trái ngược với khuyến nghị của RFC).

Name matching to find key parent

Triển khai bảo mật/bộ B cao

  • Đây là thông tin liên quan đến thuật toán Suite B được hỗ trợ trong Windows 2008 và R2

    ALGORITHM BÍ MẬT BÍ MẬT HÀNG ĐẦU

    Mã hóa: Tiêu chuẩn nâng cao (AES) 128 bit 256 bit

    Chữ ký số: Thuật toán chữ ký số Elliptic Curve (ECDSA) 256 bit. Đường cong 384 bit

    Trao đổi khóa: Đường cong Elliptic Curie Diffie-Hellman (ECDH) 256 bit. Đường cong 384 bit

    Băm: Thuật toán băm an toàn (SHA) SHA-256 SHA-384

  • Đối với tuân thủ Suite B, ECDSA_P384#Microsoft Software Key Service Provider cũng như 384 kích thước khóa và SHA384 vì thuật toán băm cũng có thể được chọn nếu mức độ phân loại mong muốn là Tối mật. Nên sử dụng các cài đặt tương ứng với mức phân loại cần thiết. ECDSA_P521 cũng có sẵn như là một tùy chọn. Mặc dù việc sử dụng đường cong ECC 521 bit có thể vượt quá yêu cầu về mật mã của Suite B, do kích thước khóa không chuẩn, 521 không phải là một phần của đặc tả chính thức của Suite B.

PKCS # 1 v2.1

Bảo vệ cổng Microsoft CA DCOM

Windows Server 2003 CA không thực thi mã hóa trên các giao diện ICOMRequest hoặc ICertAdmin theo mặc định. Thông thường, cài đặt này không bắt buộc ngoại trừ trong các tình huống hoạt động đặc biệt và không được bật. Chỉ các máy Windows Server 2003 theo mặc định mới hỗ trợ mã hóa DCOM trên các giao diện này. Ví dụ: Windows XP máy khách sẽ không mặc định thực thi mã hóa theo yêu cầu chứng chỉ cho Windows Server 2003 CA. nguồn

Lưu trữ khóa riêng CNG so với lưu trữ CSP

Nếu bạn đăng ký Mẫu chứng chỉ v3, khóa riêng sẽ đi vào bộ lưu trữ khóa riêng CNG trên máy khách. Nếu bạn đăng ký Mẫu chứng chỉ v2 hoặc v1, khóa riêng sẽ vào bộ lưu trữ CSP. Chứng chỉ sẽ hiển thị cho tất cả các ứng dụng trong cả hai trường hợp, nhưng không phải khóa riêng của chúng - vì vậy hầu hết các ứng dụng sẽ hiển thị chứng chỉ là có sẵn, nhưng sẽ không thể ký hoặc giải mã dữ liệu bằng khóa riêng được liên kết trừ khi chúng hỗ trợ lưu trữ CNG.

Bạn không thể phân biệt giữa kho CNG và CSP bằng cách sử dụng Chứng chỉ MMC. Nếu bạn muốn xem lưu trữ mà một chứng chỉ cụ thể đang sử dụng, bạn phải sử dụng CERTUTIL -repairstore my * (hoặc là CERTUTIL -user -repairstore my *) và xem trường Nhà cung cấp. Nếu nó nói "... Nhà cung cấp lưu trữ chính", thì đó là CNG trong khi tất cả các nhà cung cấp khác là CSP.

Nếu bạn tạo yêu cầu chứng chỉ ban đầu theo cách thủ công (Tạo Yêu cầu tùy chỉnh trong MMC), bạn có thể chọn giữa "Lưu trữ CNG" và "Khóa kế thừa" trong đó di sản có nghĩa là CSP. Sau đây là danh sách dựa trên kinh nghiệm của tôi về những gì không hỗ trợ CNG - bạn không thể tìm thấy danh sách có thẩm quyền ở bất cứ đâu, do đó, điều này được rút ra từ các cuộc điều tra của tôi theo thời gian:

  • EFS Không được hỗ trợ trong Windows 2008/Vista, Được hỗ trợ trong Windows 7/2008R2
  • chứng chỉ mã hóa người dùng
  • Máy khách VPN/WiFi (EAPTLS, Máy khách PEAP)

  • Windows 2008/7 Không được hỗ trợ xác thực chứng chỉ người dùng hoặc máy tính

  • Chứng chỉ máy chủ TMG 2010 trên trình nghe web
  • Chứng chỉ email người dùng Outlook 2003 cho chữ ký hoặc mã hóa
  • Kerberos Windows 2008/Vista- DC chứng chỉ
  • Quản lý vận hành trung tâm hệ thống 2007 R2
  • Trình quản lý cấu hình hệ thống trung tâm 2007 R2
  • Máy chủ SQL 2008 R2-
  • Quản lý chứng chỉ hàng đầu 2010 Quản lý chứng chỉ

Thông tin thêm về khả năng tương thích CNG được liệt kê tại đây (bằng tiếng Séc, mặc dù Chrome xử lý tốt bản dịch tự động)

Thẻ thông minh & CA phát hành

Nếu bạn dự định cung cấp cho người dùng thẻ thông minh thứ hai để xác thực, hãy sử dụng CA nhà phát hành thứ hai cho việc đó. Lý do: Yêu cầu của Windows 7

Sử dụng lệnh Windows CERTUTIL -viewstore -enterprise NTAuth để khắc phục sự cố đăng nhập Smartcard. Cửa hàng NTAuth địa phương là kết quả của lần tải xuống Chính sách nhóm cuối cùng từ cửa hàng Active Directory NTAuth. Đây là cửa hàng được sử dụng bởi đăng nhập thẻ thông minh, vì vậy việc xem cửa hàng này có thể hữu ích khi khắc phục sự cố đăng nhập thẻ thông minh.

Ngừng hoạt động Cây PKI

Nếu bạn triển khai hai cây PKI, với ý định ngừng hoạt động cây kế thừa tại một thời điểm nào đó (nơi tất cả các thiết bị cũ đã trở nên lỗi thời hoặc được nâng cấp), có thể nên đặt trường CRL Next Update thành Null. Điều này sẽ (nên?) Ngăn chặn việc bỏ phiếu liên tục cho CRLS mới cho khách hàng. Lý do là một khi PKI ngừng hoạt động, sẽ không còn quản trị nữa và không còn bị thu hồi nữa. Tất cả các certs còn lại chỉ đơn giản là còn lại để hết hạn.

Thông tin thêm về ngừng hoạt động PKI có sẵn tại đây

39
goodguys_activate

Các lệnh cụ thể của AD CS

Đây là danh sách các lệnh có liên quan để định cấu hình Máy chủ CA Windows 2008 R2. Tôi đã xóa chúng khỏi bài đăng khác vì thông tin đó đã trở nên quá dài và không phải tất cả các lệnh liên quan trực tiếp đến việc thiết lập CA.

Đây là phần của phần Làm thế nào, thay vì "cái gì và tại sao". Nó cũng bao gồm các khác biệt về phiên bản giữa các phiên bản CA (2000 so với 2003, so với 2008)


Liệt kê những gì Chính sách tuyển sinh Chỉnh sửa cờ

Một số yêu cầu từ máy khách có thể tự động bị tước dựa trên các cài đặt máy chủ bị ẩn này.

C:\Users\ChrisLamont>certutil -getreg

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration:

Keys:
  Secure Email Root v1

Values:
  Active                   REG_SZ = Secure Email Root v1
  DBDirectory              REG_SZ = C:\Windows\system32\CertLog
  DBLogDirectory           REG_SZ = C:\Windows\system32\CertLog
  DBTempDirectory          REG_SZ = C:\Windows\system32\CertLog
  DBSystemDirectory        REG_SZ = C:\Windows\system32\CertLog

  DBSessionCount           REG_DWORD = 64 (100)
  LDAPFlags                REG_DWORD = 0

  DBFlags                  REG_DWORD = b0 (176)
    DBFLAGS_MAXCACHESIZEX100 -- 10 (16)
    DBFLAGS_CHECKPOINTDEPTH60MB -- 20 (32)
    DBFLAGS_LOGBUFFERSHUGE -- 80 (128)

  Version                  REG_DWORD = 40001 (262145) -- 4.1
  SetupStatus              REG_DWORD = 6001 (24577)
    SETUP_SERVER_FLAG -- 1
    SETUP_DCOM_SECURITY_UPDATED_FLAG -- 2000 (8192)
    SETUP_SERVER_IS_UP_TO_DATE_FLAG -- 4000 (16384)
CertUtil: -getreg command completed successfully.

C:\Users\ChrisLamont>certutil -getreg policy\editflags

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\Secur
e Email Root v1\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\EditF
lags:

  EditFlags REG_DWORD = 83ee (33774)
    EDITF_REQUESTEXTENSIONLIST -- 2
    EDITF_DISABLEEXTENSIONLIST -- 4
    EDITF_ADDOLDKEYUSAGE -- 8        // <--- THIS ENTRY REMOVES A CLIENT'S Key Agreement  
    EDITF_ATTRIBUTEENDDATE -- 20 (32)
    EDITF_BASICCONSTRAINTSCRITICAL -- 40 (64)
    EDITF_BASICCONSTRAINTSCA -- 80 (128)
    EDITF_ENABLEAKIKEYID -- 100 (256)
    EDITF_ATTRIBUTECA -- 200 (512)
    EDITF_ATTRIBUTEEKU -- 8000 (32768)
CertUtil: -getreg command completed successfully.

Giải pháp là chạy lệnh certutil -setreg policy\EditFlags -EDITF_ADDOLDKEYUSAGE lần lượt cập nhật

     Configuration\spatula\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\EditFlags:

Cách xác định chính sách trên Cơ sở Per CA

Để bao gồm một chính sách trong các chứng chỉ được cấp, hãy nhập các lệnh sau vào lệnh Nhắc:

 certutil -v -setreg policy\EnableRequestExtensionlist "+2.5.29.32"
 certutil –shudown
 net start certsvc

Bạn có thể tắt cài đặt với

  certutil -v -setreg policy\EnableRequestExtensionlist      "-2.5.29.32"
  certutil –shudown
  net start certsvc

Cách xác định thời lượng bộ đệm OCSP

Các lệnh sau cho phép bạn đặt, sửa đổi và xóa cài đặt tiêu đề Tuổi tối đa.

  appcmd set config /section:httpProtocol /+customHeaders.[name='cacheControlHeader',value='max-age=604800']

Để xem các tiêu đề tùy chỉnh httpProtocol hiện tại

  appcmd list config /section:httpProtocol

Cách nhập chứng chỉ CA ngoại tuyến vào AD

:
: Root CA certificates
:
certutil -dspublish -f concorp-ca-00_CorporateRootCA.crt RootCA
:
: Sub CA certificate
:
certutil -dspublish -f connoam-ca-00_IntermediateCA1.crt SubCA
:
: Root CA CRLs
: Since these are .NET CA CRLS that have the publication location as
: part of the CRL, the publication location is optional
:
:                                              |-- publication location ---|
:
certutil -dspublish -f CorporateRootCA.crl     concorp-ca-00 CorporateRootCA
:
: Sub CA CRLs
:
certutil -dspublish -f IntermediateCA1.crl     connoam-ca-00 IntermediateCA1

Cách bật PKCS # 1 v1.21

Điều này được kích hoạt khi tệp CAPolicy.inf có AlternateSignatureAlgorithm=1. Hãy chắc chắn để nhận thức được các vấn đề tương thích.

Cuối cùng, người ta nên biết rằng việc cài đặt Dịch vụ Chứng chỉ AD không đơn giản như việc thêm vai trò. Bạn nên kiểm tra điều này Tập lệnh cài đặt VBS và đảm bảo tệp CAPolicy.inf nên được chỉnh sửa khi cần cho môi trường của bạn

Cách xác định Điểm phân phối chứng chỉ chéo

Dịch vụ chứng chỉ Windows AD cho phép điều này trong tệp CAPolicy.info với [CrossCertificateDistributionPointsExtension] mục

Misc: Sự khác biệt của AIA khi nâng cấp Windows 2000 CA lên Windows 2003

Lưu ý rằng có một sự thay đổi trong hành vi giữa các Windows 2000 và 2003 CA. Phần mở rộng chứng chỉ AKI do Windows CA phát hành khác nhau giữa Windows 2000 và Windows Server 2003. Theo mặc định, thông tin sau được lưu trữ trong phần mở rộng AIA của chứng chỉ được cấp.

  • Windows 2000 Phần mở rộng chứng chỉ AIA do CA cấp bao gồm LDAP DN của CA phát hành (tên tổ chức phát hành), số sê-ri của chứng chỉ CA phát hành và mã băm của khóa công khai chứng chỉ CA.

  • Windows Server 2003 Phần mở rộng chứng chỉ AIA do CA cấp chỉ bao gồm hàm băm của khóa chung của CA đang phát hành, còn được gọi là Key-ID.

Sự thay đổi trong hành vi là do lỗi chuỗi có thể xảy ra khi chứng chỉ CA Lới được gia hạn. Hành vi mặc định của Windows 2000 có thể dẫn đến các chuỗi không hoàn chỉnh nếu chứng chỉ CA được sử dụng để ký chứng chỉ được cấp không có sẵn cho máy khách. Với hành vi mặc định của Windows Server 2003, nếu CA được gia hạn với cùng một cặp khóa, bất kỳ chứng chỉ CA nào cho CA phát hành sử dụng cùng cặp khóa đó đều có thể được đưa vào chuỗi chứng chỉ.

Bạn có thể bắt chước hành vi cũ bằng cách chạy lệnh này

 certutil -setreg policy\EditFlags -EDITF_ENABLEAKIISSUERNAME
 certutil -setreg policy\EditFlags -EDITF_ENABLEAKIISSUERSERIAL

Liệt kê các chứng chỉ trong AD

Lệnh này sẽ liệt kê các chứng chỉ được xuất bản trong Active Directory.

certutil -viewstore "ldap:///CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com?cACertificate?one?objectClass=certificationAuthority"

Khả năng tương thích PKI ISIS MTT v1.1

Xem điều này Bài viết KB về thủ tục , đây cũng là một phương pháp thay thế CAPolicy.inf cho ISIS MTT v1.1

4
goodguys_activate

một điểm trong danh sách kiểm tra thường bị bỏ qua:

  • SAO LƯU
  • SAO LƯU
  • SAO LƯU

đặc biệt nếu bạn thực hiện CA.

3

Tôi đã hết chỗ cho câu trả lời trước của mình, nhưng nghĩ rằng đây là thông tin hợp lệ và hữu ích:

Thu hồi

Một số phần tiếp theo thảo luận về CRL và chứng chỉ, nhưng trước khi bạn đi quá xa, tôi muốn chú ý đến một vấn đề có thể ảnh hưởng đến hoạt động sản xuất và PKI: Nếu bạn nghĩ PKI của bạn sẽ thu hồi gấp đôi cùng một chứng chỉ với PKI của Microsoft (Chứng chỉ thư mục hoạt động Dịch vụ), sau đó ngày thu hồi sẽ là ngày thu hồi thứ hai, không phải ngày đầu tiên. Nhưng nếu bạn quản lý chứng chỉ trên thẻ thông minh bằng sản phẩm FIM CM của Microsoft (Quản lý danh tính hàng đầu - Quản lý chứng chỉ), thì bạn sẽ thực hiện các lần hủy bỏ trùng lặp như vậy. nguồn

1
goodguys_activate