ডোমেইন কন্ট্রোল ভ্যালিডেশন (DCV) কী? SSL সার্টিফিকেট ভ্যালিডেশন পদ্ধতির সম্পূর্ণ গাইড

যখন আপনি একটি SSL/TLS সার্টিফিকেট অর্ডার করেন, তখন Certificate Authority সরাসরি সেটি হস্তান্তর করবে না। তাদের প্রমাণ প্রয়োজন যে আপনি প্রকৃতপক্ষে যে ডোমেনটি সুরক্ষিত করছেন সেটির নিয়ন্ত্রণ আপনার হাতে রয়েছে। এখানেই Domain Control Validation (DCV) কাজে আসে। এটি এমন একটি যাচাইকরণ প্রক্রিয়া যা কোনো সার্টিফিকেট প্রদানের আগে ডোমেন মালিকানা নিশ্চিত করে।

এটি নিছক আমলাতান্ত্রিক ঝামেলা নয়। DCV আক্রমণকারীদের এমন ডোমেনের জন্য বৈধ সার্টিফিকেট পাওয়া থেকে বিরত রাখে যেগুলোর মালিক তারা নয়, যা HTTPS-কে নিরাপদ রাখার বিশ্বাস মডেলকে সম্পূর্ণরূপে ক্ষুণ্ন করতে পারত। CA/Browser Forum, যে শিল্প সংস্থাটি সার্টিফিকেট প্রদানের জন্য মূল প্রয়োজনীয়তা নির্ধারণ করে, তারা নির্দিষ্ট DCV পদ্ধতি বাধ্যতামূলক করে দিয়েছে যা সকল Certificate Authority-কে অনুসরণ করতে হয়।

এই গাইডে, আমরা DCV আসলে কী তা বিশ্লেষণ করব, বিভিন্ন উপলব্ধ যাচাইকরণ পদ্ধতিগুলো অন্বেষণ করব, এবং আপনার ইনফ্রাস্ট্রাকচারের জন্য সঠিক পদ্ধতি বেছে নিতে সাহায্য করব।

---

সূচিপত্র

1. DCV (Domain Control Validation) কী?
2. ইমেইল-ভিত্তিক ডোমেন যাচাইকরণ পদ্ধতি
3. DNS-ভিত্তিক DCV পদ্ধতি
4. HTTP/HTTPS ফাইল-ভিত্তিক যাচাইকরণ পদ্ধতি
5. বিশেষ যাচাইকরণ পরিস্থিতি
6. আপনার প্রয়োজন অনুযায়ী সঠিক DCV পদ্ধতি বাছাই করা
7. সাধারণ DCV সমস্যা এবং দ্রুত সমাধান

---

---

DCV (Domain Control Validation) কী?

Domain Control Validation (DCV) হলো এমন একটি প্রক্রিয়া যা Certificate Authority-গুলো একটি SSL/TLS সার্টিফিকেট প্রদানের আগে ডোমেন মালিকানা যাচাই করার জন্য ব্যবহার করে। এটি নিশ্চিত করে যে আবেদনকারী ইমেইলের মাধ্যমে সাড়া দিয়ে, ডোমেনে একটি ফাইল আপলোড করে, বা DNS রেকর্ড কনফিগার করে ডোমেনের উপর তার কর্তৃত্ব প্রমাণ করছে।

প্রক্রিয়াটি এভাবে কাজ করে: CA একটি অনন্য চ্যালেঞ্জ তৈরি করে (সাধারণত একটি র‌্যান্ডম আলফানিউমেরিক স্ট্রিং), এবং আপনি আপনার ডোমেনের ইনফ্রাস্ট্রাকচারের মাধ্যমে সাড়া দিয়ে নিয়ন্ত্রণ প্রদর্শন করেন। এটি DNS রেকর্ড, আপনার ওয়েব সার্ভার, বা প্রশাসনিক ইমেইল ঠিকানার মাধ্যমে হতে পারে। একবার যাচাই হয়ে গেলে, CA জানতে পারে যে তারা সার্টিফিকেটটি বৈধ ডোমেন মালিককে প্রদান করছে, আপনার সাইট নকল করার চেষ্টা করা কাউকে নয়।

শিল্প মান এবং সম্মতি

CA/Browser Forum-এর মূল প্রয়োজনীয়তাগুলো নির্দিষ্টভাবে সংজ্ঞায়িত করে DCV কীভাবে সম্পন্ন করতে হবে। এগুলো নিছক পরামর্শ নয়, বরং কঠোর নিয়ম যা CA-গুলোকে অনুসরণ করতে হয়, নাহলে ব্রাউজারে তাদের বিশ্বাসযোগ্য অবস্থান হারানোর ঝুঁকি থাকে।

বর্তমান মানগুলোর মধ্যে রয়েছে:

• যাচাইকরণে অনুমোদিত DCV পদ্ধতিগুলোর একটি ব্যবহার করতে হবে (নিচে বর্ণিত)
• Multi-Perspective Issuance Corroboration (MPIC)-এর জন্য একাধিক নেটওয়ার্ক দৃষ্টিকোণ থেকে যাচাইকরণ প্রয়োজন, যাতে স্থানীয় আক্রমণ প্রতিরোধ করা যায়
• Organization Validated (OV) এবং Extended Validation (EV) সার্টিফিকেটের জন্য যাচাইকরণ ৩৯৭ দিনের জন্য পুনরায় ব্যবহারযোগ্য
• Domain Validated (DV) সার্টিফিকেট যাচাইকরণ পুনরায় ব্যবহার করতে পারে না, প্রতিবার রিনিউ করার সময় আপনাকে যাচাই করতে হবে

একটি গুরুত্বপূর্ণ বিষয়: এই প্রয়োজনীয়তাগুলো আরও কঠোর হচ্ছে। শিল্প সর্বোচ্চ সার্টিফিকেট মেয়াদ এবং যাচাইকরণ সময়কাল কমিয়ে দিচ্ছে।

CA/Browser Forum সার্টিফিকেট মেয়াদের জন্য একটি স্পষ্ট সময়সূচি নির্ধারণ করেছে: এখন সেগুলো ১৫ মার্চ, ২০২৬ থেকে ২০০ দিনে সীমিত, এরপর ১৫ মার্চ, ২০২৭ থেকে ১০০ দিনে, এবং ১৫ মার্চ, ২০২৯ থেকে ৪৭ দিনে আরও হ্রাস করা হবে।

এই কঠোরতা যাচাইকরণ চক্রেও প্রভাব ফেলছে, যা ঘন ঘন পুনঃযাচাইকরণ এবং SSL certificate automation-কে অধিক প্রয়োজনীয় করে তুলছে।

---

ইমেইল-ভিত্তিক ডোমেন যাচাইকরণ পদ্ধতি

১. Constructed Email Verification

ইমেইল যাচাইকরণ সবচেয়ে সাধারণ DCV পদ্ধতি কারণ এটি সহজ এবং আপনার ইনফ্রাস্ট্রাকচারে কোনো প্রযুক্তিগত পরিবর্তনের প্রয়োজন হয় না। CA আপনার ডোমেনের নির্দিষ্ট ঠিকানায় একটি যাচাইকরণ লিঙ্ক বা কোড সহ একটি ইমেইল পাঠায়।

CA এই সাধারণ ইমেইল ঠিকানাগুলো চেষ্টা করবে:

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

আপনার এই সবগুলো সেটআপ করার প্রয়োজন নেই, তালিকা থেকে একটি কার্যকরী ঠিকানাই যথেষ্ট। CA আপনার ডোমেনের MX রেকর্ড পরীক্ষা করে নিশ্চিত করে যে ইমেইল ডেলিভার করা সম্ভব, তারপর যাচাইকরণ অনুরোধ পাঠায়।

ইমেইল এসে পৌঁছালে, আপনি একটি যাচাইকরণ লিঙ্কে ক্লিক করবেন বা সার্টিফিকেট অর্ডারিং প্ল্যাটফর্মে একটি কোড কপি করে ফেরত দেবেন। আপনার ইমেইল সঠিকভাবে কনফিগার করা থাকলে প্রক্রিয়াটি সাধারণত কয়েক মিনিটেই সম্পন্ন হয়।

এই পদ্ধতি ভালো কাজ করে যদি:

• আপনার ডোমেনের জন্য প্রতিষ্ঠিত ইমেইল ইনফ্রাস্ট্রাকচার থাকে
• আপনি নিয়মিত নয়, কালেভদ্রে সার্টিফিকেট অর্ডার করেন
• আপনি চান সবচেয়ে সহজ যাচাইকরণ প্রক্রিয়া, কোনো DNS বা ওয়েব সার্ভার পরিবর্তন ছাড়াই

এর অসুবিধা কী? আপনি এটি সহজে স্বয়ংক্রিয় করতে পারবেন না, এবং আপনার ইমেইল যদি ডাউন হয়ে যায় বা ঠিকানাগুলো মনিটর না করা হয়, তাহলে আপনার যাচাইকরণ ব্যর্থ হবে।

২. Email to DNS TXT Contact

এই ভিন্নতাটি ইমেইলকে DNS-এর সাথে মিলিয়ে দেয়। সাধারণ ঠিকানার পরিবর্তে, আপনি _validation-contactemail.yourdomain.com-এ একটি DNS TXT রেকর্ডে একটি নির্দিষ্ট ইমেইল ঠিকানা প্রকাশ করেন। CA এই রেকর্ড পড়ে এবং সেই ঠিকানায় যাচাইকরণ পাঠায়।

কেন এই পদ্ধতি ব্যবহার করবেন?

• পুনরায় ব্যবহারযোগ্যতা: একবার কনফিগার করলে, এটি সম্পূর্ণ যাচাইকরণ সময়কালের জন্য বৈধ থাকে
• কেন্দ্রীভূত নিয়ন্ত্রণ: আপনি সিদ্ধান্ত নেন ঠিক কোন ইমেইল যাচাইকরণ অনুরোধ গ্রহণ করবে
• টিম-বান্ধব: এটি কারো ব্যক্তিগত ইনবক্সের পরিবর্তে একটি ডিস্ট্রিবিউশন লিস্টের দিকে নির্দেশ করুন

এখানে বাস্তবিক সেটআপ দেওয়া হলো:

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

আপনার পছন্দসই যোগাযোগ ইমেইল দিয়ে এই DNS TXT রেকর্ড তৈরি করুন, এবং CA স্বয়ংক্রিয়ভাবে এটি ব্যবহার করবে। এটি বিশেষভাবে একাধিক সার্টিফিকেট পরিচালনা করা সংস্থাগুলোর জন্য উপযোগী। আপনি একটি মনিটর করা ইনবক্সের মাধ্যমে সকল ডোমেনে যাচাইকরণকে স্ট্যান্ডার্ড করতে পারেন।

---

DNS-ভিত্তিক DCV পদ্ধতি

১. DNS TXT Record Validation

DNS TXT রেকর্ড যাচাইকরণ তার নমনীয়তা এবং স্বয়ংক্রিয়করণের সম্ভাবনার জন্য জনপ্রিয়। আপনি যখন একটি সার্টিফিকেট অর্ডার করেন, CA একটি নির্দিষ্ট হোস্টনেম এবং যাচাইকরণ টোকেন প্রদান করে যা আপনি আপনার ডোমেনের DNS-এ একটি TXT রেকর্ড হিসেবে যোগ করেন।

মৌলিক প্রক্রিয়া:

1. সার্টিফিকেট অর্ডার করার সময় CA একটি হোস্টনেম (সাধারণত _dvsauth.yourdomain.com) এবং টোকেন প্রদান করে
2. আপনি সেই টোকেন মূল্য হিসেবে সহ TXT রেকর্ড তৈরি করেন
3. CA আপনার DNS কোয়েরি করে নিশ্চিত করে যে রেকর্ড বিদ্যমান
4. যাচাই হয়ে গেলে, তারা সার্টিফিকেট প্রদান করে

রেকর্ডটি সাধারণত এরকম দেখতে হয়:

_dvsauth.yourdomain.com. IN TXT "ab1c2d3e4f5g6h7i8j9k0l1m2n3o4p5q"

DNS TXT যাচাইকরণ আদর্শ যখন:

• স্বয়ংক্রিয়করণ – DNS API-গুলো এটিকে ACME ক্লায়েন্ট বা কাস্টম টুলের মাধ্যমে স্ক্রিপ্টযোগ্য করে তোলে
• ওয়েব সার্ভার নেই এমন পরিবেশ – আপনার কেবল DNS অ্যাক্সেস প্রয়োজন
• Wildcard সার্টিফিকেট – এই প্রয়োজনীয়তা আমরা Special Scenarios বিভাগে কভার করব

একটি বিষয় খেয়াল রাখতে হবে: DNS প্রপাগেশন সময়। আপনার নেমসার্ভারগুলোতে যদি উচ্চ TTL মান থাকে বা প্রপাগেশন ধীর হয়, তবে যাচাইকরণে বেশি সময় লাগতে পারে। বেশিরভাগ CA ২৪ ঘণ্টার জন্য পুনরায় চেষ্টা করবে, তবে যাচাইকরণ রেকর্ড যোগ করার আগে কম TTL মান সেট করা ভালো।

২. DNS CNAME Record Method

CNAME যাচাইকরণ একটি ভিন্ন রেকর্ড টাইপ ব্যবহার করে কিন্তু একই লক্ষ্য অর্জন করে। যাচাইকরণ টোকেন সরাসরি সংরক্ষণ করার পরিবর্তে, আপনি একটি CNAME তৈরি করেন যা CA নিয়ন্ত্রিত একটি যাচাইকরণ লক্ষ্যের দিকে নির্দেশ করে।

উদাহরণ কনফিগারেশন:

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

মূল পার্থক্য: CNAME এমন একটি রেকর্ডের দিকে নির্দেশ করে যা CA নিয়ন্ত্রণ করে, যার মানে আপনার DNS পরিবর্তন না করেই তারা যাচাইকরণ লক্ষ্য আপডেট করতে পারে। কিছু CA এটি ডোমেন প্রি-ভ্যালিডেশনের জন্যও অনুমতি দেয়, আপনি একবার CNAME সেট আপ করেন, এবং আপনি সার্টিফিকেট অর্ডার করার সময় তারা যাচাই করতে পারে।

CNAME যাচাইকরণ ভালো কাজ করে যখন:

• আপনার DNS প্রোভাইডার TXT রেকর্ডের চেয়ে CNAME পরিচালনা করা সহজ করে তোলে
• আপনি OV/EV সার্টিফিকেটের জন্য ডোমেন প্রি-ভ্যালিডেশন সক্ষমতা চান
• আপনি এমন CA-দের সাথে কাজ করছেন যারা CNAME-ভিত্তিক যাচাইকরণ প্রবাহ সমর্থন করে

সব CA CNAME যাচাইকরণ প্রদান করে না, তাই আপনার প্রোভাইডারের সাথে যাচাই করুন। কিন্তু উপলব্ধ থাকলে, এই DNS রেকর্ড টাইপ পছন্দ করা টিমগুলোর জন্য এটি একটি ভালো বিকল্প।

---

---

HTTP/HTTPS ফাইল-ভিত্তিক যাচাইকরণ পদ্ধতি

১. HTTP Practical Demonstration

ফাইল-ভিত্তিক যাচাইকরণের জন্য আপনাকে আপনার ওয়েব সার্ভারে একটি নির্দিষ্ট পাথে একটি নির্দিষ্ট ফাইল রাখতে হয়। তারপর CA HTTP বা HTTPS-এর মাধ্যমে এই ফাইলে অ্যাক্সেস করে নিশ্চিত করে যে আপনি ডোমেন হোস্ট করা সার্ভারটি নিয়ন্ত্রণ করেন।

স্ট্যান্ডার্ড পাথ হলো: http://yourdomain.com/.well-known/pki-validation/fileauth.txt

CA যথাযথ ফাইলের নাম এবং কনটেন্ট দুটোই প্রদান করে। আপনি আপনার সার্ভারে এই ফাইলটি তৈরি করেন, নিশ্চিত করেন এটি অ্যাক্সেসযোগ্য, এবং CA এটি সংগ্রহ করে যাচাই করে।

গুরুত্বপূর্ণ বাস্তবায়ন পয়েন্ট:

• ফাইলটি অবশ্যই port 80 (HTTP) বা port 443 (HTTPS)-এ অ্যাক্সেসযোগ্য হতে হবে
• .well-known ডিরেক্টরি RFC 8615-এ সংজ্ঞায়িত একটি স্ট্যান্ডার্ড লোকেশন
• এটি IP অ্যাড্রেস যাচাইকরণের জন্য বাধ্যতামূলক। যদি আপনি IPv4 বা IPv6 অ্যাড্রেসের জন্য সার্টিফিকেট নিচ্ছেন, তাহলে HTTP যাচাইকরণ সাধারণত আপনার একমাত্র বিকল্প

আপনার সরাসরি ওয়েব সার্ভার অ্যাক্সেস থাকলে ফাইল-ভিত্তিক যাচাইকরণ সহজবোধ্য। এটি কম আদর্শ যদি আপনি সীমিত ফাইল সিস্টেম অ্যাক্সেসের হোস্টিং সেবা বা এমন CDN ব্যবহার করেন যা যাচাইকরণ অনুরোধ ক্যাশে করতে পারে বা হস্তক্ষেপ করতে পারে।

সমস্যা সমাধানের পরামর্শ:

• নিশ্চিত করুন রিডাইরেক্ট হস্তক্ষেপ করছে না। CA-কে অবশ্যই যথাযথ যাচাইকরণ URL-এ পৌঁছাতে হবে
• ফায়ারওয়াল HTTP/HTTPS অ্যাক্সেসের অনুমতি দেয় কিনা পরীক্ষা করুন
• যাচাইকরণ ডিরেক্টরির জন্য ক্যাশিং নিষ্ক্রিয় করুন
• ফাইল পারমিশন পাবলিক রিড অ্যাক্সেস অনুমতি দেয় কিনা নিশ্চিত করুন

২. ACME Challenge Integration

ACME (Automated Certificate Management Environment) প্রোটোকল স্বয়ংক্রিয় DCV-এর জন্য HTTP-01 এবং DNS-01 চ্যালেঞ্জ ব্যবহার করে। যদি আপনি Let’s Encrypt বা অন্য কোনো ACME-সামঞ্জস্যপূর্ণ CA ব্যবহার করেন, আপনার ACME ক্লায়েন্ট স্বয়ংক্রিয়ভাবে সম্পূর্ণ যাচাইকরণ প্রক্রিয়া পরিচালনা করে।

HTTP-01 চ্যালেঞ্জ: /.well-known/acme-challenge/-এ একটি যাচাইকরণ ফাইল স্থাপন করে (স্ট্যান্ডার্ড HTTP যাচাইকরণের মতোই)

DNS-01 চ্যালেঞ্জ: _acme-challenge.yourdomain.com-এ একটি TXT রেকর্ড তৈরি করে

আপনার ক্লায়েন্ট (যেমন Certbot, acme.sh, বা cPanel-এর মতো প্ল্যাটফর্মে ইন্টিগ্রেটেড টুল) কোনো ম্যানুয়াল হস্তক্ষেপ ছাড়াই যাচাইকরণ এবং সার্টিফিকেট রিনিউয়াল পরিচালনা করে। ACME স্বয়ংক্রিয় সার্টিফিকেট ব্যবস্থাপনার জন্য স্ট্যান্ডার্ডে পরিণত হয়েছে, বিশেষ করে বড় সার্টিফিকেট ইনভেন্টরি পরিচালনা করা সংস্থাগুলোর জন্য।

---

বিশেষ যাচাইকরণ পরিস্থিতি

১. Multi-Domain এবং SAN Certificate যাচাইকরণ

যদি আপনি একটি মাল্টি-ডোমেন সার্টিফিকেট (যাকে SAN বা UCC সার্টিফিকেটও বলা হয়) অর্ডার করেন, তাহলে আপনাকে প্রতিটি ডোমেন আলাদাভাবে যাচাই করতে হবে। একটি একক DCV চেক সার্টিফিকেটের সব ডোমেন কভার করে না।

উদাহরণ: example.com, www.example.com, এবং shop.example.com-এর জন্য একটি সার্টিফিকেটের জন্য তিনটি আলাদা যাচাইকরণ প্রয়োজন, যদিও এগুলো সম্পর্কিত ডোমেন।

সুসংবাদ হলো? আপনি যাচাইকরণ পদ্ধতি মিশ্রিত করতে পারেন। একটি ডোমেনের জন্য ইমেইল যাচাইকরণ এবং অন্যটির জন্য DNS যাচাইকরণ ব্যবহার করুন যদি এটি আপনার ইনফ্রাস্ট্রাকচারের সাথে মেলে। CA-এর প্ল্যাটফর্ম প্রতিটি ডোমেনের যাচাইকরণ স্ট্যাটাস ট্র্যাক করবে এবং শুধুমাত্র সব ডোমেন যাচাই হয়ে গেলেই সার্টিফিকেট প্রদান করবে।

২. Wildcard Domain যাচাইকরণ

Wildcard সার্টিফিকেট (যা *.example.com কভার করে) DNS-ভিত্তিক যাচাইকরণ পদ্ধতি প্রয়োজন। বেশিরভাগ CA সুরক্ষা বিবেচনার কারণে wildcard-এর জন্য ইমেইল বা HTTP যাচাইকরণ গ্রহণ করবে না।

Wildcard-এর জন্য কেন DNS যাচাইকরণ?

Wildcard সার্টিফিকেট অসীমিত সাবডোমেইন সুরক্ষিত করে। ফাইল-ভিত্তিক যাচাইকরণ একবারে শুধুমাত্র একটি সাবডোমেইনের নিয়ন্ত্রণ প্রমাণ করতে পারবে, এবং ইমেইল যাচাইকরণ সব সম্ভাব্য সাবডোমেইনের উপর নিয়ন্ত্রণ প্রদর্শন করে না। DNS যাচাইকরণ প্রমাণ করে যে আপনি সম্পূর্ণ ডোমেনের DNS ইনফ্রাস্ট্রাকচার নিয়ন্ত্রণ করেন, যা সব সাবডোমেইন সুরক্ষিত করা একটি সার্টিফিকেটের জন্য যথাযথ।

যদি আপনার একটি wildcard সার্টিফিকেট প্রয়োজন হয়, DNS TXT বা CNAME যাচাইকরণ ব্যবহারের পরিকল্পনা করুন। এগুলো সাধারণত আপনার একমাত্র বিকল্প।

৩. Subdomain যাচাইকরণ বিবেচনা

আপনি যাচাইকরণ পদ্ধতির উপর নির্ভর করে সাবডোমেইন লেভেলে বা প্যারেন্ট ডোমেন লেভেলে যাচাই করতে পারেন। HTTP যাচাইকরণের জন্য, ফাইলটি অবশ্যই আপনি যে নির্দিষ্ট সাবডোমেইন যাচাই করছেন সেটিতে অ্যাক্সেসযোগ্য হতে হবে। DNS যাচাইকরণের জন্য, আপনি যথাযথ সাবডোমেইন লেভেলে রেকর্ড তৈরি করেন।

একটি গুরুত্বপূর্ণ পার্থক্য: প্যারেন্ট ডোমেন (example.com) যাচাই করলে বেশিরভাগ যাচাইকরণ পদ্ধতির জন্য স্বয়ংক্রিয়ভাবে সাবডোমেইন (blog.example.com) যাচাই হয় না। প্রতিটি সাবডোমেইনের নিজস্ব যাচাইকরণ প্রয়োজন, যদি না আপনি একটি wildcard সার্টিফিকেট ব্যবহার করেন।

---

আপনার প্রয়োজন অনুযায়ী সঠিক DCV পদ্ধতি বাছাই করা

আপনার ইনফ্রাস্ট্রাকচারের সাথে পদ্ধতিটি মিলিয়ে নিন:

এক নজরে সব DCV পদ্ধতির তুলনা

যাচাইকরণ পদ্ধতি	সম্পন্ন হওয়ার সময়	স্বয়ংক্রিয়করণ ক্ষমতা	প্রযুক্তিগত দক্ষতা	Wildcard সমর্থন	পুনরায় ব্যবহারযোগ্যতা (OV/EV)	সবচেয়ে উপযোগী
ইমেইল (সাধারণ)	৫-৩০ মিনিট	❌ কম	⭐ সর্বনিম্ন	✅ হ্যাঁ	❌ না	একবারের সার্টিফিকেট, ছোট ডিপ্লয়মেন্ট
ইমেইল (DNS TXT)	১৫-৬০ মিনিট	❌ কম	⭐⭐ কম-মধ্যম	✅ হ্যাঁ	✅ হ্যাঁ (৩৯৭ দিন)	একাধিক সার্টিফিকেট থাকা টিম, প্রতিষ্ঠিত ইমেইল
DNS TXT Record	১০-৬০ মিনিট	✅ উচ্চ	⭐⭐⭐ মধ্যম	✅ হ্যাঁ	✅ হ্যাঁ (৩৯৭ দিন)	স্বয়ংক্রিয়করণ, wildcard, বড় ডিপ্লয়মেন্ট
DNS CNAME	১৫-৬০ মিনিট	✅ উচ্চ	⭐⭐⭐ মধ্যম	✅ হ্যাঁ	✅ হ্যাঁ (৩৯৭ দিন)	ডোমেন প্রি-ভ্যালিডেশন, CA-পরিচালিত টোকেন
HTTP ফাইল	৫-২০ মিনিট	⚠️ মাঝারি	⭐⭐ কম-মধ্যম	❌ না	❌ না	সরাসরি সার্ভার অ্যাক্সেস, IP অ্যাড্রেস
ACME (HTTP-01)	২-১০ মিনিট	✅ অতি উচ্চ	⭐⭐⭐⭐ মধ্যম-উচ্চ	❌ না	প্রযোজ্য নয় (অটো-রিনিউয়াল)	সম্পূর্ণ স্বয়ংক্রিয়করণ, Let’s Encrypt
ACME (DNS-01)	২-১০ মিনিট	✅ অতি উচ্চ	⭐⭐⭐⭐ মধ্যম-উচ্চ	✅ হ্যাঁ	প্রযোজ্য নয় (অটো-রিনিউয়াল)	Wildcard সহ সম্পূর্ণ স্বয়ংক্রিয়করণ

পরিস্থিতি অনুযায়ী পদ্ধতি নির্বাচন

ইমেইল যাচাইকরণ ব্যবহার করুন যদি:

• আপনার সহজ, একবারের সার্টিফিকেট অর্ডার থাকে
• সাধারণ অ্যাডমিন ইমেইল ঠিকানাগুলো মনিটর করা হয়
• আপনার স্বয়ংক্রিয়করণের প্রয়োজন নেই

DNS TXT/CNAME যাচাইকরণ ব্যবহার করুন যদি:

• আপনার wildcard সার্টিফিকেট প্রয়োজন
• আপনি একাধিক সার্টিফিকেট পরিচালনা করছেন
• আপনার ওয়েব সার্ভার অ্যাক্সেস নেই
• আপনি স্বয়ংক্রিয়করণ ক্ষমতা চান

HTTP ফাইল যাচাইকরণ ব্যবহার করুন যদি:

• আপনার সরাসরি ওয়েব সার্ভার অ্যাক্সেস আছে
• আপনি IP অ্যাড্রেস যাচাই করছেন
• আপনার সংস্থায় DNS পরিবর্তন করা কঠিন

---

সাধারণ DCV সমস্যা এবং দ্রুত সমাধান

যাচাইকরণ ব্যর্থতা ঘটে। এখানে সবচেয়ে সাধারণ যে ত্রুটিগুলোর সম্মুখীন হবেন এবং সেগুলো কীভাবে দ্রুত সমাধান করবেন তা দেওয়া হলো।

HTTP File Validation: “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
• /.well-known/ পাথ ব্লক করতে পারে এমন .htaccess নিয়ম পরীক্ষা করুন
• ডোমেন যদি সম্প্রতি যোগ করা হয়ে থাকে, প্রপাগেশনের জন্য ২৪-৪৮ ঘণ্টা অপেক্ষা করুন
• অ্যাক্সেসিবিলিটি পরীক্ষা করুন: curl -v http://yourdomain.com/.well-known/pki-validation/test.txt

সাধারণ কারণ: যাচাইকরণ ফাইল পাথ বিদ্যমান নেই বা পাবলিকলি অ্যাক্সেসযোগ্য নয়।

HTTP Validation: “Forbids DCV HTTP Redirections”

ত্রুটি: “cPanel (powered by Sectigo) forbids DCV HTTP redirections.”

দ্রুত সমাধান:

• যাচাইকরণের সময় HTTPS-এ রিডাইরেক্ট সাময়িকভাবে নিষ্ক্রিয় করুন
• রিডাইরেক্ট নিয়ম থেকে /.well-known/* পাথ বাদ দিন
• .htaccess, Cloudflare পেজ রুল, বা সার্ভার কনফিগে রিডাইরেক্ট পরীক্ষা করুন
• CDN ব্যবহার করলে, সাময়িকভাবে নিষ্ক্রিয় করুন বা এক্সেপশন যোগ করুন

সাধারণ কারণ: আপনার সাইট HTTP-কে HTTPS-এ রিডাইরেক্ট করে বা অন্য কোনো ডোমেনে রিডাইরেক্ট করে, যা CA-এর যাচাইকরণ প্রচেষ্টা ব্লক করে।

DNS Validation: “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]’.”

দ্রুত সমাধান:

• DNS প্রপাগেশনের জন্য ১-২৪ ঘণ্টা অপেক্ষা করুন (TTL-এর উপর নির্ভর করে)
• যথাযথ হোস্টনেম এবং মূল্য যাচাই করুন: dig _dvsauth.example.com TXT +short
• যাচাইকরণ টোকেনে কপি/পেস্ট ত্রুটি পরীক্ষা করুন
• ডেলিগেটেড DNS (NS রেকর্ড) ব্যবহার করলে, সঠিক প্রোভাইডারে TXT রেকর্ড যোগ করুন
• যাচাইকরণ রেকর্ড যোগ করার আগে TTL কমিয়ে ৩০০ সেকেন্ডে (৫ মিনিট) নিয়ে আসুন

সাধারণ কারণ: DNS এখনও প্রপাগেট হয়নি, বা রেকর্ডে টাইপো রয়েছে।

DNS Validation: CAA Records Blocking Issuance

ত্রুটি: “Certificate authority encountered a multiple perspective CAA check error.”

দ্রুত সমাধান:

• বিদ্যমান CAA রেকর্ড পরীক্ষা করুন: dig example.com CAA
• আপনার CA-কে অনুমোদিত ইস্যুয়ারে যোগ করুন: example.com. CAA 0 issue “digicert.com”
• ping.pe টুল ব্যবহার করে CAA রেকর্ড গ্লোবালি রিজলভ হচ্ছে কিনা যাচাই করুন
• যদি কোনো CAA রেকর্ড না থাকে, আপনার কোনোটি যোগ করার প্রয়োজন নেই (অনুপস্থিতি সব CA-কে অনুমতি দেয়)

সাধারণ কারণ: CAA রেকর্ড সীমাবদ্ধ করে দেয় কোন CA আপনার ডোমেনের জন্য সার্টিফিকেট প্রদান করতে পারবে।

Email Validation: Email Not Received

দ্রুত সমাধান:

• প্রথমে স্প্যাম/জাঙ্ক ফোল্ডার পরীক্ষা করুন
• এই ঠিকানাগুলো বিদ্যমান এবং ইমেইল গ্রহণ করে কিনা যাচাই করুন: admin@, administrator@, webmaster@, hostmaster@, postmaster@
• MX রেকর্ড পরীক্ষা করুন: dig example.com MX
• আপনার স্প্যাম ফিল্টারে CA-এর ইমেইল প্রেরণ ডোমেন হোয়াইটলিস্ট করুন
• CA-এর কন্ট্রোল প্যানেল থেকে ইমেইল পুনরায় পাঠানোর অনুরোধ করুন

সাধারণ কারণ: যাচাইকরণ ইমেইল স্প্যাম ফিল্টারে ধরা পড়েছে বা অ্যাডমিন ঠিকানাগুলো বিদ্যমান নেই।

Platform-Specific: cPanel AutoSSL Failures

ত্রুটি: “Local HTTP DCV error: An internal error occurred.”

দ্রুত সমাধান:

• বিস্তারিত তথ্যের জন্য WHM > Manage AutoSSL লগ পরীক্ষা করুন
• ৩০ মিনিট অপেক্ষা করুন এবং পুনরায় চেষ্টা করুন (প্রায়শই স্বয়ংক্রিয়ভাবে সমাধান হয়)
• 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 Dragon-এর সাহায্যে আপনার SSL সার্টিফিকেট ব্যবস্থাপনা সহজ করুন

ডোমেন কন্ট্রোল ভ্যালিডেশন সঠিকভাবে করা মসৃণ সার্টিফিকেট ডিপ্লয়মেন্টের জন্য অত্যন্ত গুরুত্বপূর্ণ। SSL Dragon বিশ্বস্ত Certificate Authority-দের কাছ থেকে সার্টিফিকেট প্রদান করে যেখানে আপনার প্রয়োজনীয় সব যাচাইকরণ পদ্ধতি রয়েছে, আপনি ইমেইল, DNS, বা HTTP-ভিত্তিক যাচাইকরণ পছন্দ করুন যাই হোক না কেন।

আমাদের টিম আপনাকে Domain Validated, Organization Validated, এবং Extended Validation সার্টিফিকেটের জন্য DCV প্রয়োজনীয়তা নেভিগেট করতে সাহায্য করে। আমরা আপনাকে আপনার ইনফ্রাস্ট্রাকচারের সাথে মিলে যায় এমন যাচাইকরণ পদ্ধতির মধ্য দিয়ে নিয়ে যাব এবং যাচাইকরণে সমস্যা দেখা দিলে আপনার প্রশ্নের উত্তর দেব।

সার্টিফিকেট যাচাইকরণের সাথে লড়াই করা বন্ধ করুন। আমাদের SSL সার্টিফিকেট অপশনগুলো দেখুন!