HPE Morpheus yönetim arayüzü HTTPS üzerinden sunulsa da ilk kurulumda veya sertifika yenileme dönemlerinde tarayıcı ve API istemcileri sertifikaya güvenmeyebilir. Bunun nedeni kendinden imzalı (self-signed) sertifika, sunucu adı ile sertifika kapsamı arasındaki uyuşmazlık, süresi dolmuş sertifika ya da eksik bir ara sertifika zinciri olabilir.

Kalıcı çözüm kullanıcıların eriştiği FQDN için geçerli bir sertifikanın doğru özel anahtarla birlikte HTTPS trafiğini sonlandıran katmanda sunulmasıdır.

Bu makalede TLS’in Morpheus üzerinde çalışan yerleşik NGINX bileşeninde sonlandırılmaktadır. Sertifika dosyaları /etc/morpheus/ssl dizinine aktarılır /etc/morpheus/morpheus.rb içerisindeki NGINX parametreleri güncellenir. morpheus-ctl reconfigure ile yapılandırma uygulanır ve NGINX yenilenir. Başarı değerlendirmesi yalnızca komut çıktısına değil gerçek HTTPS bağlantısında sunulan sertifika ve uygulama erişimine dayanır.

İlk olarak Morpheus arayüzünün sertifika değişikliği öncesindeki durumu kayıt altına alınır. Örnek ortamda tarayıcı üzerinden yapılan erişimde güven uyarısı bulunmakta ve sertifika ayrıntıları görüntülenmektedir. Bu ekran değişiklik tamamlandıktan sonra elde edilecek sonuçla karşılaştırma yapmak için başlangıç noktası oluşturur.

Tarayıcıdaki “Güvenli değil / Not secure” ifadesi tek başına bağlantının şifrelenmediği anlamına gelmez. Client sistem şifreli bir HTTPS oturumu kurabilse de sunulan sertifikanın kimliğini veya güven zincirini doğrulayamayabilir.

Bu nedenle hedef yalnızca uyarıyı kaldırmak değil; doğru FQDN için geçerli, güvenilir ve özel anahtarıyla eşleşen sertifikanın sunulmasını sağlamaktır.

Sertifika değişikliği Morpheus yönetim arayüzüne erişimi kısa süreli etkileyebileceğinden kontrollü bir bakım işlemi olarak ele alınmalıdır. Öncelikle kullanılacak kurumsal erişim adresi belirlenir sertifika dosyaları doğrulanır ve mevcut yapılandırmanın geri yüklenebileceğinden emin olunur. Bu hazırlıklar özellikle birden fazla erişim katmanı bulunan ortamlarda yanlış sertifika üzerinde işlem yapılmasını önler.

Kontrol alanı	İşleme başlamadan önce doğrulanacak bilgi
Yönetim erişimi	Sunucuda root veya gerekli sudo yetkileri; gerekirse konsol üzerinden erişim.
Kurumsal FQDN ve DNS	Örneğin morpheus.ornek.com.tr adresinin hedef IP’ye çözülmesi ve kullanılacak sertifikanın SAN alanında yer alması.
Sertifika dosyaları	Sunucu sertifikası (.crt), ilgili özel anahtar (.key) ve gerekiyorsa ara sertifika zincirinin temin edilmiş olması.
Mevcut durum ve yedek	/etc/morpheus/morpheus.rb dosyasının yedeği ve mevcut sertifika dosyalarının korunması.
Bakım penceresi	Yapılandırmanın yeniden uygulanması ve NGINX yeniden başlatılması için uygun zaman planı.
TLS sonlandırma noktası	HTTPS’in doğrudan Morpheus NGINX üzerinde mi, yoksa WAF/yük dengeleyicide mi sonlandırıldığının belirlenmesi.

WAF veya yük dengeleyici istemciyle kurulan TLS oturumunu sonlandırıyorsa tarayıcıda görülen sertifika o cihazdan sunuluyor olabilir. Bu makalenin uygulama komutları Morpheus NGINX sertifikasını değiştirir çevre cihazlardaki sertifikaları otomatik olarak değiştirmez.

Bu çalışmada kullanılacak dosyalar Sectigo tarafından sağlanan sertifika paketi içerisinden seçilmiştir. Pakette sunucu sertifikasıyla birlikte kök (root) veya ara sertifika otoritelerine ait ek .crt dosyaları bulunabilir. Sunucuya tanıtılacak temel iki bileşen doğru alan adını kapsayan sertifika ve bu sertifikaya ait özel anahtardır.

Dosya adlarındaki STAR ifadesi örnek ortamda wildcard sertifika kullanıldığını göstermektedir. Bir wildcard sertifika yalnızca sertifikanın gerçekten kapsadığı alt alan adları için geçerlidir. Bu nedenle dosya adının benzer olması yeterli kabul edilmemeli sertifikanın Subject Alternative Name (SAN) ve geçerlilik bilgileri incelenmelidir.

Bu sertifika dosyaları Morpheus sunucusuna kopyalanmadan önce veya kopyalandıktan sonra OpenSSL yardımıyla sertifikanın hangi alan adlarını kapsadığı hangi sertifika otoritesi tarafından verildiği ve hangi tarihler arasında geçerli olduğu kontrol edilebilir. Aşağıdaki komut, kaynaktaki akışa eklenen önerilen doğrulama adımıdır:

openssl x509 -in STAR_ornek_com_tr.crt -noout \
  -subject -issuer -dates -ext subjectAltName

Çıktıda ilgili FQDN adresinin bulunması sertifika tarih aralığının geçerli olması ve beklenen sertifika otoritesinin görünmesi beklenir. Sertifika paketindeki ara CA belgelerinin nasıl kullanılacağı kurumsal CA zinciri gereksinimine ve sertifika sağlayıcısının yönergelerine göre ayrıca değerlendirilmelidir.

Burada sadece .crt ve .key dosyalarını kopyalamak, her ortamda eksiksiz bir güven zinciri oluşturulacağını garanti etmez.

Sertifika ile özel anahtarın (pkey) birbirine ait olmaması durumunda web sunucusu yeni sertifikayı etkinleştiremeyebilir. Eşleşme özel anahtarın kendisini ekrana yazdırmadan iki dosyanın açık anahtar özetleri karşılaştırılarak kontrol edilebilir. Aşağıdaki iki komutun ürettiği özet değerler aynı olmalıdır (ek operasyonel kontrol);

openssl x509 -in STAR_ornek_com_tr.crt -pubkey -noout | openssl sha256
openssl pkey -in STAR_ornek_com_tr.key -pubout | openssl sha256

Sertifika paketi doğrulandıktan sonra sunucu sertifikası ve özel anahtar Morpheus sunucusundaki /etc/morpheus/ssl dizinine kopyalanır. Bu dizin kaynak ortamda uygulamanın mevcut sertifika dosyalarının bulunduğu konumdur.

Dosya aktarımı öncesinde mevcut dizin içeriğini görüntülemek, yanlış dosya üzerine yazma riskini azaltır ve geri dönüş için gerekli eski dosyaları belirlemeyi kolaylaştırır.

sudo ls -lah /etc/morpheus/ssl/

Dosyalar güvenli bir yöntemle sunucuya ulaştırılır ve ilgili dizine alınır. Aşağıdaki örnekte dosyaların yönetici (root) hesabının erişebildiği bir hazırlık dizininde bulunduğunu varsayar gerçek dosya yolları ortamınıza göre değiştirilmelidir. Mevcut sertifikaları silmek ya da aynı adla üzerine yazmak yerine yeni dosyaları ayrı adla tutmak, değişiklik sırasında karşılaştırma yapmayı kolaylaştırır.

Kaynak çalışmada yeni dosyalar ilk aktarım sırasında sysadmin hesabı üzerinden görünmektedir. Sistem üzerindeki mevcut sertifika dosyalarıyla tutarlılık sağlamak amacıyla sahiplik root:root olarak ayarlanır ve her iki dosyaya 640 izni verilir. 640 izni dosya sahibine okuma ve yazma, aynı gruptaki kullanıcılara yalnızca okuma yetkisi tanırken diğer kullanıcıların erişimini kapatır.

sudo chown root:root /etc/morpheus/ssl/STAR_ornek_com_tr.crt
sudo chown root:root /etc/morpheus/ssl/STAR_ornek_com_tr.key
sudo chmod 640 /etc/morpheus/ssl/STAR_ornek_com_tr.crt
sudo chmod 640 /etc/morpheus/ssl/STAR_ornek_com_tr.key
sudo ls -l /etc/morpheus/ssl/STAR_ornek_com_tr.*

Son komutla dosya sahibinin ve grubunun root olduğu, izin bilgisinin -rw-r—– biçiminde göründüğü kontrol edilir. Bu örnek izin düzeni sağlanan uygulama kaydındaki ayarlarla uyumludur. Ortamınızda servis hesabı veya güvenlik politikası farklıysa dosya erişiminin ilgili servis tarafından mümkün olduğundan ayrıca emin olunmalıdır.

Yeni sertifika dosyalarının dizine kopyalanması tek başına yeterli değildir. Morpheus’un yerleşik NGINX bileşenine HTTPS bağlantılarında hangi sertifika ve özel anahtar dosyalarını kullanacağı ayrıca bildirilmelidir. Bu tanımlar /etc/morpheus/morpheus.rb dosyasında yapılır. İşleme başlamadan önce yapılandırma dosyasının zaman damgalı bir yedeğini almak önerilir.

sudo cp -a /etc/morpheus/morpheus.rb etc/morpheus/morpheus.rb.pre-ssl-change.bak
sudo vi /etc/morpheus/morpheus.rb

appliance_url: Erişim adresinin doğrulanması !!!

Önce appliance_url parametresine bakılır. Bu parametre kullanıcıların Morpheus yönetim arayüzüne erişmek için kullandığı URL’yi ifade eder.

Kaynak ortamda başlangıçta .local uzantılı bir ad bulunmaktadır. Kurumsal SSL sertifikası ise genel DNS’de kullanılan alan adı için düzenlendiğinden appliance_url değeri ilgili kurumsal HTTPS adresiyle uyumlu olacak şekilde değiştirilmiştir.

Örneğin istemciler https://morpheus.ornek.com.tr adresi üzerinden bağlanacaksa yapılandırmada da aynı FQDN kullanılmalıdır.

Bu adresin DNS kaydının doğru çözümlenmesi ve sertifikanın kapsadığı alan adları içinde yer alması gerekir. appliance_url zaten doğru adresi gösteriyorsa yalnızca sertifika değiştirmek için bu parametreyi yeniden düzenlemek gerekli olmayabilir.

Aynı dosyada nginx[‘ssl_certificate’] parametresi sertifika dosyasının nginx[‘ssl_server_key’] parametresi ise bu sertifikaya ait özel anahtarın tam yolunu belirtir.

Dosya adları örnek olarak verilmiştir komutları uygularken sunucuya aktarılan gerçek dosya adları kullanılmalıdır. Örnek yapılandırma aşağıdaki gibidir;

appliance_url 'https://morpheus.ornek.com.tr'
nginx['ssl_certificate'] = '/etc/morpheus/ssl/STAR_ornek_com_tr.crt'
nginx['ssl_server_key'] = '/etc/morpheus/ssl/STAR_ornek_com_tr.key'

Dosya kaydedilmeden önce üç bilgi bir kez daha karşılaştırılmalıdır appliance_url içindeki alan adı, sertifikanın SAN alanı ve NGINX parametrelerinde yazılan gerçek dosya yolları.

Sertifika dosyasının doğru, anahtar yolunun hatalı olması veya dosya adına ait küçük bir yazım farkı bulunması, sonraki yapılandırma aşamasını başarısız kılabilir.

morpheus.rb dosyasında yapılan değişiklikler kaydedildikten sonra Morpheus’un uygulama yapılandırmasının yeniden oluşturulması gerekir. Kaynak uygulamada bunun için morpheus-ctl reconfigure komutu kullanılmıştır. Bu komut tanımlanan ayarları ilgili bileşenlere uygular bu sırada çeşitli kaynakların güncellendiği ve servis yapılandırmasıyla ilgili satırlar konsola yazdırılabilir.

sudo morpheus-ctl reconfigure

İşlem tamamlanana kadar oturum açık tutulur. Kaynak ekranındaki başarılı çalışmanın sonunda “Morpheus Reconfigured!” ifadesi görülmektedir.

Bu ifadenin görünmesi yapılandırma işleminin tamamlandığını gösterir ancak sertifikanın gerçekten istemcilere doğru biçimde sunulduğu anlamına tek başına gelmez. Sonraki adımlarda NGINX ve istemci tarafı ayrıca doğrulanmalıdır.

Komut hata ile sonlanırsa NGINX yeniden başlatılmadan önce hatanın nedeni incelenmelidir. Özellikle sertifika dosyasının bulunamaması özel anahtarın (pkey) okunamaması ve yapılandırma sözdizimindeki hatalar kontrol edilmelidir. Sorun çözülmeden art arda servis yeniden başlatılması önerilmez.

Yapılandırma işlemi başarıyla tamamlandıktan sonra HTTPS trafiğini karşılayan NGINX servisi yeniden başlatılır. Böylece yeni sertifika ve özel anahtarın etkin yapılandırmayla kullanılmaya başlanması hedeflenir. Bu işlem mevcut kullanıcı oturumlarını kısa süreli etkileyebileceği için planlanan bakım aralığında gerçekleştirilmelidir.

sudo morpheus-ctl restart nginx

Yeniden başlatmanın ardından, kaynak dokümanda da kullanılan Morpheus arayüz logu izlenerek uygulamanın beklenen şekilde açılıp açılmadığı kontrol edilir.

Bu logta uygulama başlatma mesajları, servis hataları veya bağlantı problemlerine ilişkin kayıtlar görülebilir.

sudo tail -100f /var/log/morpheus/morpheus-ui/current

tail komutundaki -100 seçeneği son 100 satırı gösterirken -f seçeneği yeni satırları anlık olarak takip eder. İzleme işlemi Ctrl+C ile sonlandırılabilir. Burada kritik nokta logların uygulama davranışını gösterdiği; sertifikanın istemciye doğru sunulduğunu kanıtlamak için tarayıcı veya TLS bağlantısı üzerinden ayrı test gerektiğidir.

Değişiklik tamamlandığında kullanıcıların gerçekte eriştiği HTTPS adresi üzerinden test yapılır. Önce Morpheus arayüzü açılır ardından tarayıcının sertifika bilgileri incelenir. Yeni sertifikanın beklenen alan adına düzenlenmiş olması, sertifikayı veren kurumun doğru görünmesi ve geçerlilik tarihlerinin uygun olması kontrol edilir.

Tarayıcının güven uyarısı göstermemesi olumlu bir işarettir; bunun yanında arayüze giriş ve temel gezinme işlevleri de denenmelidir.

Tarayıcı kontrolüne ek olarak bağlantının uç noktasında gerçekte hangi sertifikanın sunulduğunu OpenSSL ile görüntülemek mümkündür. Aşağıdaki komut çalışmayı yapan istemciden erişilebilen 443/TCP uç noktasına bağlanır. Bu kontrol, kaynak dokümanın dışında önerilen isteğe bağlı bir doğrulamadır.

echo | openssl s_client -connect morpheus.ornek.com.tr:443 \
  -servername morpheus.ornek.com.tr 2>/dev/null | \
  openssl x509 -noout -subject -issuer -dates

Komut çıktısında beklenen sunucu adı, sertifikayı veren kuruluş ve geçerlilik tarihleri görülmelidir. Ortamda WAF veya yük dengeleyici varsa bu sorgunun o cihazın sertifikasını gösterebileceği unutulmamalıdır. Doğrudan Morpheus NGINX sertifikasıyla karşılaştırma yapılacaksa bağlantı yolu ve TLS sonlandırma mimarisi buna göre değerlendirilmelidir.

Geri dönüş (rollback) Senaryosu

Sertifika değişikliğinden sonra arayüze erişim kaybolursa veya yeni sertifika beklenen şekilde sunulmazsa işlem öncesinde alınan yapılandırma yedeği geri yüklenerek önceki ayarlara dönülebilir. Bu yaklaşımın çalışabilmesi, eski sertifika ve özel anahtar dosyalarının silinmemiş olmasına ve yedekte bu dosyaları işaret eden tanımların bulunmasına bağlıdır.

Önce mevcut hata çıktısı ve değişiklik bilgileri kaydedilir. Ardından yedek morpheus.rb dosyası geri yüklenir, yapılandırma yeniden uygulanır ve NGINX yeniden başlatılır.

Aşağıdaki komutlar önerilen örnek geri dönüş sırasıdır. Production sisteminde uygulanmadan önce yedek dosyanın varlığı ve içeriği doğrulanmalıdır.

sudo test -f /etc/morpheus/morpheus.rb.pre-ssl-change.bak
sudo cp -a /etc/morpheus/morpheus.rb.pre-ssl-change.bak \
  /etc/morpheus/morpheus.rb

sudo morpheus-ctl reconfigure
sudo morpheus-ctl restart nginx

Geri dönüş sonrasında eski URL üzerinden Morpheus arayüzüne erişim ve sunulan sertifika yeniden kontrol edilir. Bu işlemin amacı sertifikanın güven uyarısını çözmek değil, değişiklik öncesindeki çalışan durumu mümkün olduğunca geri kazanmaktır. Sonrasında yeni sertifikanın neden kullanılamadığı ayrı bir hata analizi olarak ele alınmalıdır.