shop.example.comaçıldığında yalnızca example.comiçin düzenlenmiş bir sertifika sunuluyorsa tarayıcı bağlantıyı durdurur. Kök alana yönlendirme eklemek bunu çözmez; TLS doğrulaması HTTP yönlendirmesinden önce yapılır.
Önce ziyaretçinin istediği tam hostu ve o SNI adıyla sunulan sertifikayı karşılaştırın. Sorun sertifikanın kapsamından, yanlış virtual hosttan, DNS kaydından veya CDN’deki host–sertifika eşlemesinden kaynaklanabilir.
Sertifika adı uyuşmazlığı nedir?
İstenen host, sertifikanın Subject Alternative Name (SAN) listesinde yoksa veya sunucu o SNI adı için yanlış sertifikayı seçerse ad uyuşmazlığı oluşur. Wildcard sertifika yalnız belirli bir alt alan seviyesini kapsar; *.example.comkök alanı veya a.b.example.comgibi daha derin hostları otomatik olarak kapsamaz.
Gerçekçi bir WordPress örneği
CDN’ye eklenen shop.example.comDNS kaydı etkinleşmiştir, fakat bu host CDN’nin özel alan listesine ve sertifikasına eklenmemiştir. Ziyaretçi varsayılan CDN sertifikasını alır. WordPress’teki site adresi doğru olsa bile hata sürer.
Başka bir durumda IPv4 doğru virtual hosta, IPv6 ise varsayılan sunucuya gider. Bu nedenle her hostu iki adres ailesinde ve SNI ile ayrı test etmek gerekir.
Neden önemlidir?
Ad uyuşmazlığı kimlik doğrulamasını bozar; tarayıcı, API istemcisi veya webhook bağlantıyı reddedebilir. Sertifika denetimini kapatmak güvenli bir çözüm değildir. Kullanılacak bütün genel hostların açıkça listelenmesi ve doğru sertifikaya bağlanması gerekir.
Temel çözüm adımları
- Hata veren URL’deki tam host adını kaydedin.
- SNI ile sunulan sertifikanın SAN listesini kontrol edin.
- DNS kaydının doğru CDN veya sunucuya yöneldiğini doğrulayın.
- Hostu kapsayan sertifikayı ilgili edge ve origin dinleyicilerine bağlayın.
- Alternatif hostu ancak TLS geçerli olduktan sonra kanonik adrese yönlendirin.
- Giriş, OAuth callback, webhook ve site haritası gibi gerçek yolları yeniden sınayın.
İleri teknik kontroller
SNI olan ve olmayan bağlantıları karşılaştırın; virtual host sırasını, CDN custom hostname ayarını, sertifika seri numarasını, IPv4/IPv6 endpoint’lerini ve proxy üzerindeki host–sertifika eşlemesini inceleyin. Birden fazla sertifika kullanılıyorsa RSA/ECDSA seçiminin de aynı SAN kapsamını sunduğunu doğrulayın.
Staging veya eski alt alanların yanlışlıkla canlı sertifika kapsamına ya da WordPress canonical URL’lerine girmediğini kontrol edin. Desteklenmeyen hostların bilinçli biçimde reddedilmesi, geniş bir varsayılan virtual hosttan daha güvenlidir.
Riskler, sık hatalar ve geri alma
Wildcard kapsamını yanlış yorumlamak, yalnız tek hostu test etmek ve yönlendirmenin TLS hatasını örteceğini sanmak sık hatalardır. Yeni sertifikayı doğrulamadan mevcut bağlantıyı kaldırmayın. Dağıtım yanlış sertifika sunarsa önceki host–sertifika eşlemesini geri yükleyin ve DNS/CDN değişikliklerini ayrı inceleyin.
AIOWS nasıl yardımcı olur?
AIOWS SSL Yöneticisi
Doğru sertifika ilgili host için sunulmaya başladıktan sonra AIOWS SSL Yöneticisi, WordPress adresleriyle yönlendirmelerin bu hostla uyumunu denetlemeye yardımcı olur.
Modül sertifika otoritesinin, DNS’in veya CDN’nin yerine geçmez. SAN listesi eksikse yeni sertifika ilgili sağlayıcı üzerinden oluşturulmalı; yanlış sertifika sunuluyorsa edge ya da web sunucusundaki SNI bağlantısı düzeltilmelidir. Ardından WordPress tarafındaki kanonik adres ve gerçek kullanıcı yolları sınanmalıdır.
Host uyuşmazlığı devam ederken yönlendirme veya eklenti ayarı eklemeyin. Önce TLS kimliğini düzeltin, sonra uygulama davranışını değerlendirin; böylece altyapı hatasını WordPress yapılandırmasıyla gizlememiş olursunuz.
AIOWS SSL Yöneticisi’ni inceleyinAIOWS planlarını karşılaştırın
İlgili AIOWS yazıları
- WordPress Sitesine SSL Nasıl Kurulur?
- WordPress SSL Handshake Hatası: Nedenleri ve Çözümleri
- WordPress’te WWW ve WWW Olmayan HTTPS Yönlendirmeleri
Sonuç ve önerilen yol
Her genel hostu doğru SAN kapsamına ve SNI bağlantısına alın. TLS kimliği doğrulanmadan yönlendirmelere güvenmeyin; DNS, CDN ve WordPress kanonik adresini ancak sertifika doğru sunulduktan sonra hizalayın.
