WIUNIX ACADEMY
تمدید گواهی با cert-manager؛ عیبیابی DNS-01 از Challenge تا گواهی ارائهشده
صفحهٔ 2 از 3؛ مراحل قبلی و پیشنیازها را پیش از ادامه مرور کن.
آموزش متناسب با محیط تو
کجا اجرا میکنی؟
سیستمعامل و نسخه را انتخاب کن تا مراحل، دستورها و راهحلها برای همان محیط نمایش داده شوند.
آموزش متناسب با مقادیر تو
تنظیمات این آموزش
مقادیر نمونه را برای محیط خودت تنظیم کن؛ متن و دستورهای مرتبط با هم تغییر میکنند. رمز، کلید خصوصی و توکن وارد نکن. مقادیر فقط در همین زبانه نگهداری میشوند و به سرور یا لینک اشتراکگذاری فرستاده نمیشوند. پیش از اجرا، DNS، گواهیها و سیاست شبکهٔ واقعی را بررسی کن.
آیپی، دامنه یا پورت مثالها با محیط تو فرق دارد؟ دکمهٔ زیر را باز کن، مقادیر را تغییر بده و «اعمال در آموزش» را بزن؛ سپس دستورهای بهروزشده را کپی کن.
تنظیم مقادیر برای محیط من12 مقدار قابلتغییر
قدم بعدی
شکست ساخت رکورد را با تأخیر دیدهشدن آن اشتباه نگیرید
اگر presented=false است و خطای ارائهدهنده ثبت شده، انتخاب solver، ارجاع Secret، مجوز API، تشخیص zone و دسترسی ارائهدهنده را بررسی کنید. presented=true فقط میگوید solver تصور میکند رکورد را ارائه کرده؛ دیدهشدن عمومی و معتبر آن را ثابت نمیکند. تغییر مجوز را از مسیر مدیریت Secret و فقط برای عملیات و zone لازم انجام دهید؛ دسترسی کل حساب راهحل مناسبی نیست.
خط فرمان؛ فقط در محیطی که مجوز بررسی آن را دارید
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مشخص شود خطا پیش از ارائهٔ رکورد رخ داده یا پس از آن و در مرحلهٔ انتشار و بررسی است.
قدم بعدی
مالک واقعی رکورد و سرور DNS پاسخگوی اصلی دامنه (authoritative) را پیدا کنید
از میزبان مجازِ دارای dig، نام دقیق Challenge را بررسی کنید. در گواهی wildcard باید نام پایه و در واگذاری زیرشاخه باید محدودهٔ واقعی DNS را در نظر بگیرید. CNAME میتواند محل TXT را عوض کند؛ cert-manager فقط در صورت تنظیم راهبرد مربوط، آن را دنبال میکند. پنل ثبت دامنه الزاماً سرور DNS اصلی دامنه (authoritative) نیست.
فرمانهای TXT بعدی فقط zone معمولیِ بدون CNAME و بدون واگذاری مستقل زیرشاخهٔ Challenge را پوشش میدهند. اگر چنین واگذاریای دیدید، این مسیر اجرایی را متوقف کنید و با مسئول DNS و cert-manager نام مؤثر و سرور آن را تعیین کنید. فرمان دارای نام ثابت را علیه نام اشتباه اجرا نکنید.
خط فرمان؛ فقط در محیطی که مجوز بررسی آن را دارید
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 یا واگذاری مستقل، پیش از پنل بعد توقف کنید.
قدم بعدی
پاسخ مستقیم سرور اصلی دامنه را با پاسخ resolver مقایسه کنید
در dns_server آدرس واقعی یکی از سرورهای اصلی دامنهِ مرحلهٔ قبل را وارد کنید. پاسخ TXT غیربازگشتی باید مقدار مورد انتظار Challenge را در نام درست نشان دهد. پاسخ resolver ممکن است بهعلت حافظهٔ نهان مثبت یا منفی دیرتر تغییر کند. مقدار TXT مربوط به ACME با توکن API ارائهدهنده فرق دارد؛ توکن را چاپ نکنید. وجود چند TXT همزمان میتواند برای اعتبارسنجیهای موازی درست باشد.
خط فرمان؛ فقط در محیطی که مجوز بررسی آن را دارید
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 مقایسه شده باشد.
قدم بعدی
اگر DNS عمومی درست است، مسیر بررسی داخلی را بررسی کنید
وقتی TXT در سرور اصلی عمومی دامنه درست است اما self-check جلو نمیرود، resolver کلاستر، خروجی DNS و دسترسی به SOA را بررسی کنید. cert-manager معمولاً از resolver بازگشتی برای کشف zone و سپس بررسی معتبر استفاده میکند، مگر پرچمهای موجود این رفتار را تغییر داده باشند. آرگومانهای فعلی کنترلر را فقط بخوانید. تغییر resolver سفارشی یا حالت recursive-only بر همهٔ صدورهای آن کنترلر اثر دارد و باید با مسئول آن و راه بازگشت انجام شود.
خط فرمان؛ فقط در محیطی که مجوز بررسی آن را دارید
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 عمومی و کنترلر یا نبود شواهد کافی مشخص شده باشد؛ تنظیم سراسری خودسرانه تغییر نکند.
قدم بعدی
علت را اصلاح کنید و برای تلاش دوباره فشار مصنوعی نسازید
پس از اصلاح علت در تنظیم صادرکننده، ارائهدهنده یا منبع اصلی، اجازه دهید کنترلر با روال معمول خود درخواست را دوباره بررسی کند. حذف پیدرپی TLS Secret، Order یا کلید حساب ACME مشکل محدودیت نرخ یا اعتبارسنجی نامعتبر را حل نمیکند. اگر تلاش دستی مجاز لازم است، فقط پس از بررسی پاسخ مرجع صدور و دامنهٔ اثر، از عملیات پشتیبانیشدهٔ تمدید در cmctl استفاده کنید. برای آزمایش تازه و مستقل، محیط staging مناسبتر است.
خط فرمان؛ فقط در محیطی که مجوز بررسی آن را دارید
# 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 حفظ میشود.
قدم بعدی
گواهیای را بررسی کنید که کاربر واقعاً دریافت میکند
Ready بودن Certificate ثابت نمیکند ingress گواهی تازه را بارگذاری کرده یا شما به مقصد درست رسیدهاید. از مسیر بیرونی مجاز، با SNI و بررسی نام میزبان اتصال بگیرید و تاریخ اعتبار و SAN را بخوانید. در مرجع خصوصی، زنجیرهٔ اعتماد مصوب را فراهم کنید؛ بررسی اعتبار را خاموش نکنید. این فرمان کلید خصوصی را نمایش نمیدهد.
خط فرمان؛ فقط در محیطی که مجوز بررسی آن را دارید
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 مورد انتظار را داشته باشد.