این خطا در مرورگرهای فارسی معمولاً با پیام‌هایی مثل «اتصال شما خصوصی نیست»، «گواهی امنیتی این سایت مشکل دارد» یا در نسخه‌های قدیمی‌تر «مشکلی در مجوز امنیتی این صفحه وب وجود دارد» دیده می‌شود. معنای همه یکی است: مرورگر نتوانسته هویت سایت را تأیید کند، و رفع مشکل «امن نبودن سایت» از پیدا کردن علت دقیق همین شکست شروع می‌شود.
خطای گواهی امنیتی سایت تقریباً همیشه یک علت فنی مشخص دارد، اما پیام مرورگر معمولاً آن را پنهان میکند. نتیجه این می‌شود که تیم‌ها روزها دنبال «مشکل SSL» می‌گردند در حالی که ایراد واقعی مثلاً یک گواهی میانی جاافتاده است. این راهنما هر خطای رایج را با کد مرورگر، علت دقیق و راه رفع توضیح میدهد، و در پایان وضعیت به‌روزِ TLS در سال ۲۰۲۶ را می‌آورد — چون بخش زیادی از توصیه‌های موجود در وب فارسی چند سال عقب است. یک نکته‌ی مهم را هم از ابتدا روشن می‌کنیم: HTTPS به معنای رمزنگاری ارتباط است، نه تضمین قابل‌اعتماد بودن سایت.
در یک نگاه
- شایع‌ترین خطای بد تشخیص داده‌شده، زنجیره‌ی ناقص گواهی است: در مرورگر دسکتاپ سالم به نظر می‌رسد و در موبایل یا در
curlخطا میدهد. - طبق RFC 9846 (جولای ۲۰۲۶) مشخصات جاری TLS 1.3 است و RFC 8446 را منسوخ میکند.
- RFC 10015 (جولای ۲۰۲۶) مجموعهسایفرهای RSA و FFDH/FFDHE را در (D)TLS 1.2 منسوخ کرده؛ TLS 1.2 فقط با ECDHE + AEAD قابل قبول است.
- HPKP را پیاده نکنید — از مرورگرها حذف شده است. جای آن Certificate Transparency و رکورد CAA است.
- HTTPS فقط می‌گوید ارتباط رمزنگاری شده؛ هیچ چیزی دربارهٔ صداقت صاحب سایت نمیگوید.
مرورگر چه چیزی را بررسی میکند و چرا خطا میدهد
پیش از رفع خطا باید بدانید مرورگر در دستدادن TLS دقیقاً چه شرط‌هایی را می‌سنجد. هر خطای گواهی، شکست یکی از این بررسی‌هاست:
- اعتبار زمانی: تاریخ فعلی باید بین
notBeforeوnotAfterگواهی باشد. - تطابق نام: نام دامنه‌ای که کاربر درخواست کرده باید در بخش SAN (Subject Alternative Name) گواهی موجود باشد. مرورگرهای مدرن به فیلد قدیمی
CNتکیه نمی‌کنند. - زنجیره‌ی اعتماد: باید مسیری از گواهی سرور، از طریق گواهی‌های میانی، به یک گواهی ریشه‌ی موجود در مخزن اعتماد دستگاه ساخته شود.
- وضعیت ابطال: گواهی نباید باطل شده باشد (از طریق OCSP یا CRL).
- کاربرد و محدودیت‌ها: گواهی باید برای احراز هویت سرور صادر شده باشد و محدودیت‌های مسیر و کاربرد کلید در آن رعایت شود.
- سازگاری پروتکل و مجموعه‌سایفر: کلاینت و سرور باید حداقل روی یک نسخه‌ی پروتکل و یک مجموعه‌سایفر مشترک توافق کنند.
نکته‌ای که تشخیص را ساده میکند: مرورگرها گواهی‌های میانی را «حدس» می‌زنند. بعضی مرورگرها میانی‌های دیده‌شده در گذشته را کش می‌کنند یا با AIA آن‌ها را دانلود می‌کنند. به همین دلیل یک زنجیره‌ی ناقص روی لپ‌تاپ شما سالم به نظر می‌رسد و روی گوشی کاربر یا در ارتباط سرور به سرور خطا میدهد. مبانی پروتکل را در دانشنامه‌ی TLS توضیح داده‌ایم.
انقضای گواهی و اختلاف ساعت سیستم
گواهی منقضی‌شده
خطای مرورگر: NET::ERR_CERT_DATE_INVALID. صریح‌ترین و ساده‌ترین حالت. علت معمول در عمل، نه فراموشی بلکه شکست خودکارسازی است: تمدید خودکار به‌خاطر تغییر مسیر تأیید، تغییر DNS، یا خطای مجوز فایل قطع شده و کسی هشدار را ندیده است.
- گواهی جدید صادر و نصب کنید و سرویس وب را ری‌استارت یا reload کنید — نصب فایل بدون بارگذاری مجدد، گواهی قدیمی را در حافظه‌ی فرایند نگه می‌دارد.
- اگر چند نقطه‌ی پایانی TLS دارید (وب‌سرور، متعادل‌کننده‌ی بار، CDN، سرور ایمیل، سرور API)، همه را جداگانه بررسی کنید. تمدید روی یکی، بقیه را به‌روز نمیکند.
- پایش انقضا را راه‌اندازی کنید، نه فقط تمدید خودکار. تمدید خودکارِ بی‌پایش، دقیقاً همان چیزی است که این حادثه را می‌سازد.
اختلاف ساعت سیستم (Clock Skew)
اگر ساعت دستگاه کاربر اشتباه باشد، گواهی کاملاً معتبر هم «منقضی» یا «هنوز معتبر نشده» تشخیص داده می‌شود. نشانه‌ی تشخیصی: خطا فقط روی یک دستگاه یا یک شبکه رخ میدهد و در بقیه سالم است. این مورد را با انقضای واقعی اشتباه نگیرید — قبل از صدور گواهی جدید، تاریخ و ساعت و منطقه‌ی زمانی دستگاه را بررسی کنید. روی سرورها هم همگام‌سازی NTP را فعال نگه دارید، چون اختلاف ساعت سرور به احراز هویت، توکن‌ها و لاگ‌ها هم آسیب می‌زند.
عدم تطابق نام دامنه
خطای مرورگر: NET::ERR_CERT_COMMON_NAME_INVALID یا پیام «گواهی برای دامنه‌ی دیگری صادر شده است». نام درخواست‌شده در SAN گواهی نیست.
علت‌های رایج، به ترتیب فراوانی
- نبود نسخه‌ی
wwwیا نسخه‌ی بدونwww. گواهی برایexample.comصادر شده اما کاربرwww.example.comرا باز کرده. این دو نام مستقل‌اند و هر دو باید در SAN باشند. - زیردامنه‌ی جدید. گواهی وایلدکارد
*.example.comفقط یک سطح را پوشش میدهد؛api.v2.example.comبا آن پوشش داده نمیشود. - خودِ دامنه در وایلدکارد نیست.
*.example.comشاملexample.comنمیشود مگر اینکه جداگانه در SAN آمده باشد. - پیکربندی نادرست میزبان مجازی. درخواست به یک vhost پیش‌فرض می‌رسد که گواهی سایت دیگری را ارائه میکند. این در سرورهایی با چند دامنه بسیار رایج است.
- نبود SNI در کلاینت قدیمی یا نبود پیکربندی SNI در سمت سرور، که باعث می‌شود گواهی پیش‌فرض ارائه شود.
- دسترسی با IP به‌جای نام دامنه. گواهی برای نام صادر شده، نه برای آدرس IP.
openssl s_client -connect example.com:443 -servername example.com \
2>/dev/null | openssl x509 -noout -subject -dates -ext subjectAltNameپارامتر -servername همان SNI است و بدون آن نتیجه گمراه‌کننده می‌شود. این دستور دقیقاً همان چیزی را نشان میدهد که سرور برای آن نام ارائه میکند: مالک گواهی، بازه‌ی اعتبار و فهرست کامل SAN.
زنجیره‌ی ناقص و گواهی میانی — پرتکرارترین تشخیص اشتباه
این بخش را با دقت بخوانید، چون در تجربه‌ی عملی بیشترین زمانِ تلف‌شده مربوط به همین مورد است. خطاها: NET::ERR_CERT_AUTHORITY_INVALID، «unable to get local issuer certificate» در curl، یا «Certificate not trusted» فقط روی برخی دستگاهها.
سازوکار
مرجع صدور گواهی، گواهی سایت شما را مستقیماً با کلید ریشه امضا نمیکند. یک یا چند گواهی میانی (Intermediate CA) در وسط قرار دارند: گواهی سایت شما را میانی امضا میکند و میانی را ریشه. مخزن اعتماد دستگاهها فقط ریشهها را دارد، نه میانیها. بنابراین وظیفه‌ی سرور شماست که در دستدادن، گواهی سایت را بههمراه گواهی‌های میانی ارسال کند تا کلاینت بتواند زنجیره را تا ریشه بسازد.
چرا مرورگر شما مشکلی نشان نمی‌دهد
سه دلیل: مرورگر ممکن است آن میانی را قبلاً از سایت دیگری دیده و کش کرده باشد؛ ممکن است با استفاده از افزونه‌ی AIA خودش آن را دانلود کند؛ و مخزن اعتماد سیستم‌عامل شما ممکن است میانی را داشته باشد. اما این «جبران‌سازی» در همه‌جا وجود ندارد. کلاینت‌هایی که همیشه خطا میدهند: curl، کتابخانه‌های HTTP در پایتون و جاوا و PHP، درگاه‌های پرداخت که به وب‌هوک شما وصل می‌شوند، اپلیکیشن‌های موبایل، و سرویس‌های شخص ثالث.
تشخیص و رفع
- با
openssl s_client -showcertsببینید سرور چند گواهی می‌فرستد. اگر فقط یکی است و مرجع صدور شما میانی دارد، زنجیره ناقص است. - فایل زنجیره را درست بسازید: گواهی سرور در ابتدا، سپس میانیها به ترتیب صعودی. گواهی ریشه لازم نیست و افزودنش فقط حجم دستدادن را زیاد میکند.
- در پیکربندی وب‌سرور از دستور مربوط به «fullchain» یا «certificate chain» استفاده کنید، نه فقط فایل گواهی سرور.
- پس از تغییر، حتماً از یک کلاینت مستقل (نه مرورگر خودتان) آزمایش کنید.
«در کروم سبز است، پس گواهی درست نصب شده.» مرورگر دسکتاپ بدترین ابزار برای راستی‌آزمایی زنجیره است، چون مکانیزم‌های ترمیم دارد. معیار درست، آزمایش با یک کلاینت بی‌حافظه مثل openssl s_client یا curl است. زنجیره‌ی ناقص معمولاً به‌شکل «درگاه پرداخت وب‌هوک را نمی‌زند» یا «اپ موبایل وصل نمیشود» ظاهر می‌شود، نه به‌شکل خطای مرورگر.
گواهی خودامضا و گواهی باطل‌شده
گواهی خودامضا (Self-signed)
خطا: NET::ERR_CERT_AUTHORITY_INVALID با پیام صریح‌تر. گواهی خودامضا رمزنگاری را فراهم میکند اما هویت را اثبات نمیکند، چون هیچ مرجع مستقلی آن را تأیید نکرده — و همین، هدف اصلی زنجیره‌ی اعتماد است.
- روی هر سرویس عمومی، گواهی خودامضا قابل قبول نیست. گواهی از یک مرجع معتبر بگیرید؛ گواهی‌های خودکار و رایگان امروز استاندارد صنعتی‌اند.
- در محیط‌های داخلی می‌توان از یک CA داخلی استفاده کرد، به شرط اینکه گواهی ریشه‌ی آن CA در مخزن اعتماد همهی دستگاه‌های سازمان توزیع شده باشد.
- هرگز به کاربران نگویید هشدار را رد کنند. این کار آن‌ها را عادت میدهد به عبور از هشداری که در حملهی واقعی هم همان شکل را دارد.
- در کد سمت سرور، هرگز راستی‌آزمایی گواهی را غیرفعال نکنید تا خطا برود. این کار حملهی میان‌راهی را کاملاً ممکن میکند و در OWASP زیر A04:2025 خطاهای رمزنگاری و CWE-297 دسته‌بندی می‌شود.
گواهی باطل‌شده (Revoked)
خطا: NET::ERR_CERT_REVOKED. مرجع صدور گواهی را پیش از انقضا باطل کرده است. علت‌های رایج: افشای کلید خصوصی، صدور نادرست، تغییر مالکیت دامنه، یا درخواست خودِ صاحب سایت.
نکته‌ی مهم: ابطال یک هشدار جدی است. اگر گواهی شما بدون اطلاعتان باطل شده، فرض اول باید افشای کلید خصوصی باشد — و آن یعنی یک رخداد امنیتی، نه یک مسئله‌ی پیکربندی. در این حالت کلید جدید بسازید (نه اینکه با همان کلید گواهی جدید بگیرید)، دنبال دلیل افشا بگردید و سرور را مثل یک سیستم در معرض خطر بررسی کنید؛ مسیر آن در پاکسازی سایت هک شده است.
برای کاهش خطر ابطال ناخواسته، رکورد CAA در DNS تعریف کنید تا فقط مرجع یا مراجع مورد نظر شما بتوانند برای دامنه‌تان گواهی صادر کنند، و لاگهای Certificate Transparency را برای صدور غیرمنتظره پایش کنید.
محتوای ترکیبی (Mixed Content)
این مورد فنی‌اً خطای گواهی نیست، اما در ذهن کاربر همان است: قفل آدرس‌بار ناقص می‌شود یا هشدار «ارتباط شما کامل امن نیست» ظاهر می‌شود. علت: صفحه با HTTPS بارگذاری شده اما منابعی از آن با http:// فراخوانی می‌شوند.
دو نوع و تفاوت مهمشان
- محتوای ترکیبی فعال (Active): اسکریپت، شیت استایل، iframe و درخواست‌های XHR/fetch. مرورگرهای مدرن این‌ها را مسدود می‌کنند، چون یک اسکریپت روی HTTP قابل دستکاری در مسیر است و می‌تواند کل صفحه را کنترل کند. نتیجه‌ی معمول: بخش‌هایی از سایت کار نمی‌کنند و در کنسول خطا هست.
- محتوای ترکیبی غیرفعال (Passive): تصویر، ویدیو و صدا. معمولاً بارگذاری می‌شوند اما نشانگر امنیت را تنزل میدهند و همچنان قابل دستکاری هستند.
رفع
- در پایگاه‌داده و قالب، آدرس‌های
http://مربوط به دامنه‌ی خودتان را بهhttps://تغییر دهید یا از مسیر نسبی استفاده کنید. - منابع شخص ثالث را با نسخه‌ی HTTPS جایگزین کنید؛ اگر سرویسی HTTPS ندارد، آن سرویس مشکل است، نه سایت شما.
- هدر
Content-Security-Policyبا دستورupgrade-insecure-requestsمی‌تواند به‌عنوان لایه‌ی گذار کمک کند، اما جایگزین اصلاح آدرس‌ها نیست. توضیح کامل سیاست در دانشنامه‌ی CSP. - پس از پاکسازی، HSTS را فعال کنید تا مرورگر خودش هرگز به HTTP برنگردد.
ناسازگاری پروتکل و مجموعه‌سایفر: وضعیت TLS در ۲۰۲۶
خطاهایی مثل ERR_SSL_VERSION_OR_CIPHER_MISMATCH یا SSL_ERROR_NO_CYPHER_OVERLAP یعنی کلاینت و سرور هیچ نسخه‌ی پروتکل یا مجموعه‌سایفر مشترکی پیدا نکردند. این خطا معمولاً بعد از مقاوم‌سازی سرور یا هنگام اتصال کلاینت‌های قدیمی رخ میدهد. برای رفع آن باید بدانید کدام تنظیمات امروز درست است — و این بخش همان جایی است که محتوای موجود در وب فارسی عقب است.
وضعیت به‌روز استانداردها
- TLS 1.3 نسخه‌ی جاری است و مشخصات آن اکنون RFC 9846 (جولای ۲۰۲۶) است که RFC 8446 را منسوخ میکند. RFC 9846 یک به‌روزرسانی جزئی با همان شماره‌ی نسخه است که الزامات را سخت‌تر و ابهامات را رفع میکند. اگر مستندات شما هنوز RFC 8446 را به‌عنوان مرجع جاری ذکر میکند، به‌روزش کنید.
- TLS 1.0 و TLS 1.1 و DTLS 1.0 با RFC 8996 رسماً منسوخ‌اند و مذاکره‌ی آن‌ها ممنوع است. SSL 2.0 و 3.0 سال‌ها پیش‌تر منسوخ شدند؛ واژه‌ی «SSL» فقط در نام محصولات باقی مانده است.
- RFC 10015 (جولای ۲۰۲۶) نقطه‌ی عطف مهمی است: کلاینت‌ها نباید مجموعهسایفرهای RSA (انتقال کلید ایستا)، FFDH غیرگذرا و FFDHE را در (D)TLS 1.2 پیشنهاد دهند و سرورها نباید آن‌ها را انتخاب کنند. مجموعاً بیش از ۱۳۰ مجموعه‌سایفر تحت تأثیر این سند منسوخ شدهاند. ECDH غیرگذرا هم «توصیه‌نشده» است. نتیجه‌ی عملی: TLS 1.2 تنها با ECDHE و رمزنگاری AEAD قابل قبول است.
- BCP 195 اکنون از سه RFC تشکیل شده: RFC 8996، RFC 9325 و RFC 9852 («پروتکل‌های جدیدی که از TLS استفاده می‌کنند باید TLS 1.3 را الزامی کنند»).
پیکربندی مبنا برای یک سایت عمومی در ۲۰۲۶
- TLS 1.3 فعال باشد.
- TLS 1.2 فقط برای سازگاری و فقط با مجموعهسایفرهای
ECDHE_ECDSAیاECDHE_RSAهمراه با AES-GCM یا ChaCha20-Poly1305. - TLS 1.0 و 1.1 و همهی SSL غیرفعال.
- HSTS با
max-ageطولانی، و در صورت آمادگی،includeSubDomainsو preload. - رکورد CAA در DNS و پایش Certificate Transparency.
- آزمون با
testssl.sh،sslyzeیاnmap --script ssl-enum-ciphers.
HTTP Public Key Pinning (هدر Public-Key-Pins) از مرورگرها حذف شده و توصیه به آن، توصیه به یک مکانیزم مرده است. علاوه بر بی‌اثر بودن، پینگذاری اشتباه میتوانست سایت را برای مدت طولانی از دسترس خارج کند. جایگزین درست همان دو موردی است که در فهرست بالا آمد: Certificate Transparency برای تشخیص صدور غیرمجاز، و رکورد CAA برای محدود کردن مراجع مجاز صدور.
جدول مرجع خطاها و باور غلط بزرگ درباره‌ی HTTPS
| خطا | علت | رفع |
|---|---|---|
ERR_CERT_DATE_INVALID | گواهی منقضی شده یا ساعت دستگاه اشتباه است | تمدید و بارگذاری مجدد سرویس؛ اگر فقط یک دستگاه خطا میدهد، ساعت آن را بررسی کنید |
ERR_CERT_COMMON_NAME_INVALID | نام دامنه در SAN گواهی نیست | افزودن همهی نام‌ها به SAN؛ بررسی vhost و SNI |
ERR_CERT_AUTHORITY_INVALID | زنجیره ناقص است یا گواهی خودامضاست | ارسال fullchain شامل میانیها؛ یا دریافت گواهی از مرجع معتبر |
ERR_CERT_REVOKED | گواهی باطل شده | بررسی احتمال افشای کلید خصوصی؛ ساخت کلید جدید و صدور مجدد |
ERR_SSL_VERSION_OR_CIPHER_MISMATCH | نسخه یا مجموعه‌سایفر مشترکی وجود ندارد | فعال‌سازی TLS 1.3 و TLS 1.2 با ECDHE + AEAD |
| هشدار محتوای ترکیبی | منابع HTTP در صفحه‌ی HTTPS | اصلاح آدرس منابع؛ فعال‌سازی HSTS |
ERR_CERT_SYMANTEC_LEGACY و مشابه | گواهی از زنجیره‌ای که اعتمادش سلب شده | صدور مجدد از یک مرجع معتبر جاری |
خطا فقط در curl یا اپ موبایل | تقریباً همیشه زنجیره‌ی ناقص | راستی‌آزمایی با openssl s_client -showcerts |
«سایت HTTPS دارد و قفلش سبز است، پس امن و قابل اعتماد است.» این جمله دو مفهوم کاملاً جدا را با هم مخلوط میکند. HTTPS تضمین میکند که ارتباط رمزنگاری شده و محتوا در مسیر دستکاری نشده، و اینکه شما با دارندهی همان نام دامنه صحبت میکنید. HTTPS هیچ چیزی دربارهٔ صداقت صاحب سایت، امنیت کد آن، یا امن بودن داده‌ی شما پس از رسیدن به سرور نمیگوید. سایت فیشینگ هم می‌تواند گواهی معتبر داشته باشد و اکثرشان دارند — چون صدور گواهی مالکیت دامنه رایگان و خودکار است. یک سایت HTTPS می‌تواند به‌طور کامل به تزریق SQL یا XSS آسیب‌پذیر باشد. HTTPS پیشنیاز است، نه گواهی سلامت. تفاوت این دو را در سایتهای ناامن بیشتر باز کرده‌ایم.
اگر می‌خواهید بدانید پیکربندی TLS شما در برابر الزامات جاری چه وضعی دارد و از آن مهمتر، پشت آن قفل چه آسیب‌پذیری‌هایی وجود دارد، تست نفوذ وب هر دو را ارزیابی میکند. چک‌لیست موارد پیکربندی برای انتشار سایت جدید هم در امنیت سایت جدید آمده است.
پرسش‌های متداول
چرا سایتم می‌گوید گواهی امنیتی معتبر نیست ولی گواهی را تازه نصب کرده‌ام؟
سه احتمال به ترتیب: (۱) سرویس وب پس از نصب reload نشده و گواهی قدیمی در حافظه است، (۲) زنجیره‌ی میانی ارسال نمیشود (fullchain استفاده نکرده‌اید)، (۳) نام دامنه‌ی مورد استفاده در SAN گواهی نیست. با openssl s_client -connect دامنه:443 -servername دامنه -showcerts هر سه را در یک نگاه می‌بینید.
گواهی میانی چیست و چرا لازم است؟
گواهی سایت شما مستقیماً با کلید ریشه امضا نمیشود؛ یک یا چند گواهی میانی در وسط زنجیره قرار دارند. مخزن اعتماد دستگاهها فقط ریشهها را دارد، پس سرور شما باید میانیها را در دستدادن ارسال کند. اگر نکند، مرورگر دسکتاپ ممکن است خودش ترمیم کند اما curl، اپ موبایل و درگاه پرداخت خطا میدهند.
آیا گواهی خودامضا برای سایت فروشگاهی مناسب است؟
نه. گواهی خودامضا رمزنگاری میدهد اما هویت را اثبات نمیکند و هر بازدیدکننده هشدار تمامصفحه میبیند. مهمتر: عادت دادن کاربر به رد کردن هشدار، دفاع او در برابر حملهی واقعی را از بین میبرد. گواهی معتبر با صدور خودکار امروز استاندارد است و مانع فنی یا هزینهای ندارد.
آیا داشتن SSL یعنی سایتم امن است؟
نه. HTTPS فقط ارتباط را رمزنگاری میکند و تضمین میدهد با دارندهی همان دامنه صحبت میکنید. دربارهٔ کیفیت کد، کنترل دسترسی، منطق کسبوکار یا امن بودن داده روی سرور هیچ چیزی نمیگوید. سایتهای فیشینگ هم گواهی معتبر دارند. HTTPS یک پیشنیاز است، نه گواهی سلامت.
آیا TLS 1.2 را باید غیرفعال کنم؟
لازم نیست، اما باید محدودش کنید. طبق RFC 10015 (جولای ۲۰۲۶) مجموعهسایفرهای RSA ایستا و همهی FFDH/FFDHE در TLS 1.2 منسوخ شدهاند. پس TLS 1.3 را فعال کنید و TLS 1.2 را فقط با ECDHE بههمراه AES-GCM یا ChaCha20-Poly1305 نگه دارید. TLS 1.0 و 1.1 طبق RFC 8996 باید کامل غیرفعال باشند.
برای محافظت از گواهی، پینگذاری کلید عمومی (HPKP) را فعال کنم؟
نه. HPKP از مرورگرها حذف شده و اثری ندارد؛ پیادهسازی نادرستش هم میتوانست سایت را برای مدت طولانی از دسترس خارج کند. جایگزین درست: رکورد CAA در DNS برای محدود کردن مراجع مجاز صدور، و پایش لاگهای Certificate Transparency برای تشخیص صدور غیرمنتظره.
منابع
- RFC 9846 — The Transport Layer Security (TLS) Protocol Version 1.3
- RFC 10015 — Deprecating Obsolete Key Exchange Methods in TLS 1.2 and DTLS 1.2
- RFC 8996 — Deprecating TLS 1.0 and TLS 1.1
- BCP 195 — Recommendations for Secure Use of TLS and DTLS
- MDN — Mixed content
- OWASP Top 10:2025 — A04 Cryptographic Failures
محمدرضا مقدم
مغز خودکارسازی تیم؛ ابزارها و زیرساخت داخلی پی‌هانتر را می‌سازد تا اسکن و گزارش‌گیری سریع‌تر و دقیق‌تر انجام شود.