لینوکس ۳۰۳؛ شب ۷: mTLS؛ این بار کلاینت هم کارت نشان می‌دهد

کتابخانه برای پنل حسابداری فقط اتصال رمز‌شده نمی‌خواهد؛ باید بداند چه کسی پشت اتصال است. یک گواهی کلاینت می‌سازیم و در ورودی پنل، هم نبودن گواهی و هم داشتن گواهی معتبر را امتحان می‌کنیم.

این جلسه بخشی از دورهٔ لینوکس ۳۰۳ در ۴۰ شب است.

محیط تمرین: Apache شب ششم روی srv؛ CA شب پنجم؛ یک کلاینت با curl و OpenSSL.

جایگاه در دوره: هدف‌های 331.2 آزمون 303-300.

احراز هویت با مجوز انجام کار فرق دارد#

mTLS یعنی TLS متقابل؛ سرور و کلاینت هر دو گواهی ارائه می‌کنند. داشتن گواهی صادرشده از CA پذیرفته‌شده هنوز مجوز خواندن هر پروندهٔ کتابخانه نیست. برنامه باید هویت گواهی را به نقش و مجوز مربوط کند. صدور تمام گواهی‌های کلاینت از یک CA عمومیِ بزرگ معمولاً مرز موردنظر یک سازمان را نمی‌سازد.

در ماشین CA، داخل پوشهٔ PKI:

cd ~/lpic303/pki
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=accountant-lab'
openssl ca -config ca.cnf -extensions client -in client.csr -out client.crt -notext
openssl verify -CAfile ca.crt -purpose sslclient client.crt
openssl pkcs12 -export -inkey client.key -in client.crt \
  -certfile ca.crt -out accountant.p12

فقط کلاینت client.key و client.crt را دریافت می‌کند؛ بستهٔ PKCS#12 برای import در برنامه‌های سازگار است و با گذرواژه محافظت می‌شود. فایل خصوصی را از کانال امن بفرست. CA و گواهی‌های عمومی را با کلید CA اشتباه نگیر.

در ورودی ساختمان نگهبان بگذار#

در VirtualHost شب ششم، احراز هویت را برای کل آن میزبان فعال کن؛ این انتخاب از پیچیدگی احراز هویت دیرهنگام در مسیرهای مختلف جلوگیری می‌کند:

SSLCACertificateFile /etc/apache2/lpic303/ca.crt
SSLVerifyClient require
SSLVerifyDepth 1

پس از apache2ctl configtest و reload، از کلاینتی که فایل‌هایش را در ~/lpic303/pki گذاشته‌ای:

curl --cacert ~/lpic303/pki/ca.crt \
  --resolve library.example.test:443:192.168.56.10 \
  https://library.example.test/
curl --cacert ~/lpic303/pki/ca.crt \
  --cert ~/lpic303/pki/client.crt --key ~/lpic303/pki/client.key \
  --resolve library.example.test:443:192.168.56.10 \
  https://library.example.test/

درخواست اول باید رد شود؛ شکل خطا می‌تواند با نسخهٔ TLS و کلاینت فرق کند. درخواست دوم باید پس از احراز هویت به HTTP برسد. گواهی server.crt با کاربرد serverAuth را به‌جای گواهی کلاینت بده و تفاوت را بررسی کن. برای کنترل ابطال کلاینت، CRL تازه را به سرور برسان و تنظیم‌های SSLCARevocationFile و SSLCARevocationCheck را طبق سیاست CA به‌کار ببر؛ فقط ابطال در دفتر CA کافی نیست.

ارتباط با جزوه‌های LDAP و SMTP#

TLS یک لایهٔ انتقال است؛ SASL چارچوب روش‌های احراز هویت برنامه‌ای است. StartTLS هم ارتقای اتصال موجود به TLS است. اگر بعداً LDAP آزمایشگاهی ساختی، ldapsearch -ZZ الزام موفقیت StartTLS را می‌دهد؛ نام میزبان و CA باید درست باشند. در SMTP، داشتن TLS به معنی بسته بودن open relay نیست: قواعد relay و احراز هویت جدا باید بررسی شوند.

جزوه‌های قدیمی LDAP، Samba و SMTP را برای فهم این مرزها مرور می‌کنیم؛ دستورهای slapd.conf قدیمی و رمزهای نمونهٔ آن‌ها، پیکربندی آمادهٔ سرور امروزی نیستند. برای بازگشت درس، سه directive mTLS را حذف، configtest و reload کن.

تمرین: گواهی معتبر یک «بازدیدکننده» چرا نباید مجوز حسابدار بدهد؟ راهنما: بررسی CA مرحلهٔ شناخت اعتبار هویت است؛ نگاشت نقش باید جدا اعمال شود. منابع: احراز هویت کلاینت در Apache و TLS در OpenLDAP 2.6 .