چگونه کلید کارخواه 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

دو خلاصه باید یکی باشند. سپس وصل شوید و تأیید کنید هویتی که سرور ثبت می‌کند همانی است که مجاز کرده‌اید، نه فقط اینکه تونل بالا آمده است. اگر کلید گم شود یا دستگاه عوض شود، پاسخ ابطال به‌همراه درخواست تازه از دستگاه جدید است؛ خواستن از مدیر که کلیدی از جای دیگر برگرداند اصل را بازیابی نمی‌کند و بی‌صدا مدلی را می‌شکند که درخواست را ایمن می‌کرد.