WordPress HTTPS: karışık içerik ve yönlendirme sorunları

WordPress'te HTTPS sorunlarının çoğu eksik sertifikadan değil, yarım kalmış bir taşımadan çıkar. Sertifika kurulu ve ana sayfada asma kilit görünüyor. Ama blog yazılarında uyarı simgesi var, içerikte hâlâ eski http:// bağlantıları duruyor ve adres çubuğuna example.com yazan ziyaretçi gerçek sayfaya varmadan önce iki üç yönlendirmeden geçiyor. Bu rehber, bu durumu güvenli bir sırayla düzeltir.

WordPress HTTPS: sertifika yalnızca ilk adımdır

Önce ölçün. Aşağıdaki iki komut, ziyaretçinin tarayıcısının hangi adımlardan geçtiğini gösterir:

curl -sI http://example.com
curl -sIL http://example.com | grep -iE '^(HTTP|location)'

İlk komut, ilk yanıtın durum kodunu ve Location başlığını verir. İkincisi tüm yönlendirmeleri takip eder. Son 200 yanıtından önce birden fazla 301 görüyorsanız, elinizde bir yönlendirme zinciri var demektir. Ardından siteyi tarayıcıda açın, F12'ye basın ve Konsol'a bakın. Karışık içerik uyarıları orada listelenir.

HTTPS'in ne yaptığını da net tutmak gerekir. Tarayıcı ile sunucu arasındaki trafiği şifreler ve yolda değiştirilmesini engeller. Bu, GDPR (AB Genel Veri Koruma Tüzüğü) Madde 32(1)(a) kapsamında sayılan önlemlerden biridir: giriş parolaları, iletişim formları ve ödeme verileri için şifreleme. Ancak sitenin kendisinin güvenli olup olmadığı hakkında hiçbir şey söylemez. Geçerli sertifikalı bir site yine de açığı olan bir eklenti çalıştırıyor, kötü amaçlı yazılım barındırıyor ya da password123 ile korunan bir yönetici hesabına sahip olabilir. Şifrelemenin diğer güvenlik önlemleriyle ilişkisi GDPR Madde 32 ve WordPress yazısında anlatılıyor.

Ücretsiz sertifikayı hosting'inizden veya ACME ile alın

AB'deki hosting kontrol panellerinin çoğu, tek bir anahtarın arkasında ücretsiz bir Let's Encrypt sertifikası sunar. Genellikle "SSL/TLS" ya da "Güvenlik" başlığı altındadır. Etkinleştirin ve sertifikanın hem example.com hem de www.example.com adını kapsadığından emin olun. Yalnızca tek ada verilmiş sertifika, diğer adda tarayıcı hatalarına yol açar; o ad yalnızca yönlendirme yapsa bile.

Kendi sunucunuzda bir ACME istemcisi kullanın. Yaygın tercih Certbot'tur ve otomatik yenilemeyi de kurar:

sudo certbot --nginx -d example.com -d www.example.com
sudo certbot renew --dry-run

Apache kullanıyorsanız --nginx yerine --apache yazın. Deneme çalıştırması, yenilemenin gerçekten işleyeceğini doğrular. Şimdi başarısız oluyorsa, bir sonraki gerçek yenilemede de başarısız olur.

Asma kilidi görmek için alan adı doğrulamalı (DV) sertifikaya para ödemeniz gerekmez. Ücretli sertifikalar destek sözleşmesi ya da belirli doğrulama ihtiyaçları için anlamlıdır. Şifreleme açısından ücretsiz sertifika da aynı derecede güçlüdür.

Yedek alın, sonra WordPress Adresi ve Site Adresini değiştirin

Herhangi bir şeyi değiştirmeden önce veritabanı yedeği alın. Sonraki adımlar binlerce satırı yeniden yazar ve yedek, geri alma düğmenizdir. Güvenebileceğiniz yedeklerin nasıl alınacağını Gerçekten geri yüklenen WordPress yedekleri yazısında bulabilirsiniz. WP-CLI ile bu tek satırdır:

wp db export before-https.sql

Ardından Ayarlar > Genel'e gidin ve hem WordPress Adresi (URL) hem de Site Adresi (URL) alanını http:// yerine https:// olacak şekilde değiştirin. WordPress bir alt dizine kuruluysa yolu koruyun. Aynı işlemi komut satırından da yapabilirsiniz:

wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'

İki alan gri ve düzenlenemezse, WP_HOME ve WP_SITEURL değerleri wp-config.php içinde tanımlıdır. Değerleri orada değiştirin. Panel ayarları bunları geçersiz kılamaz.

Oturumunuz kapandıysa ve tekrar giremiyorsanız, örneğin sertifika henüz çalışmadığı için, wp-config.php içinde WP_HOME ve WP_SITEURL değerlerini geçici olarak eski http:// adresiyle tanımlayın (zaten tanımlıysa geri çevirin) ya da iki wp option update komutunu eski değerlerle çalıştırın. Önce sertifikayı düzeltin, sonra yeniden deneyin.

Eski http:// adreslerini wp search-replace ile güvenle değiştirin

Yazılarınızda, menülerinizde, widget'larınızda ve tema seçeneklerinizde hâlâ yüzlerce http://example.com bağlantısı vardır. Bunları ham bir SQL REPLACE ile düzeltmeyin. WordPress ve pek çok eklenti ayarları serileştirilmiş PHP olarak saklar; bu biçim her dizenin uzunluğunu kaydeder, örneğin s:22:"http://example.com/img". https'teki "s" harfi dizeyi bir karakter uzatır. Kayıtlı uzunluk artık tutmaz, PHP değeri okuyamaz ve widget'lar, sayfa oluşturucu düzenleri ya da tema ayarları sessizce kaybolur.

[wp search-replace](https://developer.wordpress.org/cli/commands/search-replace/) veriyi serileştirmeden çıkarır, metni değiştirir ve doğru uzunluklarla yeniden serileştirir. Her zaman önce deneme çalıştırması yapın:

wp search-replace 'http://example.com' 'https://example.com' --all-tables --skip-columns=guid --dry-run

Tablo başına sayılara bakın. Makul görünüyorlarsa aynı komutu --dry-run olmadan çalıştırın. Birkaç not:

• --skip-columns=guid, yazı GUID'lerine dokunmaz. Bunlar bağlantı değil, tanımlayıcıdır ve geleneksel olarak değiştirilmezler.
• --all-tables, veritabanındaki her tabloya dokunur. Veritabanını başka bir site veya uygulamayla paylaşıyorsanız bunun yerine --all-tables-with-prefix kullanın.
• Kanonik ana bilgisayarınız www'siz ise http://www.example.com adresinden https://example.com adresine ikinci bir değişim çalıştırın.
• Bazı sayfa oluşturucular JSON'u kaçışlı eğik çizgilerle (http:\/\/example.com) saklar; düz bir arama bunlarla eşleşmez. Bu biçim için de bir deneme çalıştırması yapın ya da sayfa oluşturucunun kendi URL değiştirme aracını kullanın.

Sonrasında tüm önbellekleri temizleyin: wp cache flush, sayfa önbelleği eklentiniz, sunucu önbelleği ve CDN. Sayfa oluşturucunuz seçenek sunuyorsa CSS dosyalarını yeniden üretin. SSH erişiminiz yoksa Better Search Replace gibi, serileştirilmiş veriyi işleyen bir arama-değiştirme eklentisi aynı işi görür. İşiniz bitince silin.

Kanonik HTTPS ana bilgisayarına tek 301 yönlendirmesi

Tek bir kanonik adres seçin, www'li ya da www'siz, ve ona sadık kalın. Diğer her varyant tek bir 301 yönlendirmesiyle doğrudan bu adrese gitmelidir. http → https → www → son gibi bir zincir, her ilk ziyareti yavaşlatır, arama motoru taramalarını boşa harcar ve hataların izini sürmeyi zorlaştırır.

Apache için .htaccess içinde # BEGIN WordPress bloğunun üstüne:

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [L,R=301]

nginx için:

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

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name www.example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    return 301 https://example.com$request_uri;
}

Yönlendirmeyi tek bir yerde tutun. Bir eklenti, .htaccess ve CDN'in hepsi yönlendirme yaparsa zincirler ya da döngüler oluşur. Sunucuyu veya CDN'i seçin, diğerlerini kaldırın.

CDN veya ters proxy arkasında yönlendirme döngüleri

Klasik döngü, Cloudflare'in "Flexible" SSL modunda yaşanır. Tarayıcı Cloudflare ile HTTPS üzerinden konuşur, ama Cloudflare sunucunuzla düz HTTP üzerinden konuşur. Sunucu HTTP görür, HTTPS'e yönlendirir ve döngü tekrarlanır. Sunucuya bir sertifika kurun ve Cloudflare SSL/TLS ayarlarında modu Full (strict) yapın. Böylece sunucuya giden trafik şifrelenir ve sunucunun sertifikası doğrulanır.

Diğer proxy'ler ve yük dengeleyiciler özgün şemayı X-Forwarded-Proto başlığıyla iletir. WordPress bu başlığı varsayılan olarak okumaz. wp-config.php içinde "stop editing" satırının üstüne şunu ekleyin:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {
    $_SERVER['HTTPS'] = 'on';
}

FORCE_SSL_ADMIN ve giriş sayfası

define( 'FORCE_SSL_ADMIN', true );

Bu ayar, WordPress'in giriş sayfasını ve paneli yalnızca HTTPS üzerinden sunmasını sağlar. Biri eski bir http:// yer imini açsa bile parolalar ve yönetici çerezleri hiçbir zaman şifresiz gönderilmez. Bu bir emniyet ağıdır, yönlendirme çözümünüz değil. Herkese açık sayfalar için hiçbir şey yapmaz. Diğer wp-config.php ayarları wp-config.php sertleştirme: kontrol edilecek 10 ayar yazısında ele alınıyor.

Kalan karışık içeriği geliştirici araçlarında bulun

Karışık içerik, bir HTTPS sayfanın bir kaynağı HTTP üzerinden yüklemesidir. Tarayıcılar güvensiz betikleri ve çerçeveleri engeller, görseller için uyarır veya yükseltir; asma kilidin kaybolmasının nedeni budur. Etkilenen sayfada DevTools'u açın. Konsol, her güvensiz isteği URL'siyle birlikte listeler. Chromium tabanlı tarayıcılarda Network sekmesinin filtresine scheme:http yazarak hepsini tek seferde görebilirsiniz.

Temiz bir search-replace'ten sonra kalan nedenler genellikle veritabanının dışındadır. Tipik kaynaklar: tema dosyalarındaki sabit kodlanmış URL'ler, Özel HTML widget'ları, özel CSS (background: url(http://...)), sayfa oluşturucu CSS dosyaları ve eski üçüncü taraf gömmeleri. Temada bulmak için:

grep -rn "http://" wp-content/themes/your-theme/
wp db search 'http://example.com'

Sorunu kaynağında düzeltin. Her sayfa yüklenişinde URL'leri yeniden yazan eklentiler sorunu çözmez, yalnızca gizler; devre dışı bırakıldıkları anda da etkisiz kalırlar. CSP yönergesi upgrade-insecure-requests, temizlik sürerken geçici köprü işlevi görebilir. Bu yönerge WordPress güvenlik başlıkları yazısında açıklanıyor.

Yalnızca ana sayfaya bakmayın. Ödeme sayfasını, iletişim formunu, giriş sayfasını, bir blog yazısını, bir kategori arşivini ve farklı bir şablonla yapılmış her açılış sayfasını test edin.

Sertifika süresini izleyin, ardından HSTS'i açın

Otomatik yenileme, kimse fark etmeden başarısız olabilir. Yaygın nedenler: bir DNS değişikliği, yeni bir CDN'e geçiş ya da /.well-known/acme-challenge/ yolunu engelleyen bir güvenlik duvarı veya yönlendirme kuralı. Sertifikayı kontrol eden ve süresi dolmadan en az iki hafta önce sizi uyaran harici bir izleme kurun. Birçok uptime hizmeti bu kontrolü içerir. Bitiş tarihini kendiniz okumak için:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -enddate

HSTS (RFC 6797) en sona kalır. Tarayıcılara yalnızca HTTPS kullanmalarını söyler; bu yüzden bozuk bir sertifika ziyaretçiler için kesin bir hataya dönüşür. includeSubDomains ile unutulmuş, yalnızca HTTP sunan her alt alan adı da aynı sonucu doğurur. Yalnızca tüm alt alan adları ve yönlendirmeler sorunsuz çalışıyorsa etkinleştirin ve kısa bir max-age ile başlayın. Değerler ve preload uyarısı WordPress güvenlik başlıkları yazısında anlatılıyor.

secaudit.eu denetim eklentisi, dosya bütünlüğü ve güncel olmayan eklentilerin yanında sertleştirme ve yapılandırma ayarlarını da kontrol eder. Taşımadan sonra sitenin durumuna dair, belgelerinizde saklayabileceğiniz bir kayıt elde edersiniz. → secaudit.eu

Sıradaki adım: curl -sIL adım kontrolünü dört varyantın hepsinde çalıştırın (http, http://www, https://www, https). Sonra en önemli beş sayfanızı DevTools Konsolu açıkken ziyaret edin. Varyant başına en fazla bir 301, kanonik HTTPS URL'sinde doğrudan 200 ve hiç karışık içerik mesajı olmaması, taşımanın tamamlandığı anlamına gelir.

Sık sorulan sorular

Ücretsiz sertifika bir online mağaza için yeterli mi?

Evet. Ücretsiz, alan adı doğrulamalı bir sertifika, ücretli olanla aynı güçte şifreleme sağlar. Mağazanın güvenliği sertifikanın fiyatına değil, eklentilerine, güncellemelerine, girişlerine ve ödeme altyapısına bağlıdır.

Asma kilit neden yalnızca bazı sayfalarda kayboluyor?

O sayfalar en az bir kaynağı HTTP üzerinden yüklüyordur. Bu genellikle diğer sayfaların kullanmadığı bir widget'tan, şablondan ya da sayfa oluşturucu bölümünden gelen bir görsel, betik veya gömmedir. O sayfadaki DevTools Konsolu tam URL'yi gösterir.

HTTPS sitemi GDPR'a uygun yapar mı?

Hayır. HTTPS, Madde 32 kapsamında tek bir teknik önlemdir: aktarım sırasında şifreleme. GDPR ayrıca sistemlerin kendisini korumanızı, olaylardan sonra veriyi geri yükleyebilmenizi, önlemlerinizi düzenli test etmenizi ve tüm bunları belgelemenizi bekler.

Bu makale genel bilgilendirme amaçlıdır, hukuki danışmanlık değildir.