← شروع آموزش

WIUNIX ACADEMY

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

صفحهٔ 2 از 3؛ مراحل قبلی و پیش‌نیازها را پیش از ادامه مرور کن.

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

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

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

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

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

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

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

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

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

قدم بعدی

شکست ساخت رکورد را با تأخیر دیده‌شدن آن اشتباه نگیرید

اگر presented=false است و خطای ارائه‌دهنده ثبت شده، انتخاب solver، ارجاع Secret، مجوز API، تشخیص zone و دسترسی ارائه‌دهنده را بررسی کنید. presented=true فقط می‌گوید solver تصور می‌کند رکورد را ارائه کرده؛ دیده‌شدن عمومی و معتبر آن را ثابت نمی‌کند. تغییر مجوز را از مسیر مدیریت Secret و فقط برای عملیات و zone لازم انجام دهید؛ دسترسی کل حساب راه‌حل مناسبی نیست.

bash

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

kubectl --context='lab' -n 'academy-lab' get challenge 'api-tls-challenge' -o jsonpath='{.spec.dnsName}{"\n"}{.spec.type}{"\n"}{.status.presented}{"\n"}{.status.processing}{"\n"}{.status.reason}{"\n"}'
kubectl --context='lab' -n 'cert-manager' logs deployment/cert-manager --since=15m --tail=200
از کجا بدانم درست انجام شد؟

مشخص شود خطا پیش از ارائهٔ رکورد رخ داده یا پس از آن و در مرحلهٔ انتشار و بررسی است.

06

قدم بعدی

مالک واقعی رکورد و سرور DNS پاسخ‌گوی اصلی دامنه (authoritative) را پیدا کنید

از میزبان مجازِ دارای dig، نام دقیق Challenge را بررسی کنید. در گواهی wildcard باید نام پایه و در واگذاری زیرشاخه باید محدودهٔ واقعی DNS را در نظر بگیرید. CNAME می‌تواند محل TXT را عوض کند؛ cert-manager فقط در صورت تنظیم راهبرد مربوط، آن را دنبال می‌کند. پنل ثبت دامنه الزاماً سرور DNS اصلی دامنه (authoritative) نیست.

فرمان‌های TXT بعدی فقط zone معمولیِ بدون CNAME و بدون واگذاری مستقل زیرشاخهٔ Challenge را پوشش می‌دهند. اگر چنین واگذاری‌ای دیدید، این مسیر اجرایی را متوقف کنید و با مسئول DNS و cert-manager نام مؤثر و سرور آن را تعیین کنید. فرمان دارای نام ثابت را علیه نام اشتباه اجرا نکنید.

bash

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

dig +trace '_acme-challenge.api.example.com.' TXT
dig +noall +answer '_acme-challenge.api.example.com.' CNAME
dig +noall +answer 'example.com.' SOA
dig +noall +answer 'example.com.' NS
از کجا بدانم درست انجام شد؟

سرور اصلی دامنه و نبود یا وجود واگذاری روشن شده باشد؛ در صورت CNAME یا واگذاری مستقل، پیش از پنل بعد توقف کنید.

07

قدم بعدی

پاسخ مستقیم سرور اصلی دامنه را با پاسخ resolver مقایسه کنید

در dns_server آدرس واقعی یکی از سرورهای اصلی دامنهِ مرحلهٔ قبل را وارد کنید. پاسخ TXT غیر‌بازگشتی باید مقدار مورد انتظار Challenge را در نام درست نشان دهد. پاسخ resolver ممکن است به‌علت حافظهٔ نهان مثبت یا منفی دیرتر تغییر کند. مقدار TXT مربوط به ACME با توکن API ارائه‌دهنده فرق دارد؛ توکن را چاپ نکنید. وجود چند TXT هم‌زمان می‌تواند برای اعتبارسنجی‌های موازی درست باشد.

bash

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

dig @'192.0.2.53' +norecurse +time=3 +tries=1 '_acme-challenge.api.example.com.' TXT
dig +time=3 +tries=1 '_acme-challenge.api.example.com.' TXT
dig @'192.0.2.53' +tcp +norecurse +time=3 +tries=1 '_acme-challenge.api.example.com.' TXT
از کجا بدانم درست انجام شد؟

مقدار TXT در سرور اصلی دامنه و resolver جداگانه ثبت و با مقدار مورد انتظار Challenge مقایسه شده باشد.

08

قدم بعدی

اگر DNS عمومی درست است، مسیر بررسی داخلی را بررسی کنید

وقتی TXT در سرور اصلی عمومی دامنه درست است اما self-check جلو نمی‌رود، resolver کلاستر، خروجی DNS و دسترسی به SOA را بررسی کنید. cert-manager معمولاً از resolver بازگشتی برای کشف zone و سپس بررسی معتبر استفاده می‌کند، مگر پرچم‌های موجود این رفتار را تغییر داده باشند. آرگومان‌های فعلی کنترلر را فقط بخوانید. تغییر resolver سفارشی یا حالت recursive-only بر همهٔ صدورهای آن کنترلر اثر دارد و باید با مسئول آن و راه بازگشت انجام شود.

bash

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

kubectl --context='lab' -n 'cert-manager' get deployment cert-manager -o jsonpath='{range .spec.template.spec.containers[*]}{.name}{"\n"}{.args}{"\n"}{end}'
kubectl --context='lab' -n 'cert-manager' get networkpolicy
kubectl --context='lab' -n 'academy-lab' describe challenge 'api-tls-challenge'
از کجا بدانم درست انجام شد؟

تفاوت دید DNS عمومی و کنترلر یا نبود شواهد کافی مشخص شده باشد؛ تنظیم سراسری خودسرانه تغییر نکند.

09

قدم بعدی

علت را اصلاح کنید و برای تلاش دوباره فشار مصنوعی نسازید

پس از اصلاح علت در تنظیم صادرکننده، ارائه‌دهنده یا منبع اصلی، اجازه دهید کنترلر با روال معمول خود درخواست را دوباره بررسی کند. حذف پی‌درپی TLS Secret، Order یا کلید حساب ACME مشکل محدودیت نرخ یا اعتبارسنجی نامعتبر را حل نمی‌کند. اگر تلاش دستی مجاز لازم است، فقط پس از بررسی پاسخ مرجع صدور و دامنهٔ اثر، از عملیات پشتیبانی‌شدهٔ تمدید در cmctl استفاده کنید. برای آزمایش تازه و مستقل، محیط staging مناسب‌تر است.

bash

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

# Optional: only after the cause is corrected and the owner authorizes renewal:
cmctl renew --context='lab' --namespace='academy-lab' 'api-tls'
kubectl --context='lab' -n 'academy-lab' describe certificate 'api-tls'
kubectl --context='lab' -n 'academy-lab' get certificaterequest,order,challenge
از کجا بدانم درست انجام شد؟

درخواست مرتبط بدون تکرار کورکورانه به valid و Ready می‌رسد؛ در شکست، دلیل CA حفظ می‌شود.

10

قدم بعدی

گواهی‌ای را بررسی کنید که کاربر واقعاً دریافت می‌کند

Ready بودن Certificate ثابت نمی‌کند ingress گواهی تازه را بارگذاری کرده یا شما به مقصد درست رسیده‌اید. از مسیر بیرونی مجاز، با SNI و بررسی نام میزبان اتصال بگیرید و تاریخ اعتبار و SAN را بخوانید. در مرجع خصوصی، زنجیرهٔ اعتماد مصوب را فراهم کنید؛ بررسی اعتبار را خاموش نکنید. این فرمان کلید خصوصی را نمایش نمی‌دهد.

bash

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

set -o pipefail
timeout 15s openssl s_client -connect 'api.example.com:443' -servername 'api.example.com' -verify_hostname 'api.example.com' -verify_return_error </dev/null | openssl x509 -noout -dates -serial -ext subjectAltName
از کجا بدانم درست انجام شد؟

نام میزبان و زنجیرهٔ اعتماد تأیید شوند و گواهی ارائه‌شده، تاریخ اعتبار و SAN مورد انتظار را داشته باشد.

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