NET::ERR_CERT_COMMON_NAME_INVALID Hatası: Sertifika Alan Adıyla Uyuşmuyor

Bir müşteriniz ekran görüntüsü gönderiyor: tam ekran kırmızı uyarı, altında NET::ERR_CERT_COMMON_NAME_INVALID. Siz aynı adresi kendi tarayıcınızda açıyorsunuz, kilit simgesi yerinde. Farkı bulmak birkaç dakika sürüyor — müşteri www.ornek.com yazmış, siz ornek.com yazmışsınız. Ya da dün eklediğiniz panel.ornek.com alt alan adı hatayı veriyor, kök alan adı gayet iyi çalışıyor.

Türkçe arama sonuçlarının neredeyse tamamı bu hataya ziyaretçi tarafından cevap verir: önbelleği temizleyin, bilgisayarın saatini kontrol edin, antivirüsü kapatın. Bu tavsiyeler yanlış değil ama yanlış kişiye söyleniyor. Hata kodu size sunucunuzun kapsam sorunu olduğunu söylüyor: sunulan sertifika, tarayıcının istediği ana bilgisayar adını içermiyor. Ziyaretçinin bilgisayarında düzeltilecek hiçbir şey yok; işi yapması gereken sitenin sahibi.

Bu yazıda önce hatayı sık karıştırıldığı kardeşlerinden ayıracağız, sonra sunucunun gerçekte hangi sertifikayı sunduğunu tek komutla göreceğiz. Ardından bu hatayı üreten beş somut nedeni tek tek ele alıp her biri için cPanel/AutoSSL ve certbot tarafındaki kesin düzeltmeyi uygulayacağız.

Bu Hata Kardeşlerinden Nasıl Ayrılır#

Tarayıcı "Bağlantınız gizli değil" ekranını üç ayrı sebeple gösterir ve üçünün çözümü birbirinden tamamen farklıdır. Uyarı ekranındaki Gelişmiş bağlantısına tıklayıp kod satırını okumak, teşhisin yarısıdır.

Kendinden imzalı bir sertifikada iki hatanın birlikte görülmesi kafa karıştırır: sertifika hem tanınmayan bir otorite tarafından imzalanmıştır hem de çoğu zaman alan adını kapsamaz. Tarayıcı önce hangisine takılırsa onu gösterir. Zincir tarafındaki belirtileri ayırt etmek için eksik ara sertifika hatası yazısı ayrı bir teşhis akışı sunuyor; bu yazı yalnızca kapsam sorununa odaklanıyor.

Ayırt edici bir ipucu daha: kapsam hatası her cihazda ve her tarayıcıda aynı şekilde çıkar. Sizde çalışıp müşterinizde çalışmıyorsa büyük ihtimalle kapsam sorunu değil, zincir sorunu vardır — çünkü masaüstü tarayıcılar eksik ara sertifikayı çoğu zaman kendi önbelleklerinden tamamlar, mobil cihazlar tamamlamaz.

Adı Yanıltıcı: Tarayıcılar Artık Common Name'e Bakmıyor#

Hata kodunda "COMMON_NAME" yazması, sorunun sertifikanın CN alanında olduğunu düşündürür. Oysa modern tarayıcılar bu alanı hiç okumaz.

Sertifikada alan adı bilgisi iki yerde durabilir: eski Subject: CN= alanında ve Subject Alternative Name (SAN) uzantısında. CN'e geri dönüş, 2000 yılında yayımlanan RFC 2818 ile zaten kullanımdan kaldırılmıştı; Chrome 58 sürümüyle birlikte bu geri dönüş tamamen kaldırıldı. Bugün Chrome, Edge, Firefox ve Safari eşleşmeyi yalnızca SAN listesine bakarak yapar. CN alanında doğru alan adı yazsa bile SAN listesi o adı içermiyorsa hata alırsınız.

Pratik sonuçları şunlardır:

• Elle ürettiğiniz eski usul CSR'larda SAN alanı yoksa sertifika hiçbir tarayıcıda çalışmaz; openssl req komutuna -addext "subjectAltName=DNS:ornek.com,DNS:www.ornek.com" eklemek zorunludur.
• Chrome bu durumda hata ayrıntısında missing_subjectAltName ibaresini gösterir; bu ibareyi gördüyseniz teşhis kesindir.
• Let's Encrypt, cPanel AutoSSL ve ticari otoritelerin tamamı bugün SAN alanını otomatik doldurur. Yani bu özel alt durum artık çoğunlukla eski cihaz arayüzlerinde, yerel geliştirme sertifikalarında ve kendinden imzalı sertifikalarda karşınıza çıkar.

Kısacası hata kodunu "sertifikanın kapsadığı adlar ile tarayıcının istediği ad uyuşmuyor" diye okuyun. Geri kalan her şey bu tek cümlenin ayrıntısıdır.

Teşhis: Sunucu Gerçekte Hangi Sertifikayı Sunuyor#

Panelde ne yazdığının önemi yok; bağlantı sırasında karşı tarafa gerçekte ne gönderildiğine bakmak gerekir. Tek komut:

openssl s_client -connect ornek.com:443 -servername ornek.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -dates -ext subjectAltName

-servername parametresi burada zorunludur; SNI değerini gönderir ve sunucunun doğru sanal konağı seçmesini sağlar. Onu yazmazsanız sunucunun varsayılan sertifikasını görürsünüz ve yanlış sonuca varırsınız. SNI'nin el sıkışmadaki rolünü merak ediyorsanız SNI nedir yazısı arka planı veriyor.

Tipik bir çıktı şöyledir:

subject=CN = ornek.com
notBefore=Jul 14 09:12:03 2026 GMT
notAfter=Oct 12 09:12:02 2026 GMT
X509v3 Subject Alternative Name:
    DNS:ornek.com

Bu çıktı hatanın nedenini doğrudan söylüyor: SAN listesinde yalnızca ornek.com var, www.ornek.com yok. Ziyaretçi www ile girdiğinde uyarıyı alacak.

-ext subjectAltName parametresi OpenSSL 1.1.1 ve sonrasında çalışır. Daha eski bir sürümdeyseniz:

openssl s_client -connect ornek.com:443 -servername ornek.com </dev/null 2>/dev/null \
  | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

Doğru Dosyayı Sunduğunuzdan Emin Olun#

Sık rastlanan bir tuzak, diskteki sertifikayı yenilemiş olmanıza rağmen web sunucusunun başka bir dosyayı okumaya devam etmesidir. Parmak izlerini karşılaştırarak bunu saniyeler içinde kanıtlayabilirsiniz:

# Sunucunun canlıda sunduğu sertifika
openssl s_client -connect ornek.com:443 -servername ornek.com </dev/null 2>/dev/null \
  | openssl x509 -noout -fingerprint -sha256

# Diskte olduğunu sandığınız sertifika
openssl x509 -noout -fingerprint -sha256 -in /etc/letsencrypt/live/ornek.com/fullchain.pem

İki parmak izi farklıysa sertifikanız sorunsuz, yapılandırmanız yanlış dosyayı gösteriyor demektir. Bu durumda yeni sertifika almak hiçbir şeyi çözmez; ssl_certificate satırının hangi yolu işaret ettiğini düzeltmeniz gerekir.

Neden 1: Sertifika www'yu ya da www'suz Sürümü Kapsamıyor#

En yaygın nedendir. Sertifika ornek.com için alınmış, ziyaretçi www.ornek.com yazmış — ya da tam tersi. Sertifika açısından bu ikisi tamamen ayrı iki ana bilgisayar adıdır; birinin diğerini kapsaması diye bir şey yoktur.

certbot ile çözüm, mevcut sertifikayı genişletmektir. Burada kritik nokta, komuta eski alan adlarını da yazmak zorunda olmanızdır; yalnızca yeni adı verirseniz sertifika o ada daralır ve bu kez kök alan adı hata vermeye başlar:

sudo certbot certificates

sudo certbot --nginx --expand \
  --cert-name ornek.com \
  -d ornek.com -d www.ornek.com

cPanel tarafında iş daha basittir: SSL/TLS Status ekranında her iki adın da listelenmesi ve yanlarında AutoSSL kapsamını gösteren işaretin bulunması gerekir. www satırı "Excluded" görünüyorsa dışlama listesinden çıkarıp Run AutoSSL düğmesine basın.

Sertifikayı düzelttikten sonra iki adresin de açık kalması ayrı bir SEO sorunudur; sertifika her ikisini kapsadıktan sonra birini diğerine 301 ile kalıcı olarak yönlendirin.

Neden 2: Yeni Alt Alan Adı Sertifikaya Girmemiş#

Dün panel.ornek.com kaydını açtınız, DNS'i yönlendirdiniz, site geldi — ama HTTPS uyarı veriyor. Sertifikanız o adı içermiyor, çünkü sertifika o ad var olmadan önce üretilmişti.

Burada joker (wildcard) sertifikaların eşleşme kuralını bilmek zorundasınız, çünkü sezgiye aykırıdır: *.ornek.com tek bir etiket karşılar. Ne kök alan adını kapsar, ne de iki seviyeli alt alan adını.

Tablodaki son satır, "joker aldım ama iki seviyeli adresim çalışmıyor" şikâyetinin tek cevabıdır: her seviye için ayrı bir joker gerekir. Kapsam tiplerinin maliyet ve yönetim karşılaştırması için wildcard SSL nedir ve çok sayıda bağımsız alan adını tek sertifikada toplamak için SAN çoklu alan adlı SSL yazılarına bakabilirsiniz.

Az sayıda alt alan adınız varsa joker almak yerine hepsini tek tek eklemek daha basit ve daha ucuzdur:

sudo certbot certonly --nginx \
  --cert-name ornek.com \
  -d ornek.com -d www.ornek.com \
  -d panel.ornek.com -d api.ornek.com

Alt alan adı başka bir sunucuda barındırılıyorsa sertifikayı o sunucuda üretmeniz gerektiğini unutmayın: sertifika, isteği karşılayan makinede durmak zorundadır. Kök alan adının sunucusunda -d panel.ornek.com ile sertifika almaya çalışmak, doğrulama aşamasında başarısız olur.

Neden 3: Sunucu Yanlış Sertifikayı Sunuyor#

Tek IP üzerinde birden çok site barındıran sunucularda, sertifikanın kendisi doğru olsa bile yanlışı sunulabilir. Sunucu, SNI değerini eşleştiremediğinde varsayılan sanal konağın sertifikasını gönderir — yani bambaşka bir sitenin sertifikasını. Ziyaretçi de haklı olarak "bu sertifika bu adres için değil" uyarısını görür.

Teşhisi çok net bir testle yapabilirsiniz. Aynı sunucuya bir kez SNI ile, bir kez SNI'siz bağlanın:

# SNI göndererek
openssl s_client -connect 203.0.113.10:443 -servername ornek.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject

# SNI göndermeden (varsayılan sanal konak yanıt verir)
openssl s_client -connect 203.0.113.10:443 </dev/null 2>/dev/null \
  | openssl x509 -noout -subject

İkisi aynı ve yanlış çıkıyorsa, alan adınız için tanımlı bir sanal konak ya yok ya da server_name değeri yanlış yazılmış; istek varsayılana düşüyor.

Nginx'te hangi bloğun eşleştiğini görmek için birleştirilmiş yapılandırmayı okuyun:

sudo nginx -T | grep -n -E "server_name|ssl_certificate " | less

Kalıcı bir iyileştirme olarak, eşleşmeyen SNI değerlerini yanlış sertifika sunmak yerine temiz bir biçimde reddetmesini sağlayabilirsiniz:

server {
    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;
    ssl_reject_handshake on;
}

Bu yönerge nginx 1.19.4 ve sonrasında çalışır. Etkisi şudur: tanımadığı bir ad için sunucu el sıkışmayı reddeder, böylece başka bir müşterinin sertifikası hiç ortaya çıkmaz ve hata mesajı yanıltıcı olmaz. Ziyaretçi bu durumda kapsam hatası yerine bağlantı hatası görür; bu, teşhisi kolaylaştırdığı gibi sunucudaki diğer alan adlarının sertifikadan okunmasını da engeller.

Apache'de aynı kontrol tek komuttur:

sudo apachectl -S

Çıktının başındaki default server satırı, eşleşme bulunamadığında hangi sanal konağın devreye gireceğini söyler. ServerName ve ServerAlias satırlarında www sürümünü eklemeyi unutmak, bu bölümdeki hataların büyük kısmının kaynağıdır.

Neden 4: cPanel'de Park/Addon Alan Adı Ana Sertifikaya Düşmüş#

cPanel hesaplarında ek alan adları (addon domain) teknik olarak birer alt alan adı üzerine kurulur. Bir addon domain eklediğinizde AutoSSL yeni adı fark edip sertifikayı genişletmeye çalışır, ama bu her zaman başarılı olmaz. Başarısız olduğunda eski sertifika sunulmaya devam eder ve yeni alan adı ERR_CERT_COMMON_NAME_INVALID verir.

Sırayla kontrol edin:

1. SSL/TLS Status ekranını açın ve yeni alan adının listede olup olmadığına bakın. Yoksa hesap yapılandırması tamamlanmamıştır.
2. Ad listedeyse yanındaki durum sütununu okuyun. "Excluded from AutoSSL" ise dışlamayı kaldırın.
3. Run AutoSSL düğmesine basın ve işlem bitince günlüğü açın. Hata satırı genellikle DCV (Domain Control Validation) başarısızlığını gösterir.
4. DCV başarısızsa nedeni neredeyse her zaman ya alan adının henüz bu sunucuya çözümlenmemesi ya da doğrulama dosyasına erişimin bir yönlendirme kuralıyla engellenmesidir. .htaccess içindeki genel HTTPS yönlendirmesi /.well-known/acme-challenge/ yolunu da kapsıyorsa doğrulama başarısız olur.

Dördüncü maddedeki istisnayı .htaccess başına ekleyerek çözebilirsiniz:

RewriteEngine On
RewriteCond %{REQUEST_URI} ^/\.well-known/acme-challenge/ [NC]
RewriteRule ^ - [L]

AutoSSL'in çalışma mantığı, hangi sağlayıcıyı kullandığı ve kapsam kontrolünün ayrıntıları için cPanel AutoSSL nedir yazısı bu adımları daha geniş ele alıyor.

Neden 5: IP Adresiyle ya da Sunucu Hostname'iyle Erişim#

https://203.0.113.10 yazarak siteye girmeye çalıştığınızda bu hatayı almanız normaldir ve düzeltilecek bir arıza değildir. Sertifikalar alan adlarını doğrular; bir IP adresi ancak sertifikaya IP Address tipinde bir SAN girdisi eklenmişse doğrulanabilir ve halka açık otoriteler bunu yalnızca özel koşullarda verir.

Aynı durum sunucunun kendi ana bilgisayar adına da uygulanır. Paylaşımlı barındırmada server42.saglayici.com üzerinden siteye erişmek her zaman uyarı üretir, çünkü o ad sizin sertifikanızda yer almaz.

Bu iki senaryoda doğru davranış hatayı geçmeye çalışmak değil, erişimi alan adı üzerinden yapmaktır. Geliştirme aşamasında alan adı henüz yönlenmemişse yerel hosts dosyanıza bir satır ekleyin; böylece hem doğru adı kullanır hem sertifikayı doğrularsınız:

# /etc/hosts  (Windows: C:\Windows\System32\drivers\etc\hosts)
203.0.113.10  ornek.com www.ornek.com

Cloudflare Arkasındaysanız: Universal SSL'in İki Seviye Sınırı#

Cloudflare'in ücretsiz Universal SSL sertifikası, kök alan adınızı ve tek seviyeli alt alan adlarını kapsar. Yani ornek.com ve panel.ornek.com sorunsuz çalışır; api.panel.ornek.com çalışmaz ve tam olarak bu hatayı verir. Neden Neden 2'deki joker eşleşme kuralının aynısıdır: Universal SSL bir *.ornek.com joker adı içerir ve joker bir seviyeden fazlasını karşılamaz.

Seçenekleriniz şunlardır:

• Alt alan adını tek seviyeye indirin (api-panel.ornek.com gibi). Ücretsiz ve anında çalışır.
• İlgili DNS kaydını gri buluta alın; istek Cloudflare'den geçmez, kendi sunucunuzun sertifikası sunulur.
• Cloudflare tarafında ilgili seviyeyi kapsayan gelişmiş bir sertifika satın alın.

Cloudflare açıkken hatanın kaynağını ayırt etmek için sertifikayı iki yerden birden okuyun: alan adına bağlandığınızda Cloudflare'in sertifikasını, origin IP'sine bağlandığınızda kendi sertifikanızı görürsünüz. İkisinin kapsamı ayrı ayrı doğru olmak zorundadır. Cloudflare'in SSL modlarının bu tabloyu nasıl değiştirdiğini Flexible, Full ve Full Strict farkı yazısında bulabilirsiniz.

Düzelttikten Sonra: Doğrulama ve Tekrarını Önleme#

Sertifikayı yenilediğinizde web sunucusunu yeniden yüklemeyi unutmayın; certbot eklentileri bunu genellikle kendi yapar ama certonly ile aldıysanız yapmaz:

sudo nginx -t && sudo systemctl reload nginx

Ardından kapsamı canlıda doğrulayın — panelden değil, dışarıdan:

for h in ornek.com www.ornek.com panel.ornek.com; do
  printf '%-24s ' "$h"
  openssl s_client -connect "$h":443 -servername "$h" </dev/null 2>/dev/null \
    | openssl x509 -noout -ext subjectAltName | tr -d '\n' | sed 's/  */ /g'
  echo
done

Bu döngü, listelediğiniz her ad için sertifikanın kapsadığı adları tek satırda basar; hepsinin çıktısı aynı ve eksiksiz olmalıdır. Tam bir dış denetim isterseniz bağımsız bir SSL test servisinin raporundaki "Common names" ve "Alternative names" bölümlerini kontrol edin; orada listelenen adlar ile ziyaretçilerinizin kullandığı adreslerin birebir örtüşmesi gerekir.

Tekrarını önlemenin yolu, yeni alan adı ekleme adımını sertifika adımıyla birleştirmektir. Yeni bir alt alan adı açtığınızda DNS kaydı, sanal konak ve sertifika genişletme işlemlerini tek bir kontrol listesinde toplayın. certbot kullanıyorsanız yenileme sonrası servisi yeniden yükleyecek bir kanca tanımlamak da iyi bir alışkanlıktır:

sudo certbot renew --deploy-hook "systemctl reload nginx"

Son olarak izleme kurun: sertifikanın süresini değil kapsamını da denetleyen bir kontrol, bu hatayı müşteriniz görmeden yakalar. Yukarıdaki döngüyü haftalık bir cron görevine koyup çıktı beklenenden farklıysa kendinize e-posta göndermek, ticari bir izleme aracı almadan aynı işi görür.

Sıkça Sorulan Sorular#

Bu hatayı ziyaretçi kendi tarafında çözebilir mi#

Hayır. Önbellek temizleme, saat düzeltme ya da tarayıcı değiştirme bu hatayı gidermez, çünkü sorun ziyaretçinin cihazında değil sunucunun sunduğu sertifikadadır. Ziyaretçinin yapabileceği tek şey uyarıyı geçip devam etmektir ki bu da bağlantının doğrulanmadığı anlamına gelir. Çözüm tamamen site sahibinin elindedir.

Sertifikam geçerli görünüyor, süresi de dolmamış, neden bu hatayı alıyorum#

Geçerlilik süresi ile kapsam iki ayrı şeydir. Sertifika bugün geçerli olabilir ama ziyaretçinin yazdığı ana bilgisayar adını içermiyor olabilir. Sertifikanın hangi adları kapsadığını yazıdaki openssl komutuyla okuyun; Subject Alternative Name listesinde beklediğiniz ad yoksa neden budur ve tek çözüm sertifikayı o adı içerecek şekilde yeniden almaktır.

Joker sertifikam var ama alt alan adım yine hata veriyor#

Joker sertifikalar yalnızca tek bir etiket karşılar. *.ornek.com sertifikası panel.ornek.com için geçerlidir, ancak api.panel.ornek.com için geçerli değildir ve kök alan adı olan ornek.com için de geçerli değildir. İki seviyeli adres kullanacaksanız o seviye için ayrı bir joker gerekir; kök alan adı ise sertifikaya ayrıca eklenmelidir.

www için ayrı sertifika mı almalıyım#

Hayır, ayrı sertifika gerekmez. Doğru yöntem tek sertifikanın SAN listesine her iki adı da yazmaktır. certbot ile bunu --expand seçeneği ve tüm alan adlarını -d ile birlikte vererek yaparsınız; cPanel AutoSSL ise her iki adı da otomatik ekler. İki ayrı sertifika yönetmek yenileme takibini gereksiz yere zorlaştırır.

Sertifikayı yeniledim ama tarayıcı hâlâ eskisini gösteriyor#

Neredeyse her zaman web sunucusu yeniden yüklenmemiştir; nginx veya Apache eski dosyayı bellekte tutmaya devam eder. Sunucuyu yeniden yükleyip canlı sertifikanın parmak izini diskteki dosyanınkiyle karşılaştırın. İkisi hâlâ farklıysa yapılandırmanız beklediğinizden başka bir dosyayı okuyor demektir; sertifika yolunu kontrol edin.

Kendi ürettiğim sertifika neden hiçbir tarayıcıda çalışmıyor#

İki sebep birden olabilir. Birincisi, sertifikayı tanınan bir otorite imzalamadığı için tarayıcı otorite hatası verir. İkincisi, eski usul komutlarla üretilen CSR'larda Subject Alternative Name uzantısı bulunmaz ve modern tarayıcılar Common Name alanına hiç bakmadığı için kapsam hatası da eklenir. Yerel geliştirme için sertifika üretiyorsanız SAN alanını mutlaka tanımlayın.