كيف تنشئ مفتاح عميل 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 فعلاً قبل إنشاء الطلب، لأن تلك الإجابة تنتمي إلى داخل CSR. OpenVPN يربط هوية العميل تقليدياً بالاسم الشائع في الشهادة، وأدوات مثل 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

يجب أن يتطابق الملخصان. ثم اتصل وتأكد أن الهوية التي يسجلها الخادم هي التي صرّحت بها، لا مجرد أن النفق قام. وإذا فُقد المفتاح أو استُبدل الجهاز، فالجواب إبطال زائد طلب جديد من الجهاز الجديد؛ وطلب المسؤول أن يعيد إرسال مفتاح من مكان آخر لا يستعيد الأصل ويكسر بهدوء النموذج الذي جعل الطلب آمناً.