HTTPS Protokolü Nedir ve Nasıl Çalışır

HTTPS (HyperText Transfer Protocol Secure), HTTP’nin şifreli versiyonudur; standart web aktarım protokolünü TLS (Transport Layer Security) ile birleştirerek bir istemci tarayıcısı ile web sunucusu arasında kimliği doğrulanmış, şifreli bir kanal oluşturur. HTTPS üzerinden iletilen her veri baytı kriptografik olarak korunur; bu da ne pasif dinleyicilerin ne de aktif ortadaki adam saldırganlarının aktarım sırasında yükü okuyamayacağı veya sessizce değiştiremeyeceği anlamına gelir.

Pratik açıdan: bir tarayıcı https://example.com‘e bağlandığında, önce sunucunun kimliğini imzalı bir sertifika aracılığıyla doğrulayan, bir şifre paketi müzakere eden ve simetrik oturum anahtarları türeten bir TLS el sıkışması tamamlar — tek bir bayt uygulama verisi değiş tokuş edilmeden önce. Yalnızca bu el sıkışması başarılı olduktan sonra HTTP isteği tamamen şifreli olarak iletilir.

HTTP ve HTTPS: Doğrudan Karşılaştırma

TLS El Sıkışmasının Derinlemesine İncelenmesi

El sıkışmayı anlamak, sertifika hatalarını teşhis etmek, sunucu performansını ayarlamak ve güvenlik yapılandırmalarını sertleştirmek için temel oluşturur. Süreç, TLS 1.2 ve TLS 1.3 arasında biraz farklılık gösterir — ve bu fark operasyonel açıdan önemlidir.

TLS 1.2 El Sıkışması (Eski)

1. ClientHello — Tarayıcı desteklenen şifre paketlerini, TLS sürümünü ve rastgele bir nonce (client_random) gönderir.
2. ServerHello — Sunucu bir şifre paketi seçer ve kendi nonce’unu (server_random) gönderir.
3. Sertifika — Sunucu, tarayıcının güvenilir CA deposuna karşı doğrulaması için X.509 sertifika zincirini iletir.
4. ServerKeyExchange — Geçici Diffie-Hellman (ECDHE) için sunucu, özel anahtarıyla imzalanmış DH parametrelerini gönderir.
5. ClientKeyExchange — Tarayıcı bir ön ana sır oluşturur, bunu sunucunun genel anahtarıyla (RSA) şifreler veya paylaşılan bir DH sırrı (ECDHE) hesaplar ve gönderir.
6. ChangeCipherSpec / Finished — Her iki taraf da client_random, server_random ve ön ana sırdan oturum anahtarları türetir, ardından bir Finished mesajıyla onaylar.

Veri öncesi toplam gidiş-dönüş sayısı: 2 RTT.

TLS 1.3 El Sıkışması (Güncel Standart)

RFC 8446 ile standartlaştırılan TLS 1.3, birçok eski mekanizmayı ortadan kaldırır ve gecikmeyi önemli ölçüde azaltır:

1. ClientHello — Tarayıcı, desteklenen şifre paketleriyle birlikte anahtar paylaşımını (ECDHE genel değeri) hemen ekler. RSA anahtar değişimine izin verilmez.
2. ServerHello + EncryptedExtensions + Sertifika + CertificateVerify + Finished — Sunucu tek bir uçuşta yanıt verir; türetilmiş bir el sıkışma anahtarı kullanarak uzantıları ve sertifikasını zaten şifreler.
3. Client Finished — Tarayıcı sunucu sertifikasını doğrular ve Finished mesajını gönderir. Uygulama verileri hemen ardından akabilir.

Veri öncesi toplam gidiş-dönüş sayısı: 1 RTT. 0-RTT yeniden bağlantı (oturum biletleri) ile geri dönen ziyaretçiler ilk pakette veri gönderebilir — ancak bu, dikkatli sunucu tarafı işleme gerektiren tekrar saldırısı değerlendirmelerini beraberinde getirir.

TLS 1.3’ün 1.2’ye göre temel iyileştirmeleri:

• RSA anahtar değişimi kaldırıldı (ileri gizlilik riski yok)
• MD5, SHA-1, RC4, DES, 3DES kaldırıldı
• ECDHE aracılığıyla zorunlu ileri gizlilik
• Şifreli sertifika iletimi (meta veri sızıntısını azaltır)
• Daha hızlı el sıkışması, yüksek gecikmeli bağlantılarda sayfa yükleme süresini ölçülebilir şekilde azaltır

Sertifika Türleri ve Gerçekte Neyi Korudukları

Tüm SSL/TLS sertifikaları eşdeğer değildir. Yanlış türü seçmek yaygın bir operasyonel hatadır.

Alan Adı Doğrulama (DV)

Otomatik sistemler tarafından dakikalar içinde verilir (örn. Let’s Encrypt). Sertifika sahibinin alan adının DNS’ini veya web sunucusunu kontrol ettiğini kanıtlar. Tam şifreleme sağlar ancak alan adının arkasındaki kuruluşun sıfır kimlik doğrulaması yapılır. Bloglar, kişisel projeler ve dahili araçlar için uygundur.

Kuruluş Doğrulama (OV)

CA, kuruluşun yasal varlığını manuel olarak doğrular. Sertifika, şirket adını içerir. Marka güveninin önemli olduğu iş web siteleri ve SaaS platformları için uygundur.

Genişletilmiş Doğrulama (EV)

En titiz inceleme sürecidir. Tarihsel olarak tarayıcılarda şirket adıyla yeşil adres çubuğu görüntülerdi; modern tarayıcılar bu görsel ayrımı azaltmıştır, ancak EV sertifikaları sertifikanın kendisine doğrulanmış tüzel kişilik bilgilerini yerleştirmeye devam eder. Finansal kurumlar ve yüksek değerli e-ticaret için uygundur.

Wildcard Sertifikalar

Tek bir sertifika, bir alan adını ve tüm birinci düzey alt alan adlarını (*.example.com) kapsar. Kritik uyarı: bir wildcard, ikinci düzey alt alan adlarını kapsamaz (*.sub.example.com ayrı bir wildcard gerektirir). Bir wildcard özel anahtarının ele geçirilmesi, tüm alt alan adlarını aynı anda açığa çıkarır — bu önemli bir etki alanıdır.

Çok Alanlı (SAN) Sertifikalar

Konu Alternatif Adları (SAN’lar), tek bir sertifikanın birden fazla farklı alan adını (example.com, example.net, shop.example.org) kapsamasına olanak tanır. Tek bir sunucudan birden fazla mülkü yöneten barındırma ortamları için idealdir.

HTTPS’nin 2025’te Vazgeçilmez Olmasının Nedenleri

Hassas Verilerin Şifrelenmesi

TLS olmadan, bir kullanıcı ile sunucunuz arasındaki her paket potansiyel olarak düşmanca ağ altyapısından geçer — genel Wi-Fi erişim noktaları, ISP şeffaf proxy’leri ve BGP ele geçirilmiş rotalar. Kimlik bilgileri, oturum belirteçleri, ödeme verileri ve form gönderimleri düz metin olarak Wireshark gibi araçlarla kolayca yakalanabilir. HTTPS bu saldırı yüzeyini tamamen ortadan kaldırır.

Doğrulanmış Sunucu Kimliği

Sertifika güven zinciri, DNS sahteciliği ve ARP zehirleme saldırılarının kullanıcıları sessizce sahte bir sunucuya yönlendirmesini önler. Bir tarayıcı sertifikayı doğruladığında üç şeyi teyit eder: sertifikanın güvenilir deposundaki bir CA tarafından imzalandığını, alan adının sertifikanın CN veya SAN alanlarıyla eşleştiğini ve sertifikanın süresi dolmamış veya iptal edilmemiş olduğunu (OCSP veya CRL aracılığıyla kontrol edilir).

AEAD Şifreleri Aracılığıyla Veri Bütünlüğü

Modern TLS şifre paketleri, İlişkili Verilerle Kimliği Doğrulanmış Şifreleme (AEAD) kullanır — özellikle AES-256-GCM veya ChaCha20-Poly1305. Bunlar tek bir işlemde hem gizlilik hem de bütünlük sağlar. Aktarım sırasında herhangi bir bit çevirme veya enjeksiyon girişimi, MAC doğrulamasının başarısız olmasına neden olur ve bağlantı hemen sonlandırılır. Bu, ISP’lerin veya kötü niyetli aracıların HTTP yanıtlarına reklam, izleme komut dosyaları veya kötü amaçlı yazılım enjekte ettiği içerik enjeksiyon saldırılarını önler.

SEO ve Sıralama Sinyalleri

Google, 2014 yılında HTTPS’yi bir sıralama sinyali olarak onayladı ve ağırlığını giderek artırdı. Doğrudan sıralama faktörünün ötesinde, Chrome’un HTTP sayfalarındaki “Güvenli Değil” uyarısı, sıralamayı dolaylı olarak baskılayan davranışsal bir sinyal olan hemen çıkma oranlarını ölçülebilir şekilde artırır. Önemli performans iyileştirmeleri sunan HTTP/2 ve HTTP/3 (QUIC), tüm büyük tarayıcı uygulamalarında TLS gerektirir. Daha hızlı sayfalar daha iyi sıralanır; HTTPS ön koşuldur.

HSTS ve Ön Yükleme

HTTP Strict Transport Security (Strict-Transport-Security başlığı), tarayıcılara bir yönlendirme gerçekleşmeden önce bile belirli bir max-age süresi boyunca bir alan adına tüm HTTP bağlantılarını reddetmelerini bildirir. Alan adınızı HSTS ön yükleme listesine göndermek, bu davranışı tarayıcı ikili dosyalarına sabit kodlar ve ilk ziyaret güvenlik açığı penceresini tamamen ortadan kaldırır.

HTTPS Uygulaması: Üretime Hazır Bir Kılavuz

Adım 1: SSL/TLS Sertifikası Edinin

Let’s Encrypt (ücretsiz, otomatik), çoğu dağıtım için standart seçimdir. Certbot, referans ACME istemcisidir:

sudo apt update && sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d example.com -d www.example.com

Apache için:

sudo apt install certbot python3-certbot-apache -y
sudo certbot --apache -d example.com -d www.example.com

Certbot, sanal ana bilgisayar yapılandırmanızı otomatik olarak değiştirir ve yenileme için bir cron görevi veya systemd zamanlayıcısı kurar. Let’s Encrypt sertifikaları 90 gün sonra sona erer; otomatik yenileme varsayılan olarak her 60 günde bir çalışır.

Değişiklik yapmadan yenilemeyi test etmek için:

sudo certbot renew --dry-run

OV veya EV sertifikaları gerektiren üretim ortamları için ticari bir CA’dan (DigiCert, Sectigo, GlobalSign) satın alın ve manuel verme süreçlerini takip edin. AlexHost’un SSL Sertifikaları sayfası, hem DV hem de ticari sertifikalar dahil mevcut seçenekleri kapsar.

Adım 2: Sertifikayı Web Sunucunuza Yükleyin ve Yapılandırın

Nginx örneği (/etc/nginx/sites-available/example.com):

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;

    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
    add_header X-Frame-Options DENY;
    add_header X-Content-Type-Options nosniff;

    root /var/www/example.com;
    index index.php index.html;
}

Apache örneği (/etc/apache2/sites-available/example.com-ssl.conf):

<VirtualHost *:443>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example.com

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/example.com/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
    SSLCertificateChainFile /etc/letsencrypt/live/example.com/chain.pem

    SSLProtocol -all +TLSv1.2 +TLSv1.3
    SSLCipherSuite HIGH:!aNULL:!MD5
    SSLHonorCipherOrder off

    Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
</VirtualHost>

Adım 3: Kalıcı 301 Yönlendirmesiyle HTTPS’yi Zorunlu Kılın

Nginx — ayrı bir sunucu bloğu ekleyin:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Apache — .htaccess‘de veya HTTP sanal ana bilgisayarında:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

302 (geçici) yerine 301 (kalıcı) kullanın. 302, bağlantı değerini aktarmaz ve tarayıcı önbelleklerini güncellemez; bu da kullanıcıların her yeni oturumda HTTP’ye erişmeye devam edeceği anlamına gelir.

Adım 4: Karışık İçeriği Çözün

Karışık içerik, bir HTTPS sayfasının alt kaynakları (resimler, komut dosyaları, stil sayfaları, iframe’ler) HTTP üzerinden yüklemesi durumunda ortaya çıkar. Tarayıcılar karışık içeriği engeller veya uyarır; bu da sayfa işlevselliğini bozar ve HTTPS’nin güvenlik garantilerini ortadan kaldırır.

Tespit: Chrome DevTools’u (F12) açın, Konsol sekmesine gidin ve Mixed Content uyarılarını arayın. Alternatif olarak, SSL Labs Karışık İçerik Denetleyicisini veya why-no-padlock.com aracını kullanın.

Çözüm stratejileri:

• CMS veritabanınızdaki sabit kodlanmış http:// URL’lerini bir arama-değiştirme aracıyla güncelleyin (örn. WordPress için wp-cli search-replace 'http://example.com' 'https://example.com')
• Kaynakları düzeltirken geçici bir önlem olarak Content-Security-Policy: upgrade-insecure-requests başlığını ayarlayın
• Üçüncü taraf yerleştirmelerini denetleyin — bir satıcı HTTPS’yi desteklemiyorsa, yerleştirmeyi değiştirin veya kaldırın

Adım 5: Yapılandırmanızı Doğrulayın

# Test certificate chain and expiry
openssl s_client -connect example.com:443 -servername example.com < /dev/null

# Check TLS protocol versions and cipher suites
nmap --script ssl-enum-ciphers -p 443 example.com

Kapsamlı bir harici denetim için alan adınızı SSL Labs Sunucu Testine gönderin. A+ derecelendirmesi şunları gerektirir:

• Yalnızca TLS 1.2 ve 1.3 (TLS 1.0 ve 1.1 devre dışı)
• Zayıf şifre paketi yok (RC4, 3DES, dışa aktarma şifreleri)
• max-age >= 180 gün olan HSTS başlığı
• Sertifika zinciri sorunu yok (ara sertifikalar dahil)
• OCSP zımbalama etkin

Yaygın Tuzaklar ve Uç Durumlar

Sertifika zinciri eksikliği en sık karşılaşılan üretim sorunudur. Yalnızca yaprak sertifikayı ara CA sertifikası olmadan yüklerseniz, çoğu masaüstü tarayıcı zinciri çözmeye devam eder (ara sertifikaları önbelleğe alırlar), ancak mobil tarayıcılar, API istemcileri ve curl SSL_ERROR_RX_RECORD_TOO_LONG veya unable to get local issuer certificate hatasıyla başarısız olur. Her zaman fullchain.pem (Let’s Encrypt) kullanın veya diğer CA’lar için yaprak + ara sertifikaları birleştirin.

OCSP zımbalama, sunucunun OCSP yanıtını önbelleğe alıp sunmasını sağlayarak el sıkışma gecikmesini azaltır ve tarayıcının CA’nın OCSP yanıtlayıcısıyla iletişim kurmasını gerektirmez. Zımbalama olmadan, her TLS el sıkışması soğuk bağlantılarda 50–200ms gecikme ekleyen bir üçüncü taraf HTTP isteği tetikler. Nginx’te ssl_stapling on; ssl_stapling_verify on; ile etkinleştirin.

Özel anahtar güvenliği sıklıkla ihmal edilir. Özel anahtar dosyası root’a ait olmalı, yalnızca web sunucusu işlemi tarafından okunabilir olmalı ve chmod 600 izinleriyle depolanmalıdır. Özel anahtarları asla sürüm kontrolüne kaydetmeyin. Paylaşılan altyapıda, anahtar depolama için donanım güvenlik modülleri (HSM’ler) veya sır yönetim sistemleri (HashiCorp Vault, AWS Secrets Manager) kullanın.

Wildcard sertifika iptali orantısız bir etkiye sahiptir. Bir wildcard özel anahtarı ele geçirilirse ve sertifika iptal edilirse, her alt alan adı aynı anda HTTPS’yi kaybeder. Yüksek güvenlikli ortamlar için, ACME DNS-01 zorlukları aracılığıyla otomatikleştirilmiş alt alan adı başına sertifikaları tercih edin.

Yük dengeleyicide TLS sonlandırma, TLS’nin kenarda (yük dengeleyici, CDN, ters proxy) şifresinin çözüldüğü ve trafiğin dahili olarak şifresiz aktığı yaygın bir mimaridir. Bu, yalnızca dahili ağın tamamen güvenilir ve izole olması durumunda kabul edilebilir. Düzenlenmiş ortamlar (PCI-DSS, HIPAA) için, yük dengeleyici ile arka uç sunucular arasındaki trafiği yeniden şifreleyen uçtan uca şifreleme gereklidir.

AlexHost Altyapısında HTTPS

Bir VPS Hosting ortamında, Certbot’u yüklemek, Nginx veya Apache’yi doğrudan yapılandırmak ve yukarıda açıklanan sertleştirilmiş TLS ayarlarını uygulamak için tam root erişiminiz vardır. Bu, özel şifre paketleri, HSTS ön yükleme ve OCSP zımbalama gerektiren üretim iş yükleri için önerilen yoldur.

Paylaşımlı Web Hosting kullanan kullanıcılar için, Let’s Encrypt sertifikaları genellikle kontrol paneli aracılığıyla tek tıkla kurulum ile kullanılabilir; SSH erişimi olmadan sertifika verme ve yenilemeyi otomatik olarak gerçekleştirir.

Birden fazla alan adı yönetiyorsanız veya bir bayi operasyonu yürütüyorsanız, cPanel ile VPS, otomatik Let’s Encrypt sağlama için AutoSSL dahil olmak üzere barındırılan tüm alan adlarında SSL yönetimi için grafiksel bir arayüz sağlar.

Ödeme verilerini işleyen e-ticaret dağıtımları için, HTTPS’yi SSL Sertifikaları‘ndan ticari bir OV veya EV sertifikasıyla eşleştirmek, DV sertifikalarının sunamadığı kurumsal kimlik doğrulamasını sağlar — PCI-DSS uyumluluk denetimleri için geçerlidir.

Altyapınız işlemsel veya pazarlama e-postası içeriyorsa, HTTPS ve SMTP/IMAP TLS’nin ayrı konular olduğunu unutmayın. Web varlığınızı güvence altına almak, posta altyapınızı otomatik olarak güvence altına almaz; bu, E-posta Hosting yığınınızda ayrı TLS yapılandırması gerektirir.

Karar Matrisi ve Teknik Kontrol Listesi

Bir HTTPS geçişini tamamlanmış olarak işaretlemeden önce bu kontrol listesini kullanın:

Sertifika

• [ ] Güvenilir bir CA tarafından verilen sertifika (openssl verify ile doğrulayın)
• [ ] Tam sertifika zinciri yüklendi (yaprak + ara sertifikalar)
• [ ] Sertifika, sunulan tüm alan adlarını/alt alan adlarını kapsıyor (SAN’ları kontrol edin)
• [ ] Son kullanma tarihi izleme yapılandırıldı (30 gün ve 7 günde uyarı)
• [ ] Otomatik yenileme --dry-run ile test edildi

Sunucu Yapılandırması

• [ ] TLS 1.0 ve 1.1 açıkça devre dışı bırakıldı
• [ ] TLS 1.3 etkinleştirildi
• [ ] Zayıf şifre paketleri kaldırıldı (RC4, 3DES, NULL, EXPORT)
• [ ] OCSP zımbalama etkinleştirildi ve doğrulandı
• [ ] ssl_session_tickets off (oturum bileti anahtarı rotasyon sorunlarını önler)

Uygulama Katmanı

• [ ] Tüm dahili bağlantılar göreli URL’ler veya https:// kullanıyor
• [ ] Tarayıcı konsolunda karışık içerik uyarısı yok
• [ ] Content-Security-Policy: upgrade-insecure-requests başlığı ayarlandı
• [ ] Tüm ana bilgisayar adlarında HTTP’den HTTPS’ye 301 yönlendirmeleri

Güvenlik Başlıkları

• [ ] max-age >= 31536000 olan Strict-Transport-Security başlığı
• [ ] includeSubDomains yönergesi eklendi (tüm alt alan adlarının HTTPS’yi desteklediği doğrulandıktan sonra)
• [ ] Alan adı HSTS ön yükleme listesine gönderildi (isteğe bağlı ancak önerilir)

Doğrulama

• [ ] SSL Labs Sunucu Testi A veya A+ döndürüyor
• [ ] openssl s_client doğru sertifika zincirini onaylıyor
• [ ] Yenileme cron/systemd zamanlayıcısının aktif olduğu onaylandı

SSS

HTTPS tüm siber saldırı türlerine karşı koruma sağlar mı?

Hayır. HTTPS, aktarım katmanını şifreler ve sunucunun kimliğini doğrular, ancak uygulama katmanı güvenlik açıklarına (SQL enjeksiyonu, XSS, CSRF), ele geçirilmiş sunucu tarafı koduna veya kimliği doğrulanmış kullanıcının cihazını hedef alan saldırılara karşı koruma sağlamaz. Bir kimlik avı sitesi geçerli bir DV sertifikası alabilir ve kilit simgesi görüntüleyebilir — HTTPS, bağlantının şifreli olduğunu doğrular, sitenin güvenilir olduğunu değil.

HTTPS’yi etkinleştirmenin performans etkisi nedir?

TLS 1.3 ve HTTP/2 ile modern donanımda ek yük ihmal edilebilir düzeydedir. TLS el sıkışması, ilk bağlantıda bir ek gidiş-dönüş ekler (oturum biletleri veya 0-RTT ile yeniden bağlantıda sıfır). 2010’dan bu yana neredeyse tüm sunucu CPU’larında bulunan AES-NI donanım hızlandırma, simetrik şifrelemeyi hat hızında gerçekleştirir. Pratikte, HTTPS siteleri genellikle HTTP eşdeğerlerinden daha hızlı yüklenir; çünkü tarayıcılarda TLS gerektiren HTTP/2 çoklama ve başlık sıkıştırma, el sıkışma maliyetinden daha ağır basar.

Bir SSL/TLS sertifikasının süresi dolduğunda ne olur?

Tarayıcılar, siteye erişimi engelleyen tam sayfalık bir uyarı hemen görüntüler. API istemcileri ve mobil uygulamalar genellikle uyarı yerine sabit bir hatayla başarısız olur. Arama motoru tarayıcıları siteyi dizine eklemeye devam edebilir ancak sertifika hatasını işaretler. Certbot veya ACME aracılığıyla otomatik yenileme, son kullanma tarihini önler; kritik operasyonel gereksinim, yenileme cron görevinin veya systemd zamanlayıcısının çalışmasını ve yenileme uyarılarının yapılandırılmasını sağlamaktır.

TLS ve SSL arasındaki fark nedir?

SSL (Secure Sockets Layer), kritik güvenlik açıkları (POODLE, DROWN) nedeniyle 2.0 ve 3.0 sürümleri artık kullanımdan kaldırılmış ve RFC 7568 tarafından yasaklanmış olan önceki protokoldür. TLS (Transport Layer Security), yalnızca TLS 1.2 (RFC 5246) ve TLS 1.3 (RFC 8446) sürümlerinin güvenli kabul edildiği halefidir. “SSL sertifikası” terimi günlük kullanımda devam etmektedir, ancak herhangi bir modern sunucuda kullanılan gerçek protokol TLS’dir. Bir sunucuyu SSLv3’e izin verecek şekilde yapılandırmak bir uyumluluk özelliği değil, yanlış bir yapılandırmadır.

Sahip olmadığım bir alan adında HTTPS kullanabilir miyim?

Hayır. Sertifika Yetkilileri, verme öncesinde alan adı kontrolünü doğrular. ACME protokolü (Let’s Encrypt tarafından kullanılır), kontrolü kanıtlamak için bilinen bir HTTP yoluna belirli bir dosya yerleştirmenizi (HTTP-01 zorluğu) veya belirli bir DNS TXT kaydı oluşturmanızı (DNS-01 zorluğu) gerektirir. Bu zorluklardan birini geçmeden, kontrol etmediğiniz bir alan adı için hiçbir sertifika verilmez.