Wildcard SSL Nedir? Kurulum, DNS Doğrulama ve Riskler

Wildcard SSL nedir?

Wildcard SSL, tek bir sertifikayla bir alan adının birinci seviye alt alan adlarını (*.example.com biçiminde) HTTPS ile koruyan sertifika türüdür. Yıldız karakteri tek bir etiketin yerini tutar. Böylece shop.example.com ve blog.example.com aynı sertifikayı kullanır, ancak ana alan adını ayrıca eklemeniz gerekir.

Biz dijital pazarlama ve web ekibiyiz, hosting firması değiliz. Bu yüzden teknik anlatımı resmi belgelere ve standartlara dayandırdık. Kaynakları metin içinde bağlantı olarak veriyoruz, böylece her adımı kendiniz doğrulayabilirsiniz.

SSL'in ne olduğunu burada yeniden anlatmıyoruz. Temeller için SSL sertifikası ve HTTPS rehberimiz yeterli. Bu yazıda yalnızca wildcard SSL kapsamını, DNS doğrulamasını, kurulum akışını ve sınırlarını ele alıyoruz. Ayrıca her bölümde hangi işi kendiniz yapabileceğinizi, hangisini sağlayıcınıza bırakmanız gerektiğini söylüyoruz.

Wildcard SSL sertifikası tam olarak hangi adresleri kapsar?

Standartlar bu konuda nettir. RFC 9525, joker karakterin yalnızca en soldaki etiketin tamamı olarak görünebileceğini söyler. Ayrıca bu karakterin yalnızca tek bir etiketle eşleşebileceğini belirtir. Dolayısıyla kapsam sandığınızdan dardır.

*.example.com sertifikası şu adresleri korur:

• www.example.com, çünkü tek bir etiket olan "www" yıldızın yerine geçer.
• shop.example.com ve blog.example.com gibi her birinci seviye alt alan adı.
• Henüz oluşturmadığınız, ileride açacağınız alt alan adları.

Aynı sertifika şu adresleri korumaz:

• example.com, yani çıplak ana alan adı, çünkü eşleşecek bir etiket yoktur.
• a.b.example.com gibi iki seviyeli adresler, çünkü yıldız yalnızca bir etiketi kapsar.
• example.net gibi başka bir alan adı.

Pratikte sertifikayı isterken hem example.com hem *.example.com adını eklersiniz. Böylece ana alan adı ve bütün birinci seviye alt alan adları tek dosyada toplanır. RFC 9525 ayrıca bu davranışın DNS'teki joker kayıt mantığından bilerek ayrıldığını not eder. Yani DNS'te çalışan bir joker kaydın kapsamını sertifikaya aynen taşıyamazsınız.

Wildcard SSL ile tek alanlı ve SAN sertifikası arasındaki fark nedir?

Üç sertifika modeli arasındaki fark, hangi adresleri tek sertifikada toplayacağınızdan çıkar. Aşağıdaki tablo kapsamı yan yana gösterir. Özellikle alt alan adı sayınız sık değişiyorsa tabloya bakmak karar vermeyi kolaylaştırır.

Burada önemli bir ayrıntı var. Wildcard sertifika da teknik olarak SAN alanında "*.example.com" kaydını taşır. Yani bu modeller birbirinin zıddı değildir. Bir sertifikada hem example.com hem *.example.com yazabilir, hatta başka alan adlarını da ekleyebilirsiniz.

Seçimde pratik bir kural kullanıyoruz. Adresleriniz az ve sabitse SAN sertifika yeter. Adresleriniz çok ya da değişkense wildcard daha rahat yönetilir. Ancak hassas bir adres varsa onu her iki modelde de ayrı sertifikaya almak daha sağlıklıdır.

Wildcard SSL sertifikasına ne zaman ihtiyaç duyarsınız?

Her sitenin wildcard SSL'e ihtiyacı yoktur. Önce alt alan adı sayısına ve değişim hızına bakın. Birkaç sabit adres için tek alanlı ya da SAN sertifika genellikle daha sade ve daha güvenlidir.

Wildcard SSL şu durumlarda anlamlı olur:

• Her müşteri ya da kiracı için ayrı alt alan adı açan bir yazılım ürününüz varsa.
• Test, hazırlık ve canlı ortamlar için sık sık yeni alt alan adı oluşturuyorsanız.
• Çok sayıda kampanya ya da bölge alt alan adını tek noktadan yönetmek istiyorsanız.
• Alt alan adı başına sertifika yenilemeyi izlemek ekibinize yük oluşturuyorsa.

Örneğin e-ticaret tarafında mağaza, blog ve destek adresleri ayrı alt alan adlarında duruyorsa wildcard SSL işi toplar. Ancak üç sabit adresiniz varsa üç ayrı sertifika, tek bir anahtarın riskinden daha iyi bir dengedir. Riskleri ilerleyen bölümlerde ayrıntılı anlatıyoruz.

Bir de pazarlama tarafı var. Kampanya sayfalarını alt alan adlarında yayınlıyorsanız her yeni adres için sertifika beklemek lansmanı geciktirir. Böyle bir durumda wildcard, süreyi kısaltır. Yine de bu kararı yalnızca hız için vermeyin.

Ücretsiz ve ücretli wildcard SSL arasında ne fark var?

Tarayıcılar sertifikanın ücretsiz ya da ücretli olduğuna bakmaz. Zincire, kapsama, bitiş tarihine ve alan adıyla eşleşmeye bakar. Dolayısıyla alan adı doğrulamalı (DV) bir wildcard sertifika için ziyaretçi tarafında görünür bir fark beklemeyin.

Fark çoğunlukla sertifikanın çevresindedir. Ücretli sağlayıcılar genellikle destek, garanti koşulları ve yönetim paneli sunar. Ücretsiz seçenekte yenileme ve izleme işi sizdedir. Fiyat ve ömür koşulları sağlayıcıdan sağlayıcıya değiştiği için burada rakam vermiyoruz. Güncel koşulları ilgili sağlayıcının sayfasından okuyun.

• Teknik ekibiniz varsa ve otomasyon kurabiliyorsanız ücretsiz seçenek yeterli olur.
• Kesinti sorumluluğunu başkasına vermek istiyorsanız destekli bir ürün daha rahat olur.
• Sağlayıcınız AutoSSL ile wildcard sunuyorsa ayrıca ödeme yapmanız gerekmeyebilir.

Karar verirken toplam maliyeti düşünün. Sertifikanın ücreti küçük kalem olabilir, ancak bir yenileme kazasının getirdiği kesinti çok daha pahalıdır. Bu nedenle "ücretsiz mi?" sorusunu "kim sorumlu?" sorusuyla birlikte sorun.

Wildcard SSL doğrulaması neden yalnızca DNS ile mümkündür?

Sertifika otoritesi, joker karakterli bir adı onaylamadan önce alan adının sahibi olduğunuzu görmek ister. Let's Encrypt sık sorulan sorular sayfası, wildcard sertifikanın DNS-01 doğrulamasıyla alınması gerektiğini söyler. Yani web sunucusuna dosya koyarak yapılan doğrulama bu iş için yetmez.

DNS-01 sürecinde istemciniz, bir belirteçten ve hesap anahtarınızdan türetilen bir TXT kaydı üretir. Bu kaydı _acme-challenge.example.com adına koyarsınız. Sertifika otoritesi kaydı DNS'ten okuyarak doğrulamayı tamamlar. Bu anlatım Let's Encrypt doğrulama türleri belgesi ile uyumludur.

Bu yüzden wildcard SSL için ilk soru "sunucum hazır mı?" değil, "DNS'e kim, nasıl erişiyor?" sorusudur. DNS başka bir firmadaysa süreç o firmanın iznine ve API'sine bağlı kalır.

DNS değişikliklerinin görünür olması zaman alabilir. Let's Encrypt belgesi, yayılma süresinin gecikme yaratabileceğini açıkça dezavantaj olarak sayar. Bu yüzden TXT kaydını ekledikten sonra hemen devam etmeyin. Kaydı bir sorgu aracıyla görün, ardından doğrulamayı başlatın. Üstelik eski bir _acme-challenge kaydı kaldıysa yeni değerle karışabilir, o nedenle eski kaydı temizleyin.

Kuruluma başlamadan önce hangi hazırlıkları yapmalısınız?

Komutu çalıştırmadan önce dört şeyi netleştirin. Çünkü wildcard SSL sürecinde en sık takılma noktası teknik değil, yetki sorunudur. Alan adını kim yönetiyor, DNS nerede, sunucuya kim erişebiliyor?

1. Alan adının DNS yönetimine erişiminiz olduğunu doğrulayın.
2. DNS sağlayıcınızın API sunup sunmadığını öğrenin.
3. Sertifikayı kullanacak sunucuların listesini çıkarın.
4. Yenileme sırasında kimin uyarı alacağını belirleyin.

Ayrıca mevcut DNS kayıtlarını bir yere kaydedin. DNS sorgulama aracı ile bu kayıtları hızlıca görebilirsiniz. Kayıtlarınızı saklama düzeni için yedekleme stratejisi yazımız bir çerçeve sunar. DNS değişikliği yaparken küçük bir hata bütün sitenin erişimini bozabilir.

Bir noktaya daha dikkat edin. Alan adınızda CAA kaydı varsa, sertifika otoritelerinin hangisinin sertifika verebileceğini bu kayıt belirler. Wildcard için ayrı bir issuewild etiketi de bulunur. Dolayısıyla kayıt, seçtiğiniz otoriteye izin vermiyorsa doğrulama geçse bile sertifika çıkmaz.

Let's Encrypt ile wildcard SSL adım adım nasıl alırsınız?

Elinizde root erişimi olan bir VPS ya da sunucu varsa en yaygın yol Certbot'tur. Önce Certbot'u kurmanız gerekir. Güncel kurulum yönergeleri için resmi sayfayı (certbot.eff.org) izleyin, çünkü yöntem dağıtıma göre değişir.

Certbot kullanım kılavuzu wildcard sertifikanın yalnızca DNS doğrulamasıyla alınabildiğini yazar. Aynı belgedeki elle doğrulama örneği DNS meydan okumasını tercih eder. Hook betikleriyle otomasyon bu biçimde kurulur:

certbot certonly --manual --preferred-challenges=dns \
  --manual-auth-hook /path/to/dns/authenticator.sh \
  --manual-cleanup-hook /path/to/dns/cleanup.sh \
  -d example.com -d "*.example.com"

Hook vermezseniz Certbot sizden TXT kaydını elle eklemenizi ister. Bu akışı şöyle izlersiniz:

1. Certbot ekranda bir TXT değeri gösterir.
2. DNS panelinizde _acme-challenge adıyla bu değeri içeren bir TXT kaydı oluşturursunuz.
3. Kayıt yayıldıktan sonra Certbot'ta devam edersiniz.
4. Doğrulama geçerse sertifika dosyaları oluşur.

Kayıt yayılmadan devam etmeyin. Önce DNS sorgulama aracı ya da komut satırından TXT kaydının göründüğünü teyit edin. Aksi halde doğrulama başarısız olur. Elle akış tek seferlik denemeler için uygundur, ama 90 günde bir tekrar etmek zorunda kalırsınız.

Wildcard SSL yenilemesini DNS API ile nasıl otomatikleştirirsiniz?

Let's Encrypt sertifikalarının varsayılan ömrü 90 gündür; bu bilgi SSS sayfasında yer alır. Dolayısıyla elle yenileme sürdürülebilir değildir. Otomasyon için DNS sağlayıcınızın Certbot eklentisini kullanırsınız. Certbot belgesinde Cloudflare, DigitalOcean, Google ve Route 53 eklentileri listelenir.

certbot-dns-cloudflare belgesi Cloudflare için kısıtlı bir API belirteci önerir. Belirteç, ilgili bölge için DNS düzenleme yetkisi taşır. Kimlik bilgisi dosyasının biçimi şöyledir:

dns_cloudflare_api_token = BURAYA_BELIRTEC_YAZILIR

Dosyanın izinlerini kısıtlayın. Belge bu amaçla chmod 600 komutunu gösterir. Dosyayı okuyabilen herkes sizin adınıza API çağrısı yapabilir. Wildcard komutu ise şöyle görünür:

certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials ~/.secrets/certbot/cloudflare.ini \
  -d example.com \
  -d "*.example.com"

Yenileme için Certbot belgesi certbot renew komutunu verir. Zamanlamayı cron ya da systemd zamanlayıcısıyla kurarsınız. Önce deneme yapmak için certbot renew --dry-run komutunu çalıştırabilirsiniz. Başka bir DNS sağlayıcısı kullanıyorsanız ilgili eklentinin belgesini aynı sırayla izleyin.

Wildcard SSL sertifikasını Nginx ve Apache'ye nasıl bağlarsınız?

Certbot sertifika dosyalarını varsayılan olarak /etc/letsencrypt/live/example.com/ klasörüne yazar. Burada fullchain.pem ve privkey.pem dosyalarını görürsünüz. Web sunucusu yapılandırmasında bu iki dosyayı göstermeniz yeterlidir.

Nginx için örnek bir sunucu bloğu şöyledir:

server {
    listen 443 ssl;
    server_name example.com *.example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

Apache için aynı mantık geçerlidir. SSLCertificateFile satırına tam zinciri, SSLCertificateKeyFile satırına özel anahtarı yazarsınız. Ardından yapılandırmayı sınayıp servisi yeniden yüklersiniz.

Yenilemeden sonra sunucunun yeni dosyayı okuması gerekir. Certbot'un --deploy-hook seçeneğiyle yeniden yükleme komutunu bağlayabilirsiniz. Birden fazla sunucu aynı sertifikayı kullanacaksa özel anahtarı dikkatle taşıyın. Kopyaladığınız her anahtar ayrı bir risk noktasıdır. Bu nedenle sertifikayı her sunucuda ayrı ayrı yenilemeyi de değerlendirin.

cPanel'de wildcard SSL nasıl kurulur?

Paylaşımlı hosting kullanıyorsanız çoğu işi hosting sağlayıcınız belirler. cPanel SSL rehberi sayfasına göre joker karakterli sertifika, aynı IP adresini paylaşan alt alan adlarını tek sertifikayla korur. Ancak bu sertifika example.com ana alan adını korumaz.

Aynı rehber, Let's Encrypt sağlayıcısının wildcard alan adlarını koruyabildiğini belirtir. AutoSSL ise yalnızca alan adı doğrulamasını (DCV) geçen adları sertifikaya dahil eder. Dolayısıyla her şey sağlayıcının AutoSSL ayarına bağlıdır.

Elinizde hazır bir wildcard sertifika varsa genel akış şudur:

1. cPanel'de SSL/TLS arayüzüne girin.
2. "Install and Manage SSL for your site (HTTPS)" bölümünü açın.
3. Sertifikayı, özel anahtarı ve varsa CA paketini ilgili alanlara yapıştırın.
4. Sertifikayı kullanacağınız alan adını seçip kurulumu tamamlayın.

Menü adları cPanel sürümüne ve sağlayıcının ayarlarına göre farklı olabilir. Ayrıca cPanel belgesine göre gelişmiş arayüzden wildcard sertifika satın alamazsınız. Satın alma için basit arayüzü kullanırsınız. Takıldığınızda sağlayıcınızın destek ekibine yazmak en hızlı çözümdür.

Wildcard SSL kurulumunu nasıl doğrularsınız?

Kurulumdan sonra üç şeye bakın: sertifikanın hangi adları taşıdığı, bitiş tarihi ve zincirin eksiksiz olması. Hızlı kontrol için SSL sorgulama aracı işinizi görür. Komut satırını tercih ederseniz openssl ile sertifikadaki adları listeleyebilirsiniz.

openssl s_client -connect shop.example.com:443 -servername shop.example.com </dev/null | openssl x509 -noout -ext subjectAltName -dates

Çıktıda example.com ve *.example.com adlarını görmelisiniz. Ayrıca tarayıcıda farklı alt alan adlarını açıp kilit simgesini kontrol edin. Her alt alan adı için ayrı deneme yapın, çünkü bazı alt alan adları başka bir sunucuda çalışıyor olabilir.

Otomatik yenilemeyi de sınayın. certbot certificates komutu sahip olduğunuz sertifikaları ve bitiş tarihlerini listeler. Yenileme denemesi başarısız olursa hata mesajı genellikle DNS kaydını ya da API yetkisini işaret eder. Bu kontrolü kurulumdan hemen sonra, ardından da düzenli aralıklarla tekrarlayın.

Çok seviyeli alt alan adlarında wildcard SSL neden çalışmaz?

Bu, en çok yanlış anlaşılan sınırdır. *.example.com sertifikası api.example.com adresini korur, ancak v1.api.example.com adresini korumaz. RFC 9525 yıldızın yalnızca tek bir etiketle eşleşebileceğini söyler. Dolayısıyla ikinci seviye bir adres tarayıcıda sertifika hatası verir.

Üç çözümünüz var:

• İkinci seviye için ayrıca *.api.example.com adlı bir wildcard sertifika alırsınız.
• Sertifikaya bu adresleri tek tek SAN olarak eklersiniz.
• Adres yapınızı tek seviyeye indirirsiniz, örneğin v1-api.example.com biçimine geçersiniz.

Yapı kararını vermeden önce alan adı planınızı gözden geçirin. alan adı seçimi yazımız bu planlamada işinize yarar. Özellikle ürününüz müşteri başına iç içe alt alan adı açıyorsa, baştan doğru bir hiyerarşi kurmak sonradan yapacağınız düzeltmeden ucuzdur.

Wildcard SSL'in riskleri neler?

Wildcard SSL'in en büyük riski tek anahtardır. Aynı özel anahtar birçok alt alan adında ve çoğu zaman birden çok sunucuda durur. Anahtar ele geçerse saldırgan, kapsamdaki her alt alan adı için geçerli bir sertifikaya sahip olur.

Let's Encrypt belgesi, DNS-01 yönteminin dezavantajları arasında API kimlik bilgilerini web sunucularında saklamanın riskini sayar. Ayrıca her DNS sağlayıcısının gerekli API'yi sunmadığını belirtir. Bu iki nokta, otomasyon kurmadan önce düşünmeniz gereken gerçek bir bedeldir.

Bu riskleri nasıl azaltırsınız?

Risk sıfırlanmaz ama yönetebilirsiniz. İlk adım, anahtarı mümkün olduğunca az yerde tutmaktır. İkinci adım DNS yetkisini daraltmaktır. Üçüncü adım ise kritik adresleri wildcard'ın dışında bırakmaktır.

• API belirtecini yalnızca ilgili DNS bölgesi ve yalnızca DNS düzenleme yetkisiyle sınırlayın.
• Kimlik bilgisi dosyasını yalnızca gerekli kullanıcının okuyabileceği izinle saklayın.
• Ödeme, yönetim paneli ve müşteri verisi gibi hassas alt alan adlarına ayrı sertifika verin.
• Wildcard anahtarını geliştirme ve test sunucularına kopyalamayın.
• Bitiş tarihi için bağımsız bir izleme ya da takvim uyarısı kurun.

Ayrıca DNS doğrulamasını başka bir bölgeye devretmek mümkündür. Let's Encrypt belgesine göre CNAME ya da NS kayıtlarıyla doğrulamayı başka bir DNS bölgesine devredebilirsiniz. Böylece asıl bölgenizin API yetkisini sunucuya vermezsiniz. Bu yaklaşım dikkatli kurulum gerektirir, bu yüzden uzman desteği almanızı öneririz.

Wildcard SSL kurulumunda hangi hatalarla karşılaşırsınız?

Sorunların çoğu aynı beş yerden çıkar. Hataları bilmek, sorunu dakikalar içinde bulmanızı sağlar. Bu yüzden listeyi kurulumdan önce bir kez okuyun.

1. Ana alan adını sertifikaya eklememek. Sonuç olarak example.com adresi hata verir.
2. TXT kaydı yayılmadan doğrulamayı başlatmak.
3. _acme-challenge kaydını yanlış alan adına eklemek. Kayıt örneğin example.com.example.com olarak görünür.
4. API belirtecine yanlış bölge ya da yetersiz yetki vermek.
5. Sertifikayı yeniledikten sonra web sunucusunu yeniden yüklememek.

Beşinci madde özellikle sinsidir. Certbot yeni dosyayı yazar, ancak çalışan sunucu eski sertifikayı bellekte tutabilir. Dolayısıyla yenileme sonrası yeniden yükleme adımını otomasyona ekleyin. Hata mesajlarını Certbot günlüğünde ve web sunucusu günlüğünde arayın.

Bir de yönetim tarafı hatası var: sertifikanın sahibi belli değildir. Sertifikayı kuran kişi şirketten ayrılınca yenileme sessizce durur. Bu nedenle sorumluyu ve yedek sorumluyu yazılı belirleyin.

Wildcard SSL sertifikasının bitiş tarihini nasıl izlersiniz?

Otomatik yenileme kurmak yetmez, çünkü otomasyon da bozulur. DNS belirteci süresi dolabilir, kayıt değişebilir ya da zamanlayıcı durabilir. Bu yüzden bitiş tarihini bağımsız bir yoldan izleyin.

• Sunucuda certbot certificates komutuyla bitiş tarihlerini düzenli aralıklarla kontrol edin.
• Dışarıdan bakan bir kontrol için SSL sorgulama aracı aracını takvim hatırlatmasıyla birlikte kullanın.
• Yenileme günlüğünü bir yere gönderin ki hata sessiz kalmasın.
• Bitişe yakın bir uyarıyı en az iki kişiye iletin.

Ayrıca izlemenizi alt alan adı bazında yapın. Çünkü bir alt alan adı başka bir sunucuda eski bir sertifikayla çalışıyor olabilir. Wildcard sertifika tek dosya olsa da her sunucudaki kopya ayrı yenilenir. Dolayısıyla "sertifika yenilendi" mesajı, "her adres yenilendi" anlamına gelmez.

Wildcard SSL sertifikasını yeni sunucuya ya da hosting'e taşırken nelere dikkat edersiniz?

Taşıma sırasında iki seçeneğiniz var: aynı sertifikayı kopyalamak ya da yeni sunucuda yeni sertifika almak. Kopyalama hızlıdır, ancak özel anahtarın yeni bir yere gitmesi demektir. Yeni sertifika almak ise biraz zaman ister, ama anahtarı yalnızca yeni yerde tutar.

1. Eski ve yeni sunucuda hangi alt alan adlarının çalışacağını listeleyin.
2. DNS kayıtlarını değiştirmeden önce yeni sunucuda sertifikayı hazırlayın.
3. Geçişten sonra her alt alan adını tarayıcıda ve bir kontrol aracında deneyin.
4. Eski sunucudaki anahtar kopyalarını güvenli biçimde silin.

Sertifikayı taşırken yedek de almak isteyebilirsiniz. Ancak özel anahtarın yedeği, sertifikanın kendisinden çok daha hassastır. Bu nedenle anahtarı yalnızca şifreli ve erişimi sınırlı bir yerde saklayın. Yedekleme düzeni için yedekleme stratejisi yazımız bir başlangıç sunar.

Wildcard SSL kullanırken unutulmuş alt alan adları neden tehlikelidir?

Wildcard sertifika, henüz var olmayan alt alan adlarını da kapsar. Bu yüzden DNS'te unutulmuş bir kayıt, yani artık kullanmadığınız bir hizmete işaret eden alt alan adı, ayrı bir risk doğurur. Başkası o hizmeti ele geçirirse, adresiniz üzerinde sizin sertifikanızla geçerli görünen bir sayfa yayınlayabilir.

Bu durum doğrudan sertifikanın hatası değildir. Ancak wildcard, güven kapsamını genişlettiği için sonucu büyütür. Dolayısıyla sertifika kararını bir DNS temizliğiyle birlikte düşünün.

• DNS bölgenizdeki kayıtları belirli aralıklarla gözden geçirin.
• Kullanmadığınız hizmetlere işaret eden CNAME kayıtlarını silin.
• Yeni bir alt alan adı açarken kaydı ve sahibini bir listeye yazın.
• Test ortamı adreslerini iş bitince DNS'ten kaldırın.

Genel web güvenliği çerçevesi için OWASP Top 10 yazımız iyi bir başvuru noktasıdır. DNS sorgulama aracı ile kayıtlarınızı elle gözden geçirebilirsiniz.

Kurulumdan sonra hangi kontrol listesini uygularsınız?

Kurulumu bitirdiğinizde iş bitmez. Küçük bir kontrol listesi, aylar sonra çıkacak sürprizleri azaltır. Listeyi yazılı tutun ve ekibinizle paylaşın.

1. Sertifika example.com ve *.example.com adlarını taşıyor mu?
2. Her kritik alt alan adı tarayıcıda uyarısız açılıyor mu?
3. Otomatik yenileme için deneme çalıştırması başarılı mı?
4. Yenileme sonrası web sunucusu yeni dosyayı yüklüyor mu?
5. API belirteci yalnızca gereken yetkiye sahip mi?
6. Bitiş tarihi için bağımsız bir uyarı kurulu mu?
7. Sertifikadan ve anahtardan kimin sorumlu olduğu yazılı mı?

Bu listeyi her büyük DNS ya da sunucu değişikliğinden sonra yeniden uygulayın. Örneğin hosting değiştirdiğinizde ya da yeni bir alt alan adı grubu açtığınızda liste yeniden anlam kazanır.

Wildcard SSL'i ne zaman kendiniz kurmamalı, hosting sağlayıcınıza bırakmalısınız?

Dürüst olalım: her işi kendiniz yapmak zorunda değilsiniz. Bazı durumlarda sağlayıcınıza bırakmak hem daha güvenli hem daha ucuzdur. Biz hosting işletmiyoruz; bu yüzden bu kararı size tarafsız anlatabiliyoruz.

Şu durumlarda işi sağlayıcınıza bırakın:

• Paylaşımlı hostingdesiniz ve sunucuda root erişiminiz yok.
• DNS kayıtları başka bir firmada duruyor ve API erişimi alamıyorsunuz.
• Komut satırında çalışmak size yabancı ve bir hata sitenizi kapatabilir.
• Ödeme alan bir e-ticaret sitesinde kesinti riskini taşıyamazsınız.
• Kurumsal ya da düzenlemeye tabi bir yapıda anahtar yönetimi için politika gerekiyor.

Bu durumda sağlayıcınıza şunu sorun: "AutoSSL ile wildcard sertifika sunuyor musunuz, yenilemeyi kim izliyor?" Ayrıca hosting seçimi yazımız sağlayıcı seçerken sorulacak soruları toplar. Güvenlik tarafı için OWASP Top 10 yazımız genel çerçeveyi verir.

Wildcard SSL kararını hangi sırayla vermelisiniz?

Karar sırası basittir. Önce ihtiyacı sorgulayın, sonra riski tartın, en son aracı seçin. Çoğu işletme için doğru cevap karma bir yapıdır: sabit adresler için ayrı sertifika, değişken adresler için wildcard.

1. Kaç alt alan adınız var ve bunlar ne kadar sık değişiyor?
2. Hassas hizmetler aynı sertifikayı paylaşmak zorunda mı?
3. DNS sağlayıcınız API ile doğrulamayı destekliyor mu?
4. Yenilemeyi kim izleyecek, hata olursa kim uyarı alacak?
5. Sertifikayı sağlayıcınız mı yoksa siz mi yönetmelisiniz?

Sertifika kararı tek başına bir pazarlama işi değildir, ama sitenizin güveni ve hızıyla yakından ilgilidir. HTTPS bozulduğunda ziyaretçi tarayıcı uyarısı görür, reklam ve organik trafik boşa gider. site hızının SEO etkisi ve SEO danışmanlığı hizmetimiz üzerine yazdıklarımız bu ilişkiyi açıyor. Yeni bir site planlıyorsanız web tasarım hizmetimiz kapsamında bu altyapı kararlarını birlikte netleştirebiliriz.