عیب‌یابی TLS؛ زنجیرهٔ گواهی، SNI و تفاوت کلاینت‌ها

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

مسیر پیش‌فرض برای Ubuntu 26.10 بررسی شده است؛ گزینه‌های 26.04 LTS و 24.04 LTS نیز در دسترس‌اند. بسته‌ها را با همان انتشار و پیکربندی واقعی میزبان تطبیق دهید.

فایل CA انتخابی، ریشه‌های اعتماد توزیع را در آزمون‌های آنلاین مشخص می‌کند. در Debian و Ubuntu مسیر معمول bundle زیر /etc/ssl است؛ در خانوادهٔ Red Hat از bundle زیر /etc/pki استفاده می‌شود. مسیر انتخاب‌شده را در پنل تنظیمات می‌بینید. برای بررسی اختلاف اعتماد، backend واقعی curl و تنظیم اعتماد برنامهٔ مشکل‌دار را هم ثبت کنید؛ Java یا کانتینر ممکن است مخزن دیگری داشته باشد.

cat /etc/os-release
dpkg-query -W openssl curl ca-certificates coreutils
command -v openssl curl timeout
stat -c '%A %U %G %n' '/etc/ssl/certs/ca-certificates.crt'

بررسی را از کلاینتی شروع کنید که خطا می‌دهد. نسخهٔ OpenSSL، بک‌اند TLS در curl و زمان UTC آن را ثبت کنید. مرورگر، curl و اپلیکیشن ممکن است از مجموعهٔ اعتماد یکسانی استفاده نکنند.

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

date -u +'%Y-%m-%dT%H:%M:%SZ'
openssl version -a
curl --version

اتصال را به IP مشخص بفرستید، ولی app.example.com را هم به‌عنوان SNI و هم نام مورد انتظار معرفی کنید. گزینهٔ verify_return_error مهم است: s_client بدون آن ممکن است پس از خطای اعتبارسنجی هم ادامه دهد.

چاپ‌شدن گواهی یا عبارت اتصال موفق کافی نیست. نتیجهٔ verification و کد خروج را بخوانید. timeout بیرونی فقط مدت این بررسی را محدود می‌کند.

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

timeout 15 openssl s_client -connect '203.0.113.10:443' -servername 'app.example.com' -verify_hostname 'app.example.com' -CAfile '/etc/ssl/certs/ca-certificates.crt' -verify_return_error -brief </dev/null
printf 's_client exit=%s\n' "$?"

این درخواست DNS را فقط برای یک مقصد کنار می‌زند، اما نام HTTPS، هدر Host و SNI را حفظ می‌کند. از همان پورت در resolve و نشانی استفاده کنید؛ نیازی به تغییر hosts یا خاموش‌کردن verification نیست.

پاسخ401 یا403 نشان می‌دهد به HTTP رسیده‌اید، نه اینکه ورود به برنامه مجاز شده است. اگر نتیجه با OpenSSL فرق دارد، مجموعهٔ اعتماد و بک‌اند TLS هر دو ابزار را مقایسه کنید.

curl --cacert '/etc/ssl/certs/ca-certificates.crt' --noproxy '*' --resolve 'app.example.com:443:203.0.113.10' --connect-timeout 3 --max-time 15 -sS -o /dev/null -w 'HTTP %{http_code} TLSverify=%{ssl_verify_result}\n' 'https://app.example.com:443/'

پنل بعد فهرست گواهی‌های عمومی ارسال‌شده در handshake را نشان می‌دهد؛ این فهرست لزوماً یک زنجیرهٔ تأییدشده نیست. معمولاً سرور باید leaf و گواهی‌های میانی لازم را بفرستد؛ ریشهٔ قابل اعتماد در کلاینت قرار دارد و معمولاً ارسال آن لازم نیست.

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

timeout 15 openssl s_client -connect '203.0.113.10:443' -servername 'app.example.com' -showcerts </dev/null