SSL Sürüm Uyuşmazlığı: ERR_SSL_VERSION_OR_CIPHER_MISMATCH Çözümü

SSL sürüm uyuşmazlığı hatası (ERR_SSL_VERSION_OR_CIPHER_MISMATCH) nedir?

SSL sürüm uyuşmazlığı hatası, tarayıcınızla sunucunun HTTPS bağlantısı için ortak bir TLS sürümü ya da şifre paketi bulamadığını bildiren Chrome ve Edge hatasıdır. Kodu ERR_SSL_VERSION_OR_CIPHER_MISMATCH olarak görünür. Nedeni sunucu ayarı, kapatılmış eski protokoller ya da sertifikanın alan adını kapsamaması olabilir. Sayfa hiç açılmaz.

Güvenli bağlantı kurulmadan önce iki taraf el sıkışır. Tarayıcı desteklediği TLS sürümlerini ve şifre paketlerini listeler, sunucu da bunlardan birini seçer. Listelerde ortak bir madde yoksa bağlantı kurulmaz. Yani ortada bozuk bir sayfa değil, hiç başlamamış bir bağlantı vardır.

Sertifikanın ne işe yaradığını merak ediyorsanız SSL sertifikası nedir yazımıza bakabilirsiniz. Bu yazıda ise hatanın hangi katmandan geldiğini bulmaya ve gerekirse sunucu ayarında düzeltmeye odaklanıyoruz. Karışık içerik uyarısı ile bağlantı sıfırlanması hataları farklı konulardır, bu yüzden onlara burada girmiyoruz.

Hatayı kim çözmeli: ziyaretçi mi, site sahibi mi, sunucu yöneticisi mi?

Çoğu durumda sorumlu site tarafıdır, çünkü hata birçok ziyaretçide aynı anda görünür. Yine de eski bir cihaz ya da araya giren bir güvenlik yazılımı sorunu yalnızca tek kişide çıkarabilir. Aşağıdaki tablo, her rolün elindeki yetkiyi ve ilk bakacağı yeri özetler.

Küçük işletmelerde bu roller çoğu zaman aynı kişide toplanır. Buna rağmen sırayı korumanız gerekir; aksi halde yanlış katmanda vakit kaybedersiniz. Önce hatanın herkeste mi yoksa yalnızca sizde mi çıktığını anlayın, ardından katmanları dıştan içe doğru kontrol edin.

TLS sürümü ve şifre paketi nedir, tarayıcı ile sunucu nasıl anlaşır?

TLS, tarayıcı ile sunucu arasındaki trafiği şifreleyen protokoldür. Örneğin sürüm numarası protokolün kuşağını gösterir. Şifre paketi ise o bağlantıda kullanılacak anahtar değişimi, kimlik doğrulama ve şifreleme algoritmalarının birleşimidir. Her ikisinde de iki tarafın ortak bir seçeneği olması gerekir.

El sıkışmada tarayıcı ClientHello mesajıyla desteklediklerini bildirir. Ardından sunucu bunlardan birini seçerek yanıt verir. Ortak seçenek çıkmazsa sunucu bir uyarı mesajıyla bağlantıyı kapatır. Güncel sürüm olan TLS 1.3, RFC 8446 ile tanımlanmıştır. Üstelik şifre paketi listesini eskisine göre çok daha kısa tutar.

Bu nedenle SSL sürüm uyuşmazlığı iki yönden doğabilir. Sunucu çok kısıtlı bir liste sunuyorsa modern tarayıcı bile eşleşme bulamaz. Öte yandan tarayıcı çok eskiyse sunucunun güncel listesi ona uymaz. Bir de üçüncü durum vardır: sunucu alan adı için doğru sertifikayı sunamaz ve tarayıcı bunu aynı hata ekranıyla gösterir.

SSL sürüm uyuşmazlığı hangi nedenlerle ortaya çıkar?

Nedenler birkaç ana gruba ayrılır. Aşağıdaki liste, karşılaşılan senaryoları teşhiste bakmanız gereken sıraya göre dizer. Bu sıra bir istatistik değildir, yalnızca pratik bir yol haritasıdır.

• Sertifika, ziyaret edilen alan adını ya da alt alan adını kapsamıyor.
• CDN üzerinde alan adı için sertifika henüz etkinleşmemiş ya da kayıt proxy dışında kalmış.
• Sunucu yalnızca eski TLS sürümlerini ya da çok dar bir şifre listesini sunuyor.
• Sunucu ya da CDN eski TLS sürümlerini kapatmış, ziyaretçinin cihazı ise yeni sürümleri bilmiyor.
• Sertifikanın süresi dolmuş ya da yanlış sertifika dosyası yüklenmiş.
• Antivirüs veya kurumsal proxy araya girip eski bir TLS sürümüyle bağlanıyor.

İlk iki madde, yeni bir alan adı ya da alt alan adı açtıktan hemen sonra özellikle sık görülür. Eski sürümlere dayalı maddeler ise genellikle güvenlik sertleştirmesinden sonra ortaya çıkar. İki durumda da önce neyin değiştiğini hatırlamak teşhisi hızlandırır.

Tarayıcılar bu hatayı nasıl gösterir?

Hatanın adı tarayıcıya göre değişir, ancak anlamı aynıdır. Chrome ve Edge gibi Chromium tabanlı tarayıcılar "Bu site güvenli bir bağlantı sağlayamıyor" benzeri bir mesajın altında ERR_SSL_VERSION_OR_CIPHER_MISMATCH kodunu yazar. Örneğin Firefox aynı durumu kendi hata koduyla bildirir. Metinler sürümle değişebilir, bu yüzden kelimelere değil davranışa bakın.

• Sayfa tamamen boş kalır ve içerik hiç görünmez.
• Hata her yenilemede aynı biçimde geri gelir.
• Ziyaret "Yine de devam et" gibi bir seçenekle geçilemez, çünkü bağlantı hiç kurulmamıştır.
• Başka bir sitede HTTPS sorunsuz çalışır, yani sorun ağınızda değil hedef sitededir.

Son madde teşhis için değerlidir. Böylece internet bağlantınızı suçlamadan doğrudan ilgili siteye odaklanırsınız. Üstelik hata mesajındaki kod, destek talebi açarken sağlayıcınıza verebileceğiniz en net bilgidir.

Hangi neden hangi çözümle eşleşir?

Teşhis ilerledikçe belirtiyi çözümle eşleştirmek kolaylaşır. Bu nedenle tabloyu bir özet olarak kullanın, ayrıntılar sonraki bölümlerde geliyor. Her satırda önce neye baktığınızı, sonra neyi değiştireceğinizi görürsünüz.

Tablodaki üçüncü ve dördüncü satırı karıştırmayın. Biri sunucunun yeni sürümleri sunamamasıdır, diğeri ise istemcinin yeni sürümleri bilmemesidir. Dolayısıyla çözümleri birbirinin tersidir.

Teşhise hangi sırayla başlamalısınız?

Doğru sıra, en ucuz testten en pahalıya doğru ilerler. Önce hatanın kapsamını daraltın, sonra sertifikaya ve en son sunucu ayarına bakın. Böylece gereksiz yapılandırma değişikliğiyle yeni sorunlar üretmezsiniz.

1. Siteyi başka bir tarayıcıda, başka bir cihazda ve mobil veride açın.
2. Hata herkeste çıkıyorsa sertifika kapsamını ve süresini kontrol edin.
3. Alan adının DNS kayıtlarını ve CDN kullanıp kullanmadığını doğrulayın.
4. Sunucunun hangi TLS sürümlerini kabul ettiğini komut satırından test edin.
5. Nginx ya da Apache yapılandırmasındaki protokol ve şifre satırlarını inceleyin.
6. Değişikliği uygulayıp test edin, ardından sonucu birden fazla istemciyle doğrulayın.

İlk adımlar için araçlarımızdan yararlanabilirsiniz. SSL sorgulama aracı sertifikanın geçerlilik durumunu gösterir. DNS sorgulama aracı ise alan adının hangi adrese çözüldüğünü, yani CDN'e mi yoksa doğrudan sunucuya mı gittiğini anlamanıza yardım eder.

TLS 1.0 ve 1.1 neden kapatıldı?

İnternet standartlarını yayımlayan IETF, TLS 1.0 ve 1.1'i Mart 2021'de resmen kullanımdan kaldırdı. RFC 8996 bu iki sürümün kullanılmaması gerektiğini yazar. Gerekçe, güncel kriptografik algoritmaları desteklememeleridir. Aşağıdaki tablo sürümlerin güncel durumunu özetler.

Büyük tarayıcılar da bu kararı izledi. Önce uyarı gösterdiler, sonra eski sürüm desteğini kaldırdılar. Bugün yalnızca TLS 1.0 ya da 1.1 sunan bir sunucu, modern tarayıcılarda doğrudan bu hatayı verir. Kısacası sorun tarayıcıda değil, sunucunun yaşındadır.

Dolayısıyla hatayı görünce "eski sürümü geri açayım" diye düşünmeyin. Bu, güvenliği düşürür ve standartların tersine gider. Doğru yol, sunucuyu TLS 1.2 ve 1.3'ü sunacak şekilde güncellemektir.

Sunucunun OpenSSL sürümü eskiyse ne olur?

TLS desteği sunucu yazılımının kendisine değil, altındaki şifreleme kütüphanesine de bağlıdır. Nginx belgesi, TLSv1.3 parametresinin yalnızca OpenSSL 1.1.1 ya da daha yeni bir sürümle çalıştığını yazar. Apache belgesi de aynı koşulu TLSv1.3 için belirtir. Yani eski bir işletim sisteminde yapılandırma doğru olsa bile TLS 1.3 sunulamaz.

Bu durumun iki sonucu vardır, yani her şey tek satırla çözülmez. Birincisi, yalnızca yapılandırma satırını değiştirmek yetmeyebilir. İkincisi, çok eski bir sunucu TLS 1.2'yi bile sunamıyorsa asıl çözüm işletim sistemini ve paketleri güncellemektir. Bu işi paketleri bilen bir sistem yöneticisiyle yapmanız doğru olur.

Güncel kararlı sürümleri kullanmak burada en sağlam yoldur. Sürüm numarası yazmıyoruz, çünkü bu bilgi hızla eskir. Bunun yerine sunucunuzun işletim sistemi ve paket kaynağı için üreticinin resmi destek durumuna bakın ve destek süresi dolmuş bir sürüm kullanıyorsanız hosting sağlayıcınızla yükseltme planı yapın.

Sunucunuzun hangi TLS sürümlerini kabul ettiğini nasıl test edersiniz?

OpenSSL komut satırı aracı, belirli bir sürümle bağlanmayı zorlayabilir. Aşağıdaki örneklerde example.com yerine kendi alan adınızı yazmanız gerekir. Çıktıda bağlantı kurulursa o sürüm açıktır, hata verirse kapalıdır.

openssl s_client -connect example.com:443 -servername example.com -tls1_2
openssl s_client -connect example.com:443 -servername example.com -tls1_3

Bu komutlardan en az biri başarılı olmalıdır, çünkü sunucu en az bir modern sürümü sunmak zorundadır. İkisi de hata veriyorsa sunucu modern sürümleri sunmuyor demektir. Eski sürümleri denemek için -tls1_1 bayrağını kullanabilirsiniz. Ancak bazı OpenSSL derlemeleri bu sürümü zaten devre dışı bıraktığı için komut, sunucudan bağımsız hata verebilir.

Curl ile de benzer bir test yapabilirsiniz:

curl -vI --tlsv1.2 --tls-max 1.2 https://example.com

Böylece bu komut yalnızca TLS 1.2 ile bağlanmayı dener. Ayrıca ayrıntılı çıktıda anlaşılan sürümü ve şifre paketini görürsünüz. Bağlantı kuruluyorsa sorun büyük olasılıkla sunucu protokollerinde değil, sertifika kapsamında ya da CDN ayarındadır.

Nginx'te ssl_protocols ve ssl_ciphers nasıl ayarlanır?

Nginx belgelerine göre ssl_protocols direktifinin varsayılan değeri TLSv1.2 TLSv1.3 olarak yazılıdır. TLSv1.3 varsayılanı 1.23.4 sürümünden itibaren geçerlidir. Çok eski bir kurulumda ya da elle yazılmış eski bir satırda bu liste farklı olabilir.

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

    ssl_protocols TLSv1.2 TLSv1.3;
}

Şifre listesini (ssl_ciphers) çoğu zaman elle yazmanız gerekmez, çünkü Nginx'in varsayılanı da iş görür. Özel bir liste gerekiyorsa Mozilla'nın SSL yapılandırma üreticisi sunucu yazılımınıza göre güncel bir örnek hazırlar. Değişiklikten sonra nginx -t ile sözdizimini sınayın, ardından yapılandırmayı yeniden yükleyin.

Next.js ya da Node.js uygulamasını Nginx arkasında yayınlıyorsanız Next.js VPS deploy rehberimizdeki sertifika adımlarına da göz atın.

Apache'de SSLProtocol ve SSLCipherSuite nasıl ayarlanır?

Apache 2.4 belgelerine göre SSLProtocol için varsayılan değer all -SSLv3 biçimindedir. Bu ifade, SSLv3 dışındaki tüm sürümleri açık bırakır. Dolayısıyla eski bir kurulumda TLS 1.0 ve 1.1 hâlâ açık olabilir. Sertleştirmek için bunları açıkça kapatabilirsiniz.

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

TLS 1.3 şifre paketleri için ayrı bir sözdizimi vardır. Apache belgesi, OpenSSL 1.1.1 ve sonrasında SSLCipherSuite satırında TLSv1.3 belirtecinin kullanılabileceğini yazar. Yine de varsayılan listeyi yeterli bulup dokunmamak çoğu site için en güvenli seçimdir.

Değişikliği uygulamadan önce apachectl configtest komutuyla sözdizimini denetleyin. Ayrıca bu ayarı paylaşımlı hostingde değil, kendi VPS'inizde değiştirebilirsiniz. Alternatif sunucu yazılımlarını merak ediyorsanız OpenLiteSpeed ile Nginx karşılaştırmasına göz atın.

Sertifika alan adınızı kapsamıyor olabilir mi?

Evet, bu SSL sürüm uyuşmazlığı hatasının en sık nedenlerinden biridir. Çünkü sertifika yalnızca içindeki alan adlarını kapsar. Örneğin example.com için alınmış bir sertifika, www.example.com ya da blog.example.com adresini otomatik olarak kapsamaz. Tarayıcı ise bu uyumsuzluğu hata ekranıyla gösterir.

Sertifikanın hangi adları kapsadığını şu komutla görebilirsiniz. Komut, OpenSSL 1.1.1 ve sonrasında çalışan -ext seçeneğini kullanır:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -dates -ext subjectAltName

Çıktıdaki subjectAltName satırı, sertifikanın geçerli olduğu tüm adları listeler. Yani aradığınız adres orada yoksa sertifikayı yenileyin ve eksik adı ekleyin. Joker karakterli sertifika tek seviyeyi kapsar; ayrıntılar için Wildcard SSL yazımıza bakın.

SNI nedir ve yanlış sertifikanın gelmesine neden olur mu?

SNI (Server Name Indication), tarayıcının bağlanmak istediği alan adını el sıkışma sırasında sunucuya söylemesini sağlayan TLS uzantısıdır. Aynı IP adresinde birden fazla site barındıran sunucu, doğru sertifikayı bu bilgiye bakarak seçer. Yani SNI, tek IP üzerindeki çok siteli düzenin temelidir.

SNI doğru çalışmazsa sunucu varsayılan sertifikayı gönderebilir. Bu sertifika başka bir alan adına aittir ve tarayıcı bağlantıyı reddeder. Yeni bir siteyi sunucuya ekledikten sonra yalnızca o sitede hata çıkıyorsa, sanal sunucu bloğunun ve sertifika yolunun doğru olup olmadığını kontrol edin.

Test ederken OpenSSL komutundaki -servername bayrağını unutmayın. Bayrak olmadan komut SNI göndermez ve sunucunun varsayılan sertifikasını görürsünüz. Böylece yanlış bir sonuca bakıp doğru çalışan siteyi bozuk sanabilirsiniz.

Cloudflare veya başka bir CDN kullanıyorsanız ne kontrol etmelisiniz?

Cloudflare belgelerine göre bu hata, alan adınız ya da alt alan adınız bir sertifikayla kapsanmadığında çıkar. Belge dört ana neden sayar. Üstelik bunların hepsi CDN panelinden çözülebilir, sunucuya dokunmanız gerekmez.

• Universal SSL sertifikasının etkinleşmesi, alan adı eklendikten sonra 15 dakika ile 24 saat arasında sürebilir.
• Universal ve Advanced sertifikalar yalnızca proxy üzerinden geçen kayıtları kapsar, "DNS only" kayıtlar kapsanmaz.
• Özel (Custom) sertifika kullanıyorsanız sertifikanın süresi dolmuş olabilir.
• Universal SSL yalnızca ana alan adını ve tek seviye alt alan adını kapsar; dev.docs.example.com gibi adlar varsayılan olarak dışarıda kalır.

Çözümler sırasıyla şunlardır: panelde durumun Active olmasını beklemek, kaydı Proxied yapmak, yeni sertifika yüklemek ve çok seviyeli adlar için Total TLS ya da Advanced sertifika kullanmak. Ayrıntılar için Cloudflare'in hata sayfasına bakın.

Bir de Minimum TLS Version ayarı vardır. Cloudflare bu ayarı, seçilen sürümü ya da daha yenisini desteklemeyen ziyaretçilerin bağlantısını reddeden bir filtre olarak tanımlar. Dolayısıyla ayarı gereksiz yükseltirseniz eski ama meşru istemciler hata görebilir. Ayrıntı için minimum TLS sürümü belgesine göz atın.

Şifre listesi sertifika türüyle çelişiyor olabilir mi?

Evet, özellikle elle yazılmış şifre listelerinde bu olur. Şifre paketlerinin adı, kimlik doğrulamada hangi sertifika türünü beklediklerini de içerir. Sunucudaki sertifika ECDSA türündeyse ve listede yalnızca RSA sertifikası bekleyen paketler varsa, ortak bir seçenek kalmaz.

Bu durum genellikle şu senaryoda doğar: biri internetten eski bir şifre listesi kopyalar ve yapılandırmaya yapıştırır. Daha sonra sertifikayı yeniler ya da türünü değiştirir. Böylece liste artık yeni sertifikayla örtüşmez. Dolayısıyla SSL sürüm uyuşmazlığı, sertifika eskisi gibi çalışırken bir anda başlar.

Çözüm basittir: elle yazdığınız şifre listesini kaldırıp sunucu yazılımının varsayılanına ya da güncel bir hazır örneğe dönün. Sertifika türünden emin değilseniz sertifikanızı sağlayan firmaya sorun. Ayrıca liste ile sertifikayı birlikte düşünmeden ikisini ayrı ayrı değiştirmeyin.

Eski cihaz ve tarayıcılarda bu hata neden çıkar?

Eski işletim sistemleri ve tarayıcılar TLS 1.2'yi hiç bilmeyebilir. Bu cihazlar yalnızca TLS 1.0 ya da 1.1 ile bağlanmaya çalışır. Sunucu ise standartlar gereği bu sürümleri kabul etmez. Sonuçta ortak sürüm bulunmaz ve hata ekrana gelir.

Böyle bir durumda doğru çözüm istemciyi güncellemektir. Ziyaretçi işletim sistemini ya da tarayıcısını yükseltmelidir. Sunucuda TLS 1.0'ı geri açmak ise tüm ziyaretçilerin güvenliğini zayıflatır. Bu yüzden onu hiç önermiyoruz.

Peki ziyaretçilerinizin ne kadarı eski cihaz kullanıyor, yani bu sorun gerçekten önemli mi? Bunu tahmin etmek yerine analitik verinize bakın. GA4'teki teknoloji raporları tarayıcı ve işletim sistemi dağılımını gösterir. Ancak eski cihazların payı küçükse ek bir adım atmanız gerekmez. Payı büyükse müşterilerinize güncelleme önerisi içeren kısa bir bilgi sayfası hazırlayabilirsiniz.

Antivirüs, kurumsal proxy ve tarayıcı ayarları hatayı tetikler mi?

Evet, tetikleyebilir. Bazı antivirüs yazılımları ve kurumsal güvenlik geçitleri HTTPS trafiğini kendi ara sertifikalarıyla yeniden şifreler. Bu aracı katman eski bir TLS sürümüyle çalışıyorsa tarayıcı ile sunucu arasında ortak sürüm kalmayabilir. Hata ise yalnızca o ağda ya da bilgisayarda çıkar, dolayısıyla sunucu suçlanmamalıdır.

Ziyaretçi tarafında şu sırayı izleyin:

1. Siteyi başka bir ağda, örneğin mobil veride açmayı deneyin.
2. Başka bir tarayıcı ve başka bir cihazla karşılaştırın.
3. İşletim sistemi ve tarayıcı güncellemelerini yükleyin.
4. Antivirüsün HTTPS tarama özelliğini geçici olarak kapatıp yeniden deneyin.
5. Kurumsal ağdaysanız BT ekibinize durumu bildirin.

Hata başka ağda ya da cihazda yoksa sorun büyük olasılıkla sizin tarafınızdadır. Bu nedenle sunucuya dokunmadan önce bu ayrımı yapmak saatler kazandırır.

Bu hata SEO ve satışları nasıl etkiler?

Ziyaretçi sayfayı açamıyorsa içeriğinizi göremez. Arama motoru tarayıcıları da HTTPS adresine bağlanamazsa sayfayı okuyamaz. Kalıcı bir hata, Search Console'da erişim sorunu olarak görünebilir. Bu nedenle sertifika ve TLS ayarını ciddiye almanız gerekir.

E-ticarette etki daha doğrudan olur, çünkü ödeme sayfasına ulaşamayan müşteri alışverişi tamamlayamaz. Güven konusunu daha geniş ele almak isterseniz e-ticaret sitesinde müşteri güveni yazımızı okuyun.

Sıfır kesintiyi hiçbir ekip garanti edemez. Fakat sertifika yenilemelerini izlemek ve yapılandırma değişikliklerinden sonra test etmek riski belirgin biçimde azaltır. Teknik sağlık denetiminde bu kontroller ilk sıralarda yer alır; SEO danışmanlığı hizmetimizde de rutin olarak ele alıyoruz.

Ne zaman kendiniz yapmamalı, hosting sağlayıcınıza bırakmalısınız?

Biz dijital pazarlama ve web ekibiyiz, hosting firması değiliz. Bu yüzden bu yazıdaki komutlar resmi belgelere dayanır ve her sunucu ortamında aynı sonucu vermeyebilir. Aşağıdaki durumlarda işi hosting sağlayıcınıza bırakmak daha güvenlidir.

• Paylaşımlı hosting kullanıyorsanız ve sunucu yapılandırma dosyalarına erişiminiz yoksa.
• Sertifikayı hosting paneli otomatik yönetiyorsa ve elle değiştirmek bu düzeni bozabilirse.
• Yapılandırma dosyasında neyi değiştirdiğinizi tam olarak anlamıyorsanız.
• Canlı bir e-ticaret sitesinde yedeksiz değişiklik yapacaksanız.
• Sorun CDN ile sunucu arasındaki bağlantı modundaysa ve iki tarafı birden yönetmiyorsanız.

Kendi VPS'inizde çalışıyorsanız önce yedek alın. Web sitesi yedekleme stratejisi yazımız bunun için bir başlangıçtır. Sağlayıcı seçerken de web sitesi için hosting nasıl seçilir rehberindeki destek ölçütlerine bakın.

Sağlayıcınızdan destek isterken hangi bilgileri vermelisiniz?

Destek talebi ne kadar net olursa çözüm o kadar hızlı gelir. Bu nedenle yazmadan önce birkaç bilgiyi toplayın. Aşağıdaki liste, hosting sağlayıcınızın ya da CDN yöneticinizin ilk sorularını önceden yanıtlar.

• Hata mesajının tam metni ve hangi alan adında ya da alt alan adında çıktığı.
• Hatanın ilk ne zaman başladığı ve hemen öncesinde neyin değiştiği.
• Hatanın herkeste mi yoksa yalnızca belirli cihaz ya da ağlarda mı görüldüğü.
• OpenSSL ya da curl komutunuzun çıktısı.
• CDN kullanıp kullanmadığınız ve sertifikayı kimin yönettiği.

Bu bilgiler sayesinde sağlayıcı sorunu daha kısa sürede daraltır. Ayrıca tarih bilgisi, otomatik sertifika yenilemesinin ya da bir yapılandırma güncellemesinin tetikleyici olup olmadığını gösterir. Kısacası iyi hazırlanmış bir talep, gidip gelen yazışmaları azaltır.

Düzeltmeden sonra neyi doğrulamalısınız?

Hatanın kaybolması tek başına yeterli değildir. Çözümün kalıcı olduğunu ve başka bir şeyi bozmadığını doğrulamanız gerekir. Özellikle yapılandırma dosyasına dokunduysanız aşağıdaki kontrolleri sırayla yapın.

1. Hem www'li hem www'siz adresi, ayrıca kullandığınız alt alan adlarını açın.
2. Birden fazla tarayıcıda ve mobil cihazda ana sayfayı ve bir ödeme ya da form sayfasını deneyin.
3. OpenSSL komutuyla TLS 1.2 ve 1.3 bağlantılarının kurulduğunu doğrulayın.
4. SSL sorgulama aracıyla sertifika bitiş tarihini not edin ve takviminize hatırlatıcı ekleyin.
5. Sunucu hata günlüğünde yeni bir hata satırı olmadığından emin olun.

Yanlış bir ayar sunucunun hiç açılmamasına da yol açabilir. Bu durumda 500 Internal Server Error yazımızdaki teşhis sırası işinize yarar. Değişikliği geri alabilmek için eski yapılandırma dosyasının kopyasını saklayın.

Bu hatayı çözerken en sık yapılan yanlışlar nelerdir?

Aşağıdaki hatalar, sorunu çözmek yerine yenisini ekler. Hepsi ise telaşla yapılan müdahalelerden doğar. Dolayısıyla yavaş ve sırayla ilerlemek çoğu zaman en hızlı yoldur.

• Eski TLS sürümlerini geri açmak, hem güvenliği hem standart uyumunu bozar.
• İnternetten kopyalanmış uzun şifre listelerini yapılandırmaya yapıştırmak, sertifika uyumsuzluğu doğurabilir.
• Hatanın CDN'de mi sunucuda mı olduğunu ayırt etmeden iki yerde birden ayar değiştirmek, nedeni gizler.
• Yapılandırmayı test etmeden yeniden yüklemek, siteyi tamamen kapatabilir.
• Önbellekteki eski sonucu görüp çözümün çalışmadığını sanmak, gereksiz müdahaleye yol açar.

Dolayısıyla son maddeyi önemsemelisiniz. Düzeltmeden sonra gizli pencerede ve farklı bir ağda deneyin. Yönlendirme zincirleri de benzer karışıklık yaratabilir; yönlendirme zinciri hatası yazımız bu konuda ek bilgi verir.

Özet: SSL sürüm uyuşmazlığı için kısa yol haritası nedir?

Önce hatanın kapsamını belirleyin: herkeste mi, yalnızca sizde mi? Herkesteyse sertifikanın alan adını kapsadığını ve CDN durumunu kontrol edin. Sonra sunucunun TLS 1.2 ve 1.3 sunduğunu test edin ve gerekirse protokol satırını düzeltin.

Yalnızca eski cihazlarda çıkıyorsa istemciyi güncelleyin, standartlara aykırı biçimde eski sürümleri geri açmayın. Öte yandan elinizin ulaşmadığı bir katman varsa hosting sağlayıcınızdan ya da CDN yöneticinizden destek isteyin. Böylece hem güvenliği hem erişilebilirliği korursunuz.