Tôi đã tạo một Cơ quan cấp chứng chỉ gốc tự ký cho một vài dịch vụ nội bộ trong công ty của chúng tôi do tôi tự cấu hình (chủ yếu phục vụ qua HTTPS). Sau đó, tôi đã tạo chứng chỉ cho các dịch vụ đó, đã ký với CA.
Bây giờ tôi muốn thêm tiện ích mở rộng x509 (điểm phân phối CRL) vào CA gốc mà không làm mất hiệu lực chứng chỉ máy chủ hiện có được cấp từ CA này. Điều này có thể không?
Cảm giác ruột của tôi là "có" bởi vì theo tôi hiểu, việc truy cập vào khóa riêng tương ứng là cần thiết và đủ cho "toàn quyền" đối với nhận dạng chứng chỉ. Đó là, trừ khi có một số loại nonce được kết hợp cùng với khóa chung vào chứng chỉ khi nó được tạo (có khả năng).
Tôi vẫn còn khá mới đối với việc quản lý chứng chỉ SSL, nhưng tôi (nghĩ rằng tôi) hiểu những điều cơ bản của chuỗi tin cậy tiêu chuẩn. Tôi cũng thoải mái với việc sử dụng cơ bản các loại tiền điện tử PKI khác: Tôi quản lý các khóa SSH và sử dụng GPG để ký và mã hóa. Tôi đã học Khoa học Máy tính, mặc dù tôi chỉ là một người học tự học về mật mã.
Tôi chưa bao giờ thực hiện CSR cho IIRC ban đầu (tôi nghĩ đó là đầu ra trực tiếp của openssl req -new -x509). Dĩ nhiên, tôi vẫn có khóa riêng của CA gốc và sử dụng nó, tôi có thể "đảo ngược" chứng chỉ gốc thành Yêu cầu ký chứng chỉ:
openssl x509 -x509toreq -in MyCA.pem -out MyCA.csr -signkey private/MyCA.key
Tôi đã hy vọng điều này sẽ "trích xuất" một cách hiệu quả các nonce đã đề cập ở trên và cho phép tôi tạo lại chứng chỉ nhưng lần này với một crlDistributionPointstrường và do đó, tất cả các chứng chỉ đã được ký với CA gốc vẫn sẽ xác nhận đối với CA mới này, ngoại trừ khách hàng sẽ truy xuất tệp CRL (hiện đang trống) của tôi từ URL HTTP được chỉ định trong trường.
Vì vậy, tôi đã thực hiện một tập tin cấu hình mở rộng ext.conf:
[ cert_ext ]
subjectKeyIdentifier=hash
crlDistributionPoints=URI:http://security.mycompany.co.za/root.crl
Và tôi đã tạo phiên bản mới của CA gốc từ CSR:
openssl x509 -extfile ./ext.conf -extensions cert_ext -req -signkey private/MyCA.key -in MyCA.csr -out MyNewCA.pem
Bây giờ khi tôi xem chứng chỉ với openssl x509 -text -in MyNewCA.pem | less
Tôi có thể thấy phần mở rộng CRL:
X509v3 extensions:
X509v3 Subject Key Identifier:
82:D0:01:03:49:FF:30:16:FA:DC:0A:1E:C1:8C:3D:66:A1:78:FF:F8
X509v3 CRL Distribution Points:
Full Name:
URI:http://security.mycompany.co.za/root.crl`
Nhưng than ôi! Chứng chỉ đã ký trước đây của tôi không còn hiệu lực đối với chứng chỉ này:
openssl verify -verbose -CAfile MyCA.pem git.pem
git.pem: OK
openssl verify -verbose -CAfile MyNewCA.pem git.pem
git.pem: <redacted DN>
error 20 at 0 depth lookup:unable to get local issuer certificate
Chủ yếu là tôi đang tìm kiếm cái nhìn sâu sắc hơn về cách chứng chỉ hoạt động và tại sao. Nhưng tôi cũng hoan nghênh một giải pháp cho vấn đề dẫn đến vấn đề này, vì vậy đây cũng là một số thông tin cơ bản.
Làm thế nào tôi gặp rắc rối này: HTTPS để các dịch vụ nội bộ hoạt động tốt khi CA của tôi được cài đặt qua Explorer RMB → Cài đặt GUI chứng chỉ trên Windows hoặc /usr/local/share/ca-certificatestiếp theo là update-ca-certificatestrên Debian và Ubuntu. Nhưng gần đây tôi đã gặp phải một ngoại lệ: Git trên Windows, cụ thể là nếu được cài đặt để sử dụng Windows Secure Channel làm SSL back-end. Theo mặc định, rõ ràng là phải có trường CRL trong chứng chỉ SSL.
Vì vậy, tôi đoán đây thực sự là sự cố Windows Secure Channel vì thông báo lỗi tôi tiếp tục chạy dường như hoàn toàn do Microsoft cung cấp: fatal: unable to access 'https://angery@git.mycompany.co.za/gitblit/r/secret_project.git/': schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate.
Nếu tôi cài đặt Git với OpenSSL và ghép thủ công CA của mình vào tệp được chỉ ra bởi git.http.sslcainfo thì nó hoạt động, nhưng tôi sợ người dùng của tôi sẽ có xu hướng không xác minh nhận dạng SSL nếu họ cảm thấy quá trình này nỗ lực hơn nhấp qua GUI cài đặt chứng chỉ Windows "dễ dàng".
-x509toreqsẽ phục hồi tất cả thông tin duy nhất từ CA gốc, nhưng nó không hoặc có gì sai với quy trình của tôi từ đó.
req -new -x509và x509 -req -signkeycả hai mặc định nối tiếp của chứng chỉ tự ký thành một số ngẫu nhiên (mặc dù điều này có thể bị ghi đè) một cách hiệu quả. Nếu chứng chỉ con của bạn (hoặc bất kỳ trong số chúng) có chứa AuthorKeyIdentifier sử dụng tùy chọn 'nhà phát hành + nối tiếp' (thay vì hoặc ngoài tùy chọn 'keyid'), đó sẽ là trường hợp nếu bạn sử dụng cavới tệp cấu hình mặc định ngược dòng, bạn cần tạo root mới với serial nối tiếp với root cũ; sử dụng -set_serial. ...