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

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

محیط تمرین: Ubuntu 24.04 و OpenSSL 3؛ فایل‌های server.key و server.csr از شب چهارم؛ بدون root.

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

دفتر ثبت صادرکننده#

در این تمرین، CA مستقیماً گواهی سرویس را امضا می‌کند. در طراحی عملیاتی معمولاً ریشه از صادرکنندهٔ آنلاین جدا می‌شود؛ گم شدن کلید ریشه مشکل یک سرویس نیست، مشکل کل مجموعهٔ اعتماد است. ابزار openssl ca برای یادگیری مفید است؛ آن را بدون طراحی دسترسی، پشتیبان و هم‌زمانی به سرویس صدور سازمان تبدیل نکن.

در ~/lpic303/pki:

umask 077
cd ~/lpic303/pki
mkdir -p newcerts
touch index.txt
printf '1000\n' > serial
printf '1000\n' > crlnumber
openssl genpkey -algorithm RSA -aes-256-cbc \
  -pkeyopt rsa_keygen_bits:3072 -out ca.key
openssl req -new -x509 -key ca.key -days 365 -sha256 -out ca.crt \
  -subj '/CN=LPIC303 Lab Root' \
  -addext 'basicConstraints=critical,CA:TRUE' \
  -addext 'keyUsage=critical,keyCertSign,cRLSign'

OpenSSL گذرواژهٔ CA را تعاملی می‌پرسد. فایل ca.cnf را در همین پوشه بساز:

[ca]
default_ca = lab
[lab]
dir = .
database = $dir/index.txt
new_certs_dir = $dir/newcerts
certificate = $dir/ca.crt
private_key = $dir/ca.key
serial = $dir/serial
crlnumber = $dir/crlnumber
default_md = sha256
default_days = 30
default_crl_days = 7
policy = names
unique_subject = no
[names]
commonName = supplied
[server]
basicConstraints = critical,CA:FALSE
keyUsage = critical,digitalSignature,keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = DNS:library.example.test
[client]
basicConstraints = critical,CA:FALSE
keyUsage = critical,digitalSignature
extendedKeyUsage = clientAuth

این فایل قواعد افزونه‌ها را تعیین می‌کند؛ اطلاعات CSR به‌صورت کور کپی نمی‌شوند.

openssl ca -config ca.cnf -extensions server -in server.csr -out server.crt -notext
openssl verify -CAfile ca.crt -purpose sslserver server.crt
openssl ca -config ca.cnf -extensions server -in server.csr -out revoked.crt -notext
openssl ca -config ca.cnf -revoke revoked.crt
openssl ca -config ca.cnf -gencrl -out ca.crl
openssl verify -CAfile ca.crt -CRLfile ca.crl -crl_check server.crt
openssl verify -CAfile ca.crt -CRLfile ca.crl -crl_check revoked.crt

صدور را پس از خواندن مشخصات تأیید کن. فقط گواهی دوم ابطال می‌شود؛ server.crt برای درس بعد سالم می‌ماند. آزمون آخر باید با خطای ابطال شکست بخورد. بررسی معمولی بدون -crl_check لزوماً از ابطال خبر ندارد: داشتن CRL به معنی استفادهٔ خودکار تمام کلاینت‌ها از آن نیست.

سه سازوکار متفاوت#

CRL فهرست امضاشدهٔ ابطال‌هاست؛ OCSP وضعیت یک گواهی را پاسخ می‌دهد. Certificate Transparency ثبت عمومی صدور را قابل مشاهده می‌کند و جای ابطال نیست. انقضا هم زمان پایان اعتبار است، حتی اگر کلید هرگز لو نرفته باشد.

ACME پروتکل خودکارسازی صدور و تمدید است؛ certbot یک کلاینت آن است. نام .test آزمایشگاه برای گواهی عمومی نیست؛ آزمون ACME را فقط با دامنهٔ تحت کنترل خودت و محیط staging انجام بده. CFSSL ابزار دیگری برای کار با PKI است، نه همان certbot. سیاست تمدید باید نصب و reload و آزمون پس از تمدید را هم شامل شود.

مأموریت امشب#

از openssl x509 -in server.crt -noout -dates -serial -issuer شواهد بگیر. آیا حذف revoked.crt از دیسک، کلاینت‌های دیگر را از ابطال آگاه می‌کند؟ پاسخ: نه، وضعیت باید از سازوکار بررسی معتبر به آن‌ها برسد.

مرجع فرمان‌ها: openssl-ca و openssl-verify . سازوکار خودکارسازی: مستندات ACME در Let’s Encrypt و CFSSL .