Let’s Encrypt ile Ücretsiz SSL Sertifikası

Let’s Encrypt; kamu yararına çalışan, ücretsiz, otomatize, açık bir sertifika otoritesidir (Certificate Authority, CA)^1. Internet Security Research Group (ISRG) tarafından sağlanan bir hizmettir.^2

Bu yazıda; CentOS 7 üzerinde Apache konfigürasyonunu ve Let’s Encrypt kurulumunu gerçekleştirmeye çalışacağız.

Warner Bros ACME. RTFM Coyote!
Warner Bros ACME. RTFM Coyote!

Sertifika? Otorite?

Konu, sanıldığından çok daha derin. Fakat derine inecek düzeyde olmadığım için ben de yüzeysel kalacağım.

“Neden HTTPS? Neden SSL?” gibi noktaları atlıyorum. Bu soruların yanıtları defalarca yazıldı, çizildi. İlle de bilmek istiyorum derseniz tabii ki ilgili bağlantıları – her zaman olduğu gibi – buraya bırakacağım.

Özünde yapmak istediğimiz basit, daha doğrusu basit görünen, bir iş var. “Internet” adı verilen bir ağ üzerinde 2 ucun haberleşebilmesini istiyoruz. Çok doğal ve her gün yaptığımız bir şey. Fakat takdir edersiniz ki her iletişime geçtiğiniz uç ile aranızda doğrudan bir bağlantı yok. Bu da şunu gösteriyor: Karşı tarafa göndermek istediğiniz her ne ise, önce başkasına gönderdiniz. Muhtemelen o da başka bir noktaya gönderdi. Kafalardan seken network paketi, kalecinin kucağında kaldı.

Aşağıdaki örneği inceleyelim:

traceroute çıktısı
traceroute çıktısı
[ali@icecast ~]$ traceroute alisezisli.com.tr
traceroute to alisezisli.com.tr (5.2.87.131), 30 hops max, 60 byte packets
 1  72.14.209.95 (72.14.209.95)  1.974 ms  1.903 ms  1.844 ms
 2  ae1.istanbul1.ist.seabone.net (93.186.132.131)  40.485 ms et1-1-2.istanbul1.ist.seabone.net (93.186.132.165)  38.869 ms  43.340 ms
 3  netin-haberlesme.istanbul1.ist.seabone.net (93.186.132.195)  39.867 ms  38.786 ms  39.492 ms
 4  212.156.144.46.static.turktelekom.com.tr (212.156.144.46)  46.456 ms  50.801 ms  46.299 ms
 5  * * *
 6  * * *
 7  phobos.alastyr.com (5.2.87.131)  46.719 ms  45.253 ms  49.874 ms

Kısaca özetlemek gerekirse; traceroute, network paketlerinizin gittiği rotayı size gösteren bir programdır. Yukarıda da göreceğiniz üzere 7 denemede bu sayfaya ulaştım. Arada farklı noktalara da uğramak zorunda kaldığımı görüyorsunuz.

Peki gönderdiğim verileri, arada geçtiğim noktalar görebilir mi? Ya da Wi-Fi bağlantısı yaptığım bir cafede, herkesin verisi havada uçuşuyorken acaba kendi verilerini değil de benimkileri okumak isteyen biri olursa ne olur, okuyabilir mi? Evde, iş yerinde vs. aynı router’a bağlandığım kişiler benim için bir tehdit oluşturabilir mi?

Soruların hepsinin yanıtı evet. Peki ne yapacağız? Internet üzerinden kullanıcı adı ve parolalar göndererek kendimizi tanıtmaya, kendimiz olduğumuzu ispatlamaya çalışıyoruz. Adres, telefon, kredi kartı bilgileri gönderip alışveriş yapıyoruz. Bankacılık işlemleri yapıyoruz. Özel görüşmelerimizi gerçekleştiriyoruz. Ve bu verilerin tamamı network üzerinde bir yerlerden geçiyor. Nereye nasıl gittiğine dair de en ufak bir fikrimiz yok.

Neyse ki burada devreye kriptoloji giriyor ve günü kurtarıyor. Ama sakın, bak sakın, sakın ola “Aaa evet WhatsApp da uçtan uca şifreliyor.” demeyin. SAKIN!!!

Açık Anahtar, Diffie-Hellman

Elimizde bir veri var. Bunu sadece göndereceğimiz kişinin okuyabilmesini istiyoruz. Öyle bir kilit yapalım ki, bunu sadece tek bir anahtar açabilsin. Öyle bir kilit yapalım ki, kilide bakarak anahtarı bulunamasın. Öyle bir yöntem geliştirelim ki, karşı taraf bana kilidini rahatlıkla gönderebilsin. Başkalarının bu kilidi görmesi hiç de umrumuzda olmasın.

Bu süreci bize sağlayan yöntemlere “Açık Anahtar Protokolleri (Public-Key Protocols)” diyoruz. Bilinen ilk örneklerinden biri de Diffie-Hellman Anahtar Değişimi‘dir.^3

Bu iş pür matematik. Detaylandıracak kadar matematiğim de yok açıkçası. Fakat süreci kısaca anlatmaya çalışalım:

  • Kendi sisteminizde bir anahtar çifti (key-pair) oluşturuyorsunuz.
  • Bu anahtarlardan biri private (özel), diğeri public (açık) anahtar.
  • Public key’iniz ile şifrelenen bir şeyi sadece sizin private key’iniz açabiliyor.
  • Public key’inize bakarak private key’inizi bulmak imkansız.
  • Dolayısıyla public key’inizi herkese gönderebilirsiniz.
  • Public key’inizi bana gönderdiniz. Mesajı onunla şifreledim. Size gönderdim.
  • Yolda bu veriyi inceleyen kişiler (Man in the middle, MIM), içeriği okuyamıyor.
  • Paket size ulaşıyor ve private key’iniz ile açıyorsunuz.
  • Şifreli iletişimimiz tamamlanmış oluyor.

Soru: Şifrelemeyi emanet ettiğiniz anahtarlarınızı kim oluşturdu?

Cevap: Kendiniz.

Soru: Canınız isterse, kendi private key’inizi de başkalarıyla paylaşarak size özel gelen mesajları başkalarının görmesine de izin verebilir misiniz? (Yapmamalısınız tabi ki..)

Cevap: Evet.

Soru: Anahtarlarınızı siz üretmeyin. Ben sizin için üreteyim dersem, private anahtarınızın bir kopyasını da kendime almadığımı garanti edebilir misiniz?

Cevap: Sanmıyorum.

Soru: WhatsApp’ın “uçtan uca” şifrelemesinde anahtarları kim üretiyor?

Cevap: WhatsApp uygulaması.

Başka sorum yok. “Bu ne ya düz mantık bu.” diyor olabilirsiniz. Siz bilirsiniz. Bu konuyu bir kenara bıraktıktan sonra devam edelim.

Açık Anahtarın Doğruluğunun Kontrolü

Public key’inizi bana gönderdiniz. “Mesajı bununla şifrele” dediniz. Fakat acaba bu sizin public key’iniz miydi? Yanlış bir iş yapıyor olmayayım? Ya da elimdeki yüzlerce public key içerisinden hangi anahtarın kime ait olduğunu nasıl bileceğim? Esasında bu işler için anahtar sunucularımız var. Anahtar yöneticilerimiz var. Fakat söz konusu web olduğunda işler biraz daha karmaşık hâl alıyor. Burada public key’in sahipliğini gösteren, bunu doğrulayan elektronik dokümanlar devreye giriyor ki bunlara “Açık Anahtar Sertifikası (Public Key Certificate)^4 diyoruz.

Daha önce belirttiğimiz gibi, esasında yapılan işlem tamamen matematik. Kendi anahtar çiftinizi üretmenizde hiçbir sakınca ve/veya zorluk yok. Fakat buna nasıl güveneceğiz?

Kendi ürettiğiniz key’leri paylaşabileceğiniz bazı anahtar sunucuları var. Hatta bu key’i kullanarak size şifreli mesaj gönderebilen arkadaşlarınız, sizin anahtarınızı onaylayarak güvenilirliğini arttırıyor. Aşağıda, OpenPGP Keyserver ve MIT PGP Public Key Server tarafından sorgulanan açık anahtarımın sonuçlarını görebilirsiniz:

OpenPGP Keyserver sorgusu
OpenPGP Keyserver sorgusu
MIT PGP Public Key Server
MIT PGP Public Key Server

Bu anahtar sunucularına göre, bahsi geçen public anahtar gerçekten de bana ait. Ya da birileri benim sunucumda cirit attı ve kendi anahtarlarını bana aitmiş gibi göstermeyi başardı…

Şimdi bütün dünyayı düşünelim. Bir web sitesine gireceksiniz. Web sunucusu sizin siz olduğunuza, siz de o sitenin gerçekten o site olduğuna inanmak istiyorsunuz ki şifrelemeyi doğru ve güvenilir bir şekilde başlatabilesiniz. Fakat anahtarlar sunucu, istemci, hatta belki de oturum bazında bile değişiyor. Burada devreye “sertiifka otoriteleri” giriyor.

Örneğin Mozilla Firefox tarayıcısı, “Ben şu şu şu otoritelere güveniyorum.” diyor. Ve eğer bağlanacağınız sunucunun anahtarları bu otorite tarafından doğrulandıysa, sizi şöyle şeyler karşılıyor:

Wikipedia.org DigiCert Inc tarafından doğrulanmış.
Wikipedia.org DigiCert Inc tarafından doğrulanmış.
alisezisli.com.tr, Let's Encrypt tarafından doğrulanmış.
alisezisli.com.tr, Let’s Encrypt tarafından doğrulanmış.

Let’s Encrypt’i Farklı Kılan nedir?

Web’i daha güvenli hâle getirmek için birçok şirket SSL sertifikası hizmeti vermeye başladı. Otorite oldular, anlaşmalar yaptılar. Sonrasında da “Bana ayda şu kadar USD verirsen SSL sertifikası kullanabilirsin.” demeye başladılar. Tam güvenlik işi kapitale bağlanıyor derken Let’s Encrypt çıktı ve “Biz de otoriteyiz. Gereken süreçleri tamamladık. Ama bizim hizmetimiz ücretsizdir.” dedi. Bu sayede, kendi kendimize SSL sertifikaları üretebiliyoruz ve ücret ödemek durumunda kalmıyoruz.

Let’s Encrypt Nasıl Çalışır?

Warner Bros çizgi filmlerinden hatırlarsınız belki. Her ürünün markası “ACME“. Her şeyi yapan firma (A Company Making Everything). Aaa ne güzel fun fact değil mi? Değil. Bu yaygın inanış yanlış. ACME ismi oradan gelmiyor. Zaten bizim ACME’nin bununla da bir ilgisi yok 🙂

Bizim ACME’mizin açılımı şu: Automatic Certificate Management Environment. RFC8555 standardı. Sertifika otoritesi ve sunucu arasındaki doğrulama mekanizmasını otomatize etmeyi amaçlayan bir protokol.^5

Let’s Encrypt ve ACME’nin hedefi, tarayıcıların güvenebileceği sertifikaları otomatik olarak, insan müdahalesi olmadan alabilen bir HTTPS server’ı mümkün kılmak. Tüm süreci – anladığım kadarıyla – özetlemeye çalışacağım. Tabii ki doğru kaynağın neresi olduğunu da belirtmeden geçmeyeceğim.^6

  1. Sitemiz “example.com” olsun.
  2. Önce agent’ımız, sertifika otoritesine (CA), web server’ın bir domainde olduğunu ispatlar. Sonrasında agent, domain üzerindeki sertifikaları yenileme ve iptal etme hakkı kazanır. Tüm mevzu bu kadar aslında.
  3. Domain’in doğrulanması için Let’s Encrypt bazı challenge’lar sunar. DNS kaydı sorgular ya da o domain altında özel bir dosya arar.
  4. Challenge’ların yanısıra Let’s Encrypt, agent’ın kendi anahtar çiftiyle oturum açmasını; dolayısıyla bu anahtarların gerçek sahibi olduğunu görmek ister.
  5. Challenge’ları tamamlayan agent, CA’ya giderek hazır olduğunu iletir.
  6. CA, challenge’ları kontrol eder. Oluşturulan dosyaları alır, içeriğini doğrulamaya çalışır. Doğrulama başarılı olursa, bu domain gerçekten de bu agent’ın kurulu olduğu sunucudadır. Bu sistem yöneticisine güvenebiliriz. Domain’i gerçekten de o yönetiyor. Bu durum, süreci başlatan anahtar çiftinin (key pair), yetkilendirilmiş anahtar çifti (authorized key pair) olmasını sağlar.
  7. Yetkilendirme tamamlandıktan sonraki süreç ise nispeten daha kolay. CA’ya, kendi anahtarınızla imzalanmış mesajlar gönderiyorsunuz ve sertifikalarınızı talep etme, yenileme, iptal etme gibi taleplerde bulunuyorsunuz. Zaten dijital olarak imzalanmış bu talepleriniz de CA tarafından karşılanıyor.

Let’s Encrypt Kurulumu

Let’s Encrypt’i kullanabilmek için bazı ön hazırlıklara ihtiyacımız var. Öncelikle, sunucumuzda Virtual Host tanımlı bir web server olmalı. Aksi takdirde, ilerleyen adımlarla sıkıntı yaşayacağız. Bir de DNS A kaydı oluşturmamız gerekecek. Bunların hepsini, sıfırdan yapalım istiyorum.

Apache Web Server Kurulumu

Bu konuyu CentOS 7 Üzerine WordPress Kurulumu başlıklı yazımda zaten açıklamıştım. Fakat o yazıda hiçbir konfigürasyon yapmamıştık. Bu nedenle kurulum adımlarını biraz hızlı geçerek işi konfigürasyon tarafına yoğunlaştıracağım.

  1. yum install httpd #Apache web server’ı kur.
  2. systemctl enable httpd #Servisi enable et.
  3. systemctl start httpd #Servisi başlat.

Bu adımlardan sonra, firewall tarafındaki konfigürasyonumuzu yapıyoruz.

[root@icecast ~]# firewall-cmd --list-all
trusted (active)
  target: ACCEPT
  icmp-block-inversion: no
  interfaces: eth0
  sources:
  services:
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

[root@icecast ~]# firewall-cmd --permanent --add-service=https
success
[root@icecast ~]# firewall-cmd --permanent --add-service=http
success
[root@icecast ~]# firewall-cmd --reload
success
[root@icecast ~]# firewall-cmd --list-all
trusted (active)
  target: ACCEPT
  icmp-block-inversion: no
  interfaces: eth0
  sources:
  services: http https
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

Önce var olan kuralları listeledik. Sonrasında https ve http servisleri için “kalıcı (permanent)” kurallar ekledik. Kuralların hemen geçerli olması için “firewall-cmd –reload” çalıştırdık. Tekrar listeleme yaptığımda “services” kısmında “http” ve “https”i görebiliyoruz.

Bu adımları tamamladıktan sonra, tarayıcınızda “http://<server_ip>” adresine gittiğinizde Apache test sayfasını görebiliyor olmalısınız.

Apache Web Server Virtual Host Tanımlama

Başlamadan şunu belirteyim. Nginx kullanmak istiyorsanız anahtar kelimeniz “server block“. Bu yazıda Apache ile devam ediyorum.

Özetlemek gerekirse; Virtual Host, bir sunucu üzerinde birden fazla domain için web server hizmeti verebilmek için kullandığımız bir yapı. Bütün bir sunucunun konfigürasyonunu koşturmak yerine, farklı sanal hostların konfigürasyonlarını ayrı ayrı oluşturabilmemizi sağlar. Bu sayede aynı web server üzerinde birden fazla domain’e hizmet verilebilir. Zaten “shared hosting” dediğimiz kavram da böyle bir şey değil mi?

Aşağıdaki komutlarda, “gnuadm.in” domainini kullanacağım. Bunu gördüğünüz her noktada, kendi alan adınızı yazmalısınız.

[root@icecast html]# mkdir -p /var/www/gnuadm.in/html
[root@icecast html]# mkdir -p /var/www/gnuadm.in/log
[root@icecast html]# ls -l /var/www
total 0
drwxr-xr-x. 2 root root  6 Nov 16 16:19 cgi-bin
drwxr-xr-x. 4 root root 29 Dec 18 07:39 gnuadm.in
drwxr-xr-x. 2 root root  6 Dec 17 09:56 html
[root@icecast html]# vi /var/www/gnuadm.in/html/index.html

Satır satır açıklayalım:

  1. Apache’nin varsayılan servis dizini “/var/www/html“. Bazen bunun “/var/www” olduğunu da görebilirsiniz. Burayla şu an ilgilenmiyoruz. Çünkü Apache’nin varsayılan konfigürasyonunu kullanmayacağız. Fakat kendi domain’imizin servis edilecek dosyalarını saklamak için bir dizin oluşturuyoruz.
  2. Burada da, aynı ana dizin altına “html” değil, “log” dizini oluşturduk. Bu alan adına ait log’lar bu dizin altına yazılacak.
  3. /var/www” dizininin izinlerinin 755 (rwxr-xr-x) olduğundan emin olmalıyız.
  4. Sitemizin “html” dizini altında bir index.html dosyası oluşturduk. İçine basit bir html kodu yazabilirsiniz. Üşeniyorum diyenler için:
<!doctype html>
<head>
        <title>Let's Encrypt Denemesi</title>
</head>

<body>
        <p>Let's Encrypt çalıştı mı?</p>
</body>
</html>

Gerekli dizin hazırlıklarını tamamladıktan sonra, Virtual Host oluşturma işine başlayabiliriz. Burada hazırlayacağımız konfigürasyon dosyalarının temel amacı, Apache web server’a, farklı domain’lerden gelen isteklere farklı yanıtlar vermesi gerektiğini anlatmak olacak.

Bu konfigürasyon dosyaları için 2 dizine ihtiyaç duyacağız: “sites-available” ve “sites-enabled“. “sites-available” dizini, konfigürasyon dosyalarını tutacak. “sites-enabled” dizini ise, bu konfigürasyonlardan hangilerine yanıt verileceğini gösterecek. Yani aslında “sites-available” içine bir konfigürasyon hazırladıktan sonra, “sites-enabled” içine linkleyeceğiz.

[root@icecast html]# mkdir /etc/httpd/sites-available /etc/httpd/sites-enabled
[root@icecast html]# vi /etc/httpd/conf/httpd.conf

Birinci satırda, sites-available ve sites-enabled dizinlerini oluşturduk. İkinci satırda ise Apache’nin konfigürasyon dosyasını açıyoruz. Burada, IncludeOptional kısmında bir değişiklik yapmamız lazım. Eski değeri:

# Supplemental configuration
#
# Load config files in the "/etc/httpd/conf.d" directory, if any.
IncludeOptional conf.d/*.conf

olan kısmı, aşağıdaki şekilde değiştiriyoruz. Çünkü konfigürasyon dosyalarımız varsayılan dizinden değil, “sites-enabled” dizinininden gelsin istiyoruz:

# Supplemental configuration
#
# Load config files in the "/etc/httpd/conf.d" directory, if any.
IncludeOptional sites-enabled/*.conf

Bu ayarı tamamladıktan sonra – henüz bu ayarın aktif olmadığı gerçeğini aklımızda tutarak – yolumuza devam ediyoruz. Birkaç işimiz daha var. Bu işlerin tamamını bitirdikten sonra Apache’yi yeniden başlatacağız.

[root@icecast html]# vi /etc/httpd/sites-available/gnuadm.in.conf

Domain’imiz için bir config dosyası oluşturduk. İçerisine VirtualHost tanımı yapacağız. Aşağıdaki VirtualHost tanımını inceleyelim:

<VirtualHost *:80>
    ServerName www.gnuadm.in
    ServerAlias gnuadm.in
    DocumentRoot /var/www/gnuadm.in/html
    ErrorLog /var/www/gnuadm.in/log/error.log
    CustomLog /var/www/gnuadm.in/log/requests.log combined
</VirtualHost>

80 portuna gelen talepleri dinleyen bir VirtualHost var. Server ismi ve alias tanımlanmış. Belge kökü olarak, hazırladığımız html dizini gösterilmiş. Hata logları ve diğer loglar için de, daha önceden oluşturduğumuz log dizinleri altında dosyalar gösterilmiş. Biz bu dosyaları oluşturmadık. Bunların oluşturulmasını Apache’den bekleyeceğiz.

Sonrasında sites-enabled ve sites-available arasında bir sembolik link oluşturuyoruz.

[root@icecast html]# ln -s /etc/httpd/sites-available/gnuadm.in.conf /etc/httpd/sites-enabled/gnuadm.in.conf

İşimizin bittiği yanılgısına düşmediğiniz için teşekkürler.

Apache Virtual Host SELinux Konfigürasyonu

SELinux, Apache’nin varsayılan konfigürasyonu ile çalışacak şekilde hazırlanmıştır. Fakat biz, Apache için farklı bir konfigürasyon hazırladık. En basitinden, log’larını yazacağı dizini değiştirdik. bu gibi değişikliklerden dolayı SELinux üzerinde bazı değişiklikler yapmamız gerekiyor.

Yollarımızdan biri şu:

[root@icecast~]# setsebool -P httpd_unified 1

Yukarıdaki komut ile, bütün Apache process’lerinin aynı şekilde değerlendirilmesi gerektiğini (httpd_unified 1) söyüyoruz. “-P” ile de bu yaklaşımın her boot sonrasında sürdürülmesi gerektiğini belirtiyoruz. Bu yaklaşım; host başına değil, tüm sistem genelindeki Apache process’leri için çalışacak. Nispeten kolay, fakat biraz yüzeysel.

Başka bir yaklaşımda ise her hostun her dizini için SELinux konfigürasyonu yapmamız gerekiyor. Ona burada yer vermiyorum. Tabii ki ilgili bir dokümanı sizinle paylaşıyorum.^7

SELinux konfigürasyonu sonrasında Apache’yi yeniden başlattığımızda – ki Apache configlerini değiştirdikten sonra da yeniden başlatmamıştık hatırlarsanız – Apache’nin custom log dizinlerine yazmaya başladığını görebiliriz:

[root@icecast ~]# ls -la /var/www/gnuadm.in/log/
total 0
drwxr-xr-x. 2 root root  6 Dec 18 07:39 .
drwxr-xr-x. 4 root root 29 Dec 18 07:39 ..
[root@icecast ~]# systemctl restart httpd
[root@icecast ~]# ls -la /var/www/gnuadm.in/log/
total 0
drwxr-xr-x. 2 root root 43 Dec 18 10:48 .
drwxr-xr-x. 4 root root 29 Dec 18 07:39 ..
-rw-r--r--. 1 root root  0 Dec 18 10:48 error.log
-rw-r--r--. 1 root root  0 Dec 18 10:48 requests.log

Alan adınızı aldığınız sağlayıcıya göre, DNS kayıtlarının düzenlemesi kısmı farklılık gösterecektir. Fakat DNS A kaydınızı, sunucunuzun IP’sine yönlendirme işlemini tamamladıktan sonra (DNS ön belleklerinin güncellenmesi zaman alabilir) web siteniz sizi karşılayacaktır. Eğer hem www hem de www olmayan şekilde erişim sağlamak isterseniz, bir de CNAME kaydı oluşturabilirsiniz.

DNS A ve CNAME kayıtları
DNS A ve CNAME kayıtları
Apache Virtual Host denemesi
Apache Virtual Host denemesi

Certbot Kurulumu

Let’s Encrypt, shell erişimi olan herkes için Certbot ACME client‘ı öneriyor. Fakat bu client işinizi görmezse, farklı ACME client’lar da seçebilirsiniz.

Certbot’un instruction’larına bakmak istediğimizde ise, bizi güzel bir arayüz karşılıyor:

Certbot instructions
Certbot instructions

CentOS 7 üzerinde Apache web server’ım olduğunu belirttikten sonra, ihtiyacım olan şeyleri sıralıyor. Buna göre:

  • CLI kullanabilmelisiniz. (Çok şükür fena değiliz :))
  • Hâli hazırda 80 portundan hizmet veren bir HTTP server’ınız olmalı. (Zaten bir web server’ınız yoksa ya da varsa ama hizmet veremiyorsa, doğrulama kısmını yapamaz değil mi?)
  • Bu servisler SSH yapabileceğiniz, root yetkilerine sahip olabileceğiniz bir sunucuda çalışmalı.

Ön hazırlıkta bir sorunumuz olmadığına göre, kuruluma başlayabiliriz.

  1. EPEL repolarını açıyoruz: yum install epel-release
  2. snapd paketini kuruyoruz: yum install snapd
  3. Snap iletişimini yöneten systemd socket’ini enable ediyoruz: systemctl enable –now snapd.socket
  4. Classic snap desteğini sağlayabilmek için, bir sembolik link oluşturuyoruz: ln -s /var/lib/snapd/snap /snap
  5. Sonrasında path’lerin hazırlanabilmesi için ya bir logout – login yapmamız ya da makineyi yeniden başlatmamız isteniyor. Ben logout – login yaptım. Buraya kadar olan kısım, CentOS üzerine snap kurulumu içindi.^8
  6. Snap servisini yeniden başlatıyoruz: systemctl restart snapd
  7. Sonrasında, snapd sürümümüzün güncel olduğuna emin oluyoruz: snap install core; sudo snap refresh core
  8. Snap dışında farklı bir paket yöneticisinden kurduğunuz “certbot” varsa, bunları kaldırmalısınız:
    1. Certbot ile ilgili bir paket arıyorum: rpm -qa | grep certbot
    2. Kurulu bir şey bulamadım. Eğer bulsaydım, yum remove <paketadı> şeklinde kaldırabilirdim.
  9. Certbot’u kuruyoruz: snap install –classic certbot
  10. Certbot komutunun çalışabilmesi için sembolik linkleri hazırlıyoruz: ln -s /snap/bin/certbot /usr/bin/certbot
  11. Apache için SSL modülünü kuruyoruz: yum install mod_ssl
  12. Certbot’un sertifika alıp kurmasını istiyoruz: certbot –apache
    1. Eğer sadece seritifkayı alıp kurulumu ertelemek isteseydik: certbot certonly –apache
[root@icecast ~]# yum search mod_ssl
[......]
============================================== N/S matched: mod_ssl ==============================================
mod_ssl.x86_64 : SSL/TLS module for the Apache HTTP Server

  Name and summary matches only, use "search all" for everything.
[root@icecast ~]# yum install mod_ssl
[......]

==================================================================================================================
 Package                Arch                  Version                                Repository              Size
==================================================================================================================
Installing:
 mod_ssl                x86_64                1:2.4.6-97.el7.centos                  updates                114 k

Transaction Summary
==================================================================================================================
Install  1 Package

[......]
Installed:
  mod_ssl.x86_64 1:2.4.6-97.el7.centos

Complete!
[root@icecast ~]# certbot --apache
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache

Which names would you like to activate HTTPS for?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: gnuadm.in
2: www.gnuadm.in
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel):
Cert not yet due for renewal

You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry.
(ref: /etc/letsencrypt/renewal/gnuadm.in.conf)

What would you like to do?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: Attempt to reinstall this existing certificate
2: Renew & replace the cert (may be subject to CA rate limits)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 1
Keeping the existing certificate
Created an SSL vhost at /etc/httpd/sites-available/gnuadm.in-le-ssl.conf
Deploying Certificate to VirtualHost /etc/httpd/sites-available/gnuadm.in-le-ssl.conf
Enabling site /etc/httpd/sites-available/gnuadm.in-le-ssl.conf by adding Include to root configuration
Deploying Certificate to VirtualHost /etc/httpd/sites-available/gnuadm.in-le-ssl.conf
Redirecting vhost in /etc/httpd/sites-enabled/gnuadm.in.conf to ssl vhost in /etc/httpd/sites-available/gnuadm.in-le-ssl.conf

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations! You have successfully enabled https://gnuadm.in and
https://www.gnuadm.in
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

IMPORTANT NOTES:
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Yukarıdaki çıktıda göreceğiniz “What would you like to do?” ile başlayan 2 seçenek, yüksek ihtimalle sizde çıkmayacak. Çünkü benim elimde sertifikalarım zaten vardı, sadece kuramamıştım (mod_ssl’i yüklemeyi unuttuğum için).

Eğer sertifika kurulumu sırasında aşağıdaki hatayı alırsanız (Could not find ssl_module; not disabling session tickets veya Could not find ssl_module; not installing certificate), mod_ssl’i yükledikten sonra tekrar deneyebilirsiniz:

[root@icecast ~]# certbot --apache
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Could not find ssl_module; not disabling session tickets.
Plugins selected: Authenticator apache, Installer apache

Which names would you like to activate HTTPS for?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: gnuadm.in
2: www.gnuadm.in
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel):
Requesting a certificate for gnuadm.in and www.gnuadm.in
Performing the following challenges:
http-01 challenge for www.gnuadm.in
Waiting for verification...
Cleaning up challenges
Created an SSL vhost at /etc/httpd/sites-available/gnuadm.in-le-ssl.conf
Could not find ssl_module; not installing certificate.

IMPORTANT NOTES:
 - Unable to install the certificate
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/gnuadm.in/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/gnuadm.in/privkey.pem
   Your cert will expire on 2021-03-18. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot again
   with the "certonly" option. To non-interactively renew *all* of
   your certificates, run "certbot renew"

Peki bunca şey ne içindi?

CentOS 7 Apache Web Server üzerinde ücretsiz Let's Encrypt SSL sertifikası
CentOS 7 Apache Web Server üzerinde ücretsiz Let’s Encrypt SSL sertifikası

Bence çalıştı 🙂

Şimdi web sitemize giren kişiler “HTTPS” protokolü ile gelebilir. Burası tamam. Bazı browser eklentileri, https’i zorluyor. Burası da tamam. Fakat biz yine de her türlü HTTP istedğini HTTPS’e yönlendirelim. Virtual Host’umuzun konfigürasyonuna ufak bir ekleme yapıp bu işi yapalım derken bir de ne görüyoruz:

[root@icecast ~]# cat /etc/httpd/sites-available/gnuadm.in.conf
<VirtualHost *:80>
    ServerName www.gnuadm.in
    ServerAlias gnuadm.in
    DocumentRoot /var/www/gnuadm.in/html
    ErrorLog /var/www/gnuadm.in/log/error.log
    CustomLog /var/www/gnuadm.in/log/requests.log combined
RewriteEngine on
RewriteCond %{SERVER_NAME} =gnuadm.in [OR]
RewriteCond %{SERVER_NAME} =www.gnuadm.in
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
[root@icecast ~]# cat /etc/httpd/sites-available/gnuadm.in-le-ssl.conf
<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerName www.gnuadm.in
    ServerAlias gnuadm.in
    DocumentRoot /var/www/gnuadm.in/html
    ErrorLog /var/www/gnuadm.in/log/error.log
    CustomLog /var/www/gnuadm.in/log/requests.log combined

Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/gnuadm.in/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/gnuadm.in/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/gnuadm.in/chain.pem
</VirtualHost>
</IfModule>

Yaptığımız Virtual Host konfigürasyonu değiştirilmiş. Apache Rewrite modülü sayesinde gelen bütün talepler https://’li adrese yönlendirilmiş. Ayrıca yeni bir konfigürasyon dosyası oluşturulmuş ve bu dosya da bizim Virtual Host dosyasına aşırı benziyor. Dikkat ederseniz 80 değil, 443’ü dinliyor.

Peki sertifikamızın süresi dolduğunda ne olacak? Bir Let’s Encrypt yenilemesi yapmamız gerekiyor. Şimdi bunun üzerinde çalışalım. Önce, bu sertifikayı yenileyip yenileyemeyeceğimizi test edeceğiz. Fakat gerçekten yenilemek istemiyoruz, sadece test etmek istiyoruz. İkinci olarak, bu iş için “certbot”un bir zamanlanmış görevi olup olmadığını kontrol ediyoruz. Certbot dokümantasyonuna göre zamanlanmış görevi arıyorsak şuralara bakmalıyız:

 The command to renew certbot is installed in one of the following locations:

    /etc/crontab/
    /etc/cron.*/*
    systemctl list-timers
[root@icecast ~]# certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/gnuadm.in.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator apache, Installer apache
Simulating renewal of an existing certificate for gnuadm.in and www.gnuadm.in
Performing the following challenges:
http-01 challenge for gnuadm.in
http-01 challenge for www.gnuadm.in
Waiting for verification...
Cleaning up challenges

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
new certificate deployed with reload of apache server; fullchain is
/etc/letsencrypt/live/gnuadm.in/fullchain.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates below have not been saved.)

Congratulations, all renewals succeeded. The following certs have been renewed:
  /etc/letsencrypt/live/gnuadm.in/fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates above have not been saved.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[root@icecast ~]# systemctl list-timers
NEXT                         LEFT          LAST                         PASSED    UNIT
Fri 2020-12-18 16:06:00 UTC  3h 2min left  Fri 2020-12-18 04:25:02 UTC  8h ago    snap.certbot.renew.t

1 timers listed.
Pass --all to see loaded but inactive timers, too.

Sonuç Olarak

Web’i daha güvenli hâle getirmek için kriptografik algoritmalar hayati önem taşıyor. Let’s Encrypt gibi ücretsiz SSL çözümleri de bütün web’in bir şekilde HTTPS’e yönelmesini destekliyor. Ücretli ve ücretsiz SSL sertifikaları arasında bir fark var mıdır, bunu detaylı olarak bilemiyorum. Fakat Let’s Encrypt’in büyük patladığı bir habere denk gelmedim.

Eğer bu dokümanı takip ederken bazı sıkıntılarla karşılaşırsanız; bunlar çok yüksek ihtimalle DNS kayıtlarınızın eksik, hatalı veya henüz güncellenmemiş olmasından kaynaklı hatalar olacak.

Bağlantılar

1- About Let’s Encrypt, https://letsencrypt.org/about/

2- About Internet Security Research Group, https://www.abetterinternet.org/about/

3- Diffie-Hellman key exchange, https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

4- Public key certificate, https://en.wikipedia.org/wiki/Public_key_certificate

5- Automatic Certificate Management Environment (ACME), https://tools.ietf.org/html/rfc8555

6- How It Works, https://letsencrypt.org/how-it-works/

7- How To Install the Apache Web Server on CentOS 7, https://www.digitalocean.com/community/tutorials/how-to-install-the-apache-web-server-on-centos-7

8- Installing snap on CentOS, https://snapcraft.io/docs/installing-snap-on-centos

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir