Cách thiết lập chính xác openssl CA để tạo chứng chỉ ứng dụng khách ssl

Tôi đang cấu hình CA đầu tiên của mình. Mục đích sẽ là cấp chứng chỉ cho khách hàng của chúng tôi, những người sẽ sử dụng chúng để truy cập dịch vụ EDI của chúng tôi qua https. Vì vậy, tôi cần phải tạo chứng chỉ ứng dụng khách ssl. Toàn bộ quá trình ký chứng chỉ hoạt động cho đến bây giờ và chứng chỉ có thể được sử dụng thành công để truy cập dịch vụ của chúng tôi, nhưng tôi lo lắng về một điều:

Các mục đích chứng chỉ được tạo là cách để chung chung:

$ openssl x509 -purpose  -noout -in client.crt.pem
Certificate purposes:
SSL client : Yes
SSL client CA : No
SSL server : Yes
SSL server CA : No
Netscape SSL server : Yes
Netscape SSL server CA : No
S/MIME signing : Yes
S/MIME signing CA : No
S/MIME encryption : Yes
S/MIME encryption CA : No
CRL signing : Yes
CRL signing CA : No
Any Purpose : Yes
Any Purpose CA : Yes
OCSP helper : Yes
OCSP helper CA : No

Tôi cảm thấy rằng không nên có mục đích nào khác ngoài ứng dụng khách SSL và S / MIME trong trường hợp của tôi. Tôi có sai và điều này nên ở lại như nó?

Nếu tôi đúng và tôi nên vô hiệu hóa các mục đích khác, tôi nên đặt gì trong cấu hình openssl.cnf của mình?

Đây là cấu hình hiện tại của tôi (tước một chút):

[ CA_edi ]
# here was directory setup and some other stuff, cut it for clarity
x509_extensions = usr_cert      # The extentions to add to the cert

name_opt    = ca_default        # Subject Name options
cert_opt    = ca_default        # Certificate field options
# Extension copying option: use with caution.
# copy_extensions = copy
# stripped rest of config about validity days and such

[ usr_cert ]

basicConstraints=CA:FALSE
nsCertType = client, email
keyUsage = nonRepudiation, digitalSignature, keyEncipherment, keyAgreement

Tôi đang làm gì sai khi các certs tạo ra cho phép sử dụng máy chủ?

Bạn có quyền quan tâm đến "ký CRL", "Bất kỳ CA có mục đích" và "Trình trợ giúp OCSP", những thứ này thường được dành riêng cho chứng chỉ CA hoặc chứng chỉ được cấp cụ thể để ký danh sách thu hồi chứng chỉ (CRL, danh sách chứng chỉ không hợp lệ) hoặc chạy máy chủ OCSP (tương tự CRL, nhưng dịch vụ trực tuyến cung cấp trạng thái hợp lệ cho chứng chỉ).

Trang tài liệu OpenSSL có liên quan dành cho lệnh x509 và x509v3_config

Đây là cấu hình OpenSSL tôi sử dụng để tạo chứng chỉ ứng dụng khách:

[user]
basicConstraints = critical,CA:FALSE
extendedKeyUsage = clientAuth,emailProtection
subjectAltName=email:copy
crlDistributionPoints = URI:http://www.rgweb.org/ca/rgweb-ca.crl
authorityKeyIdentifier=keyid:always
authorityInfoAccess = caIssuers;URI:http://www.rgweb.org/ca/rgweb-ca.cer

Tôi sẽ đưa bạn qua từng dòng một:

Các basicConstraintsđược thiết lập như quan trọng, mà có nghĩa là "bác bỏ chứng chỉ này nếu bạn không hiểu chút này", và xác định rằng giấy chứng nhận là không phải là một CA . Ngay cả khi ai đó sử dụng phần mềm để cấp chứng chỉ từ chứng chỉ này, nó sẽ không bao giờ được tin cậy.

Việc sử dụng khóa mở rộng là không cần thiết, nhưng một số phần mềm yêu cầu phải có mặt và có một mục đích cụ thể được liệt kê. Điều này liệt kê xác thực ứng dụng khách (những gì bạn đang nói) và cả mã hóa & ký mã email S / MIME; bạn có thể xóa mục đích S / MIME một cách an toàn nếu bạn không cần nó.

subjectAltNamecho phép bạn bao gồm thông tin về chủ đề mà bạn không thể đưa vào subjecttrường. Nó cũng được sử dụng trong chứng chỉ máy chủ web để bao gồm các tên miền mà chứng chỉ có thể được sử dụng cho ngoài tên miền được chỉ định trong thuộc tính tên chung của chủ đề; các chứng chỉ này được gọi là chứng chỉ SAN (tên thay thế chủ đề). Đó là thực tế phổ biến để bao gồm địa chỉ email subjectAltNamethay vì trong chủ đề; bạn hoàn toàn không phải bao gồm một địa chỉ email và có thể bỏ qua phần mở rộng.

crlDistributionPointsliệt kê các địa điểm mà CRL cho cơ quan ban hành có sẵn; nó nói với phần mềm đang cố xác thực chứng chỉ "đây là nơi để xem chứng chỉ này có còn hiệu lực không." Để sử dụng Internet, http://URL có thể là tốt nhất (CRL được ký điện tử, do đó không cần httpsvà nó có thể gây ra sự cố vòng lặp tin cậy).

authorityKeyIdentifierthường là hàm băm SHA-1 của khóa công khai của CA (mặc dù nó có thể là các giá trị khác). Nếu bạn bao gồm tiện ích mở rộng này, giá trị phải khớp với giá trị subjectKeyIdentifiertrong chứng chỉ CA đang phát hành .

authorityInfoAccessgiống như một chút crlDistributionPointsnhưng nó chỉ định nơi nhận chứng chỉ CA phát hành thay vì CRL. Điều này hữu ích nếu bạn có một chuỗi tin cậy dài: ví dụ: CA-1 phát hành CA-2, phát hành CA-3, phát hành chứng chỉ; phần mềm cố gắng xác minh chứng chỉ có thể sử dụng tiện ích mở rộng này để lấy chứng chỉ CA-3, sau đó sử dụng giá trị trong chứng chỉ đó để lấy chứng chỉ CA-2, v.v. Thông thường, chuỗi chứng chỉ (trong trường hợp này là chứng chỉ CA-2 và chứng chỉ CA-3) được gói cùng với chứng chỉ của đối tượng (ví dụ: trong giao dịch SSL hoặc email S / MIME). Tôi không biết bất kỳ phần mềm nào sử dụng tiện ích mở rộng này, nhưng tôi cũng không biết rằng nó cũng không được sử dụng. Nó thường được bao gồm trong giấy chứng nhận.

Của tất cả các điều đó, bạn chỉ thực sự cần sự basicConstraintsvà extendedKeyUsage; các ràng buộc cơ bản thực sự, thực sự phải rất quan trọng (hoặc bạn vừa trao chứng chỉ CA!) và việc sử dụng khóa mở rộng thường không có.