ما هو التحقق من التحكم بالنطاق (Domain Control Validation – DCV)؟ الدليل الشامل لأساليب التحقق من شهادة SSL

عندما تطلب شهادة SSL/TLS، لن تسلمك جهة إصدار الشهادات (CA) الشهادة مباشرة. فهي بحاجة إلى دليل يثبت أنك تتحكم فعلًا في النطاق الذي تريد تأمينه. وهنا يأتي دور التحقق من ملكية النطاق (Domain Control Validation – DCV). إنها عملية التحقق التي تؤكد ملكية النطاق قبل إصدار أي شهادة.

هذا ليس مجرد إجراء بيروقراطي روتيني. فـ DCV يمنع المهاجمين من الحصول على شهادات صالحة لنطاقات لا يملكونها، وهو أمر من شأنه أن يقوّض تمامًا نموذج الثقة الذي يحافظ على أمان HTTPS. منتدى CA/Browser، وهو الهيئة الصناعية التي تضع المتطلبات الأساسية لإصدار الشهادات، يفرض طرق DCV محددة يجب على جميع جهات إصدار الشهادات اتباعها.

في هذا الدليل، سنشرح ماهية DCV، ونستعرض طرق التحقق المختلفة المتاحة، ونساعدك على اختيار النهج المناسب لبنيتك التحتية.

---

جدول المحتويات

1. ما هو التحقق من ملكية النطاق (DCV)؟
2. طرق التحقق من النطاق القائمة على البريد الإلكتروني
3. طرق DCV القائمة على DNS
4. طرق التحقق القائمة على ملفات HTTP/HTTPS
5. سيناريوهات تحقق خاصة
6. اختيار طريقة DCV المناسبة لاحتياجاتك
7. مشكلات DCV الشائعة وحلولها السريعة

---

---

ما هو DCV (التحقق من ملكية النطاق)؟

التحقق من ملكية النطاق (DCV) هو العملية التي تستخدمها جهات إصدار الشهادات للتحقق من ملكية النطاق قبل إصدار شهادة SSL/TLS. تؤكد هذه العملية التحكم من خلال مطالبة مقدم الطلب بالرد عبر البريد الإلكتروني، أو رفع ملف إلى النطاق، أو إعداد سجلات DNS لإثبات السلطة على النطاق.

تعمل العملية على النحو التالي: تُنشئ جهة إصدار الشهادات تحديًا فريدًا (عادةً سلسلة عشوائية أبجدية رقمية)، وتُظهر أنت التحكم من خلال الرد عبر البنية التحتية لنطاقك. يمكن أن يكون ذلك عبر سجلات DNS، أو خادم الويب الخاص بك، أو عناوين البريد الإلكتروني الإدارية. بمجرد التحقق، تعلم جهة إصدار الشهادات أنها تُصدر الشهادة لمالك النطاق الشرعي، وليس لشخص يحاول انتحال شخصية موقعك.

معايير الصناعة والامتثال

تُحدد المتطلبات الأساسية لـ منتدى CA/Browser بالضبط كيفية إجراء DCV. وهذه ليست مجرد اقتراحات، بل قواعد صارمة يجب على جهات إصدار الشهادات اتباعها وإلا فقدت مكانتها الموثوقة في المتصفحات.

تشمل المعايير الحالية:

• يجب أن يستخدم التحقق إحدى طرق DCV المعتمدة (سيتم تناولها أدناه)
• تأكيد الإصدار متعدد المنظورات (Multi-Perspective Issuance Corroboration – MPIC) يتطلب التحقق من عدة منظورات شبكية لمنع الهجمات المحلية
• يمكن إعادة استخدام التحقق لمدة 397 يومًا بالنسبة لشهادات التحقق من المؤسسة (OV) والتحقق الموسع (EV)
• لا يمكن إعادة استخدام التحقق في شهادات النطاق المُتحقق منه (DV)، بل يجب عليك التحقق في كل مرة تجدد فيها الشهادة

وإليك أمرًا مهمًا: هذه المتطلبات تزداد صرامة. فالصناعة تعمل على تقليص المدد القصوى للشهادات وفترات التحقق.

حدد منتدى CA/Browser جدولًا زمنيًا واضحًا لمدة صلاحية الشهادات: أصبحت الآن محدودة بـ 200 يومًا اعتبارًا من 15 مارس 2026، مع تخفيضات إضافية إلى 100 يوم اعتبارًا من 15 مارس 2027، و47 يومًا ابتداءً من 15 مارس 2029.

يؤثر هذا التشديد أيضًا على دورات التحقق، مما يجعل إعادة التحقق المتكررة وأتمتة شهادات SSL أمرًا ضروريًا بشكل متزايد.

---

طرق التحقق من النطاق القائمة على البريد الإلكتروني

1. التحقق بواسطة بريد إلكتروني مُنشأ

التحقق عبر البريد الإلكتروني هو طريقة DCV الأكثر شيوعًا لأنه بسيط ولا يتطلب أي تغييرات تقنية على بنيتك التحتية. ترسل جهة إصدار الشهادات بريدًا إلكترونيًا يحتوي على رابط أو رمز تحقق إلى عناوين محددة في نطاقك.

ستجرب جهة إصدار الشهادات عناوين البريد الإلكتروني العامة هذه:

• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]

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

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

تعمل هذه الطريقة بشكل رائع إذا:

• كانت لديك بنية تحتية بريدية راسخة لنطاقك
• كنت تطلب شهادات بين الحين والآخر، وليس على نطاق واسع
• كنت تريد أبسط عملية تحقق دون أي تغييرات على DNS أو خادم الويب

ما هو الجانب السلبي؟ لا يمكنك أتمتة هذه العملية بسهولة، وإذا تعطل بريدك الإلكتروني أو لم تُراقب العناوين، فسيفشل التحقق.

2. البريد الإلكتروني إلى جهة اتصال TXT في DNS

يجمع هذا النوع بين البريد الإلكتروني و DNS. فبدلاً من استخدام عناوين عامة، تنشر عنوان بريد إلكتروني محددًا في سجل TXT في DNS على _validation-contactemail.yourdomain.com. تقرأ جهة إصدار الشهادات هذا السجل وترسل التحقق إلى ذلك العنوان.

لماذا تستخدم هذا النهج؟

• إعادة الاستخدام: بمجرد إعداده، يبقى صالحًا طوال فترة التحقق الكاملة
• تحكم مركزي: تحدد بالضبط أي بريد إلكتروني يستقبل طلبات التحقق
• مناسب للفرق: وجّهه إلى قائمة توزيع، وليس إلى صندوق بريد شخصي لأحد الأشخاص

إليك الإعداد العملي:

_validation-contactemail.yourdomain.com. IN TXT "mailto:[email protected]"

ما عليك سوى إنشاء سجل TXT في DNS هذا مع بريد الاتصال المفضل لديك، وستستخدمه جهة إصدار الشهادات تلقائيًا. هذا مفيد بشكل خاص للمؤسسات التي تدير عدة شهادات. يمكنك توحيد التحقق عبر جميع النطاقات من خلال صندوق بريد واحد يتم مراقبته.

---

طرق DCV القائمة على DNS

1. التحقق بواسطة سجل TXT في DNS

يحظى التحقق بسجل TXT في DNS بشعبية كبيرة لمرونته وإمكانية أتمتته. عند طلب شهادة، تقدم لك جهة إصدار الشهادات اسم مضيف محدد ورمز تحقق تضيفه كسجل TXT إلى DNS الخاص بنطاقك.

العملية الأساسية:

1. تقدم جهة إصدار الشهادات اسم مضيف (عادةً _dvsauth.yourdomain.com) ورمزًا أثناء طلب الشهادة
2. تُنشئ سجل TXT بذلك الرمز كقيمة
3. تستعلم جهة إصدار الشهادات عن DNS الخاص بك للتأكد من وجود السجل
4. بمجرد التحقق، تُصدر الشهادة

يبدو السجل عادةً هكذا:

_dvsauth.yourdomain.com. IN TXT "ab1c2d3e4f5g6h7i8j9k0l1m2n3o4p5q"

التحقق بواسطة سجل TXT في DNS مثالي لـ:

• الأتمتة – تجعل واجهات برمجة تطبيقات DNS هذا قابلًا للبرمجة النصية من خلال عملاء ACME أو الأدوات المخصصة
• البيئات الخالية من خوادم الويب – تحتاج فقط إلى الوصول إلى DNS
• الشهادات ذات علامة النجمة (Wildcard) – سنتناول هذا المتطلب في قسم السيناريوهات الخاصة

هناك أمر واحد يجب مراقبته: زمن انتشار DNS. إذا كانت خوادم الأسماء لديك تحتوي على قيم TTL عالية أو انتشار بطيء، فقد يستغرق التحقق وقتًا أطول. تعيد معظم جهات إصدار الشهادات المحاولة لمدة 24 ساعة، ولكن من الأفضل تعيين قيم TTL أقل قبل إضافة سجلات التحقق.

2. طريقة سجل CNAME في DNS

يستخدم التحقق بسجل CNAME نوع سجل مختلف لكنه يحقق نفس الهدف. فبدلاً من تخزين رمز التحقق مباشرة، تُنشئ سجل CNAME يشير إلى هدف تحقق تتحكم فيه جهة إصدار الشهادات.

مثال على الإعداد:

_dnsauth.yourdomain.com. IN CNAME random-token.dcv.digicert.com.

الفرق الرئيسي: يشير سجل CNAME إلى سجل تتحكم فيه جهة إصدار الشهادات، مما يعني أنها تستطيع تحديث هدف التحقق دون أن تُغيّر أنت DNS. تسمح بعض جهات إصدار الشهادات أيضًا بهذا للتحقق المسبق من النطاق، حيث تُعِد سجل CNAME مرة واحدة، ويمكنها التحقق كلما طلبت شهادات.

يعمل التحقق بسجل CNAME جيدًا عندما:

• يجعل مزود DNS الخاص بك إدارة سجلات CNAME أسهل من سجلات TXT
• تريد إمكانية التحقق المسبق من النطاق لشهادات OV/EV
• تعمل مع جهات إصدار شهادات تدعم عمليات التحقق القائمة على CNAME

ليست جميع جهات إصدار الشهادات تقدم التحقق بـ CNAME، لذا تحقق مع مزودك. لكن عندما يكون متاحًا، فإنه خيار متين للفرق التي تفضل هذا النوع من سجلات DNS.

---

---

طرق التحقق القائمة على ملفات HTTP/HTTPS

1. الإثبات العملي عبر HTTP

يتطلب التحقق القائم على الملفات وضع ملف محدد على خادم الويب الخاص بك في مسار مُعيّن. ثم تصل جهة إصدار الشهادات إلى هذا الملف عبر HTTP أو HTTPS لتأكيد أنك تتحكم في الخادم المستضيف للنطاق.

المسار المعياري هو: http://yourdomain.com/.well-known/pki-validation/fileauth.txt

تُقدم جهة إصدار الشهادات كل من اسم الملف الدقيق والمحتوى. تُنشئ هذا الملف على خادمك، وتضمن إمكانية الوصول إليه، وتتحقق جهة إصدار الشهادات من خلال جلبه.

نقاط تنفيذ بالغة الأهمية:

• يجب أن يكون الملف متاحًا على المنفذ 80 (HTTP) أو المنفذ 443 (HTTPS)
• دليل .well-known هو موقع معياري مُحدد في RFC 8615
• هذا مطلوب للتحقق من عنوان IP. إذا كنت تحصل على شهادة لعنوان IPv4 أو IPv6، فإن التحقق عبر HTTP هو عادةً خيارك الوحيد

التحقق القائم على الملفات مباشر إذا كان لديك وصول مباشر إلى خادم الويب. وهو أقل ملاءمة إذا كنت تستخدم خدمات استضافة ذات وصول مقيد إلى نظام الملفات أو شبكات CDN التي قد تُخزّن مؤقتًا طلبات التحقق أو تتداخل معها.

نصائح لاستكشاف الأخطاء وإصلاحها:

• تأكد من أن عمليات إعادة التوجيه لا تتداخل. يجب أن تصل جهة إصدار الشهادات إلى عنوان URL الدقيق للتحقق
• تحقق من أن جدران الحماية تسمح بالوصول عبر HTTP/HTTPS
• عطّل التخزين المؤقت لدليل التحقق
• تحقق من أن أذونات الملف تسمح بالوصول للقراءة العامة

2. تكامل تحدي ACME

يستخدم بروتوكول ACME (بيئة إدارة الشهادات الآلية) تحديات HTTP-01 و DNS-01 لتحقيق DCV آليًا. إذا كنت تستخدم Let’s Encrypt أو أي جهة إصدار شهادات أخرى متوافقة مع ACME، فإن عميل ACME الخاص بك يتعامل مع عملية التحقق بأكملها تلقائيًا.

تحدي HTTP-01: يضع ملف تحقق في /.well-known/acme-challenge/ (مشابه للتحقق القياسي عبر HTTP)

تحدي DNS-01: يُنشئ سجل TXT في _acme-challenge.yourdomain.com

يتولى عميلك (مثل Certbot أو acme.sh أو الأدوات المدمجة في منصات مثل cPanel) عملية التحقق وتجديد الشهادة دون تدخل يدوي. أصبح ACME المعيار المتبع لـالإدارة الآلية للشهادات، خاصةً بالنسبة للمؤسسات التي تدير مخزونًا كبيرًا من الشهادات.

---

سيناريوهات تحقق خاصة

1. التحقق من شهادات النطاقات المتعددة و SAN

إذا كنت تطلب شهادة متعددة النطاقات (تُسمى أيضًا شهادات SAN أو UCC)، يجب عليك التحقق من كل نطاق بشكل منفصل. لا يغطي فحص DCV واحد جميع النطاقات على الشهادة.

مثال: تتطلب شهادة لـ example.com و www.example.com و shop.example.com ثلاثة عمليات تحقق منفصلة، حتى لو كانت نطاقات مرتبطة ببعضها.

الخبر السار؟ يمكنك مزج طرق التحقق. استخدم التحقق عبر البريد الإلكتروني لنطاق واحد والتحقق عبر DNS لآخر إذا كان ذلك يتناسب مع بنيتك التحتية. ستتتبع منصة جهة إصدار الشهادات حالة التحقق لكل نطاق، ولن تُصدر الشهادة إلا بعد التحقق من جميع النطاقات.

2. التحقق من نطاقات Wildcard

تتطلب شهادات Wildcard (التي تغطي *.example.com) طرق تحقق قائمة على DNS. لن تقبل معظم جهات إصدار الشهادات التحقق عبر البريد الإلكتروني أو HTTP لشهادات Wildcard بسبب اعتبارات أمنية.

لماذا التحقق عبر DNS لشهادات Wildcard؟

تُؤمّن شهادات Wildcard عددًا غير محدود من النطاقات الفرعية. يمكن للتحقق القائم على الملفات إثبات التحكم في نطاق فرعي واحد فقط في كل مرة، ولا يُظهر التحقق عبر البريد الإلكتروني التحكم في جميع النطاقات الفرعية المحتملة. يثبت التحقق عبر DNS أنك تتحكم في البنية التحتية لـ DNS للنطاق بأكمله، وهو أمر مناسب لشهادة تحمي جميع النطاقات الفرعية.

إذا كنت بحاجة إلى شهادة Wildcard، فخطط لاستخدام التحقق بسجل TXT أو CNAME في DNS. هذه عادةً خياراتك الوحيدة.

3. اعتبارات التحقق من النطاق الفرعي

يمكنك التحقق على مستوى النطاق الفرعي أو مستوى النطاق الرئيسي، بحسب طريقة التحقق. بالنسبة للتحقق عبر HTTP، يجب أن يكون الملف متاحًا في النطاق الفرعي المحدد الذي تتحقق منه. بالنسبة للتحقق عبر DNS، تُنشئ سجلات على مستوى النطاق الفرعي المناسب.

تمييز مهم: التحقق من النطاق الرئيسي (example.com) لا يُحقق تلقائيًا النطاقات الفرعية (blog.example.com) في معظم طرق التحقق. يحتاج كل نطاق فرعي إلى تحققه الخاص ما لم تكن تستخدم شهادة Wildcard.

---

اختيار طريقة DCV المناسبة لاحتياجاتك

طابق الطريقة مع بنيتك التحتية:

مقارنة جميع طرق DCV في لمحة

طريقة التحقق	الوقت المطلوب للإنجاز	إمكانية الأتمتة	المهارة التقنية	دعم Wildcard	إمكانية إعادة الاستخدام (OV/EV)	الأنسب لـ
البريد الإلكتروني (عام)	5-30 دقيقة	❌ منخفضة	⭐ ضئيلة	✅ نعم	❌ لا	شهادات فردية، عمليات نشر صغيرة
البريد الإلكتروني (DNS TXT)	15-60 دقيقة	❌ منخفضة	⭐⭐ منخفضة-متوسطة	✅ نعم	✅ نعم (397 يومًا)	الفرق التي لديها شهادات متعددة، بنية بريد إلكتروني راسخة
سجل TXT في DNS	10-60 دقيقة	✅ عالية	⭐⭐⭐ متوسطة	✅ نعم	✅ نعم (397 يومًا)	الأتمتة، شهادات Wildcard، عمليات النشر الكبيرة
CNAME في DNS	15-60 دقيقة	✅ عالية	⭐⭐⭐ متوسطة	✅ نعم	✅ نعم (397 يومًا)	التحقق المسبق من النطاق، الرموز المُدارة من جهة إصدار الشهادات
ملف HTTP	5-20 دقيقة	⚠️ متوسطة	⭐⭐ منخفضة-متوسطة	❌ لا	❌ لا	الوصول المباشر للخادم، عناوين IP
ACME (HTTP-01)	2-10 دقائق	✅ عالية جدًا	⭐⭐⭐⭐ متوسطة-عالية	❌ لا	غير قابل للتطبيق (تجديد تلقائي)	الأتمتة الكاملة، Let’s Encrypt
ACME (DNS-01)	2-10 دقائق	✅ عالية جدًا	⭐⭐⭐⭐ متوسطة-عالية	✅ نعم	غير قابل للتطبيق (تجديد تلقائي)	الأتمتة الكاملة مع شهادات Wildcard

اختيار الطريقة حسب السيناريو

استخدم التحقق عبر البريد الإلكتروني إذا:

• كانت لديك طلبات شهادات بسيطة، لمرة واحدة
• كانت عناوين البريد الإلكتروني الإدارية العامة مُراقبة
• لم تكن بحاجة إلى الأتمتة

استخدم التحقق عبر سجل TXT/CNAME في DNS إذا:

• كنت بحاجة إلى شهادات Wildcard
• كنت تدير عدة شهادات
• لم يكن لديك وصول إلى خادم الويب
• كنت تريد إمكانيات الأتمتة

استخدم التحقق بملف HTTP إذا:

• كان لديك وصول مباشر إلى خادم الويب
• كنت تتحقق من عناوين IP
• كانت تغييرات DNS صعبة في مؤسستك

---

مشكلات DCV الشائعة وحلولها السريعة

تحدث حالات فشل التحقق. إليك أكثر الأخطاء شيوعًا التي قد تواجهها وكيفية حلها بسرعة.

التحقق بملف HTTP: “404 Not Found”

الخطأ: “The system queried for a temporary file at http://example.com/.well-known/pki-validation/[filename].txt, but the web server responded with the following error: 404 (Not Found).”

حلول سريعة:

• أنشئ يدويًا بنية الدليل: /public_html/.well-known/pki-validation/
• عيّن الأذونات: الدلائل إلى 755، والملفات إلى 644
• تحقق من قواعد .htaccess التي قد تحظر مسار /.well-known/
• إذا تمت إضافة النطاق للتو، انتظر 24-48 ساعة للانتشار
• اختبر إمكانية الوصول: curl -v http://yourdomain.com/.well-known/pki-validation/test.txt

السبب الشائع: مسار ملف التحقق غير موجود أو غير متاح للجمهور.

التحقق عبر HTTP: “Forbids DCV HTTP Redirections”

الخطأ: “cPanel (powered by Sectigo) forbids DCV HTTP redirections.”

حلول سريعة:

• عطّل إعادة التوجيه إلى HTTPS مؤقتًا أثناء التحقق
• استثنِ مسار /.well-known/* من قواعد إعادة التوجيه
• تحقق من .htaccess، أو قواعد صفحات Cloudflare، أو إعدادات الخادم بحثًا عن عمليات إعادة توجيه
• إذا كنت تستخدم شبكة CDN، عطّلها مؤقتًا أو أضف استثناءً

السبب الشائع: موقعك يعيد توجيه HTTP إلى HTTPS أو يعيد التوجيه إلى نطاق آخر، مما يمنع محاولة التحقق من جهة إصدار الشهادات.

التحقق عبر DNS: “No TXT Record That Matches”

الخطأ: “The DNS query to ‘_dvsauth.example.com’ for the DCV challenge returned no ‘TXT’ record that matches the value ‘[expected-value]’.”

حلول سريعة:

• انتظر 1-24 ساعة لانتشار DNS (يعتمد على TTL)
• تحقق من اسم المضيف والقيمة بدقة: dig _dvsauth.example.com TXT +short
• تحقق من أخطاء النسخ واللصق في رمز التحقق
• إذا كنت تستخدم DNS مفوّضًا (سجلات NS)، أضف سجل TXT عند المزود الصحيح
• قلّل TTL إلى 300 ثانية (5 دقائق) قبل إضافة سجلات التحقق

السبب الشائع: لم ينتشر DNS بعد، أو يحتوي السجل على أخطاء إملائية.

التحقق عبر DNS: سجلات CAA تمنع الإصدار

الخطأ: “Certificate authority encountered a multiple perspective CAA check error.”

حلول سريعة:

• تحقق من سجلات CAA الموجودة: dig example.com CAA
• أضف جهة إصدار الشهادات الخاصة بك إلى الجهات المصدرة المسموح بها: example.com. CAA 0 issue “digicert.com”
• تحقق من أن سجلات CAA تُحل عالميًا باستخدام أداة ping.pe
• إذا لم توجد سجلات CAA، فلست بحاجة لإضافة أي منها (الغياب يسمح بجميع جهات إصدار الشهادات)

السبب الشائع: تُقيّد سجلات CAA جهات إصدار الشهادات التي يمكنها إصدار شهادات لنطاقك.

التحقق عبر البريد الإلكتروني: لم يتم استلام البريد الإلكتروني

حلول سريعة:

• تحقق من مجلدات البريد العشوائي/غير المرغوب فيه أولاً
• تحقق من وجود هذه العناوين واستلامها للبريد الإلكتروني: admin@، administrator@، webmaster@، hostmaster@، postmaster@
• تحقق من سجلات MX: dig example.com MX
• أضف نطاقات إرسال البريد الإلكتروني الخاصة بجهة إصدار الشهادات إلى القائمة البيضاء في مرشح البريد العشوائي لديك
• اطلب إعادة إرسال البريد الإلكتروني من لوحة تحكم جهة إصدار الشهادات

السبب الشائع: تم التقاط بريد التحقق الإلكتروني بواسطة مرشحات البريد العشوائي أو أن عناوين المسؤولين غير موجودة.

خاص بمنصة معينة: فشل AutoSSL في cPanel

الخطأ: “Local HTTP DCV error: An internal error occurred.”

حلول سريعة:

• تحقق من WHM > Manage AutoSSL logs للحصول على التفاصيل
• انتظر 30 دقيقة وأعد المحاولة (غالبًا ما تُحل تلقائيًا)
• بدّل بين موفري Sectigo و Let’s Encrypt
• امسح قائمة انتظار AutoSSL: WHM > Manage AutoSSL > Clear pending queue

أوامر تشخيص سريعة

قبل التواصل مع الدعم، قم بتشغيل هذه الفحوصات:

# Verify DNS propagation
dig yourdomain.com +short
dig _dvsauth.yourdomain.com TXT +short

# Test HTTP file accessibility
curl -v http://yourdomain.com/.well-known/pki-validation/test.txt

# Check CAA and MX records
dig yourdomain.com CAA
dig yourdomain.com MX

---

بسّط إدارة شهادات SSL الخاصة بك مع SSL Dragon

إن ضبط التحقق من ملكية النطاق بشكل صحيح أمر بالغ الأهمية لنشر سلس للشهادات. تقدم SSL Dragon شهادات من جهات إصدار شهادات موثوقة مع جميع طرق التحقق التي تحتاجها، سواء كنت تفضل التحقق عبر البريد الإلكتروني، أو DNS، أو HTTP.

يساعدك فريقنا على التنقل بين متطلبات DCV لشهادات النطاق المُتحقق منه، والتحقق من المؤسسة، والتحقق الموسع. سنرشدك خلال طريقة التحقق التي تتناسب مع بنيتك التحتية ونجيب على أسئلتك عند ظهور مشكلات في التحقق.

توقف عن الصراع مع عملية التحقق من الشهادات. تصفح خيارات شهادات SSL لدينا!