HTTPS + Linode NodeBalancer'ı Şifreleyelim

Açıkçası, Let's Encrypt muhtemelen dilimlenmiş ekmekten bu yana en iyi şeydir ve açık kaynak araçlarıyla ücretsiz bir SSL/TLS sertifikası ve söz konusu sertifikayı kalıcı olarak oluşturmak ve otomatik olarak yenilemek için bir API almanızı sağlar.

Standart belgeler de dahil olmak üzere Let's Encrypt'i kullanmaya başlamak için zaten çok sayıda kılavuz var ve Brad başka bir makalede Let's Encrypt tarafından ne kadar heyecanlı olduğundan bahsetmişti. Ancak bugün, bir yan proje için ihtiyaç duyduğum çok özel bir şeye bakacağız: Linode NodeBalancer ile Let's Encrypt sertifikası kullanmak.

Güncellendi 2017-02-22

Bu makale başlangıçta letsencrypt-auto beta sürümündeyken yazılmıştır, şimdi bunun yerine artık standart Certbot aracına başvurmak için hafif bir güncelleme yapılmıştır.

Her şey yine de çalışmalıdır, ancak sertifika yenileme komutları, certonly yerine renew eylemi kullanılarak biraz kısaltılabilir.

HTTPS + Düğüm Dengeleme

Başarılı bir web siteniz veya hizmetiniz olduğunda, iş yükünün üstesinden gelmek için trafiğinizi birden çok sunucuya bölmeniz gereken bir noktaya gelme ihtimaliniz vardır. Yalnızca sunucu arızalarına karşı koruma sağlamak için birden fazla web sunucusu kullanma konusunda söylenecek çok şey var. Bu nedenle, bir düğüm dengeleyici genellikle gelen internet trafiğini kabul etmek ve onu yeni isteği en iyi şekilde işleyebilecek arka uç sunucusuna hızlı bir şekilde iletmek için kullanılır ve istemci ile sunucu arasında ileri geri sıralanır.

Bir veya daha fazla web sunucusunun önünde düğüm dengeleyici kullanırken bir HTTPS isteğini işlemenin iki yaygın yolu vardır. HTTPS isteğini düğüm dengeleyicinin arkasındaki web sunucularına iletirsiniz veya isteği düğüm dengeleyicide sonlandırıp istek üzerine HTTP olarak arka uç sunucularına iletirsiniz.

Her iki yöntemin de artıları ve eksileri vardır. Örneğin, çok yüksek hacimli güvenli trafikte, bu tür cihazlar genellikle şifre çözme ve şifreleme iş yükünü kaldıracak kadar güçlü olmadığından düğüm dengeleyicide sonlandırma sorunlu olabilir, bu nedenle HTTPS trafiğini web sunucularına iletmek daha iyidir. Tersine, Let's Encrypt sertifikalarının 90 günlük nispeten kısa bir ömrü olduğundan, birçok web sunucunuzun otomatik olarak yenilenen sertifikalarla düzgün şekilde yapılandırıldığından emin olmak, tek bir veya yalnızca birkaç düğüm dengeleyiciyi güncellemeye kıyasla zahmetli olabilir.

İlk olarak, bir web sunucusunda HTTPS kurmaya alışkınsanız, biraz daha kolay olduğu için, düğüm dengeleyicide HTTPS için bir TCP geçiş yapılandırması kurmayı tartışacağız ve ardından HTTPS sonlandırmasını nasıl kuracağımızı göreceğiz. bir Linode NodeBalancer ve nispeten kısa süreli Let's Encrypt sertifikası yenilendiğinde sertifikasını güncel tutun.

TCP Geçişi

Bir Linode NodeBalancer üzerinde HTTPS trafiğini kabul edecek bir konfigürasyon ayarlamak normalde konfigürasyona bir sertifika eklemenizi gerektirdiğinden, ancak bu yöntemle arka uç web sunucularının HTTPS isteğini sonlandırmasını istiyoruz, bunun yerine üzerinde bir konfigürasyon ayarlamamız gerekiyor. TCP protokolünü ve 443 numaralı bağlantı noktasını kullanan düğüm dengeleyici.

Yukarıdaki ekran görüntüsünde bir TCP yapılandırması için temel kurulumu göreceksiniz:

Liman: 443

Protokol: TCP

Algoritma: En Az Bağlantılar (benim seçimim, Round Robin veya Source IP olabilir)

Oturum Yapışkanlığı: Tablo (benim seçimim, Yok veya HTTP Çerez olabilir)

“Aktif Sağlık Kontrolü” bölümü için Kontrol Aralığı, Zaman Aşımı ve Denemeler için varsayılanlara bağlı kaldım, ancak özellikle Sağlık Kontrolü Türü olarak “TCP Bağlantısı” kullanıyorum çünkü daha sonra orada bir HTTP olmasına güvenmem gerekmiyor arka uçtaki sunucu. İstersem sadece HTTPS kullanabilirim.

Ayrıca Linode NodeBalancer yapılandırmamın ekran görüntüsünde zaten bir düğüm eklediğimi göreceksiniz: “apps2”, Let's Encrypt sertifikası sağlamak ve kullanmak için yapılandıracağımız Debian 8.x tabanlı sunucudur.

Let's Encrypt sertifikasının kurulumunu kolaylaştırmak için, sertifikada birincil alan olarak kullanacağınız aynı alan adından HTTP istekleri sunabilmek önemlidir, bu yüzden " apps2” bir düğüm olarak.

Let's Encrypt'i Ayarlama

Daha önce de belirtildiği gibi, Let's Encrypt sertifikasını kullanmak için bir web sunucusunun nasıl kurulacağına dair birçok makale var, bu yüzden burada çok fazla ayrıntıya girmeyeceğim. Let's Encrypt'i le.ianmjones.com'a geçerli bir sertifikadan hizmet vermek için kullanabileceğimden emin olmak için yaptığım incelik burada.

1. DNS'imde le.ianmjones.com'u düğüm dengeleyicimin IP adresine yönlendirmek için bir alt alan girişi oluşturuldu.
2. http://le.ianmjones.com'a hizmet vermek için çalışan bir sanal ana bilgisayarım olduğundan emin oldum
3. sudo su - kök kullanıcı olduğumdan emin olmak için (Let's Encrypt'in /etc dizinine ve web kökünüze yazması gerekiyor).
4. apt-get install letsencrypt
5. letsencrypt certonly --webroot -w /var/www/le.ianmjones.com/ \
-d le.ianmjones.com --staging

Let's Encrypt aracı ve tüm bağımlılıkları yüklendikten sonra, ilk çalıştırma, hizmetle oluşturduğu hesapla ilişkilendirilecek bir e-posta adresi istemek gibi bir sertifika imzalama isteği oluşturmak için sorular sordu. Gerçek bir e-posta adresi belirlemek önemlidir, çünkü sertifikanızı yenilemeden önce geçerlilik süresinin dolmasına izin verirseniz, hatırlatıcılar bu adrese gönderilir. letsencrypt aracı yalnızca Debian için değildir, birçok Linux dağıtımında, FreeBSD ve OpenBSD'de çalışır, sürekli olarak ek platformlar üzerinde çalışılmaktadır.

letsencrypt aracını kullanırken certonly ve --webroot , bu, daha sonra başka bir yerde kullanabileceğim bir sertifikanın oluşturulmasını sağlamak ve Let's Encrypt'e kontrolün bende olduğunu doğrulamak için webroot yöntemini kullanmasını söylemek içindi. etki alanı. Bu parametre kombinasyonunu kullandığınızda, letsencrypt , -w bayrağıyla belirttiğiniz web kökü altında oluşturduğu bir .well-known/acme-challenge/ dizinine rasgele adlandırılmış bir dosya bırakır ve Let's Encrypt hizmetinden bunu kontrol etmesini ister. etki alanından erişilebilir olduğunu onaylayın. Bu yüzden en azından ilk başta le.ianmjones.com etki alanı için çalışan bir HTTP sunucusuna ihtiyacım vardı.

Ayrıca --apache veya diğer web sunucusuna özel sağlama yöntemleri yerine certonly yöntemini kullanmamız gerekiyor. Uygun olmalarına rağmen, daha sonra bu sertifikaları düğüm dengeleyici sonlandırma yöntemimizle farklı bir şekilde kullanmak istiyoruz (ben ileriyi düşünüyorum).

--staging parametresini kullandığımı fark edeceksiniz. Bunun nedeni, sertifikalarınızı ilk kez ayarlarken yapılandırmanızla ilgili sorunlarla karşılaşmanız ve her şeyi düzgün bir şekilde çalıştığından emin olana kadar bir şeyleri düzeltmeniz ve letsencrypt birden çok kez çalıştırmanız gerekmesidir. Canlı Let's Encrypt sunucusunun, düzensiz süreçlerle kötüye kullanımı durdurmak için oldukça düşük oran sınırları vardır (yazma sırasında her hafta kamuya açık alan başına yalnızca 5 sertifika verilir veya yenilenir) ve ararsanız birkaç saat hatta günlerce sizin için çalışmayı reddeder. çok sık. Hazırlama sunucusunun çok daha yüksek sınırları vardır ve bu nedenle ilk kurulum sırasında kullanılmalıdır.

letsencrypt çalıştırıldığında ve Tamam ile geri geldiğinde, Apache web sunucumu yapılandırmak için ihtiyacım olan her şey /etc/letsencrypt dizini altındaydı. Apache'yi yapılandırmak için benim için en önemli dosyalar /etc/letsencrypt/live/le.ianmjones.com/ :

 [email protected]:/etc/letsencrypt# ls -l live/le.ianmjones.com/ total 0 lrwxrwxrwx 1 root root 40 Jan 29 00:23 cert.pem -> ../../archive/le.ianmjones.com/cert3.pem lrwxrwxrwx 1 root root 41 Jan 29 00:23 chain.pem -> ../../archive/le.ianmjones.com/chain3.pem lrwxrwxrwx 1 root root 45 Jan 29 00:23 fullchain.pem -> ../../archive/le.ianmjones.com/fullchain3.pem lrwxrwxrwx 1 root root 43 Jan 29 00:23 privkey.pem -> ../../archive/le.ianmjones.com/privkey3.pem

live/le.ianmjones.com bir archive dizinindeki gerçek dosyalara sembolik bağlantılar içerdiğini ve bağlantılı dosyaların hepsinin adında 3 olduğunu fark edeceksiniz. Bu, sertifika dosyalarınızı yenilediğinizde sembolik bağların otomatik olarak yeni sürümleri gösterecek şekilde güncellendiği ve böylece web sunucusu yapılandırmalarınızda aynı dosyalara başvurmaya devam edebileceğiniz anlamına gelen temiz bir mekanizmadır. Bu durumda, --staging bayrağıyla birkaç test yaptıktan sonra, o bayrağı kaldırdım ve canlı hizmete karşı letsencrypt çalıştırdım.

 letsencrypt certonly --webroot -w /var/www/le.ianmjones.com/ -d le.ianmjones.com

Apache sanal ana bilgisayarını le.ianmjones.com'dan HTTPS sunmak üzere ayarlamak için sırasıyla SSLCertificateFile , SSLCertificateChainFile ve SSLCertificateKeyFile yönergelerinin değerleri olarak cert.pem , chain.pem ve privkey.pem dosya yollarını kullandım. Aşağıdakiler /etc/apache2/sites-available/le.ianmjones.com.conf adresindeki tam sanal ana bilgisayar yapılandırma /etc/apache2/sites-available/le.ianmjones.com.conf ve a2ensite le.ianmjones.com tarafından etkinleştirilmiştir:

 <VirtualHost *:443> ServerName le.ianmjones.com ServerAdmin [email protected] DocumentRoot /var/www/le.ianmjones.com DirectoryIndex index.html index.php SSLEngine On SSLCertificateKeyFile /etc/letsencrypt/live/le.ianmjones.com/privkey.pem SSLCertificateFile /etc/letsencrypt/live/le.ianmjones.com/cert.pem SSLCertificateChainFile /etc/letsencrypt/live/le.ianmjones.com/chain.pem ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined <Directory /var/www/le.ianmjones.com> AllowOverride All </Directory> </VirtualHost> <VirtualHost *> ServerName le.ianmjones.com ServerAdmin [email protected] DocumentRoot /var/www/le.ianmjones.com DirectoryIndex index.html index.php ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined <Directory /var/www/le.ianmjones.com> AllowOverride All </Directory> </VirtualHost> # vim: syntax=apache ts=4 sw=4 sts=4 sr noet

Bu noktada, bir Linode NodeBalancer'ın arkasından sunulan Let's Encrypt sertifikasına sahip çalışan bir https://le.ianmjones.com vardı.

Sertifika Otomatik Yenileme

Takip ettiyseniz ve birkaç kez letsencrypt çalıştırmayı denediyseniz, her seferinde soru sorduğunu fark etmişsinizdir. Sertifikanızın otomatik olarak yenilenmesini ayarlamaya çalışıyorsanız, bu bir sorun olacaktır.

Neyse ki, tüm yapmak istediğinizi belirtmek için kullanabileceğiniz bir renew-by-default parametresi var ve verilen etki alanlarını en son yapılandırdığınızdan bu yana hiçbir şey değişmedi. Let's Encrypt, /etc/letsencrypt/renewal içindeki ilgili dosyadan ihtiyaç duyduğu her şeyi alacaktır. Soru sorulmaması için -n (etkileşimli olmayan) işaretini, her şeyi yolunda tutmak için --agree-tos ve -m [email protected] ile birlikte kullanabilirsiniz.

Bir kenara, çok daha iyi olması gereken yeni bir letsencrypt renew komutu yolda. Önümüzdeki 30 gün içinde hangi sertifikaların yenilenmek üzere olduğunu kontrol edecek ve sadece onları yenileyecek Hangi alan adlarının ve doğrulama yöntemlerinin kullanılacağının söylenmesine gerek kalmayacak.

Sertifikayı haftada bir kez yenilemek için cronumu ayarlamadan önce, çalıştırılacak küçük bir kabuk betiği oluşturdum, ardından test ettim ve Apache'yi zarif bir şekilde yeniden başlattım ( apache2ctl graceful ile).

Apache'nin yeniden başlatılmasından sonra sitedeki sertifika yeni sona erme tarihini yansıtıyordu.

Yapılması gereken tek şey crontab -e ve betiğin haftalık çalışmasını eklemekti (daha iyi bir yönetici /etc/cron.weekly/ bir şeyler ekleyebilir).

 5 5 * * 1 /root/renew_lets_encrypt.sh && /usr/sbin/apache2ctl graceful

Let's Encrypt hız sınırları konusunda çok dikkatli olmak istiyorsanız, cron işinizi bunun yerine ayda bir, belki ayda iki kez çalışacak şekilde ayarlamanızı öneririm. Let's Encrypt sertifikalarımı haftada bir yenilemeye başlamamın tek nedeni, Let's Encrypt beta aşamasındaki geri bildirim döngüsünün çok uzun olmamasını sağlamaktı.

Ayrıca elbette geçici olarak crontab'ıma yinelenen bir giriş ekledim, ancak gelecekte sadece birkaç dakika sonra ve daha sonra Apache'nin beklenen zamanda yeniden başlatıldığını ve SSL sertifikamın yeni bir son kullanma tarihi ve saati ile güncellendiğini kontrol ettim. . Bu, cron'un betiği çalıştırdığı ortamın herhangi bir sorun yaşamamasını sağladı.

Bu yöntemin tercih ettiğiniz web sunucusuna uyarlanması çok kolay ve yeni sertifika dosyalarını scp , rsync , ansible ve kardeşleri aracılığıyla veya yapılandırma dosyalarını paylaşarak diğer sunucularınıza göndermeniz için genişletmesi kolay olacaktır. GlusterFS aracılığıyla. Zaten bir grup düğüm dengeli web sunucusu kurduysanız, yapılandırma dosyalarını eşitlemek için tercih ettiğiniz yönteme sahip olmanız gerekir.

NodeBalancer, HTTPS'yi Sonlandırdı

HTTPS şifre çözme/şifreleme işlemlerini gerçekleştiren ve yenilenen Let's Encrypt sertifikasıyla otomatik olarak güncellenen bir Linode NodeBalancer kurmak için önce yeni NodeBalancer bağlantı noktası yapılandırmasını manuel olarak kurdum.

443 numaralı bağlantı noktası trafiğini işleyen bir yapılandırmayla zaten kurduğum HTTPS'yi işlemek için aynı Linode NodeBalancer'ı kullanmak istediğim için, önce bu yapılandırmayı kaldırdım ve yeni bir HTTPS yapılandırması ekledim.

Yukarıdaki ekran görüntüsünde iki yeni büyük alan göreceksiniz, SSL Sertifikası ve Özel Anahtar , bunlar NodeBalancer'ın HTTPS protokolünü işleyebilmesi için gereklidir. Sunucumu Let's Encrypt'ten bir sertifika alacak şekilde kurmuş olduğum ve iki yeni alan için mükemmel eşleşmeler olan hem fullchain.pem hem de privkey.pem sağladıkları için, içeriklerini bu iki alana kopyaladım ve kaydettim .

 [email protected]:/etc/letsencrypt/live/le.ianmjones.com# cat fullchain.pem ... [email protected]:/etc/letsencrypt/live/le.ianmjones.com# cat privkey.pem

Bundan sonra, HTTPS/port 443 trafiği artık NodeBalancer'da sonlandırılırken bağlantı olarak 80 numaralı bağlantı noktasını kullanarak web sunucu düğümüme ekleme meselesiydi.

Bu noktada, Let's Encrypt'ten en son yenilediğim SSL sertifikasını kullanarak Linode NodeBalancer üzerinde çalışan bir HTTPS yapılandırmasına sahiptim.

NodeBalancer Sertifikasını Güncelleme

Daha önce, web sunucumu sertifikasını her hafta otomatik olarak yenileyecek şekilde ayarladım. Artık sertifikamı NodeBalancer'da kullanmaya geçtiğime göre, NodeBalancer'ı güncellemesi için yenileme sürecini uzatmam gerekiyor.

Linode, yalnızca sunucularınız (Linodes) değil, NodeBalancer'lar da dahil olmak üzere hesabınızı yönetmek için harika bir API'ye sahiptir.

İlk başta, önerilen PHP kitaplığı güncel olmadığı ve bir NodeBalancer'da HTTPS kurmayı işlemediği için ham API'yi PHP cURL ile kullanmayı amaçladım. Çeşitli API çağrılarını test etmek için harika Paw uygulamasını kullandım ve PHP cURL kod oluşturma uzantısını kullanarak bazı örnek PHP'leri gördüm.

Bu işe yaradı, ancak kullanıcı adlarını, şifreleri ve API anahtarlarını depolamak ve ardından güncellemek için yapılandırmayı seçmek ve ardından verileri içine yerleştirmek için gereken çağrı akışını idare etmekle uğraşacağım anlamına geliyordu, düzgün kodlanmış vb. roket bilimi, PHP geliştiricileri olarak her gün bunun çoğunu yapıyoruz, ama, bleh.

Sonra Linode CLI'yi kontrol ettim ve düşük ve ihtiyacım olan her şeye sahip olduğunu ve basit bir şekilde kurulduğunu gördüm:

 # apt-get install linode-cli # linode configure 

Yeni bir renew_lets_encrypt.sh kabuk betiği doğdu, yoksa bu bourne mu?

 #!/bin/bash if [ ! -d letsencrypt ] then git clone https://github.com/letsencrypt/letsencrypt fi if [ ! -d letsencrypt ] then echo "Could not find letsencrypt directory, exiting." exit 1 fi cd letsencrypt # le.ianmjones.com letsencrypt certonly --webroot --renew-by-default -w /var/www/le.ianmjones.com/ -d le.ianmjones.com EXIT_STATUS=$? if [ $EXIT_STATUS -ne 0 ] then exit $EXIT_STATUS fi /usr/bin/linode nodebalancer config-update --label apps --port 443 --ssl-cert /etc/letsencrypt/live/le.ianmjones.com/fullchain.pem --ssl-key /etc/letsencrypt/live/le.ianmjones.com/privkey.pem exit $?

Bu, NodeBalancer "uygulamalarının" 443 numaralı bağlantı noktası yapılandırmasını yeni bir SSL sertifikası ve özel anahtarla güncellemek için betiğime etkili bir şekilde tek bir satır ekledi. Tüm kimlik doğrulama daha önce linode configure kullanılarak gerçekleştiriliyordu, bu nedenle bu komut herhangi bir kullanıcı ayrıntısı veya API anahtarı girilmesine gerek kalmadan çalıştırılabilir.

Geriye kalan tek şey, 443 numaralı bağlantı noktası için tüm Apache sanal ana bilgisayar yapılandırmalarımızı kaldırmak ve ayrıca yeni SSL sertifikalarını almak için Apache'yi yeniden yüklememiz gerekmediği için cron girişinden && apache2ctl graceful kaldırmaktır.

 5 5 * * 1 /root/renew_lets_encrypt.sh

Ve bununla birlikte, Linode NodeBalancer'ıma otomatik olarak yenilenen Let's Encrypt sertifikalarım gönderildi.

Alan Ekleme

HTTPS kurulumuma lex.ianmjones.com eklemek istersem ne olur?

Sanal sunucum zaten HTTP için ayarlanmışken, tek yapmam gereken yeni etki alanını ve letsencrypt komutumun sonuna eklemekti. Let's Encrypt, sertifikayı fazladan etki alanlarını içerecek şekilde genişletmeyi düşündüğünüzü onaylamak isteyeceğinden, ilk kez --renew-by-default bayrağı olmadan çalıştırmak en iyisidir.

 [email protected]:~# ./letsencrypt certonly --webroot -w /var/www/le.ianmjones.com/ -d le.ianmjones.com -w /var/www/lex.ianmjones.com/ -d lex.ianmjones.com

Yenileme komut dosyasının yeni web kökü ve etki alanı ile güncellendiğinden emin olun ve ardından, haftalık çok sınırlı sertifika sorunlarınızdan başka birini kullanmaktan memnun değilseniz, düğüm dengeleyiciyi güncellemek için komutu manuel olarak çalıştırın.

 [email protected]:~# linode nodebalancer config-update --label apps --port 443 --ssl-cert /etc/letsencrypt/live/le.ianmjones.com/fullchain.pem --ssl-key /etc/letsencrypt/live/le.ianmjones.com/privkey.pem Updated NodeBalancer config apps 443

lex.ianmjones.com'daki sertifika, değişiklikleri yansıtır.

basit şeyler

Orada çok fazla kelime yazdım, ancak renew_lets_encrypt.sh betiğine baktığınızda her şey oldukça basit, doğru parametrelerle sadece birkaç CLI çağrısı. letsencrypt ve linode gibi komut satırı araçları görevlerimizi çok daha basit hale getiriyor.

Farkı yaratan hazırlıktır, sertifika almak için hangi alan adlarına ihtiyacınız olduğunu önceden bilmek, sertifika talep etme sayısını en aza indirmenize yardımcı olacaktır (mevcut Let's Encrypt beta sürümünde büyük bir sorun). Baştan itibaren düğüm dengeleyicide HTTPS kullanmaya karar verirseniz, web sunucunuzda HTTPS kurmak ve 443 numaralı TCP bağlantı noktasını geçmekle uğraşmanıza bile gerek kalmaz.

Artık düğüm dengeleyicinizin HTTPS yapılandırmasına web sunucusu düğümlerini neşeyle ekleyebilirsiniz ve sertifikaları yapılandırma konusunda endişelenmenize gerek yoktur.

Henüz Let's Encrypt ile oynadınız mı? Linode API'si ve CLI'si ne durumda? Aşağıdaki yorumlarda sahip olabileceğiniz ipuçlarını görmek isteriz.