วิธีการตั้งค่า openssl CA อย่างถูกต้องเพื่อสร้างใบรับรองไคลเอ็นต์ SSL

ฉันกำลังกำหนดค่า CA แรกของฉัน โดยมีวัตถุประสงค์เพื่อออกใบรับรองให้กับลูกค้าของเราซึ่งจะใช้เพื่อเข้าถึงบริการ EDI ของเราผ่าน https ดังนั้นฉันต้องสร้างใบรับรองไคลเอ็นต์ SSL กระบวนการทั้งหมดของการลงนามใบรับรองใช้งานได้ในขณะนี้และสามารถใช้ใบรับรองได้สำเร็จในการเข้าถึงบริการของเรา

วัตถุประสงค์ของใบรับรองที่สร้างขึ้นเป็นวิธีทั่วไป:

$ 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

ฉันรู้สึกว่าไม่ควรมีวัตถุประสงค์อื่นนอกจากไคลเอนต์ SSL และการลงชื่อ S / MIME ในกรณีของฉัน ฉันผิดและนี่ควรจะเป็นอย่างนั้นหรือไม่

หากฉันถูกต้องและฉันควรปิดการใช้งานวัตถุประสงค์อื่นฉันควรใส่ openssl.cnf ใน config ของฉันอย่างไร

นี่คือการตั้งค่าปัจจุบันของฉัน (ปล้นเล็กน้อย):

[ 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

ฉันทำอะไรผิดที่ certs ที่สร้างขึ้นอนุญาตให้ใช้เซิร์ฟเวอร์ได้?

openssl

— SWilk
แหล่งที่มา

ตรวจทาน "cert_opt = ca_default" ซึ่งดูเหมือนว่ากำลังสร้างการแทนที่

— zedman9991

ดูเหมือนว่าเป็นคำถามที่ดีหลายปีต่อมาและไม่มีคำตอบ?

— Evan Carroll

ใช่ไม่มีคำตอบ ฉันไม่ได้คิดออกเอง แต่การทดสอบ EDI เบต้าของเราอยู่ในระหว่างดำเนินการและฉันจะต้องดำเนินการให้เสร็จสิ้นในอนาคตอันใกล้สำหรับเวอร์ชันการผลิต

— SWilk

ฉันได้รับคำตอบที่ดีที่สุดด้านล่าง แต่ถ้าคุณสามารถรวมสำเนาของผลลัพธ์จาก

openssl x509 -text -nameopt multiline -certopt no_sigdump -certopt no_pubkey -noout -in one_of_your_client_certificates.pem

และส่วนขยายจากopenssl.cnfไฟล์ของคุณฉันจะดูว่าฉันสามารถให้คำแนะนำที่เฉพาะเจาะจงมากขึ้นได้ไหม

— Calrion

คุณมีสิทธิ์ที่จะกังวลเกี่ยวกับ "การลงนาม CRL", "CA วัตถุประสงค์ใด ๆ " และ "ตัวช่วย OCSP" ซึ่งโดยปกติจะถูกสงวนไว้สำหรับใบรับรอง CA หรือใบรับรองที่ออกโดยเฉพาะสำหรับการลงนามรายการเพิกถอนใบรับรอง (CRL ซึ่งเป็นรายการใบรับรองที่ ไม่ถูกต้อง) หรือใช้งานเซิร์ฟเวอร์ OCSP (คล้ายกับ CRL แต่เป็น Online Service ที่ให้สถานะความถูกต้องสำหรับใบรับรอง)

หน้าเอกสารประกอบ OpenSSL ที่เกี่ยวข้องมีไว้สำหรับคำสั่ง x509และx509v3_config

นี่คือการกำหนดค่า OpenSSL ที่ฉันใช้สำหรับสร้างใบรับรองไคลเอ็นต์:

[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

ฉันจะพาคุณผ่านมันทีละบรรทัด:

basicConstraintsถูกตั้งค่าเป็นสำคัญซึ่งหมายถึง "ปฏิเสธใบรับรองนี้ถ้าคุณไม่เข้าใจบิตนี้" และระบุว่าใบรับรองไม่แคลิฟอร์เนีย แม้ว่าใครบางคนใช้ซอฟต์แวร์เพื่อออกใบรับรองจากใบรับรองนี้ แต่ก็ไม่น่าเชื่อถือ

การใช้คีย์เพิ่มเติมนั้นไม่จำเป็น แต่ซอฟต์แวร์บางตัวต้องมีอยู่และมีจุดประสงค์เฉพาะในรายการ รายการนี้เป็นการรับรองความถูกต้องของลูกค้า (สิ่งที่คุณกำลังพูดถึง) และการเซ็นชื่อ & การเข้ารหัสอีเมล S / MIME; คุณสามารถลบวัตถุประสงค์ S / MIME ได้อย่างปลอดภัยหากคุณไม่ต้องการ

subjectAltNameช่วยให้คุณสามารถรวมข้อมูลเกี่ยวกับเรื่องที่คุณไม่สามารถรวมไว้ในsubjectฟิลด์ นอกจากนี้ยังใช้ในใบรับรองเซิร์ฟเวอร์ของเว็บเพื่อรวมชื่อโดเมนที่อาจใช้ใบรับรองนอกเหนือจากโดเมนที่ระบุในแอตทริบิวต์ชื่อทั่วไปของหัวเรื่อง ใบรับรองเหล่านี้เรียกว่าใบรับรอง SAN (ชื่อสำรองของชื่อเรื่อง) มันเป็นเรื่องธรรมดาที่จะรวมที่อยู่อีเมลในsubjectAltNameแทนที่จะเป็นเรื่อง; คุณไม่จำเป็นต้องรวมที่อยู่อีเมลเลยและสามารถละเว้นส่วนขยายได้

crlDistributionPointsแสดงรายการสถานที่ที่มี CRL สำหรับหน่วยงานที่ออกบัตร มันบอกว่าซอฟต์แวร์กำลังพยายามตรวจสอบใบรับรอง "ที่นี่จะไปที่ไหนเพื่อดูว่าใบรับรองนี้ยังคงถูกต้องอยู่หรือไม่" สำหรับการใช้อินเทอร์เน็ตhttp://URL น่าจะดีที่สุด (CRL มีการเซ็นชื่อแบบดิจิทัลดังนั้นไม่จำเป็นต้องใช้httpsและอาจทำให้เกิดปัญหาห่วงการเชื่อถือได้)

authorityKeyIdentifierมักจะเป็นแฮช SHA-1 ของรหัสสาธารณะของ CA ที่ออก (แม้ว่ามันอาจจะเป็นค่าอื่น ๆ ก็ตาม) หากคุณมีส่วนขยายนี้ค่าจะต้องตรงกับค่าของsubjectKeyIdentifierในการออกใบรับรอง CA

authorityInfoAccessมันค่อนข้างจะเหมือนกันcrlDistributionPointsแต่มันระบุตำแหน่งที่จะรับใบรับรอง CA ที่ออกใบรับรองแทน CRL สิ่งนี้มีประโยชน์หากคุณมีสายการเชื่อถือที่ยาวนาน: เช่นปัญหา CA-1 CA-2 ซึ่งออก CA-3 ซึ่งออกใบรับรอง ซอฟต์แวร์ที่พยายามตรวจสอบใบรับรองสามารถใช้ส่วนขยายนี้เพื่อรับใบรับรอง CA-3 จากนั้นใช้ค่าในใบรับรองนั้นเพื่อรับใบรับรอง CA-2 ฯลฯ โดยปกติแล้วห่วงโซ่ใบรับรอง (ในกรณีนี้คือใบรับรอง CA-2 และใบรับรอง CA-3) จะถูกแนบมาพร้อมกับใบรับรองของหัวเรื่อง (เช่นในธุรกรรม SSL หรืออีเมล S / MIME) ฉันไม่รู้ซอฟต์แวร์ที่ใช้ส่วนขยายนี้ แต่ฉันไม่รู้ว่ามันไม่ได้ใช้กันโดยทั่วไปเช่นกัน โดยทั่วไปจะรวมอยู่ในใบรับรอง

ของทุกสิ่งที่คุณเท่านั้นจริงๆต้องbasicConstraintsและextendedKeyUsage; ข้อ จำกัด พื้นฐานจริง ๆต้องสำคัญมาก (หรือคุณเพิ่งส่งมอบใบรับรอง CA!) และโดยทั่วไปการใช้คีย์แบบขยายจะไม่ใช่

— Calrion
แหล่งที่มา

ขอบคุณสำหรับคำตอบ. ฉันหมดความหวังไปแล้ว ฉันจะอ่านมันในภายหลังในวันนี้และกลับไปหาคุณโดยเร็วที่สุด

— SWilk