زنجیره‌های گواهی
اعتماد چطور از گواهی سرور به یک Root CA که دستگاه شما از قبل به آن اعتماد دارد منتقل می‌شود — و این‌که کلاینت‌ها چطور این مسیر را اعتبارسنجی می‌کنند.
1. چرا زنجیره‌های گواهی وجود دارند
غیرممکن است که هر دستگاهی گواهی همه‌ی وب‌سایت‌ها را ذخیره کند. در عوض، دستگاه‌ها یک مجموعه‌ی کوچک از گواهی‌های Root CA مورد اعتماد را از پیش نصب دارند. زنجیره‌های گواهی اجازه می‌دهند این اعتماد از آن ریشه‌ها به میلیاردها وب‌سایت گسترش پیدا کند.
اگر یک Intermediate به خطر بیفتد و ابطال شود، فقط گواهی‌هایی که توسط آن صادر شده‌اند تحت تأثیر قرار می‌گیرند — ریشه و سایر Intermediateها معتبر باقی می‌مانند.
2. سه نوع گواهی در زنجیره
هر زنجیره‌ی گواهی از سه نقش تشکیل می‌شود. هر کدام نقش مشخصی در ایجاد اعتماد دارند.
گواهی برگ / انتهایی (Leaf / End-Entity)
روی سرور شما نصب می‌شود و در حین هندشیک TLS ارائه می‌گردد. شامل نام دامنه، کلید عمومی سرور، تاریخ‌های اعتبار و صادرکننده است.
- دامنه (Domain): www.example.com
- SAN: www.example.com, example.com
- Issuer: Example Intermediate CA 1
گواهی Intermediate CA
مجوز صدور گواهی برای گواهی‌های انتهایی را دارد. توسط Root (یا Intermediate دیگری) امضا می‌شود. مستقیماً در Trust Storeها نصب نمی‌شود.
- Subject: Example Intermediate CA 1
- Signed by: Example Root CA
گواهی Root CA
بالای زنجیره — خودامضا (self-signed). کلاینت‌ها چون این گواهی از قبل در سیستم‌عامل یا مرورگر نصب شده، به آن اعتماد می‌کنند.
- از قبل مورد اعتماد Windows / macOS / iOS / Android / Firefox است
- کلید خصوصی به‌طور آفلاین نگه‌داری می‌شود — به‌ندرت استفاده می‌گردد
3. اعتبارسنجی زنجیره چگونه انجام می‌شود
وقتی کلاینت به سرور متصل می‌شود، مجموعه‌ای از بررسی‌ها را انجام می‌دهد تا تصمیم بگیرد آیا به گواهی ارائه‌شده اعتماد کند یا نه.
ارسال گواهی + زنجیره توسط سرور
سرور گواهی برگ و معمولاً یک یا چند گواهی Intermediate را می‌فرستد. Root ارسال نمی‌شود — چون کلاینت آن را قبلاً دارد.
کلاینت مسیری تا یک Root مورد اعتماد می‌سازد
کلاینت زنجیره را لینک می‌کند: برگ → Intermediate → Root. از Intermediateهایی که سرور می‌فرستد، گواهی‌های کش‌شده‌ی محلی و Trust Store خودش استفاده می‌کند.
بررسی امضاها
امضای هر گواهی با کلید عمومی والدش (گواهی صادرکننده) بررسی می‌شود. اگر هر کدام رد شود، اتصال قبول نمی‌شود.
- کلید عمومی Root → امضای Intermediate را تأیید می‌کند
- کلید عمومی Intermediate → امضای گواهی برگ را تأیید می‌کند
تطابق نام دامنه (SAN)
نام‌های Subject Alternative Name در گواهی برگ باید شامل نام میزبان درخواستی باشند.
- درخواست برای shop.example.com — SAN شامل shop.example.com ✓
- SAN فقط www.example.com را دارد ✗ → خطای مرورگر
بررسی بازه‌ی اعتبار
تمام گواهی‌های زنجیره باید در بازه‌ی Not Before / Not After معتبر باشند.
Key Usage / Extended Key Usage
گواهی برگ باید اجازه‌ی «TLS Web Server Authentication» را داشته باشد. استفاده از گواهی‌ای که فقط برای احراز هویت کلاینت است روی یک وب‌سایت → نامعتبر است.
بررسی ابطال (CRL / OCSP)
کلاینت بررسی می‌کند که آیا هر گواهی‌ای ابطال شده است یا خیر. OCSP Stapling اجازه می‌دهد سرور مدرک ازپیش‌گرفته‌شده را ضمیمه کند تا نیاز به درخواست مستقیم کلاینت کاهش یابد.
- CRL — فهرست قابل‌دانلود گواهی‌های ابطال‌شده
- OCSP — پرس‌وجوی آنی وضعیت هر گواهی
- OCSP Stapling — سرور مدرک امضاشده را ضمیمه می‌کند
رفتار ابطال (revocation) بسته به پلتفرم و شرایط شبکه متفاوت است، اما از نظر مفهومی همیشه بخشی از فرآیند اعتبارسنجی زنجیره محسوب می‌شود.
3. چرا سرورها باید کل زنجیره را ارسال کنند
رایج‌ترین پیکربندی اشتباه TLS این است که فقط گواهی برگ ارسال شود و Intermediate ارسال نشود. اکثر کلاینت‌ها فقط Rootها را همراه خود دارند — نه Intermediateها.
زنجیره‌ی ناقص
سرور فقط گواهی برگ را می‌فرستد. کلاینت هیچ Intermediate کش‌شده‌ای ندارد → زنجیره ساخته نمی‌شود → خطاهایی مثل: 'unable to get local issuer certificate'، 'certificate verify failed'.
زنجیره‌ی کامل (درست)
سرور گواهی برگ + تمام Intermediateها را می‌فرستد. کلاینت آن‌ها را به یک Root مورد اعتماد در Trust Store خودش متصل می‌کند → موفقیت پایدار روی همه‌ی دستگاه‌ها.
برخی مرورگرها به‌طور خودکار Intermediateهای مفقود را از طریق افزونه‌ی AIA واکشی می‌کنند — اما اپ‌های موبایل و کلاینت‌های API معمولاً این کار را نمی‌کنند. همیشه زنجیره‌ی کامل را سرو کنید.
4. نمونه‌ی زنجیره در دنیای واقعی
یک زنجیره‌ی معمولی گواهی HTTPS عمومی برای www.example.com با یک Intermediate.
www.example.com ← برگ (روی سرور شما سرو می‌شود) ↓ امضاشده توسط Example Intermediate TLS CA 2026 ← Intermediate (روی سرور شما سرو می‌شود) ↓ امضاشده توسط Example Root CA ← Root (به‌صورت محلی مورد اعتماد، توسط سرور ارسال نمی‌شود)
5. چگونه زنجیره‌های گواهی را بررسی کنیم
دستورهای عملی برای این‌که ببینید سرور شما دقیقاً چه چیزی ارسال می‌کند و زنجیره کامل است یا نه.
openssl s_client (راه دور)
دقیقاً نشان می‌دهد سرور در حین هندشیک TLS چه چیزی ارسال می‌کند و هر خطای اعتبارسنجی‌ای را گزارش می‌دهد.
openssl s_client -connect example.com:443 -servername example.com -showcerts
به این‌ها نگاه کنید: گواهی برگ، گواهی(های) Intermediate، کد Verify return در انتها
خطای زنجیره‌ی ناقص: 'Verify return code: 21 (unable to verify the first certificate)'
openssl verify (فایل‌های محلی)
اعتبارسنجی یک زنجیره‌ی گواهی از روی فایل‌های PEM محلی.
openssl verify -CAfile root.pem -untrusted intermediate.pem server.pem
خروجی موفق: server.pem: OK
نمایشگر گواهی در مرورگر
روی آیکون قفل کلیک کنید → «Certificate» / «Connection is secure» → مسیر گواهی (Certificate Path) را ببینید. کل زنجیره و هر مشکل احتمالی را نشان می‌دهد.
6. کجا زنجیره‌های گواهی بیشترین اهمیت را دارند
مشکلات زنجیره بسته به نوع کلاینت به شکل‌های متفاوتی خودشان را نشان می‌دهند.
جمع‌بندی
یک زنجیره‌ی گواهی، گواهی سرور را از طریق یک یا چند Intermediate CA به یک Root مورد اعتماد متصل می‌کند و امکان اعتبارسنجی امن و مقیاس‌پذیر اعتماد را فراهم می‌سازد.
- کلیدهای Root CA آفلاین نگه داشته می‌شوند — Intermediateها صدور روزمره را انجام می‌دهند
- یک Intermediate به خطر افتاده را می‌توان ابطال کرد بدون این‌که Root را عوض کنیم
- زنجیره‌ی ناقص رایج‌ترین پیکربندی اشتباه TLS است
- زنجیره‌های Cross-Signed سازگاری با Trust Storeهای قدیمی را افزایش می‌دهند