کارشناس زن کنار نمونهٔ آموزشی صدور و تمدید گواهی

WIUNIX ACADEMY

تمدید گواهی با cert-manager؛ عیب‌یابی DNS-01 از Challenge تا گواهی ارائه‌شده

مشخص کنید تمدید گواهی در ارائهٔ رکورد TXT، انتشار DNS، بررسی ACME یا بارگذاری گواهی تازه متوقف شده است؛ گواهی سالم فعلی را حفظ کنید.

پیشرفته40 دقیقه مطالعهبه‌روزرسانی
محیطت را انتخاب کن

آموزش متناسب با محیط تو

کجا اجرا می‌کنی؟

سیستم‌عامل و نسخه را انتخاب کن تا مراحل، دستورها و راه‌حل‌ها برای همان محیط نمایش داده شوند.

AlmaLinux 9بررسی‌شده با مستندات رسمی ·

آموزش متناسب با مقادیر تو

تنظیمات این آموزش

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

آی‌پی، دامنه یا پورت مثال‌ها با محیط تو فرق دارد؟ دکمهٔ زیر را باز کن، مقادیر را تغییر بده و «اعمال در آموزش» را بزن؛ سپس دستورهای به‌روز‌شده را کپی کن.

تنظیم مقادیر برای محیط من12 مقدار قابل‌تغییر

از اینجا شروع کن

در پایان چه چیزی خواهی داشت؟

زنجیرهٔ منابع cert-manager و پاسخ DNS را دنبال کنید تا محل شکست تمدید روشن شود و پس از اصلاح، گواهی واقعیِ ارائه‌شده به کاربر را تأیید کنید.

سیستم‌عامل‌ها و نسخه‌های پوشش‌داده‌شده

فرمان‌ها و تفاوت‌های محیط‌های منتخب با مستندات رسمی بررسی شده‌اند؛ این بررسی به معنای اجرای عملی روی همهٔ سیستم‌ها یا سرویس شما نیست. فرم فعلی نام‌های ساده تا ۳۲کاراکتر را می‌پذیرد؛ این محدودیت فرم است، نه Kubernetes. اگر نام واقعی طولانی‌تر است، مقدار نمونه را کپی نکنید؛ فرمان را در ویرایشگر خودتان با نام کامل تنظیم کنید. نام منبع را تغییر ندهید.

قبل از شروع

  • نصب موجود و پشتیبانی‌شدهٔ cert-manager، دسترسی مجاز به Certificate و منابع مرتبط و نسخهٔ سازگار kubectl.
  • اختیار بررسی DNS دامنه و آشنایی با ارائه‌دهنده و واگذاری‌های آن؛ اطلاعات API فقط در سازوکار محرمانهٔ فعلی نگه‌داری می‌شوند.
  • دسترسی به dig و OpenSSL و مسیر بیرونی مجاز برای بررسی گواهی؛ در صورت نیاز cmctl سازگار و تأیید مسئول صدور.
01

قدم بعدی

ابزار میزبان انتخاب‌شده را آماده کنید

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

از kubectl لینوکسیِ موجود استفاده کنید که اختلاف آن با همهٔ نسخه‌های API Server حداکثر یک نسخهٔ فرعی باشد. پیش از ادامه نسخهٔ سرور را در کانتکست مجاز ببینید. برای این عیب‌یابی kubelet یا kubeadm نصب نکنید و مخزن بستهٔ کلاینت را بازنویسی نکنید.

bash

میزبان انتخاب‌شده؛ نصب بسته فقط با مجوز تغییر همین میزبان

sudo dnf install ca-certificates bash coreutils bind-utils openssl
if ! command -v curl >/dev/null 2>&1; then sudo dnf install curl; fi
cat /etc/os-release
command -v bash curl timeout
command -v kubectl
kubectl version --client --output=yaml
dig -v
از کجا بدانم درست انجام شد؟

نسخهٔ سیستم با انتخاب شما یکسان باشد، ابزارها پیدا شوند و نسخهٔ کلاینت و سرویس با شرایط بالا سازگار باشند. اگر باینری موجود نیست یا سازگار نیست، ادامه ندهید.

حفاظت میزبان و مسیرهای نصب موجود را حفظ کنید

SELinux را در حالت enforcing و قواعد firewalld را فعال نگه دارید. ابزار کلاینت به خروجی مجازِ API، TLS یا SFTP نیاز دارد و پورت ورودی تازه‌ای لازم نیست. نتیجهٔ سرویس محدودشدهٔ systemd ممکن است با اجرای تعاملی فرق داشته باشد. خطای AVC، برچسب فایل و مجوز سرویس را با مسئول سیاست بررسی کنید؛ خاموش‌کردن SELinux یا دیوارهٔ آتش و مجوز گسترده راه‌حل نیست. خطای زنجیرهٔ اعتماد یا سیاست رمزنگاری به مقصد سازگار نیاز دارد، نه ضعیف‌کردن حفاظت سیستم. مسیر داده و پیکربندی سفارشی باید برچسب مناسب فعلی را حفظ کند؛ بازبرچسب‌گذاری بازگشتیِ کورکورانه انجام ندهید.

bash

میزبان انتخاب‌شده؛ فقط خواندن وضعیت حفاظت

if command -v getenforce >/dev/null 2>&1; then getenforce; fi
if command -v firewall-cmd >/dev/null 2>&1; then firewall-cmd --state; fi

نخست مشخص کنید تمدید در کدام مرحله متوقف شده است

Certificate گواهی و Secret مطلوب را توصیف می‌کند. CertificateRequest یک درخواست صدور را ثبت می‌کند و صادرکنندهٔ ACME برای آن Order و یک یا چند Challenge می‌سازد. خطا ممکن است پیش از ساخت رکورد DNS، هنگام انتشار و بررسی داخلی، در اعتبارسنجی مرجع صدور یا پس از صدور و هنگام بارگذاری گواهی در سرویس رخ دهد. فقط Ready=False را نبینید؛ مرحلهٔ دقیق را پیدا کنید.

این آموزش نصب cert-manager یا نسخه‌ای عمومی برای همهٔ ارائه‌دهندگان DNS نیست. اطلاعات API باید در Secret محافظت‌شدهٔ موجود بمانند. محتوای Secret را در فرم، لاگ یا آرگومان فرمان وارد نکنید.

02

قدم بعدی

نام منبع، دامنه و زمان تمدید را از هم تفکیک کنید

کانتکست مجاز و نام دقیق Certificate را تأیید کنید. شرایط منبع، notAfter، renewalTime و نام و نوع صادرکننده را بخوانید. ممکن است گواهی فعلی هنوز معتبر باشد، درحالی‌که تمدید آن شکست می‌خورد. نام منبع الزاماً نام دامنهٔ SAN یا نام Secret گواهی نیست.

bash

خط فرمان؛ فقط در محیطی که مجوز بررسی آن را دارید

kubectl config get-contexts 'lab'
kubectl --context='lab' -n 'academy-lab' get certificate 'api-tls' -o yaml
kubectl --context='lab' -n 'academy-lab' describe certificate 'api-tls'
از کجا بدانم درست انجام شد؟

Certificate درست، زمان انقضا و تمدید و issuerRef مربوط به آن مشخص شده باشند.

03

قدم بعدی

درخواست و Challenge مربوط به همین تمدید را پیدا کنید

فهرست منابع فضای نام را بخوانید و ownerReferences را از Certificate تا درخواست جاری دنبال کنید. وجود درخواست‌های قدیمی طبیعی است؛ منبعی را انتخاب کنید که زمان و نسل آن با تمدید ناموفق مرتبط است. نام‌های این فیلدها شناسه‌اند، نه اطلاعات احراز هویت. برای پاک‌کردن نشانهٔ خطا، درخواست‌ها را حذف نکنید.

bash

خط فرمان؛ فقط در محیطی که مجوز بررسی آن را دارید

kubectl --context='lab' -n 'academy-lab' get certificaterequest,order,challenge
kubectl --context='lab' -n 'academy-lab' describe certificaterequest 'api-tls-1'
kubectl --context='lab' -n 'academy-lab' describe order 'api-tls-order'
kubectl --context='lab' -n 'academy-lab' describe challenge 'api-tls-challenge'
از کجا بدانم درست انجام شد؟

CertificateRequest، Order و Challenge درست و رابطهٔ مالکیت و زمان آن‌ها ثبت شده باشند.

04

قدم بعدی

صادرکننده را در محدودهٔ درست بررسی کنید

پنل متناسب با issuerRef.kind را انتخاب کنید. Issuer به فضای نام Certificate تعلق دارد؛ ClusterIssuer سراسری است و محل جست‌وجوی Secret آن از تنظیم cluster-resource namespace پیروی می‌کند. پیش از دست‌کاری مجوز DNS، آمادگی صادرکننده، ثبت حساب ACME و انتخاب solver بر اساس دامنه و selector را بررسی کنید.

bash

خط فرمان؛ فقط در محیطی که مجوز بررسی آن را دارید

# Run only the command matching issuerRef.kind:
kubectl --context='lab' -n 'academy-lab' describe issuer 'letsencrypt'
# OR, for ClusterIssuer:
kubectl --context='lab' describe clusterissuer 'letsencrypt'
از کجا بدانم درست انجام شد؟

نوع و محدودهٔ صادرکننده، وضعیت حساب و انتخاب solver با Certificate مورد بررسی سازگار باشند.

همهٔ آموزش‌های آکادمی ↗