Hosting Taşırken SSL Ne Olur? Yeni Sunucuda HTTPS Kesintisini Önleme

Taşıma planınız hazır: dosyalar yeni sunucuda, veritabanı aktarıldı, TTL düşürüldü. Son adım olarak yeni sunucuda certbot çalıştırıyorsunuz ve komut hata veriyor: Timeout during connect (likely firewall problem). Doğrulama sunucusu siteadi.com adresine bağlanmaya çalıştı, DNS onu hâlâ eski sunucunun IP'sine gönderdi, dolayısıyla yeni sunucuda bıraktığınız doğrulama dosyasını bulamadı.

Elinizde iki seçenek var gibi görünür ve ikisi de kötüdür. Ya DNS'i çevirirsiniz ve siteniz sertifikasız açılır — ziyaretçi kırmızı "Bağlantınız gizli değil" ekranıyla karşılaşır. Ya da sertifikayı beklersiniz, ama sertifika DNS çevrilmeden gelmez. Bu, taşıma rehberlerinin neredeyse tamamının atladığı bir tavuk-yumurta problemidir; dosya kopyalama ve DNS anlatılır, sertifikanın hangi anda ve nasıl hazır olacağı anlatılmaz.

İyi haber şu: bu kilidi açan üç ayrı yol var ve üçü de DNS'e hiç dokunmadan çalışıyor. Aşağıda önce sertifikanın gerçekte neye bağlı olduğunu netleştireceğiz, sonra üç yolu tek tek kuracağız, DNS'i çevirmeden HTTPS'i test etmeyi göstereceğiz ve en pahalı tuzağı — HSTS — ayrı bir bölümde ele alacağız.

Sertifika Sunucuya Değil, Alan Adına Bağlıdır#

Bu tek cümle sorunun yarısını çözer. Bir SSL/TLS sertifikası içinde IP adresi ya da sunucu kimliği yazmaz; içinde alan adı (CN ve SAN alanları), geçerlilik tarihleri ve sertifikayı imzalayan otoritenin bilgisi bulunur. Bu yüzden siteadi.com için alınmış geçerli bir sertifika, dosyaları hangi makineye koyarsanız koyun aynen çalışmaya devam eder.

Bunun pratik sonucu şudur: taşımada sertifikayı yeniden almanız şart değildir. Elinizdeki sertifika ve ona ait özel anahtar dosyasını yeni sunucuya kopyalamak, süre dolana kadar yeterlidir. Yeni sertifika almak yalnızca iki durumda gerekir — anahtar dosyası kayıpsa ya da sertifikanın süresi taşımaya yakın doluyorsa.

Kendi sertifikanızın ne kadar ömrü kaldığını taşıma planını yapmadan önce öğrenin:

# Canlı sitedeki sertifikanın geçerlilik tarihlerini ve kapsadığı alan adlarını göster
echo | openssl s_client -connect siteadi.com:443 -servername siteadi.com 2>/dev/null \
  | openssl x509 -noout -dates -subject -issuer -ext subjectAltName

Çıktıdaki notAfter tarihi taşıma gününden 15 günden az sonraysa taşımadan önce yenileyin. Yenileme ve taşımayı aynı güne sıkıştırmak, iki riskli işlemi üst üste bindirir.

Yalnızca .crt Dosyasını Taşımak Neden Yetmez?#

Taşımada en sık yapılan hata, sertifika sağlayıcısından gelen ZIP dosyasını alıp içindeki .crt dosyasını yeni sunucuya yüklemek ve "tamam" demektir. Yeni sunucu bu dosyayla ya hiç başlamaz ya da başlar ama ziyaretçiler yine uyarı alır. Çünkü çalışan bir HTTPS yapılandırması üç parçadan oluşur ve .crt bunlardan sadece biridir.

Özel anahtar en kritik parçadır çünkü hiçbir yerde yedeği yoktur. CSR üretildiği anda sunucuda oluşur ve sertifika otoritesine hiç gönderilmez. Eski sunucuyu silerseniz o anahtar yok olur ve elinizdeki .crt bir işe yaramaz; sertifikayı yeniden düzenletmeniz (reissue) gerekir. Çoğu otoritede bu ücretsizdir ama saatler alabilir.

Ara sertifika zinciri ise sessiz bir tuzaktır: zinciri eksik bıraktığınızda site sizin masaüstü tarayıcınızda sorunsuz açılır, ama bazı mobil cihazlarda ve API entegrasyonlarında hata verir. Bu davranışın tam açıklaması ve düzeltmesi eksik ara sertifika hatası yazısında var. Dosya uzantıları karışıyorsa PEM, DER, PFX ve CRT formatları hangi sunucunun hangisini istediğini anlatıyor.

Anahtar ile sertifikanın gerçekten eşleştiğini taşımadan önce doğrulayın; eşleşmiyorsa web sunucusu başlamaz:

# RSA anahtarlar için: iki çıktı birebir aynı olmalı
openssl x509 -noout -modulus -in siteadi.crt | openssl md5
openssl rsa  -noout -modulus -in siteadi.key | openssl md5

# ECC anahtarlar için modulus yoktur, açık anahtarı karşılaştırın
openssl x509 -in siteadi.crt -pubkey -noout | openssl sha256
openssl pkey -in siteadi.key -pubout        | openssl sha256

Yol 1: DNS-01 Doğrulamasıyla Sertifikayı Baştan Almak#

Bu, tavuk-yumurta problemini kökünden çözen yöntemdir ve elinizde eski sunucunun erişimi olmasa bile çalışır.

Let's Encrypt varsayılan olarak HTTP-01 doğrulaması kullanır: doğrulama sunucusu http://siteadi.com/.well-known/acme-challenge/... adresine bağlanır ve orada bıraktığınız dosyayı okur. Bu yöntem alan adının o anda hangi IP'ye baktığına doğrudan bağımlıdır — taşımanın kilitlendiği yer tam olarak burasıdır.

DNS-01 doğrulaması ise dosya değil, DNS kaydı ister. Doğrulama sunucusu _acme-challenge.siteadi.com adresinde belirli bir TXT kaydı arar. Bu kaydı DNS panelinizden eklersiniz ve alan adının A kaydının hangi sunucuyu gösterdiğinin hiçbir önemi kalmaz. Yani eski sunucu yayındayken, yeni sunucuda geçerli bir sertifika üretebilirsiniz.

DNS sağlayıcınızın bir Certbot eklentisi varsa süreç tamamen otomatiktir:

# Cloudflare örneği: API jetonunu bir dosyaya koyup izinlerini daraltın
sudo mkdir -p /root/.secrets
echo "dns_cloudflare_api_token = JETONUNUZ" | sudo tee /root/.secrets/cloudflare.ini
sudo chmod 600 /root/.secrets/cloudflare.ini

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/cloudflare.ini \
  --dns-cloudflare-propagation-seconds 60 \
  -d siteadi.com -d www.siteadi.com

DNS sağlayıcınızın eklentisi yoksa elle de yapabilirsiniz. Certbot size bir TXT değeri verir, siz DNS panelinden eklersiniz, kayıt yayıldıktan sonra Enter'a basarsınız:

sudo certbot certonly --manual --preferred-challenges dns \
  -d siteadi.com -d www.siteadi.com

Elle yöntemde iki noktaya dikkat edin. Birincisi, TXT kaydının TTL değerini mümkün olan en düşük değere çekin; yüksek TTL ile doğrulama zaman aşımına uğrar. TTL'in ne işe yaradığını bilmiyorsanız TTL nedir yazısı kısa bir özet sunuyor. İkincisi ve daha önemlisi: --manual ile alınan sertifikalar kendiliğinden yenilenmez. Bir doğrulama betiği (--manual-auth-hook) tanımlamadıysanız, 90 gün sonra siteniz sessizce sertifikasız kalır. Taşıma tamamlanıp DNS yeni sunucuya döndükten sonra normal HTTP-01 yöntemine geçmeyi planlayın:

# DNS çevrildikten sonra otomatik yenilenebilir yapıya dönmek için
sudo certbot certonly --nginx -d siteadi.com -d www.siteadi.com --force-renewal
sudo certbot renew --dry-run

Joker (wildcard) sertifika kullanıyorsanız DNS-01 zaten tek seçenektir; ayrıntısı için wildcard SSL nedir yazısına bakın. Certbot'un genel kurulumu ve otomatik yenileme mantığı ise Let's Encrypt ile ücretsiz SSL yazısında.

Yol 2: Let's Encrypt Dosyalarını Eski Sunucudan Kopyalamak#

Eski sunucuya SSH erişiminiz varsa en hızlı yol budur. Let's Encrypt sertifikaları /etc/letsencrypt altında durur ve bu dizinin tamamı taşınabilir. Sertifikanın son kullanma tarihine kadar yeni sunucu sorunsuz HTTPS servis eder; asıl yenilemeyi DNS çevrildikten sonra rahatça yaparsınız.

# ESKİ sunucuda çalıştırın — sembolik bağlar korunmalı, bu yüzden -a şart
sudo rsync -avz /etc/letsencrypt/ root@YENI_IP:/etc/letsencrypt/

# YENİ sunucuda doğrulayın
sudo certbot certificates

certbot certificates çıktısı sertifikaları ve kalan gün sayısını listeliyorsa kopyalama başarılıdır. Ancak burada çok sık gözden kaçan bir ayrıntı var: yenileme yapılandırması da kopyalanır ve eski sunucunun yollarını taşır. /etc/letsencrypt/renewal/siteadi.com.conf dosyasının içinde şuna benzer satırlar bulunur:

[renewalparams]
authenticator = webroot
installer = apache
[[webroot_map]]
siteadi.com = /home/eskikullanici/public_html

Yeni sunucuda o dizin yoksa ya da web sunucusu Apache değil Nginx'se, yenileme 90 gün sonra sessizce başarısız olur. Kimse fark etmez, sonra bir sabah site kapalıdır. Bu yüzden kopyalamadan hemen sonra prova yapın ve yolları düzeltin:

sudo certbot renew --dry-run

Prova hata veriyorsa renewal dosyasındaki authenticator ve webroot_map satırlarını yeni sunucunun gerçek yapılandırmasına göre düzenleyin, sonra provayı tekrarlayın. Yenilemenin sürekli çalıştığından emin olma yöntemleri SSL otomatik yenileme yazısında toplanmış durumda.

Yol 3: Ücretli Sertifikayı Anahtarıyla Birlikte Taşımak#

Ücretli bir DV, OV ya da EV sertifikanız varsa yeniden satın almanız gerekmez; aynı sertifika yeni sunucuda geçerlidir. Yapmanız gereken üç dosyayı eksiksiz toplamaktır.

Eski sunucudan alacaklarınız:

1. Özel anahtar — Linux'ta genelde /etc/ssl/private/ ya da cPanel'de SSL/TLS → Private Keys ekranındadır.
2. Sertifika — cPanel'de SSL/TLS → Certificates, panelsiz sunucuda /etc/ssl/certs/ altında.
3. Ara sertifika (CA bundle) — sağlayıcının gönderdiği ZIP içinde bulunur; kaybettiyseniz sağlayıcının destek sayfasından yeniden indirilebilir.

Üç dosya elinizdeyken yeni sunucuya kurulum, sunucu yazılımına göre değişir. Nginx tek bir birleşik dosya ister ve sıra önemlidir — önce sizin sertifikanız, sonra ara sertifikalar:

cat siteadi.crt ca-bundle.crt > /etc/ssl/certs/siteadi-fullchain.crt

server {
    listen 443 ssl;
    server_name siteadi.com www.siteadi.com;

    ssl_certificate     /etc/ssl/certs/siteadi-fullchain.crt;
    ssl_certificate_key /etc/ssl/private/siteadi.key;
    ssl_protocols       TLSv1.2 TLSv1.3;
}

Apache ise üç dosyayı ayrı ayrı ister:

SSLEngine on
SSLCertificateFile      /etc/ssl/certs/siteadi.crt
SSLCertificateKeyFile   /etc/ssl/private/siteadi.key
SSLCertificateChainFile /etc/ssl/certs/ca-bundle.crt

Yeni sunucunuz Windows/IIS ise üç dosyayı tek bir PFX paketine birleştirmeniz gerekir:

openssl pkcs12 -export -out siteadi.pfx \
  -inkey siteadi.key -in siteadi.crt -certfile ca-bundle.crt

Kuruluma geçmeden anahtar dosyasının izinlerini daraltın: chmod 600 ve sahibi root olsun. Taşıma sırasında anahtarı e-posta ya da mesajlaşma uygulamasıyla göndermeyin; scp veya rsync kullanın.

DNS'e Dokunmadan Yeni Sunucudaki HTTPS'i Test Etmek#

Sertifika kuruldu ama alan adı hâlâ eski sunucuyu gösteriyor. Doğru çalışıp çalışmadığını nasıl anlarsınız? Tarayıcıda IP adresini yazarak değil — o zaman sertifika alan adıyla eşleşmediği için zaten uyarı alırsınız ve hiçbir şey öğrenemezsiniz.

Doğru yöntem, isteği alan adıyla yapıp yalnızca hedef IP'yi elle değiştirmektir. curl bunu tek parametreyle yapar:

# İstek siteadi.com adına yapılır ama yeni sunucunun IP'sine gider
curl -sSI --resolve siteadi.com:443:203.0.113.77 https://siteadi.com/ | head -n 12

Sertifikanın kendisini incelemek isterseniz openssl doğrudan cevap verir. -servername parametresi SNI başlığını gönderir; onsuz sunucu size varsayılan sanal konağın sertifikasını döndürür ve yanlış sonuç alırsınız:

echo | openssl s_client -connect 203.0.113.77:443 -servername siteadi.com 2>/dev/null \
  | openssl x509 -noout -subject -dates -issuer

Tarayıcıda göz kararı bakmak isterseniz kendi bilgisayarınızın hosts dosyasına geçici bir satır ekleyin. Windows'ta C:\Windows\System32\drivers\etc\hosts, macOS ve Linux'ta /etc/hosts:

203.0.113.77    siteadi.com www.siteadi.com

Bu satır yalnızca sizin bilgisayarınızı etkiler, ziyaretçiler etkilenmez. Test bitince satırı silmeyi unutmayın; unutulduğunda DNS geri alınsa bile sizin bilgisayarınız yeni sunucuya gitmeye devam eder ve "bende çalışıyor" tuzağı doğar. Bu test yöntemi taşımanın diğer adımlarında da geçerlidir; genel geçiş planı için site taşırken kesinti olur mu yazısına bakın.

HSTS Açıksa Geri Dönüş Yoktur#

Buraya kadar anlatılan her sorunun bir kaçış kapısı var: sertifika bir an eksik kalırsa ziyaretçi uyarı görür, "Gelişmiş → Yine de devam et" der ve siteye girer. HSTS bu kapıyı kapatır ve taşımadaki en pahalı hatayı buradan çıkarır.

HSTS başlığını bir kez alan tarayıcı, belirtilen süre boyunca o alan adına yalnızca geçerli sertifikayla bağlanmayı kural olarak hafızasına yazar. Sertifika bir an bile geçersiz olursa tarayıcı ziyaretçiye "devam et" seçeneği bile sunmaz — kırmızı ekran ve kapalı kapı. Yani taşıma sırasında sertifikanın beş dakika eksik kalması, HSTS'siz bir sitede kaşınacak bir aksaklıkken HSTS'li bir sitede tam kesintidir.

Önce sitenizde HSTS olup olmadığını öğrenin:

curl -sI https://siteadi.com | grep -i strict-transport

Çıktı boşsa bu bölümü atlayabilirsiniz. Strict-Transport-Security: max-age=31536000; includeSubDomains gibi bir satır görüyorsanız plan yapmanız gerekir:

1. Taşımadan en az iki hafta önce max-age değerini kısa bir süreye düşürün, örneğin max-age=300.
2. Bu düşürmenin etkili olması için ziyaretçilerin siteye HTTPS üzerinden en az bir kez daha uğraması gerekir; tarayıcı yeni başlığı ancak o zaman görür. Bu yüzden düşürmeyi taşımadan hemen önce yapmak işe yaramaz.
3. Taşıma bitip yeni sunucuda sertifika doğrulandıktan sonra max-age değerini eski haline geri çıkarın.

# Taşıma penceresi boyunca geçici olarak
Header always set Strict-Transport-Security "max-age=300"

⚠️ Sitenizi HSTS preload listesine kaydettirdiyseniz durum daha da katıdır: bu liste tarayıcıların içine gömülü gelir ve max-age düşürmek onu etkilemez. Listeden çıkmak hstspreload.org üzerinden talep edilir ve tarayıcı sürüm döngüleri nedeniyle aylar sürer. Preload listesindeki bir siteyi taşıyorsanız tek seçeneğiniz, geçiş anında geçerli bir sertifikanın kesintisiz hazır olmasıdır — yani yukarıdaki üç yoldan biri şart. Mekanizmanın tamamı HSTS nedir yazısında anlatılıyor.

Kendi bilgisayarınızda test yaparken takıldıysanız Chrome'da chrome://net-internals/#hsts ekranından alan adını silebilirsiniz. Bu yalnızca sizin tarayıcınızı temizler; ziyaretçilerin sorununu çözmez.

cPanel'e Taşıyorsanız AutoSSL Ne Zaman Devreye Girer?#

cPanel hesabına taşınıyorsanız iki ayrı mekanizma var ve zamanlamaları farklı.

Hesap aktarım aracıyla (Transfer Tool) taşıma yapıldıysa kurulu sertifikalar hesap arşivinin içinde gelir ve yeni sunucuda otomatik olarak kurulur. Yani DNS çevirdiğinizde HTTPS zaten çalışıyor olur. Kontrol etmek için yeni sunucudaki cPanel'de SSL/TLS Status ekranına bakın; alan adının yanında yeşil kilit ve bir son kullanma tarihi görmelisiniz. Aktarım aracının genel işleyişi cPanel hesap taşıma yazısında.

Elle taşıma yaptıysanız AutoSSL devreye girer, ama bir koşulla: AutoSSL doğrulamayı alan adının o an gerçekten sunucuya çözülmesine dayandırır. DNS hâlâ eski sunucuyu gösterirken AutoSSL çalışır, doğrulamayı yapamaz ve o alan adını "kapsam dışı" olarak işaretler. Dolayısıyla sıralama şudur:

1. DNS'i yeni sunucuya çevirin.
2. Yayılmanın tamamlanmasını bekleyin (düşürülmüş TTL ile genelde 5-30 dakika).
3. cPanel'de SSL/TLS Status → Run AutoSSL düğmesine basın; zamanlanmış çalışmayı beklemeyin.

Bu sıralamanın kaçınılmaz sonucu, DNS çevrildikten sonra AutoSSL tamamlanana kadar geçen kısa bir sertifikasız penceredir. HSTS'siz bir sitede birkaç dakikalık uyarı katlanılabilir; HSTS'li bir sitede kabul edilemez. Bu yüzden HSTS kullanan sitelerde AutoSSL'e güvenmeyin, sertifikayı Yol 1 veya Yol 3 ile önceden hazırlayın. AutoSSL'in kapsam sorunları cPanel AutoSSL rehberinde ayrıntılı ele alınıyor.

Doğru Taşıma Sırası ve Geçiş Sonrası Kontrol#

Tüm bölümleri tek bir akışa indirgeyelim. Sıra, bu yazının özetidir: sertifika hazır → DNS çevir → doğrula.

1. Mevcut sertifikanın son kullanma tarihini ve HSTS durumunu ölçün.
2. HSTS varsa max-age değerini düşürün ve en az iki hafta bekleyin.
3. Yeni sunucuda sertifikayı hazırlayın: DNS-01 ile alın, /etc/letsencrypt dizinini kopyalayın ya da ücretli sertifikayı üç dosyasıyla kurun.
4. curl --resolve ile DNS'e dokunmadan yeni sunucuda HTTPS'i doğrulayın; zincirin eksiksiz olduğunu teyit edin.
5. TTL'i düşürün, dosya ve veritabanı senkronizasyonunu tamamlayın.
6. DNS A kaydını yeni IP'ye çevirin.
7. Eski sunucuyu en az 72 saat açık ve sertifikalı bırakın. Yayılma tamamlanana kadar bir kısım ziyaretçi eski IP'ye düşmeye devam eder; oradaki sertifikanın da geçerli olması gerekir. Bu ayrıntı sık atlanır ve eski sunucudaki sertifikanın süresi tam o pencerede dolduğunda hata raporları anlaşılmaz görünür.
8. Yayılmayı doğrulayın, AutoSSL kullanıyorsanız elle tetikleyin, max-age değerini eski haline getirin.

Geçişten sonra üç kontrolü yapın: curl -sI ile başlıkları okuyun, zincirin tam olduğunu bağımsız bir istemciden doğrulayın ve dilerseniz SSL Labs testiyle yapılandırmanın notunu alın. Ayrıca yenilemenin gerçekten kurulu olduğundan emin olun — taşıma sonrası en sık görülen gecikmeli arıza, üç ay sonra yenilenmeyen bir sertifikadır.

Sıkça Sorulan Sorular#

SSL sertifikam hosting taşırken geçersiz mi olur?#

Hayır. Sertifika alan adına bağlıdır, sunucuya ya da IP adresine değil. Aynı sertifika ve ona ait özel anahtar dosyasını yeni sunucuya kurduğunuzda, son kullanma tarihine kadar aynen çalışır. Geçersiz hale gelmesinin tek yolu süresinin dolması ya da otoriteye iptal ettirmenizdir. Taşıma sırasında hata almanızın sebebi sertifikanın geçersizleşmesi değil, yeni sunucuya hiç kurulmamış olmasıdır.

DNS'i çevirmeden yeni sunucuda sertifika alabilir miyim?#

Evet, DNS-01 doğrulaması tam olarak bunun için var. Bu yöntemde doğrulama sunucusu alan adınıza bağlanmaz; _acme-challenge adlı bir TXT kaydı arar. A kaydınız eski sunucuyu göstermeye devam ederken bu kaydı ekleyip yeni sunucuda geçerli bir sertifika üretebilirsiniz. Sağlayıcınızın Certbot eklentisi varsa süreç tamamen otomatiktir, yoksa TXT kaydını elle ekleyerek de yapabilirsiniz.

Sertifikanın .key dosyasını kaybettim, ne yapmalıyım?#

Özel anahtarın hiçbir yerde yedeği yoktur; sertifika otoritesinde de bulunmaz. Bu durumda sertifikayı yeniden düzenletmeniz (reissue) gerekir. Yeni sunucuda taze bir CSR üretir, sağlayıcının panelinden reissue talebi açar ve alan adı doğrulamasını tekrar yaparsınız. Çoğu otoritede bu işlem ücretsizdir ve sertifikanın kalan süresi aynen devam eder, ancak birkaç saat sürebileceği için taşıma gününe bırakmayın.

Taşıma sonrası "güvenli değil" uyarısı geliyor, sebebi ne olabilir?#

Üç olasılık var. Birincisi sertifika yeni sunucuya hiç kurulmamıştır; sunucu kendi varsayılan ya da kendinden imzalı sertifikasını sunuyordur. İkincisi ara sertifika zinciri eksiktir; bu durumda masaüstünde çalışır ama mobilde hata verir. Üçüncüsü alan adı uyuşmazlığıdır: sertifika yalnızca siteadi.com için alınmışken ziyaretçi www.siteadi.com adresine giriyordur. Üçünü de sunucuya bağlanıp sertifika ayrıntılarını okuyarak birbirinden ayırabilirsiniz.

Eski sunucuyu taşıdıktan hemen sonra kapatabilir miyim?#

Kapatmayın. DNS değişikliği anında herkese ulaşmaz; TTL süresince bir kısım ziyaretçi ve resolver eski IP'ye gitmeye devam eder. Eski sunucu kapalıysa o ziyaretçiler siteye hiç erişemez; açık ama sertifikası dolmuşsa güvenlik uyarısı alır. En az 72 saat, mümkünse bir hafta boyunca eski sunucuyu çalışır ve sertifikalı halde bırakın. Bu süre aynı zamanda geri dönüş güvenliğiniz olur.

HSTS kullanan bir siteyi taşımanın riski tam olarak nedir?#

HSTS açıkken tarayıcı, sertifika geçersiz olduğunda ziyaretçiye "yine de devam et" seçeneğini sunmaz; erişim tamamen kapanır. Normal bir sitede kısa bir sertifika boşluğu atlatılabilir bir uyarıyken, HSTS'li sitede tam kesintidir. Bu yüzden taşımadan iki hafta önce max-age değerini düşürmeli, sertifikayı geçişten önce hazır etmeli ve preload listesindeyseniz kesintisiz sertifikayı zorunlu şart olarak planlamalısınız.