วิธีสร้างคีย์ไคลเอนต์ VPN และส่ง CSR เพื่อลงนาม

ไม่ช้าก็เร็ว ผู้ใช้ VPN จะเสนอส่งคีย์ส่วนตัวทางอีเมลเพื่อให้ผู้ดูแลระบบสร้างใบรับรองได้ และข้อเสนอนั้นคือสิ่งที่ต้องปฏิเสธ ขั้นตอนที่ได้ผลเก็บคีย์ไว้ที่ไคลเอนต์ตั้งแต่คำสั่งแรก ไคลเอนต์สร้างคีย์ ส่งคำขอลงนามใบรับรอง ผู้ออกใบรับรองตรวจสอบและอนุมัติ และใบรับรองที่ลงนามแล้วก็กลับมาอยู่ข้างคีย์ที่สร้างมันขึ้นมา รายการตรวจสอบด้านล่างล้มเหลวแบบปิดในทุกขั้นตอน และนั่นคือประเด็น เพราะสองในห้าขั้นตอนคือขั้นตอนที่ผู้คนข้ามเมื่อรีบ

ขั้นที่ 1: สร้างคีย์ในที่ที่มันจะอยู่

สร้างบนเครื่องที่จะเก็บคีย์และเก็บไว้ที่นั่น คีย์ซอฟต์แวร์จะอยู่ในไฟล์ที่มีสิทธิ์เข้มงวด คีย์ที่หนุนด้วยฮาร์ดแวร์หรืออยู่ในที่เก็บที่จัดการจะไม่กลายเป็นไฟล์เลย และเส้นทางการลงทะเบียนมักเป็นเครื่องมือแยกต่างหากไม่ใช่คำสั่ง OpenSSL ไม่ว่าอย่างไร ก็ไม่มีใครจำเป็นต้องเห็นครึ่งส่วนตัว

ขั้นตอนซอฟต์แวร์มีลักษณะเช่นนี้ โดยสร้างคีย์และคำขอในเซสชันเดียว:

umask 077
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out client.key
openssl req -new -key client.key -out client.csr -subj "/CN=alice-vpn/O=Example"

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

ขั้นที่ 2: ใส่ตัวตนไว้ในคำขอ ไม่ใช่ในอีเมล

ตัดสินใจว่า VPN ตรวจสอบตัวตนอะไรจริง ๆ ก่อนสร้างคำขอ เพราะคำตอบนั้นอยู่ภายใน CSROpenVPN เชื่อมโยงตัวตนของไคลเอนต์กับชื่อสามัญของใบรับรองตามธรรมเนียม และเครื่องมืออย่าง strongSwan จับคู่สตริงตัวตนกับชื่อเรื่องหรือชื่อทางเลือกของชื่อเรื่อง อีเมลที่บอกว่าฉันชื่อ alice ไม่ใช่หลักฐาน และคำขอที่ชื่อเรื่องบอกเช่นเดียวกันก็ดีกว่าเพียงเล็กน้อย

เพิ่มชื่อทางเลือกของชื่อเรื่องเมื่อตัวตรวจสอบของคุณตรวจสอบหนึ่งรายการ เพราะการจับคู่สมัยใหม่มักไม่สนใจ CN แบบเก่า:

openssl req -new -key client.key -out client.csr \
  -subj "/CN=alice-vpn/O=Example" \
  -addext "subjectAltName=DNS:alice-vpn"

ทำให้ CN สั้น คงที่ และผูกกับบัญชีไม่ใช่รุ่นแล็ปท็อป ชื่อที่มีหมายเลขซีเรียลของอุปกรณ์ผู้ใช้คือปัญหาซัพพอร์ตที่รอการเปลี่ยนฮาร์ดแวร์ครั้งแรก

ขั้นที่ 3: ตรวจสอบคำขอก่อนลงนาม

ผู้ออกใบรับรองตรวจสอบสองสิ่งที่ต่างกัน และการหลอมรวมทั้งสองคือข้อผิดพลาดคลาสสิก อย่างแรก คำขอมีความสอดคล้องภายใน ลายเซ็นถูกตรวจสอบกับคีย์สาธารณะที่มันพกพา อย่างที่สอง ผู้ขอมีสิทธิ์ในสิ่งที่คำขอเรียกร้อง และไม่มีการตรวจสอบเชิงรหัสใดตอบสิ่งนั้นได้

ส่วนกลไกคือคำสั่งเดียว และควรพิมพ์ผลการตรวจสอบพร้อมกับชื่อเรื่อง:

openssl req -in client.csr -noout -verify -subject
openssl req -in client.csr -noout -pubkey | openssl pkey -pubin -noout -text

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

ขั้นที่ 4: อนุญาต แล้วลงนามด้วยส่วนขยายที่ชัดเจน

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

cat > client.ext <<'EOF'
basicConstraints = CA:FALSE
keyUsage = digitalSignature
extendedKeyUsage = clientAuth
EOF
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -days 365 -extfile client.ext -out client.crt

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

บันทึกสิ่งที่ออกให้: หมายเลขซีเรียล ชื่อเรื่อง ตัวตนที่ขอ ผู้อนุมัติ และวันหมดอายุ บันทึกนั้นคือสิ่งที่การตัดสินใจเพิกถอนในภายหลังพึ่งพา และไม่สามารถสร้างใหม่จากใบรับรองเพียงอย่างเดียวได้หากร่องรอยการลงทะเบียนอยู่เพียงในกล่องจดหมาย

ขั้นที่ 5: ติดตั้งข้างคีย์ที่ตรงกันและพิสูจน์คู่คีย์

ไคลเอนต์ได้รับ ใบรับรองและห่วงโซ่ของผู้ออกใบรับรอง ไม่ใช่คีย์. ก่อนเชื่อมต่อ ให้ยืนยันว่าใบรับรองจับคู่กับคีย์ที่มีอยู่บนดิสก์จริง เพราะคู่ที่ไม่ตรงกันจะสร้างความล้มเหลวในการจับมือที่สับสนในภายหลังมาก:

openssl x509 -in client.crt -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256
openssl pkey -in client.key -pubout -outform DER | openssl sha256

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