# Domain Control Validation (DCV)? Complete Guide to SSL Certificate Validation Methods Domain Control Validation (DCV) is a critical security process that certificate authorities (CAs) use to verify that you have control over the domain for which you’re requesting an SSL certificate. Before issuing any SSL certificate, CAs must confirm that the applicant actually owns or manages the domain listed in the certificate. This validation step protects against fraudulent certificate issuance and ensures that only legitimate domain owners can obtain certificates for their websites. In this guide, we’ll explore DCV in detail, covering the different validation methods, best practices, and how to troubleshoot common issues. ## Why Domain Control Validation Matters The primary purpose of DCV is to prevent cybercriminals from obtaining SSL certificates for domains they don’t own. Without this validation requirement, an attacker could theoretically request a certificate for your domain and use it to conduct phishing attacks, man-in-the-middle (MITM) attacks, or other malicious activities. Here’s why DCV is essential: – **Prevents certificate fraud**: Ensures only authorized individuals can obtain certificates for a domain – **Protects user trust**: Visitors can be confident they’re communicating with legitimate websites – **Meets industry standards**: DCV is required by the CA/Browser Forum Baseline Requirements, which all legitimate CAs must follow – **Supports compliance**: Many regulatory frameworks require proper validation before issuing security credentials ## Common Domain Control Validation Methods CAs typically offer multiple DCV methods to accommodate different server configurations and user preferences. Here are the most widely used approaches: ### 1. DNS CNAME Validation DNS CNAME validation is one of the most popular and reliable DCV methods. The CA provides you with a unique CNAME record that you add to your domain’s DNS zone file. **How it works:** 1. Request an SSL certificate 2. CA provides a CNAME record (e.g., `_acme-challenge.yourdomain.com CNAME validation.acme-dns.com`) 3. Add this record to your DNS provider’s control panel 4. CA queries DNS to verify the record exists 5. Certificate is issued once validation is confirmed **Advantages:** – Works across all hosting environments – No downtime required – Can be automated with DNS API integrations – Ideal for load-balanced or multi-server setups – Works even if your website is offline **Disadvantages:** – Requires DNS access – May take a few minutes for DNS propagation – Not ideal if you frequently change DNS records ### 2. DNS TXT Record Validation Similar to CNAME validation, DNS TXT record validation requires you to add a specific TXT record to your DNS zone. **How it works:** 1. CA generates a unique TXT record value 2. You add the TXT record to your DNS settings 3. CA verifies the TXT record exists via DNS query 4. Certificate is issued upon successful verification **Example TXT record:** “` _acme-challenge.yourdomain.com TXT “validation-string-here” “` **Advantages:** – Simple to implement – Works with all domain registrars – Can be automated – Universal compatibility **Disadvantages:** – DNS propagation delays – Requires DNS access – Manual entry can be error-prone if not careful ### 3. HTTP File Upload Validation HTTP file upload (also called HTTP-01 challenge) requires you to upload a specific validation file to your web server’s root directory. **How it works:** 1. CA provides a unique validation file and its contents 2. Upload the file to `/.well-known/acme-challenge/` on your server 3. CA attempts to access the file via HTTP 4. Certificate is issued if the file is found with correct content **Example file path:** “` http://yourdomain.com/.well-known/acme-challenge/validation-token “` **Advantages:** – Doesn’t require DNS access – Quick validation (no DNS propagation needed) – Works well for simple setups **Disadvantages:** – Requires web server access – Must be on accessible server on port 80 – Doesn’t work if your website is offline – Can fail with certain web hosting configurations – Load balancers and multi-server setups complicate implementation – WAF or firewall may block the validation request ### 4. HTTPS File Upload Validation This method is similar to HTTP validation but uses HTTPS instead. **How it works:** 1. CA provides validation file details 2. Upload file to `/.well-known/acme-challenge/` on your HTTPS server 3. CA retrieves the file via HTTPS 4. Certificate is issued upon verification **Advantages:** – More secure than HTTP validation – Works on HTTPS-enabled servers – No DNS changes needed **Disadvantages:** – Requires existing HTTPS access (chicken-and-egg problem for initial certificates) – More complex to implement – Still requires direct web server access ### 5. Email Validation Email validation is a traditional method where the CA sends a verification email to domain-associated email addresses. **How it works:** 1. CA sends verification email to common domain addresses ([email protected], [email protected], etc.) 2. You click the verification link in the email 3. Certificate is issued after you confirm via email **Advantages:** – Simple and straightforward – No server configuration needed – Works with all domain types **Disadvantages:** – Time-sensitive (links expire) – Requires email access – Slower validation process – Relies on email deliverability – Less suitable for automation – Not recommended for production environments ### 6. Phone Validation For higher-assurance certificates (OV and EV certificates), CAs may conduct phone verification. **How it works:** 1. CA calls the phone number on file for the domain registrant or organization 2. You verify your organization’s details during the call 3. Certificate is issued after successful verification **Advantages:** – Higher assurance validation – Detects fraudulent applications more effectively – Required for EV certificates **Disadvantages:** – Time-consuming – Requires availability during business hours – Can be inconvenient – Slower issuance process ## DCV Timeline and Re-validation Requirements Understanding validation timelines is crucial for certificate management: – **Initial Validation**: Usually completes within minutes to hours, depending on the method chosen – **Re-validation**: Most CAs require DCV every 13 months, coinciding with certificate renewal – **DNS Propagation**: May take 5-15 minutes; longer in some cases – **Email Validation**: Can take 24-48 hours in worst-case scenarios Pro tip: Start your renewal process early (30-45 days before expiration) to ensure sufficient time for validation without rushing. ## Best Practices for Domain Control Validation ### 1. Choose the Right DCV Method for Your Setup – **Multi-server/load-balanced environments**: Use DNS validation – **Simple single-server setups**: HTTP or email validation works fine – **Need automation**: Use DNS or HTTP validation with API support – **Limited technical access**: Email validation may be your best option ### 2. Maintain Accurate Domain Records – Keep your domain registrar contact information current – Ensure domain admin email is monitored and accessible – Document your DNS provider’s access credentials – Maintain updated WHOIS information ### 3. Plan for DNS Propagation – Don’t assume immediate DNS record visibility – Allow extra time for global DNS propagation – Consider using DNS propagation checkers – Validate DNS changes before requesting certificate validation ### 4. Automate Where Possible – Use CA APIs with DNS providers (Cloudflare, Route53, etc.) – Implement automation tools like Certbot for Let’s Encrypt – Set up automatic certificate renewal processes – Monitor certificate expiration dates ### 5. Document Your Validation Process – Keep records of which DCV method you use – Document DNS records and validation file locations – Maintain email address lists for validation notifications – Track certificate renewal timelines ### 6. Security Considerations – **Limit DNS access**: Only give necessary DNS credentials to trusted personnel – **Secure validation files**: Use restrictive file permissions on `.well-known` directories – **Monitor validation emails**: Watch for unexpected certificate requests – **Protect domain accounts**: Use strong passwords and multi-factor authentication on domain registrar accounts ## Troubleshooting Common DCV Issues ### DNS Validation Not Working **Problem**: CA can’t find your DNS record **Solutions:** – Verify DNS record is correctly spelled and formatted – Check DNS propagation with online tools – Confirm you’re editing the correct DNS zone – Wait longer for propagation (can take 15+ minutes) – Check for typos in CNAME or TXT values ### HTTP File Validation Fails **Problem**: CA can’t access the validation file **Solutions:** – Verify file is in correct directory: `/.well-known/acme-challenge/` – Check file permissions (should be world-readable) – Ensure port 80 (HTTP) is open and accessible – Verify no firewall or WAF is blocking the request – Check web server access logs for the validation request – Confirm file contains exact content provided by CA – Ensure website responds to HTTP on port 80 ### Email Validation Not Arriving **Problem**: Verification email not received **Solutions:** – Check spam/junk folders – Verify correct email address is on file – Confirm domain email addresses exist and are monitored – Request CA resend the validation email – Check email server logs for delivery issues – Ensure domain DNS MX records are configured correctly ### Certificate Still Not Issued **Problem**: Validation passed but certificate not issued **Solutions:** – Verify you completed all required validation steps – Check domain doesn’t have security issues flagged by CA – Ensure no pending fraud checks – Review CA communication for additional requirements – Contact CA support with your certificate order number ## DCV for Different Certificate Types ### Domain Validation (DV) Certificates DV certificates use only domain control validation. No organization details are verified. Perfect for: – Personal websites – Blogs – Testing environments – Quick SSL implementation ### Organization Validation (OV) Certificates OV certificates require DCV plus organization verification through: – Business registration verification – Phone validation – Additional documentation Better for: – Business websites – E-commerce sites – Sites handling customer data – Professional services ### Extended Validation (EV) Certificates EV certificates demand the most thorough validation: – DCV verification – Extensive organization checks – Legal documentation review – Phone verification with authorized representatives – Background checks Ideal for: – Financial institutions – E-commerce platforms – High-trust websites – Sites handling sensitive transactions ## DCV and Wildcard Certificates Wildcard certificates (*.yourdomain.com) require DCV just like standard certificates, but with important notes: – **DNS validation**: The only method that works for wildcard issuance – **Email validation**: Also supported for wildcards – **File upload**: Cannot validate wildcards (no HTTP access to `*.yourdomain.com`) – **Coverage**: Once validated, the wildcard protects all subdomains ## Automating DCV with APIs Many modern CAs and DNS providers offer APIs to automate DCV: **Popular integrations:** – **Let’s Encrypt + Certbot**: Automated renewal with DNS or HTTP validation – **Cloudflare API**: Automatic DNS record management – **AWS Route53**: Programmatic DNS updates – **DigitalOcean API**: Automated DNS validation – **Azure DNS**: Integration with certificate management These automations significantly reduce manual validation steps and certificate renewal headaches. ## Final Thoughts Domain Control Validation is a crucial security mechanism that protects the integrity of the SSL certificate ecosystem. By understanding the various DCV methods, choosing the right approach for your infrastructure, and following best practices, you can ensure smooth certificate issuance and renewal processes. Whether you’re managing a single website or a complex multi-domain environment, selecting the appropriate DCV method and maintaining proper domain records will save you time and prevent certificate-related downtime. Need help choosing the right SSL certificate with your preferred DCV method? SSL Dragon offers a wide range of SSL certificates from trusted CAs, with flexible validation options to suit your specific needs.

Bir SSL/TLS sertifikası sipariş ettiğinizde, Sertifika Otoritesi (CA) bunu sadece teslim etmez. Sizdeki alanı gerçekten kontrol ettiğinizin kanıtını gerektirir. İşte bu noktada Alan Kontrolü Doğrulaması (DCV) devreye giriyor. Bu, herhangi bir sertifika verilmeden önce alan sahipliğini onaylayan doğrulama işlemidir.

Bu sadece bürokratik kırmızı bant değildir. DCV, saldırganların sahip olmadıkları alanlar için geçerli sertifikalar almasını engeller; bu, HTTPS’yi güvende tutan güven modelini tamamen baltalayacaktır. Sertifika yetkililerinin yayın gerekliliklerini belirleyen endüstri kuruluşu olan CA/Browser Forum, tüm Sertifika Otoritelerinin izlemesi gereken belirli DCV yöntemleri zorunlu kılar.

Bu kılavuzda, DCV’nin ne olduğunu açıklayacağız, mevcut farklı doğrulama yöntemlerini keşfedeceğiz ve altyapınız için doğru yaklaşımı seçmenize yardımcı olacağız.

---

İçindekiler

1. Alan Kontrolü Doğrulaması (DCV) Nedir?
2. E-posta Tabanlı Alan Doğrulama Yöntemleri
3. DNS Tabanlı DCV Yöntemleri
4. HTTP/HTTPS Dosya Tabanlı Doğrulama Yöntemleri
5. Özel Doğrulama Senaryoları
6. İhtiyaçlarınız için Doğru DCV Yöntemini Seçme
7. Yaygın DCV Sorunları ve Hızlı Çözümler

---

---

DCV (Alan Kontrolü Doğrulaması) Nedir?

Alan Kontrolü Doğrulaması (DCV), Sertifika Otoritelerinin bir SSL/TLS sertifikası vermeden önce alan sahipliğini doğrulamak için kullandığı işlemdir. E-posta aracılığıyla yanıt vererek, alana bir dosya yükleyerek veya DNS kayıtlarını yapılandırarak alan üzerindeki yetki kanıtlanarak kontrolü doğrular.

Süreç şu şekilde çalışır: CA benzersiz bir zorluk (genellikle rastgele alfanümerik bir dize) oluşturur ve siz bunu alan altyapınızın aracılığıyla yanıtlayarak kontrol gösterirsiniz. Bu DNS kayıtları, web sunucunuz veya yönetim e-posta adresleri aracılığıyla olabilir. Doğrulama yapıldıktan sonra, CA sertifikayı sitenizi taklit etmeye çalışan biri değil, meşru alan sahibine verdiğini bilir.

Endüstri Standartları ve Uyum

CA/Browser Forum‘un temel gereksinimleri, DCV’nin tam olarak nasıl yapılması gerektiğini tanımlar. Bunlar öneriler değil, CA’ların güvenilen statüsünü tarayıcılarda kaybetme riski altında izlemesi gereken katı kurallardır.

Mevcut standartlar şunları içerir:

• Doğrulama, onaylanan DCV yöntemlerinden birini kullanmalıdır (aşağıda ele alınmıştır)
• Çok Perspektifli İhraç Doğrulaması (MPIC), yerelleştirilmiş saldırıları önlemek için birden fazla ağ perspektifinden doğrulama gerektirir
• Doğrulama, Kuruluş Doğrulanmış (OV) ve Genişletilmiş Doğrulama (EV) sertifikaları için 397 gün boyunca yeniden kullanılabilir
• Alan Doğrulanmış (DV) sertifikaları doğrulamayı yeniden kullanamaz, her yenileme sırasında doğrulamanız gerekir

İşte önemli bir şey: bu gereklilikler sıkılaşıyor. Endüstri, maksimum sertifika ömürlerini ve doğrulama sürelerini azaltıyor.

CA/Browser Forum, sertifika ömürleri için açık bir zaman çizelgesi tanımlamıştır: bunlar artık 15 Mart 2026 itibariyle 200 gün ile sınırlandırılmıştır; 15 Mart 2027’den 100 güne daha fazla azalış ve 15 Mart 2029’dan itibaren 47 güne yapılacaktır.

Bu sıkılaşma, doğrulama döngülerini de etkiler ve sık sık yeniden doğrulama ile SSL sertifikası otomasyonunı giderek daha gerekli hale getirir.

---

E-posta Tabanlı Alan Doğrulama Yöntemleri

1. Yapılandırılmış E-posta Doğrulaması

E-posta doğrulaması, altyapınızda teknik değişiklik gerektirmediği için en yaygın DCV yöntemidir. CA, alanınızda belirli adresler için doğrulama bağlantısı veya kodu içeren bir e-posta gönderir.

CA şu genel e-posta adreslerini deneyecektir:

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

Bunların hepsini ayarlamanız gerekmez, listeden çalışan bir adres yeterli. CA, e-postanın teslim edilebileceğini doğrulamak için alanınızın MX kayıtlarını kontrol eder, ardından doğrulama isteğini gönderir.

E-posta geldiğinde, bir doğrulama bağlantısını tıklarsınız veya bir kodu sertifika sipariş platformuna geri kopyalarsınız. Söz konusu e-postanız düzgün şekilde yapılandırılmışsa, işlem genellikle sadece birkaç dakika sürer.

Bu yöntem şu durumlarda mükemmel çalışır:

• Alanınız için kurulu e-posta altyapınız vardır
• Sertifikaları ara sıra sipariş ediyorsunuz, ölçekte değil
• DNS veya web sunucusu değişiklikleri olmadan en basit doğrulama işlemini istiyorsunuz

Dezavantajı nedir? Bunu kolayca otomatikleştiremezsiniz ve e-postanız arızaya uğrarsa veya adresler izlenmezse, doğrulamanız başarısız olur.

2. DNS TXT İletişimi E-postası

Bu varyasyon e-postayı DNS ile birleştirir. Genel adresleri kullanmak yerine, _validation-contactemail.yourdomain.com‘de DNS TXT kaydında belirli bir e-posta adresi yayınlarsınız. CA bu kaydı okur ve doğrulama işlemini bu adrese gönderir.

Bu yaklaşım neden kullanılır?

• Yeniden kullanılabilirlik: Yapılandırıldıktan sonra, tam doğrulama süresi için geçerli kalır
• Merkezi kontrol: Doğrulama isteklerini tam olarak hangi e-postanın alacağını siz belirleyin
• Takım dostu: Birinin kişisel gelen kutusuna değil, bir dağıtım listesine işaret edin

İşte pratik kurulum:

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

Yalnızca tercih ettiğiniz iletişim e-postasını içeren bu DNS TXT kaydını oluşturun ve CA bunu otomatik olarak kullanacaktır. Bu, birden fazla sertifikayı yöneten kuruluşlar için özellikle yararlıdır. Tüm alanlar arasında bir izlenen gelen kutusu aracılığıyla doğrulamayı standartlaştırabilirsiniz.

---

DNS Tabanlı DCV Yöntemleri

1. DNS TXT Kaydı Doğrulaması

DNS TXT kaydı doğrulaması, esnekliği ve otomasyon potansiyeli nedeniyle popülerdir. Bir sertifika sipariş ettiğinizde, CA sertifikası sırasında alanınızın DNS’sine eklediğiniz belirli bir ana bilgisayar adı ve doğrulama jetonu sağlar.

Temel süreç:

1. CA, sertifika siparişi sırasında bir ana bilgisayar adı (tipik olarak _dvsauth.yourdomain.com) ve jeton sağlar
2. Bu jetonu değer olarak TXT kaydını oluşturursunuz
3. CA, kaydın var olduğunu doğrulamak için DNS’nizi sorgular
4. Doğrulandıktan sonra, sertifikayı yayınlarlar

Kayıt tipik olarak şöyle görünür:

_dvsauth.yourdomain.com. IN TXT "ab1c2d3e4f5g6h7i8j9k0l1m2n3o4p5q"

DNS TXT doğrulaması şu durumlarda idealdir:

• Otomasyon – DNS API’leri bunu ACME istemcileri veya özel araçlar aracılığıyla komut dosyası haline getirir
• Web sunucusu olmayan ortamlar – yalnızca DNS erişimine ihtiyacınız vardır
• Joker kartı sertifikaları – bu gereksinimi Özel Senaryolar bölümünde ele alacağız

Dikkat edilecek bir şey: DNS yayılma süresi. Ad sunucularınız yüksek TTL değerlerine sahipse veya yavaş yayılıyorsa, doğrulama daha uzun sürebilir. Çoğu CA 24 saat boyunca yeniden deneyecek, ancak doğrulama kayıtlarını eklemeden önce daha düşük TTL değerleri ayarlamak en iyisidir.

2. DNS CNAME Kaydı Yöntemi

CNAME doğrulaması farklı bir kayıt türü kullanır ancak aynı hedefe ulaşır. Doğrulama jetonu doğrudan depolamak yerine, CA tarafından kontrol edilen bir doğrulama hedefine işaret eden bir CNAME oluşturursunuz.

Örnek yapılandırma:

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

Temel fark: CNAME, CA’nın kontrol ettiği bir kayda işaret eder, bu da siz DNS’yi değiştirmeden doğrulama hedefini güncelleyebilecekleri anlamına gelir. Bazı CA’lar ayrıca buna alan öncesi doğrulaması için izin verin; CNAME’i bir kez ayarlayın ve sertifika siparişi verdiğinizde doğrulayabilirler.

CNAME doğrulaması şu durumlarda iyi çalışır:

• DNS sağlayıcınız CNAME’leri TXT kayıtlarından daha kolay yönetir

OV/EV sertifikaları için domain ön doğrulama yeteneğini istiyorsunuz

CNAME tabanlı doğrulama akışlarını destekleyen CA’larla çalışıyorsunuz

Tüm CA’lar CNAME doğrulaması sunmaz, bu nedenle sağlayıcınızla kontrol edin. Ancak mevcut olduğunda, bu DNS kayıt türünü tercih eden takımlar için sağlam bir seçenektir.

---

---

HTTP/HTTPS Dosya Tabanlı Doğrulama Yöntemleri

1. HTTP Pratik Gösterimi

Dosya tabanlı doğrulama, belirli bir dosyayı web sunucunuza belirlenmiş bir yola yerleştirmenizi gerektirir. CA daha sonra bu dosyaya HTTP veya HTTPS aracılığıyla erişerek etki alanını barındıran sunucuyu kontrol ettiğinizi doğrular.

Standart yol şu şekildedir: http://yourdomain.com/.well-known/pki-validation/fileauth.txt

CA hem tam dosya adını hem de içeriği sağlar. Sunucunuzda bu dosyayı oluşturursunuz, erişilebilir olduğundan emin olursunuz ve CA bunu alarak doğrulama gerçekleştirir.

Kritik uygulama noktaları:

• Dosya port 80 (HTTP) veya port 443 (HTTPS) üzerinde erişilebilir olmalıdır
• .well-known dizini, RFC 8615’te tanımlanmış standart bir konumdur
• Bu, IP adresi doğrulaması için gereklidir. IPv4 veya IPv6 adresi için bir sertifika alıyorsanız, HTTP doğrulaması tipik olarak tek seçeneğinizdir

Dosya tabanlı doğrulama, web sunucusuna doğrudan erişiminiz varsa basittir. Dosya sistemi erişimi kısıtlı barındırma hizmetleri veya doğrulama isteklerini önbelleğe alabilecek veya müdahale edebilecek CDN’ler kullanıyorsanız idealden daha az uygundur.

Sorun giderme ipuçları:

• Yönlendirmelerin müdahale etmediğinden emin olun. CA, tam doğrulama URL’sine ulaşmalıdır
• Güvenlik duvarlarının HTTP/HTTPS erişimine izin verip vermediğini kontrol edin
• Doğrulama dizini için önbelleği devre dışı bırakın
• Dosya izinlerinin genel okuma erişimine izin verdiğini doğrulayın

2. ACME Challenge Entegrasyonu

ACME (Automated Certificate Management Environment) protokolü otomatik DCV için HTTP-01 ve DNS-01 challenge’ları kullanır. Let’s Encrypt veya başka bir ACME uyumlu CA kullanıyorsanız, ACME istemciniz tüm doğrulama sürecini otomatik olarak yönetir.

HTTP-01 challenge: /.well-known/acme-challenge/ adresine bir doğrulama dosyası yerleştirir (standart HTTP doğrulamasına benzer)

DNS-01 challenge: _acme-challenge.yourdomain.com adresinde bir TXT kaydı oluşturur

İstemciniz (Certbot, acme.sh gibi veya cPanel gibi platformlardaki entegre araçlar) doğrulama ve sertifika yenilemeleri manuel müdahale olmadan yönetir. ACME, özellikle büyük sertifika envanterlerini yöneten kuruluşlar için otomatik sertifika yönetimi standardı haline gelmiştir.

---

Özel Doğrulama Senaryoları

1. Çok Alan Adı ve SAN Sertifika Doğrulaması

Çok alan adlı bir sertifika (SAN veya UCC sertifikaları olarak da adlandırılır) sipariş ediyorsanız, her alan adını ayrı ayrı doğrulamanız gerekir. Tek bir DCV kontrolü sertifikadaki tüm alanları kapsamaz.

Örnek: example.com, www.example.com ve shop.example.com için bir sertifika, ilgili alanlar olsa bile üç ayrı doğrulama gerektirir.

İyi haber? Doğrulama yöntemlerini karıştırabilisiniz. Bir alan için e-posta doğrulaması, diğeri için DNS doğrulaması kullanın (altyapınızla eşleşirse). CA’nın platformu her alan için doğrulama durumunu izler ve tüm alanlar doğrulanıncaya kadar sertifikayı yalnızca yayınlar.

2. Joker Alan Adı Doğrulaması

Joker sertifikaları (*.example.com’u kapsayan) DNS tabanlı doğrulama yöntemleri gerektirir. Çoğu CA, güvenlik endişeleri nedeniyle joker alanlar için e-posta veya HTTP doğrulamasını kabul etmez.

Joker alanlar için neden DNS doğrulaması?

Joker sertifikaları sınırsız alt alanları güvence altına alır. Dosya tabanlı doğrulama yalnızca bir seferde bir alt alanı kanıtlayabilir ve e-posta doğrulaması tüm olası alt alanları kontrol göstermez. DNS doğrulaması tüm etki alanının DNS altyapısını kontrol ettiğinizi kanıtlar, bu da tüm alt alanları koruyan bir sertifika için uygun olur.

Joker sertifikası gerekiyorsa, DNS TXT veya CNAME doğrulaması kullanmayı planlayın. Bunlar tipik olarak tek seçeneğiniz olup olmadığıdır.

3. Alt Alan Adı Doğrulama Hususları

Doğrulama yöntemine bağlı olarak ana alan adı düzeyinde veya alt alan adı düzeyinde doğrulayabilirsiniz. HTTP doğrulaması için dosya, doğruladığınız belirli alt alanda erişilebilir olmalıdır. DNS doğrulaması için uygun alt alan adı düzeyinde kayıtlar oluşturursunuz.

Önemli bir ayrım: Ana alanı doğrulamak (example.com), çoğu doğrulama yönteminde alt alanları otomatik olarak doğrulamaz (blog.example.com). Joker sertifika kullanmadığınız sürece her alt alan adının kendi doğrulaması gerekir.

---

İhtiyaçlarınız İçin Doğru DCV Yöntemini Seçme

Yöntemi altyapınızla eşleştirin:

Tüm DCV Yöntemlerini Bir Bakışta Karşılaştırın

Doğrulama Yöntemi	Tamamlanma Süresi	Otomasyon Yeteneği	Teknik Beceri	Joker Alan Desteği	Yeniden Kullanılabilirlik (OV/EV)	En İyi Kullanım
E-posta (Genel)	5-30 dakika	❌ Düşük	⭐ Minimum	✅ Evet	❌ Hayır	Tek seferlik sertifikalar, küçük dağıtımlar
E-posta (DNS TXT)	15-60 dakika	❌ Düşük	⭐⭐ Düşük-Orta	✅ Evet	✅ Evet (397 gün)	Birden fazla sertifikası olan takımlar, yerleşik e-posta
DNS TXT Kaydı	10-60 dakika	✅ Yüksek	⭐⭐⭐ Orta	✅ Evet	✅ Evet (397 gün)	Otomasyon, joker alanlar, büyük dağıtımlar
DNS CNAME	15-60 dakika	✅ Yüksek	⭐⭐⭐ Orta	✅ Evet	✅ Evet (397 gün)	Alan ön doğrulaması, CA tarafından yönetilen tokenler
HTTP Dosyası	5-20 dakika	⚠️ Orta	⭐⭐ Düşük-Orta	❌ Hayır	❌ Hayır	Doğrudan sunucu erişimi, IP adresleri
ACME (HTTP-01)	2-10 dakika	✅ Çok Yüksek	⭐⭐⭐⭐ Orta-Yüksek	❌ Hayır	N/A (otomatik yenileme)	Tam otomasyon, Let’s Encrypt
ACME (DNS-01)	2-10 dakika	✅ Çok Yüksek	⭐⭐⭐⭐ Orta-Yüksek	✅ Evet	N/A (otomatik yenileme)	Jokerler ile tam otomasyon

Senaryoya Göre Yöntem Seçimi

E-posta doğrulaması kullanın:

• Basit, tek seferlik sertifika siparişleriniz var
• Genel yönetici e-posta adresleri izlenir
• Otomasyona ihtiyacınız yok

DNS TXT/CNAME doğrulaması kullanın:

• Joker sertifikaları gerekli
• Birden fazla sertifikayı yönetiyorsunuz
• Web sunucusu erişiminiz yok
• Otomasyon yetenekleri istiyorsunuz

HTTP dosya doğrulaması kullanın:

• Doğrudan web sunucusu erişiminiz var
• IP adresleri doğruluyorsunuz
• Kuruluşunuzda DNS değişiklikleri zor

---

Yaygın DCV Sorunları ve Hızlı Çözümler

Doğrulama başarısızlıkları olur. İşte karşılaşacağınız en sık hatalar ve hızlı çözümleri.

HTTP Dosya Doğrulaması: “404 Bulunamadı”

Hata: “Sistem http://example.com/.well-known/pki-validation/[filename].txt adresinde geçici bir dosya sorguladı ancak web sunucu aşağıdaki hatayı döndürdü: 404 (Bulunamadı).”

Hızlı çözümler:

• Dizin yapısını el ile oluşturun: /public_html/.well-known/pki-validation/
• İzinleri ayarlayın: dizinler 755, dosyalar 644
• /.well-known/ yolunu engelleyebilecek .htaccess kurallarını kontrol edin
• Etki alanı yeni eklendiyse, yayılma için 24-48 saat bekleyin
• Erişilebilirliği test edin: curl -v http://yourdomain.com/.well-known/pki-validation/test.txt

Yaygın neden: Doğrulama dosyası yolu mevcut değil veya herkese açık değil.

HTTP Doğrulaması: “DCV HTTP Yönlendirmelerini Yasaklar”

Hata: “cPanel (Sectigo tarafından desteklenir) DCV HTTP yönlendirmelerini yasaklar.”

Hızlı çözümler:

• Doğrulama sırasında HTTPS’ye yönlendirmeleri geçici olarak devre dışı bırakın
• Yönlendirme kurallarından /.well-known/* yolunu hariç tutun
• .htaccess, Cloudflare sayfa kuralları veya sunucu yapılandırmasını yönlendirmeler açısından kontrol edin
• CDN kullanıyorsanız geçici olarak devre dışı bırakın veya istisna ekleyin

Yaygın neden: Siteniz HTTP’den HTTPS’ye veya başka bir etki alanına yönlendiriyor ve CA’nın doğrulama denemesini engelliyor.

DNS Doğrulaması: “Eşleşen TXT Kaydı Yok”

Hata: “‘_dvsauth.example.com’ için DNS sorgusu, DCV başarısı için ‘[expected-value]’ değeriyle eşleşen ‘TXT’ kaydı döndürmedi.”

Hızlı çözümler:

• DNS yayılması için 1-24 saat bekleyin (TTL’ye bağlıdır)
• Tam alan adını ve değeri doğrulayın: dig _dvsauth.example.com TXT +short
• Doğrulama jetonu kopyalanırken oluşan hataları kontrol edin
• Temsilci DNS (NS kayıtları) kullanıyorsanız, TXT kaydını doğru sağlayıcıya ekleyin
• Doğrulama kayıtlarını eklemeden önce TTL’yi 300 saniyeye (5 dakika) düşürün

Yaygın neden: DNS henüz yayılmamış veya kayıtta yazım hatası var.

DNS Doğrulaması: CAA Kayıtları Sertifika Düzenlemeyi Engelliyor

Hata: “Sertifika yetkilisi çoklu perspektif CAA kontrol hatası ile karşılaştı.”

Hızlı çözümler:

• Mevcut CAA kayıtlarını kontrol edin: dig example.com CAA
• CA’nızı izin verilen yayıncılara ekleyin: example.com. CAA 0 issue “digicert.com”
• CAA kayıtlarının ping.pe aracı kullanarak küresel olarak çözümlenip çözümlenmediğini doğrulayın
• CAA kayıtları yoksa herhangi birini eklemeniz gerekmez (yokluk tüm CA’lara izin verir)

Yaygın neden: CAA kayıtları, hangi CA’ların etki alanınız için sertifika düzenleyebileceğini kısıtlar.

E-posta Doğrulaması: E-posta Alınmadı

Hızlı çözümler:

• Önce spam/istenmeyen klasörlerini kontrol edin
• Bu adreslerin var olduğunu ve e-posta aldığını doğrulayın: admin@, administrator@, webmaster@, hostmaster@, postmaster@
• MX kayıtlarını kontrol edin: dig example.com MX
• CA’nın e-posta gönderme etki alanlarını spam filtrenizde beyaz listeye alın
• CA’nın kontrol panelinden e-posta yeniden gönderimini talep edin

Yaygın neden: Doğrulama e-postası spam filtreleri tarafından engellendi veya yönetici adresleri mevcut değil.

Platform’a Özel: cPanel AutoSSL Hataları

Hata: “Yerel HTTP DCV hatası: Bir iç hata oluştu.”

Hızlı çözümler:

• WHM > Manage AutoSSL günlüklerini ayrıntılar açısından kontrol edin
• 30 dakika bekleyin ve tekrar deneyin (genellikle otomatik olarak çözülür)
• Sectigo ve Let’s Encrypt sağlayıcıları arasında geçiş yapın
• AutoSSL sırasını temizleyin: WHM > Manage AutoSSL > Clear pending queue

Hızlı Tanı Komutları

Destek ekibine başvurmadan önce şu kontrolleri çalıştırın:

# DNS yayılmasını doğrulayın
dig yourdomain.com +short
dig _dvsauth.yourdomain.com TXT +short

# HTTP dosya erişilebilirliğini test edin
curl -v http://yourdomain.com/.well-known/pki-validation/test.txt

# CAA ve MX kayıtlarını kontrol edin
dig yourdomain.com CAA
dig yourdomain.com MX

---

SSL Dragon ile SSL Sertifika Yönetimini Basitleştirin

Alan kontrolü doğrulamasını doğru bir şekilde gerçekleştirmek, pürüzsüz sertifika dağıtımı için çok önemlidir. SSL Dragon, e-posta, DNS veya HTTP tabanlı doğrulama dahil ihtiyacınız olan tüm doğrulama yöntemleriyle güvenilen Sertifika Yetkililerinden sertifikalar sunar.

Ekibimiz, Alan Doğrulaması, Kuruluş Doğrulaması ve Genişletilmiş Doğrulama sertifikaları için DCV gereksinimlerinde size rehberlik eder. Altyapınıza uygun doğrulama yöntemi konusunda size rehberlik edecek ve doğrulama sorunları ortaya çıktığında soruları yanıtlayacağız.

Sertifika doğrulaması ile mücadele etmeyi bırakın. SSL sertifika seçeneklerimizi inceleyin!