Sunucularınızda HTTPS'yi etkinleştirme

Can Yılmaz
Chris Palmer
Matt Gaunt

Bu makalede açıklanan adımlar

  1. 2048 bit RSA herkese açık/özel anahtar çifti oluşturun.
  2. Ortak anahtarınızı yerleştiren bir sertifika imzalama isteği (CSR) oluşturun.
  3. Nihai sertifika veya sertifika zinciri almak için CSR'nizi Sertifika Yetkilinizle (CA) paylaşın.
  4. Nihai sertifikanızı /etc/ssl (Linux ve Unix) gibi web'den erişilemeyen bir yere veya IIS'nin gerektirdiği her yere (Windows) yükleyin.

Anahtarlar ve sertifika imzalama istekleri oluşturma

Bu bölümde, özel/ortak anahtarlar ve bir CSR oluşturmak için çoğu Linux, BSD ve Mac OS X sistemiyle birlikte gelen Opensl komut satırı programı kullanılır.

Genel/özel anahtar çifti oluşturma

2.048 bitlik bir RSA anahtar çifti oluşturarak başlayalım. 1.024 bit gibi daha küçük bir anahtar, kaba kuvvette tahmin saldırılarına karşı yeterli direnç göstermez. 4.096 bit gibi daha büyük bir anahtar, fazla yük anlamına gelir. Zamanla, bilgisayarla yapılan işlemler ucuzlaştıkça anahtar boyutları da artar. 2048 şu anda uygun.

RSA anahtar çiftini oluşturma komutu:

openssl genrsa -out www.example.com.key 2048

Bu, aşağıdaki çıkışı sağlar:

Generating RSA private key, 2048 bit long modulus
.+++
.......................................................................................+++
e is 65537 (0x10001)

Sertifika imzalama isteği oluşturma

Bu adımda, bir sertifika imzalama isteğine veya CSR'ye ortak anahtarınızı ve kuruluşunuz ve web sitenizle ilgili bilgileri yerleştirirsiniz. openssl komutu etkileşimli olarak gerekli meta verileri ister.

Aşağıdaki komut çalıştırılıyor:

openssl req -new -sha256 -key www.example.com.key -out www.example.com.csr

Aşağıdaki çıktıyı verir:

You are about to be asked to enter information that will be incorporated
into your certificate request

What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CA
State or Province Name (full name) [Some-State]:California
Locality Name (for example, city) []:Mountain View
Organization Name (for example, company) [Internet Widgits Pty Ltd]:Example, Inc.
Organizational Unit Name (for example, section) []:Webmaster Help Center Example
Team
Common Name (e.g. server FQDN or YOUR name) []:www.example.com
Email Address []:webmaster@example.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

CSR'nin geçerliliğini sağlamak için şu komutu çalıştırın:

openssl req -text -in www.example.com.csr -noout

Yanıt da şöyle görünmelidir:

Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=CA, ST=California, L=Mountain View, O=Google, Inc.,
OU=Webmaster Help Center Example Team,
CN=www.example.com/emailAddress=webmaster@example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:ad:fc:58:e0:da:f2:0b:73:51:93:29:a5:d3:9e:
                    f8:f1:14:13:64:cc:e0:bc:be:26:5d:04:e1:58:dc:
                    ...
                Exponent: 65537 (0x10001)
        Attributes:
            a0:00
    Signature Algorithm: sha256WithRSAEncryption
         5f:05:f3:71:d5:f7:b7:b6:dc:17:cc:88:03:b8:87:29:f6:87:
         2f:7f:00:49:08:0a:20:41:0b:70:03:04:7d:94:af:69:3d:f4:
         ...

CSR'nizi bir sertifika yetkilisine gönderin

Farklı sertifika yetkilileri (CA'lar), MT'lerinizi onlara göndermek için farklı yöntemler gerektirir. Yöntemler arasında web sitelerinde bir form kullanmak, MT'yi e-postayla göndermek veya başka bir yol yer alabilir. Bazı CA'lar (veya bayileri) sürecin bir kısmını veya tamamını (bazı durumlarda anahtar çifti ve CSR oluşturma dahil) otomatikleştirebilir.

CSR'yi CA'nıza gönderin ve son sertifikanızı veya sertifika zincirinizi almak için bu yöneticinin talimatlarını uygulayın.

Ortak anahtarınız için kefil olma hizmeti için farklı CA'lar farklı miktarlarda para alır.

Anahtarınızı, birkaç farklı ad (ör. tümü example.com, www.example.com, example.net ve www.example.net) veya *.example.com gibi "joker karakter" adları dahil olmak üzere birden fazla DNS adıyla eşleme seçenekleri de vardır.

Örneğin, şu anda CA'lardan biri aşağıdaki fiyatları sunmaktadır:

  • Standart: Yılda 16 dolar, example.com ve www.example.com için geçerlidir.
  • Joker karakter: Yılda 150 ABD doları, example.com ve *.example.com için geçerlidir.

Bu fiyatlara göre, 9'dan fazla alt alan adınız olduğunda joker karakter sertifikaları ekonomiktir. Aksi takdirde, yalnızca bir veya daha fazla tek ad sertifikası satın alabilirsiniz. (Beş adetten fazla alt alan adınız varsa sunucularınızda HTTPS'yi etkinleştirdiğinizde joker karakter sertifikası sizin için daha uygun olabilir.)

Sertifikaları, /etc/ssl (Linux ve Unix) gibi web erişimi olmayan bir yerde veya IIS (Windows) için gereken yerlerde tüm kullanıcı arabirimi sunucularınıza kopyalayın.

Sunucularınızda HTTPS'yi etkinleştirme

Sunucularınızda HTTPS'yi etkinleştirmek, web sayfalarınızın güvenliğini sağlamada kritik bir adımdır.

  • Sunucunuzu HTTPS desteği için ayarlamak üzere Mozilla'nın Sunucu Yapılandırması aracını kullanın.
  • Sitenizi Qualys'in pratik SSL Sunucu Testi ile düzenli olarak test edin ve en azından A veya A+ alın.

Bu noktada, operasyonlar için kritik bir karar vermeniz gerekir. Aşağıdakilerden birini seçin:

  • Web sunucunuzun içerik sunduğu her ana makine adı için farklı bir IP adresi ayırın.
  • Ada dayalı sanal barındırma kullanın.

Her ana makine adı için farklı IP adresleri kullanıyorsanız tüm istemciler için hem HTTP'yi hem HTTPS'yi kolayca destekleyebilirsiniz.

Ancak, çoğu site operatörü IP adreslerini korumak için ve genel olarak daha kullanışlı olduğundan ada dayalı sanal barındırma kullanır. Windows XP ve Android 2.3'ten önceki sürümlerde IE sorunu, HTTPS ad tabanlı sanal barındırma için son derece önemli olan Sunucu Adı Göstergesi'ni (SNI) anlamamalarıdır.

Bir gün (umarım yakında) SNI'yı desteklemeyen istemciler modern yazılımlarla değiştirilir. Kullanıcılarınızın yeterli kısmının modern yazılıma ne zaman taşındığını öğrenmek için istek günlüklerinizdeki kullanıcı aracısı dizesini izleyin. (Eşiğinizin ne olduğuna siz karar verebilirsiniz. Belki %5'ten az veya %1'den az).

Sunucularınızda henüz HTTPS hizmetiniz yoksa bu hizmeti hemen etkinleştirin (HTTP'yi HTTPS'ye yönlendirmeden; aşağıya bakın). Web sunucunuzu, satın aldığınız ve yüklediğiniz sertifikaları kullanacak şekilde yapılandırın. Mozilla'nın kullanışlı yapılandırma oluşturma aracını kullanabilirsiniz.

Çok sayıda ana makine adınız veya alt alan adınız varsa bunların her birinin doğru sertifikayı kullanması gerekir.

Şimdi ve sitenizin kullanım ömrü boyunca, Qualys'in pratik SSL Sunucu Testi ile HTTPS yapılandırmanızı kontrol edin. Siteniz A veya A+ puanı vermelidir. Düşük nota neden olan tüm durumları hata olarak kabul edin. (Bugünün A, geleceğin B'sidir çünkü algoritmalara ve protokollere yönelik saldırılar sürekli olarak artmaktadır.)

Site içi URL'leri göreli yap

Artık sitenizi hem HTTP hem de HTTPS üzerinden sunduğunuza göre, protokol ne olursa olsun her şeyin mümkün olduğunca sorunsuz çalışması gerekiyor. Önemli bir faktör de site içi bağlantılar için göreli URL'ler kullanmaktır.

Site içi URL'ler ve harici URL'lerin protokolden bağımsız olduğundan emin olun. Diğer bir deyişle, göreli yollar kullandığınızdan veya //example.com/something.js gibi protokolü dışarıda bıraktığınızdan emin olun.

Karma içerik olarak bilinen HTTP kaynakları içeren bir sayfayı HTTPS aracılığıyla sunduğunuzda bir sorun oluşur. Tarayıcılar, HTTPS'nin tüm gücünün kaybedildiği konusunda kullanıcıları uyarır. Aslında, etkin karma içerik (komut dosyası, eklentiler, CSS, iframe'ler) söz konusu olduğunda, tarayıcılar genellikle içeriği hiç yüklemez veya yürütmez. Bu da sayfanın bozulmasına yol açar. Ayrıca, HTTPS kaynaklarını HTTP sayfasına eklemenin hiçbir sorun yaratmayacağını unutmayın.

Ayrıca, sitenizdeki diğer sayfalara bağlantı verdiğinizde, kullanıcılar HTTPS'den HTTP'ye düşürülebilir.

Bu sorunlar, sayfalarınızda http:// şemasını kullanan tam nitelikli, site içi URL'ler bulunduğunda ortaya çıkar.

Yapılmaması gerekenler
<h1>Welcome To Example.com</h1>
<script src="http://example.com/jquery.js"></script>
<link rel="stylesheet" href="http://assets.example.com/style.css"/>
<img src="http://img.example.com/logo.png"/>;
<p>A <a href="http://example.com/2014/12/24/">new post on cats!</a></p>
Tam nitelikli site içi URL'ler kullanmaktan kaçının.

Başka bir deyişle, site içi URL'lerin mümkün olduğunca göreli olmasını sağlayın: protokole bağlı (//example.com ile başlayan protokol eksiktir) veya ana makineye göre (/jquery.js gibi yalnızca yol ile başlayan).

Yapılması gerekenler
<h1>Welcome To Example.com</h1>
<script src="/jquery.js"></script>
<link rel="stylesheet" href="/assets/style.css"/>
<img src="/images/logo.png"/>;
<p>A <a href="/2014/12/24/">new post on cats!</a></p>
Göreli site içi URL'ler kullanın.
Yapılması gerekenler
<h1>Welcome To Example.com</h1>
<script src="//example.com/jquery.js"></script>
<link rel="stylesheet" href="//assets.example.com/style.css"/>
<img src="//img.example.com/logo.png"/>;
<p>A <a href="//example.com/2014/12/24/">new post on cats!</a></p>
Dilerseniz protokole bağlı site içi URL'ler de kullanabilirsiniz.
Yapılması gerekenler
<h1>Welcome To Example.com</h1>
<script src="/jquery.js"></script>
<link rel="stylesheet" href="/assets/style.css"/>
<img src="/images/logo.png"/>;
<p>A <a href="/2014/12/24/">new post on cats!</a></p>
<p>Check out this <a href="https://foo.com/"><b>other cool site.</b></a></p>
Siteler arası URL'ler için HTTPS URL'lerini kullanın (mümkünse).

Bunu elle değil, komut dosyasıyla yapın. Sitenizin içeriği bir veritabanındaysa komut dosyanızı veritabanınızın geliştirme kopyasında test edin. Sitenizin içeriği basit dosyalardan oluşuyorsa komut dosyanızı, dosyaların bir geliştirme kopyası üzerinde test edin. Bu değişiklikleri üretime yalnızca, değişiklikler normal şekilde QA'dan geçtikten sonra aktarın. Sitenizdeki karma içeriği algılamak için Bram van Damme'ın komut dosyasını veya benzer bir içeriği kullanabilirsiniz.

Diğer sitelere bağlantı oluştururken (bu sitelerin kaynaklarını eklemek yerine) sitelerin çalışma şeklini kontrol edemediğiniz için protokolü değiştirmeyin.

Büyük siteler için taşıma işleminin daha sorunsuz olması için protokole bağlı URL'leri öneririz. Henüz HTTPS'yi tam olarak dağıtıp dağıtamayacağınızdan emin değilseniz sitenizi tüm alt kaynaklarda HTTPS kullanmaya zorlamak geri tepebilir. HTTPS'nin yeni ve tuhaf olduğu bir dönem olabilir. HTTP sitesi her zamanki gibi çalışmaya devam etmelidir. Zamanla, taşıma işlemini tamamlar ve HTTPS'de kilitlersiniz (sonraki iki bölüme bakın).

Siteniz komut dosyalarına, resimlere veya CDN ya da jquery.com gibi bir üçüncü taraftan sunulan diğer kaynaklara dayanıyorsa iki seçeneğiniz vardır:

  • Bu kaynaklar için protokole bağlı URL'ler kullanın. Üçüncü taraf HTTPS sunmuyorsa HTTPS'yi sunmasını isteyin. jquery.com da dahil olmak üzere çoğu zaten yapıyor.
  • Kaynakları, hem HTTP hem HTTPS olanağı sunan, kontrol ettiğiniz bir sunucudan sunun. Bu çoğu zaman zaten iyi bir fikirdir. Çünkü bu şekilde, sitenizin görünümü, performans ve güvenliği üzerinde daha fazla denetime sahip olursunuz. Ayrıca, bir üçüncü tarafa güvenmek zorunda değilsiniz ve bu her zaman işe yarar.

HTTP'den HTTPS'ye yönlendirme

Arama motorlarına, sitenize ulaşmanın en iyi yolunun HTTPS olduğunu bildirmek için sayfanızın başına standart bağlantı eklemeniz gerekir.

Sayfalarınızda <link rel="canonical" href="https://…"/> etiketleri ayarlayın. Bu, arama motorlarının sitenize ulaşmak için en iyi yolu belirlemesine yardımcı olur.

Katı Taşıma Güvenliği'ni etkinleştirin ve çerezleri güvenli hale getirin

Bu noktada, HTTPS kullanımını "kısıtlamaya" hazırsınız.

  • 301 yönlendirmesi maliyetini önlemek için HTTP Strict Transport Security'yi (HSTS) kullanın.
  • Çerezlerde her zaman Güvenli işaretini ayarla.

Öncelikle, istemcilere bir http:// referansını izlerken bile sunucunuza her zaman HTTPS üzerinden bağlanmaları gerektiğini bildirmek için Strict Transport Security'yi kullanın. Bu yöntem, SSL Stripping gibi saldırıları eler ve HTTP'yi HTTPS'ye Yönlendirme bölümünde etkinleştirdiğimiz 301 redirect işleminin gidiş dönüş maliyetini önler.

Strict-Transport-Security üst bilgisini ayarlayarak HTTP Strict Transport Security'yi (HSTS) etkinleştirin. OWASP'ın HSTS sayfası, çeşitli sunucu yazılımları için talimat bağlantıları içerir.

Çoğu web sunucusu, özel üstbilgiler ekleme konusunda benzer bir yetenek sunar.

Ayrıca, istemcilerin hiçbir zaman HTTP üzerinden çerez (kimlik doğrulaması veya site tercihleri için) göndermediğinden emin olmak da önemlidir. Örneğin, bir kullanıcının kimlik doğrulama çerezi düz metin olarak gösterilirse diğer her şeyi doğru yapmış olsanız bile kullanıcının tüm oturumunun güvenlik garantisi kaldırılır.

Bu nedenle, web uygulamanızı ayarladığı çerezlerde her zaman Güvenli işaretini ayarlayacak şekilde değiştirin. Bu OWASP sayfasında, çeşitli uygulama çerçevelerinde Secure flag'inin nasıl ayarlanacağı açıklanmaktadır. Her uygulama çerçevesinin işareti ayarlamanın bir yolu vardır.

Çoğu web sunucusu, basit bir yönlendirme özelliği sunar. Arama motorlarına ve tarayıcılara HTTPS sürümünün standart olduğunu belirtmek ve kullanıcılarınızı HTTP'den sitenizin HTTPS sürümüne yönlendirmek için 301 (Moved Permanently) kullanın.

Arama sıralaması

Google, HTTPS'yi pozitif bir arama kalitesi göstergesi olarak kullanır. Google, arama sıralamasını korurken sitenizi nasıl aktaracağınız, taşıyacağınız veya taşıyacağınız konusunda bir kılavuz da yayınlar. Bing, web yöneticileri için yönergeler de yayınlar.

Performans

İçerik ve uygulama katmanları iyi ayarlandığında (mükemmel öneriler için Steve Souders'ın kitaplarına bakın), kalan TLS performansı endişeleri genellikle uygulamanın genel maliyetine kıyasla küçük olur. Ayrıca, bu maliyetleri azaltabilir ve amorti edebilirsiniz. (TLS optimizasyonu ve genel olarak TLS optimizasyonuyla ilgili yararlı öneriler için Ilya Grigorik'in Yüksek Performanslı Tarayıcı Ağ İletişimi başlıklı makaleyi inceleyin.) Ayrıca Ivan Ristic'in OpenSSLCookbook ve Madde Korumalı SSL ve TLS konularına da bakın.

Bazı durumlarda TLS, büyük ölçüde HTTP/2'yi mümkün hale getirmenin sonucu olarak performansı iyileştirebilir. Chris Palmer, Chrome Dev Summit 2014 2014 etkinliğinde HTTPS ve HTTP/2 performansı hakkında konuştu.

Yönlendiren üst bilgileri

Kullanıcılar HTTPS sitenizden diğer HTTP sitelerine giden bağlantıları izlediğinde kullanıcı aracıları, Yönlendiren üst bilgisini göndermez. Bu bir sorunsa, bunu çözmenin birkaç yolu vardır:

  • Diğer siteler HTTPS'ye taşınmalıdır. Davetli siteler bu kılavuzun Sunucularınızda HTTPS'yi etkinleştirme bölümünü tamamlayabilirse, sitenizdeki bağlantıları http:// ile https:// arasında değiştirebilir veya protokole bağlı bağlantılar kullanabilirsiniz.
  • Yönlendiren başlıklarıyla ilgili çeşitli sorunları çözmek için yeni Yönlendiren Politikası standardını kullanın.

Gelecekte arama motorları HTTPS'ye taşındığından, HTTPS'ye geçtiğinizde büyük olasılıkla daha fazla Yönlendiren üstbilgisi görürsünüz.

Reklam geliri

Reklam göstererek sitelerinden para kazanan site operatörleri, HTTPS'ye taşımanın reklam gösterimlerini azaltmadığından emin olmak ister. Ancak içerik güvenliğiyle ilgili karma sorunlar nedeniyle HTTPS sayfasında HTTP <iframe> çalışmaz. Burada karmaşık bir işlem sorunu mevcuttur: Reklamverenler HTTPS üzerinden yayın yapana kadar, site operatörleri reklam gelirini kaybetmeden HTTPS'ye geçemezler. Ancak site operatörleri HTTPS'ye geçene kadar, reklamverenlerin HTTPS'yi yayınlamak için fazla motivasyonları olmaz.

Reklamverenler en azından HTTPS üzerinden reklam hizmeti sunmalıdır (ör. bu sayfadaki "Sunucularınızda HTTPS'yi etkinleştirme" bölümünü tamamlayarak). Birçok reklamveren bunu zaten yapıyor. Hiç HTTPS sunmayan reklamverenlerden en azından başlamalarını istemelisiniz. Yeterli sayıda reklamveren düzgün bir şekilde birlikte çalışana kadar Site İçi URL'leri göreceli yapma işlemini ertelemek isteyebilirsiniz.