مشکلات رایج SSL/TLS
رایج‌ترین پیکربندی‌های نادرست و موارد خاص در SSL/TLS — ظاهر آن‌ها، علت وقوع و اثری که بر سیستم می‌گذارند.
1. گواهی منقضی‌شده
اعتبار گواهیهر گواهی یک بازه‌ی اعتبار (Not Before / Not After) دارد. اگر زمان فعلی خارج از این بازه باشد، گواهی نامعتبر است.
خطاها و نشانه‌ها
- Chrome: NET::ERR_CERT_DATE_INVALID
- Firefox: Warning: Potential Security Risk Ahead
- CLI: certificate has expired
- CLI: verify error:num=10:certificate has expired
دلایل
- گواهی قبل از انقضا (با طول عمر ۹۰ روزه یا ۱ ساله) تمدید نشده است
- تمدید خودکار (مثل Let's Encrypt) شکست خورده یا اصلاً تنظیم نشده است
- ساعت سیستم اشتباه است — به بخش «مشکلات ساعت» در پایین مراجعه کنید
portal.company.com از Let's Encrypt (گواهی ۹۰ روزه) استفاده می‌کند. اسکریپت تمدید بعد از یک تغییر DNS از کار می‌افتد. هیچ مانیتورینگی وجود ندارد.
- اسکریپت تمدید اجرا می‌شود → اعتبارسنجی DNS شکست می‌خورد → گواهی تمدید نمی‌شود
- ۹۰ روز می‌گذرد → گواهی منقضی می‌شود
- همه‌ی کارمندان پیام «ارتباط شما خصوصی نیست» را می‌بینند
نتیجهبرخی کاربران روی ادامه کلیک می‌کنند (خطرناک)؛ کلاینت‌های API به‌شدت خطا می‌دهند و از اتصال خودداری می‌کنند.
اعتماد کاربران از بین می‌رود. کلاینت‌های API بدون امکان دور زدن خطا، اتصال را رد می‌کنند. در محیط‌های مقررات‌محور می‌تواند نقض الزامات تطبیق (compliance) باشد.
2. عدم تطابق نام میزبان (Hostname Mismatch)
اعتبار گواهیفیلد Subject Alternative Name (SAN) در گواهی باید با نام میزبانِ درخواستی کلاینت یکسان باشد. در صورت عدم تطابق، گواهی نمی‌تواند هویت آن میزبان را ثابت کند.
خطاها و نشانه‌ها
- مرورگر: The certificate is only valid for …
- مرورگر: This server could not prove that it is app.example.com
- CLI: hostname mismatch
- CLI: certificate does not match host
دلایل
- استفاده از گواهی www.example.com روی سروری که app.example.com را سرو می‌کند
- جابجایی اشتباهی گواهی به دامنه‌ای دیگر
- اتصال با IP (مثل https://203.0.113.10) در حالی که گواهی برای یک نام دامنه صادر شده است
- پیکربندی اشتباه Reverse Proxy که گواهی نادرست را به نام میزبان نگاشت می‌کند
Virtual host مربوط به api.example.com در Nginx اشتباهاً طوری تنظیم شده که از گواهی www.example.com استفاده کند.
- استقرار: در nginx.conf، ssl_certificate به www.example.com.crt اشاره می‌کند
- کلاینت درخواست https://api.example.com/v1/ را می‌فرستد
- سرور گواهی‌ای با SAN: www.example.com ارائه می‌کند
نتیجهمرورگرها هشدار عدم تطابق نشان می‌دهند. کلاینت‌های API هندشیک TLS را کلاً شکست‌خورده اعلام می‌کنند.
کلاینت‌ها نمی‌توانند تأیید کنند که واقعاً با سرور درست در ارتباط هستند. عدم تطابق می‌تواند نشانه‌ی حمله‌ی Man-in-the-Middle باشد.
3. زنجیره‌ی گواهی ناقص
زنجیره و اعتمادسرور باید هم گواهی برگ (Leaf) و هم همه‌ی گواهی‌های Intermediate را ارائه کند. اگر Intermediateها موجود نباشند، کلاینت‌هایی که آن‌ها را کش نکرده‌اند نمی‌توانند مسیری تا یک Root مورد اعتماد بسازند.
خطاها و نشانه‌ها
- unable to get local issuer certificate
- unable to verify the first certificate
- CERT_UNTRUSTED (در Node.js)
- ناپایدار: در Chrome دسکتاپ کار می‌کند، روی Android خطا می‌دهد
دلایل
- ادمین فقط گواهی برگ را نصب می‌کند و Intermediate را جا می‌گذارد
- استفاده از cert.pem به جای fullchain.pem در Let's Encrypt
- Load balancer یا پراکسی پایان‌دهنده‌ی TLS به‌اشتباه پیکربندی شده است
دامنه api.mobileapp.com از Let's Encrypt استفاده می‌کند. ادمین به‌جای fullchain.pem، فایل cert.pem را تنظیم می‌کند.
- Chrome دسکتاپ: کار می‌کند — مرورگر Intermediate مفقود را از طریق AIA می‌آورد یا از کش استفاده می‌کند
- Android قدیمی: TLS شکست می‌خورد — Intermediate کش نشده، AIA هم اجرا نمی‌شود
- تیکت‌های پشتیبانی می‌رسد: «روی لپ‌تاپ من کار می‌کند، روی موبایل خراب است»
نتیجهوقفه‌ی سرویس در محیط Production برای بخشی از کلاینت‌ها که در محیط توسعه به‌سختی قابل بازتولید است.
دستگاه‌های قدیمی، سیستم‌های تعبیه‌شده و کلاینت‌های غیرمرورگری را از کار می‌اندازد. می‌تواند باعث قطعی‌های间ی و سخت‌عیب‌یابی شود.
4. CA نامعتبر یا ناشناخته
زنجیره و اعتمادگواهی توسط CAای صادر شده که کلاینت به آن اعتماد ندارد. شامل گواهی‌های Self-signed، گواهی‌های CA خصوصی که روی کلاینت‌ها توزیع نشده‌اند و گواهی‌های صادرشده توسط CAهای عمومیِ از اعتماد خارج‌شده است.
خطاها و نشانه‌ها
- مرورگر: Your connection is not private
- مرورگر: This certificate is not trusted
- CLI: self signed certificate
- CLI: unable to get local issuer certificate
دلایل
- استفاده از گواهی Self-signed در محیط Production (به‌جای محیط توسعه)
- Root مربوط به PKI داخلی سازمان روی همه‌ی دستگاه‌ها نصب نشده است
- یک CA عمومی به‌دلیل نقض سیاست‌ها از سمت مرورگرهای اصلی از فهرست اعتماد خارج شده است
دامنه intranet.corp.local از «Corp Root CA» استفاده می‌کند. لپ‌تاپ‌های سازمانی آن را نصب دارند. یک پیمانکار با لپ‌تاپ شخصی خود متصل می‌شود.
- لپ‌تاپ سازمانی → Corp Root CA مورد اعتماد است → اتصال OK
- لپ‌تاپ پیمانکار → Corp Root CA ناشناخته → خطای TLS
نتیجهپیمانکار پیام «Certificate not trusted» را می‌بیند. اگر روی ادامه کلیک کند، عملاً یاد می‌گیرد هشدارها را نادیده بگیرد.
کاربران به نادیده گرفتن هشدارهای گواهی عادت می‌کنند — عادتی بسیار خطرناک. کلاینت‌های خارجی بدون توزیع Root CA نمی‌توانند به سرویس اعتماد کنند.
5. جفت گواهی / کلید خصوصی اشتباه
پیکربندیکلید خصوصی روی سرور با کلید عمومی داخل گواهی هم‌خوانی ندارد. گواهی و کلید، یک جفت رمزنگاری‌شده هستند و باید دقیقاً به هم مربوط باشند.
خطاها و نشانه‌ها
- SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch
- سرور نمی‌تواند Listener مربوط به TLS را در Nginx / Apache بالا بیاورد
- کلاینت‌ها قادر به تکمیل هندشیک TLS نیستند
دلایل
- قاتی شدن فایل‌ها هنگام استقرار (استفاده از .key اشتباه با .crt)
- تمدید گواهی، اما باقی گذاشتن کلید خصوصی قدیمی در تنظیمات
- خطاهای کپی/پیست هنگام ساخت CSR و کلید
ادمین server_new.key می‌سازد و server_new.crt را دریافت می‌کند، اما nginx.conf همچنان به server_old.key اشاره می‌کند.
- nginx -s reload → خطا: key values mismatch
- Nginx نمی‌تواند Listener مربوط به TLS را Bind کند
- همه‌ی ترافیک HTTPS قطع می‌شود
نتیجهتا زمانی که جفت صحیح کلید/گواهی در تنظیمات برگردانده نشود، قطع کامل محیط Production ادامه دارد.
TLS به‌طور کامل از کار می‌افتد. باعث قطعی فوری در محیط Production می‌شود.
6. عدم سازگاری پروتکل یا Cipher Suite
پیکربندیکلاینت و سرور باید روی یک نسخه‌ی TLS و یک Cipher Suite مشترک به توافق برسند. اگر گزینه‌ی مشترکی وجود نداشته باشد، هندشیک شکست می‌خورد.
خطاها و نشانه‌ها
- ssl3_get_record:wrong version number
- handshake_failure
- ERR_SSL_VERSION_OR_CIPHER_MISMATCH (در مرورگرها)
- javax.net.ssl.SSLHandshakeException (در Java)
دلایل
- سرور TLS 1.2+ را الزامی کرده اما کلاینت فقط TLS 1.0 را پشتیبانی می‌کند
- سرور Cipher Suiteهای قدیمی را غیرفعال کرده؛ کلاینت Legacy هیچ‌یک از Cipherهای جدید را پشتیبانی نمی‌کند
- میان‌افزارها (پراکسی‌ها، Load Balancerهای قدیمی) فقط پروتکل‌های منسوخ را پشتیبانی می‌کنند
تیم امنیت، سرور را فقط روی TLS 1.2/1.3 با AES-GCM + ChaCha20 قفل می‌کند. یک اپلیکیشن Legacy با Java 6 تلاش به اتصال می‌کند.
- Java 6 فقط SSLv3 / TLS 1.0 با Cipherهای قدیمی را پشتیبانی می‌کند
- در هندشیک: هیچ پروتکل/Cipher مشترکی پیدا نمی‌شود
- اتصال با SSLHandshakeException رد می‌شود
نتیجهیکپارچگی Legacy شکسته می‌شود. یا باید پروتکل قدیمی را دوباره فعال کنید یا کلاینت Java را ارتقا دهید.
نیازمند توازن بین سخت‌گیری امنیتی و سازگاری است. کلاینت‌های Legacy ممکن است به‌طور خاموش از کار بیفتند.
7. پیکربندی اشتباه SNI
پیکربندیSNI (Server Name Indication) به سرور اجازه می‌دهد چند وب‌سایت HTTPS را روی یک IP میزبانی کند و بر اساس نام میزبان، گواهی درست را انتخاب کند. بدون پیکربندی صحیح SNI، کلاینت‌ها ممکن است گواهی اشتباه دریافت کنند.
خطاها و نشانه‌ها
- برخی دامنه‌ها روی یک IP، گواهی نادرست نشان می‌دهند
- در مرورگرهای مدرن کار می‌کند، در کلاینت‌های قدیمی بدون پشتیبانی SNI شکست می‌خورد
- hostname mismatch برای دامنه‌ای که قرار است گواهی مخصوص خودش را داشته باشد
دلایل
- چند دامنه روی یک IP بدون Virtual Host سازگار با SNI
- کلاینت Legacy، SNI نمی‌فرستد → سرور گواهی پیش‌فرض (اشتباه) را می‌فرستد
- Reverse Proxy نادرست پیکربندی شده و Routing بر اساس SNI را درست انجام نمی‌دهد
آدرس 203.0.113.5 میزبان app.example.com و dashboard.example.com است؛ هر کدام گواهی مخصوص خودشان را دارند.
- کلاینت قدیمی (بدون SNI) به dashboard.example.com متصل می‌شود
- سرور گواهی پیش‌فرض را (برای app.example.com) می‌فرستد
- کلاینت با خطای hostname mismatch مواجه می‌شود
نتیجهکلاینت‌های قدیمی نمی‌توانند به dashboard.example.com دسترسی پیدا کنند. راه‌حل: IP جداگانه، یا گواهی Wildcard / چند SAN.
برای میزبانی چند سایت HTTPS روی یک IP حیاتی است. بیشتر روی کلاینت‌های قدیمی، سیستم‌های تعبیه‌شده و پراکسی‌های بدپیکربندی‌شده اثر می‌گذارد.
8. اختلاف ساعت / زمان نادرست سیستم
محیط و عملیاتبررسیهای اعتبار TLS مبتنی بر زمان هستند. اگر ساعت دستگاه به‌شدت اشتباه باشد، گواهی‌های معتبر ممکن است منقضی یا هنوز-معتبر-نشده به نظر برسند.
خطاها و نشانه‌ها
- certificate is not yet valid
- certificate has expired (در حالی که واقعاً منقضی نشده)
- خطاهای SSL هم‌زمان روی تعداد زیادی سایت
دلایل
- ساعت دستگاه روی تاریخ اشتباهی تنظیم شده است (مثلاً تنظیم کارخانه، عدم استفاده از NTP)
- زمان سرور به‌طور قابل‌توجهی از زمان واقعی منحرف شده است
تاریخ یک لپ‌تاپ به‌طور اتفاقی روی سال ۲۰۱۵ تنظیم شده است.
- کاربر به https://www.google.com می‌رود
- فیلد 'Not Before' گواهی روی سال ۲۰۲۴ است — یعنی بعد از زمان فعلیِ ۲۰۱۵ روی سیستم
- مرورگر: 'Your connection is not private'
نتیجهکاربر سایت را مقصر می‌داند. ریشه‌ی مشکل، ساعت محلی دستگاه است. راه‌حل: فعال‌سازی NTP / اصلاح زمان سیستم.
باعث بروز انبوهی از خطاهای SSL جعلی می‌شود. اعمال همگام‌سازی NTP روی همه‌ی سرورها و دستگاه‌ها حیاتی است.
9. مشکلات OCSP / ابطال گواهی
محیط و عملیاتکلاینتها ممکن است از طریق OCSP یا CRL وضعیت ابطال گواهی را بررسی کنند. اگر این بررسی‌ها شکست بخورند یا اشتباه پیکربندی شده باشند، اتصال‌ها می‌توانند مسدود شوند یا به‌صورت نامحسوس تنزل پیدا کنند.
خطاها و نشانه‌ها
- OCSP stapling error
- revocation status unknown
- کلاینت‌های سخت‌گیر اتصال را مسدود می‌کنند؛ کلاینت‌های سهل‌گیر بی‌سروصدا از آن می‌گذرند
دلایل
- Endpoint مربوط به OCSP responder در دسترس نیست یا توسط فایروال مسدود شده است
- پیکربندی اشتباه OCSP stapling (پاسخ stapled قدیمی یا نامعتبر)
- مشکلات间ی شبکه بین کلاینت و Endpoint مربوط به OCSP
سرور از OCSP stapling استفاده می‌کند اما پاسخ stapled قدیمی/منقضی‌شده می‌فرستد.
- کلاینت سخت‌گیر پاسخ stapled را دریافت می‌کند → زمان آن را بررسی می‌کند → منقضی است → رد اتصال
- کلاینت سهل‌گیر پاسخ stapled را نادیده می‌گیرد، خودش OCSP چک می‌کند یا کلاً رد می‌شود
- خرابی间ی: برخی کلاینت‌ها متصل می‌شوند، برخی نه
نتیجهخرابی间ی و سخت‌اشکال‌زدایی که به میزان سخت‌گیری کلاینت بستگی دارد.
وقتی کلید خصوصی به خطر افتاده، ابطال (revocation) حیاتی است. پیکربندی اشتباه باعث خرابی间ی وابسته به نوع کلاینت می‌شود.
10. محتوای ترکیبی (Mixed Content)
محیط و عملیاتیک صفحه‌ی HTTPS که منابع خود (اسکریپت، تصویر، CSS) را از طریق HTTP بارگذاری می‌کند. محتوای ترکیبی فعال (مانند اسکریپت‌ها) به‌خصوص خطرناک است؛ مرورگرهای مدرن روزبه‌روز بیشتر آن را به‌طور پیش‌فرض مسدود می‌کنند.
خطاها و نشانه‌ها
- Mixed Content: The page was loaded over HTTPS, but requested an insecure resource…
- مرورگر اسکریپت‌ها/استایل‌ها را از originهای http:// مسدود می‌کند
- عملکرد صفحه بی‌صدا از کار می‌افتد
دلایل
- URLهای hard-coded با http:// در HTML، JS یا CSS که هنگام مهاجرت به HTTPS به‌روزرسانی نشده‌اند
- CDN شخص ثالث یا محتوای خارجی که هنوز روی HTTP سرو می‌شود
سایت https://blog.example.com استایل‌های خودش را روی HTTPS بارگذاری می‌کند اما یک اسکریپت CDN را از طریق HTTP می‌کشد.
- صفحه لود می‌شود: https://blog.example.com/style.css → OK
- مرورگر درخواست می‌کند: http://cdn.example.com/script.js → مسدود می‌شود
- در DevTools: هشدار Mixed Content؛ قابلیت‌های تعاملی صفحه از کار می‌افتند
نتیجهمهاجم می‌تواند از طریق اسکریپت ناامن، کد تزریق کند. مرورگر آن را مسدود می‌کند، اما صفحه می‌شکند.
امنیت HTTPS را تضعیف می‌کند. امکان تزریق کد از طریق منابع ناامن را فراهم می‌کند. مرورگرهای مدرن محتوای فعالِ ترکیبی را به‌طور پیش‌فرض مسدود می‌کنند.
جمع‌بندی
مشکلات رایج SSL/TLS در چهار دسته قرار می‌گیرند. درک هر مشکل در قالب این دسته‌ها، سرعت عیب‌یابی شما را بالا می‌برد.
اعتبار گواهی
- گواهی‌های منقضی‌شده
- نام میزبان اشتباه (عدم تطابق CN/SAN)
- CA نامعتبر (Self-signed یا ناشناخته)
مشکلات زنجیره و اعتماد
- Intermediateهای گواهیِ مفقود
- CA / PKI پیکربندی‌شده به شکل نامناسب
ناسازگاری‌های پیکربندی
- جفت گواهی / کلید خصوصی اشتباه
- عدم سازگاری نسخه‌ی پروتکل یا Cipher
- پیکربندی اشتباه SNI
محیط و عملیات
- ساعت‌های سیستم نادرست (Time Skew)
- خطاهای OCSP / ابطال گواهی
- محتوای ترکیبی که امنیت HTTPS را تضعیف می‌کند
درک این مشکلات برای عیب‌یابی قطعی‌های Production، حفظ اعتماد کاربران و تضمین سازگاری میان دستگاه‌ها و کلاینت‌های مختلف حیاتی است.