Dịch vụ chứng chỉ MS có thể là cấp dưới của CA được tạo bằng OpenSSL


15

Tôi muốn thiết lập một cơ quan chứng nhận doanh nghiệp cho tên miền của tôi. Vì vậy, tôi có thể cấp giấy chứng nhận cho các mục đích khác nhau. Tôi muốn làm theo cách tốt nhất để có một CA ngoại tuyến làm gốc và thiết lập CA doanh nghiệp của tôi làm cấp dưới. Nhưng có vẻ ngớ ngẩn khi cấp phép một bản sao đầy đủ của Windows cho nhiệm vụ này.

Những gì tôi hy vọng có thể làm là cài đặt một số phân phối trực tiếp vào đĩa flash USB, sau đó cài đặt openssl và thiết lập CA của tôi trên ổ đĩa flash. Khi tôi sẵn sàng xây dựng khóa / cert gốc, tôi sẽ ngắt kết nối máy tính khỏi mạng và sau đó không bao giờ sử dụng đĩa USB đó trên máy tính gắn mạng nữa.

Tôi có thể ký đúng và tạo chứng chỉ CA cấp dưới cho CA doanh nghiệp Windows không, có thể sử dụng được. Tôi cần sử dụng các tùy chọn nào với OpenSSL để xây dựng CA và ký chứng chỉ CA cấp dưới đúng cách.

Tôi đã cố gắng tìm kiếm trên web, và đây là điều duy nhất tôi có thể tìm thấy về chủ đề này. Nhưng nó có trước năm 2008, và tôi không hoàn toàn chắc chắn rằng mọi người đều thành công.


Để rõ ràng, Công cụ không nhất thiết phải là OpenSSL, nhưng tôi không muốn chạy một CA lớn như EJBCA. Tôi đang tìm kiếm một CA trọng lượng rất nhẹ có thể chạy trong môi trường livecd / liveusb.
Zoredache

Câu trả lời:


14

Yup, nó hoạt động tốt; cơ quan cấp chứng chỉ Windows không có vấn đề gì về việc chạy như một cấp dưới của root không phải Windows.

Đã thử nghiệm với một gốc OpenSSL và cấp dưới Windows 2008 R2 trong chế độ Enterprise.


Một vài điều để chơi tốt với những gì MS CA mong đợi trong cấu hình OpenSSL:

  • Các vị trí AIA và CDP hợp lệ nên áp dụng cho chứng chỉ gốc, trong phần được định cấu hình bởi thuộc x509_extensionstính của [req]phần dành cho root tự ký. Một cái gì đó dọc theo những dòng này:

    authorityInfoAccess = caIssuers;URI:http://test-rootca.test.local/root.pem
    crlDistributionPoints = URI:http://test-rootca.test.local/root.crl
    
  • Một cấu hình OpenSSL nhất định có thể không cho phép các CA cấp dưới theo mặc định. Thay đổi điều đó đối với các yêu cầu đã ký (tất nhiên đảm bảo rằng điều này không phù hợp với các yêu cầu không phải là CA, tất nhiên). Điều này sẽ nằm trong phần được cấu hình bởi thuộc x509_extensionstính của [ca]phần:

    basicConstraints=CA:TRUE
    certificatePolicies=2.5.29.32.0
    

Vì vậy, chúng tôi sẽ làm một CA để kiểm tra.

Tạo gốc của bạn:

openssl req -new -x509 -keyout /etc/ssl/private/root.key -out /etc/ssl/certs/root.pem -nodes -extensions v3_ca

Fiddle với cấu hình của bạn và tạo các tập tin và thư mục cần thiết trong [ca] mục phần cấu hình OpenSSL của bạn.

Tất cả được thiết lập để có được phía Microsoft của mọi thứ đang diễn ra; tạo một CA cấp dưới Windows bằng cách ký thủ công.

Tải yêu cầu chứng chỉ lên máy chủ OpenSSL. Trong khi bạn đang ở đó, tải về chứng chỉ gốc. Nhập nó vào cửa hàng gốc đáng tin cậy - của máy tính, không phải người dùng của bạn!

Cấp giấy chứng nhận cấp dưới:

openssl ca -in test-subca.req
(you might need to specify a permissive policy manually with -policy, check your config)

Nếu điều đó không hoạt động, CA của bạn có thể có vấn đề với cấu hình - thư mục certs mới, tệp chỉ mục, tệp nối tiếp, v.v. Kiểm tra thông báo lỗi.

Nếu nó đã đi, thì đó là nó. Nếu bạn chưa có, hãy tạo CRL và đặt nó vào CDP mà bạn đã cấu hình ở trên; Tôi vừa cài đặt Apache và gây nhiễu nó trong webroot:

openssl ca -gencrl -out /var/www/root.crl

Và đặt chứng chỉ của bạn ở vị trí AIA, nếu chưa có:

cp /etc/ssl/certs/root.pem /var/www/root.pem

Tải xuống chứng chỉ cấp dưới mới được cấp và cài đặt nó vào CA với phần đính kèm MMC của Tổ chức chứng nhận. Nó sẽ nắm bắt về bất kỳ vấn đề nào với sự tin tưởng hoặc xác nhận, nhưng nó không phản đối đạo đức đối với việc thực hiện nó.

Kết quả cuối cùng; một Windows CA hoạt động mà không có khiếu nại từ snap-in Enterprise PKI, với một OpenSSL Generated Certificatethuộc tính trong các thuộc tính.

làm việc


6

Tôi thấy những gì bạn đang nhận được, nhưng tôi không nghĩ OpenSSL là công cụ hoàn hảo cho công việc. Bạn có thể muốn xem các dự án của Cơ quan cấp chứng chỉ nguồn mở như EJBCA , tập trung nhiều hơn vào chức năng này so với OpenSSL và có tài liệu cụ thể mà bạn có thể sử dụng.

Tôi không thấy lý do tại sao khái niệm này sẽ không hoạt động, vì tất cả những gì bạn đang làm là ký chứng chỉ CA cấp dưới. Nếu bạn đang trả tiền cho một CA công cộng để làm điều này cho bạn, bạn sẽ không nhất thiết phải biết hoặc quan tâm đến hương vị của máy chủ mà họ đang sử dụng.

Tất cả bạn cần quan tâm là:

  • bạn có thể ký chứng chỉ từ CSR do cấp dưới của bạn tạo ra
  • kết quả có thể được cài đặt trên chính cấp dưới
  • bạn có chứng chỉ ký gốc có thể được cài đặt là đáng tin cậy trên bất kỳ ứng dụng khách nào bạn đang nhắm mục tiêu
  • bạn có thể tạo danh sách hủy bỏ được phục vụ ở đâu đó

Tôi không thể nói rằng tôi đã làm điều này, nhưng tôi chắc chắn nếu bạn theo dõi các tài liệu để tạo CSR từ hộp cửa sổ, sau đó làm theo tài liệu CA của bạn để tạo chứng chỉ .p7k từ CSR, thì bạn sẽ ổn.

Nhân tiện - tôi khuyên bạn nên tạo CA của mình dưới dạng máy ảo cho một trình ảo hóa phổ biến như Hyper-V hoặc VMware, thay vì đĩa khởi động, đảm bảo bạn lưu trữ nó một cách an toàn ở nơi nào đó người kế nhiệm của bạn có thể tìm thấy nó và quay nó ngoại tuyến định kỳ để đảm bảo nó chạy hoặc chuyển nó sang phương tiện / công nghệ mới. Một CA gốc có thể có tuổi thọ 10 hoặc 20 năm ...


+1 OpenSSL không phải là công cụ hàng đầu để tạo CA, nhưng nói chung nó hoạt động. Tôi chưa cấp chứng chỉ CA phụ cho Windows Enterprise CA, nhưng không thể tưởng tượng được tại sao nó không hoạt động (mặc dù MS đã thực hiện các hành vi chống cạnh tranh nghiêm trọng hơn trong quá khứ). +1 lớn cho CA là VM. Giữ một bản sao thứ hai của chứng chỉ gốc là một ý tưởng hay (Base64 trên giấy rất bền và dễ giữ trong két / hộp ký gửi / v.v.)
Chris S

Tôi khá hài lòng với bản thân mình khi nhận ra rằng tôi có thể thiết lập máy ảo mà không cần bất kỳ máy ảo nào và chỉ cần sử dụng ổ đĩa mềm ảo để bật CSR và ký tắt certs. Sneakernet tái sinh với sự tỏa sáng của Thế kỷ 21!
dunxd
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.