كيف تحصل على تقدير SSL من فئة A+ (قائمة تحقق 2026)

ما الذي يحدد التقدير فعليًا

يمنح CertH درجات لخمسة مجالات مرجّحة من مصافحة TLS خالصة: صلاحية الشهادة وسلسلتها، وقوة المفتاح وخوارزمية التوقيع، وإصدارات البروتوكول المعروضة، وحزم التشفير المتفاوض عليها، إضافة إلى HSTS وOCSP stapling. لا وصول إلى الخادم، ولا وكيل، ولا رفع لملفات الإعداد — كل شيء يُراقب من الخارج تمامًا كما يراه المتصفح.

الحدود بسيطة. يتطلب A+ درجة 95 أو أعلى، ووجود TLS 1.3 في قائمة البروتوكولات المتفاوض عليها، وHSTS إما مُسبق التحميل أو بحد أقصى max-age لا يقل عن 180 يومًا. يبدأ A من 90، وB من 80، وC من 70، وD من 55، وما دون 55 هو F. الشهادة المنتهية تعني صفرًا تلقائيًا.

التغييرات الأربعة التي تنقلك من A إلى A+

عمليًا تكون الفجوة دائمًا واحدًا من هذه الأربعة. أصلحها بالترتيب — كل واحد منها قابل للتحقق بشكل مستقل من الخارج، لذا يمكنك إعادة الفحص بعد كل خطوة.

• •فعّل TLS 1.3. يمنح نقاطًا بحد ذاته وهو مطلوب لـ A+ حتى مع 100 كاملة في كل شيء آخر.
• •ارفع HSTS إلى max-age=15552000 (180 يومًا) على الأقل. السنة (31536000) هي الخيار الشائع.
• •قدّم سلسلة كاملة تشمل الشهادات الوسيطة. غياب الوسيط يظهر كخطأ في السلسلة لدى بعض العملاء ويكلّف نقاطًا.
• •فعّل OCSP stapling كي يسافر فحص الإبطال مع المصافحة بدل تسريب عنوان IP للزائر إلى جهة الإصدار.

إعداد nginx الذي يحقق A+

مقطع server كامل لـ nginx حديث (1.19+ مع OpenSSL 1.1.1+). إذا كان nginx مبنيًا مع OpenSSL أقدم، فسيكون TLS 1.3 غير متاح بصمت مهما كتبت هنا — تحقق أولًا بـ nginx -V.

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
resolver 1.1.1.1 8.8.8.8 valid=300s;

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

إعداد Apache الذي يحقق A+

يحتاج Apache إلى تعريف ذاكرة stapling مرة واحدة على مستوى الخادم، لا داخل المضيف الافتراضي. أما الباقي فيوضع داخل كتلة <VirtualHost *:443>.

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder off
SSLSessionTickets off

SSLUseStapling on
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

الأخطاء التي تُبقي الموقع عند A

الأكثر شيوعًا: تفعيل HSTS مع includeSubDomains على نطاق لا يزال لديه نطاقات فرعية تعمل بـ HTTP فقط — تتعطل فورًا، والرد المعتاد هو حذف الترويسة بالكامل، وهو ما يعيدك إلى A. اطرح HSTS على مراحل: ابدأ بـ max-age 300 ثانية، وراقب أسبوعًا، ثم ارفعه إلى سنة.

الخطأ الثاني الأكثر شيوعًا هو افتراض أن TLS 1.3 مُفعّل لأن الشهادة حديثة. الشهادات وإصدارات البروتوكول مستقلة. شهادة جديدة تمامًا على خادم لا يتحدث إلا TLS 1.2 تبقى دون 95.

الثالث هو وجود CDN أمام الأصل. إذا أنهى Cloudflare أو Fastly أو موازن التحميل TLS، فإعداد الأصل لا معنى له — التقدير يعكس الحافة، لذا يجب تغيير الإعداد هناك.

تحقق بنفسك

يمكن تأكيد كل تغيير في ثوانٍ من الطرفية. لا يُتفاوض على TLS 1.3 إلا إذا قدّمه الخادم فعلًا، ويظهر HSTS في ترويسات الاستجابة، ويظهر stapling في كتلة استجابة OCSP.

# Does the server actually negotiate TLS 1.3?
openssl s_client -connect example.com:443 -tls1_3 -servername example.com </dev/null 2>/dev/null | grep "Protocol"

# Is HSTS set, and for how long?
curl -sI https://example.com | grep -i strict-transport-security

# Is OCSP stapling actually working?
openssl s_client -connect example.com:443 -status -servername example.com </dev/null 2>/dev/null | grep -A2 "OCSP Response"

FAQ