W poprzednim artykule opisałem swoje pierwsze wrażenia po uruchomieniu następcy Cisco VIRL, czyli Cisco Modeling Labs 2.0. Zaznaczyłem, że jednym z potencjalnie silnych punktów CML 2.0 będzie jego API. Jednak do poprawnego działania API wypadałoby zmienić domyślny certyfikat SSL. Przygotowałem dla Was instrukcję jak to zrobić – nie jest to czynność niestety prosta, ale każdy może zainstalować własny certyfikat SSL w CML 2.0
Po co własny certyfikat SSL?
Zasadniczo nie jest to rzecz niezbędna. Nic nie stoi na przeszkodzie by pozostawić domyślny certyfikat podpisany wewnętrznym CA o nazwie VIRL Labs CA. Jedyne z czym będziemy się spotykać to ostrzeżenia przeglądarki, że CA nie jest zaufane. Także uruchamianie wszelkich skryptów korzystających z API będzie wymagało włączenia ignorowania niepoprawnych certyfikatów. A co jeżeli taki serwer chcielibyśmy wystawić do Internetu by zdalnie zarządzać symulacjami? Albo napisać aplikację na telefon do takiego zarządzania? Wtedy wbudowany certyfikat już na pewno nie przejdzie.
Parę lat temu na potrzeby swojego laba i sieci domowej uruchomiłem usługę urzędu certyfikacji (Certificate Authority). Stworzyłem też zestaw skryptów do tworzenia kluczy i podpisywania żądań. Certyfikaty CA zainstalowałem jako zaufane na swoich urządzeniach. Dzięki temu z jednej strony mam pewność, że łączę się ze swoim urządzeniem, z drugiej zaś nie muszę omijać wbudowanych w API mechanizmów bezpieczeństwa.
Jeżeli chcesz zbudować podobną infrastrukturę u siebie to możesz wzorować się na opisie, który parę lat temu umieściłem na swoim anglojęzycznym blogu.
Tworzymy nowy certyfikat SSL w CML 2.0
W CML 2.0 certyfikaty wykorzystywane są w dwóch miejscach. Jest to Lab Manager nasłuchujący na porcie 443 oraz System Maintenance Controls na porcie 9090. Ja podmieniłem certyfikat w pierwszej z nich jedynie, gdyż to ona odpowiada za dostęp do interfejsu GUI oraz API. Wydawało mi się, że będzie to dość prosta operacja i możliwa do wykonania przez GUI albo panel administracyjny CMS. Nic bardziej mylnego! Niestety to kolejna rzecz, która nie została w CML 2.0 przemyślana i wymaga nakombinowania się. A serio wystarczyłby formularz w panelu administracyjnym. Nawet mój prawie 10-letni NAS to ma….
Uprzedzając nieco rozwój wydarzeń powiem, że potrzebujemy wygenerować klucz szyfrujący, CSR (Certificate Signing Request) i podpisać go w naszej infrastrukturze CA. Klucz i CSR możemy utworzyć na maszynie z CML 2.0, ale ułatwię Ci zadanie. Wystarczy nam dowolny komputer z Linuksem i openssl. Potrzebujemy znać także adres IP i nazwę FQDN (jeżeli taką nadaliśmy) naszej maszyny wirtualnej z CML 2.0. U mnie są to odpowiednio 172.16.1.5 oraz cml.virl.lan. Polecenie generujące klucz i CSR wygląda następująco:
SAN=DNS:cml.virl.lan,IP:172.16.1.5 openssl req -new -nodes -out cml.virl.lan.csr -keyout cml.virl.lan.key -subj "/CN=cml.virl.lan" -config etc/server-SAN-env.conf
W mojej sieci wszystkie certyfikaty muszą mieć rozszerzenie Subject Alternative Name, stąd konieczność zdefiniowania zmiennej SAN oraz użycia odpowiedniej konfiguracji usługi CA. Nie testowałem, czy certyfikat bez SAN poprawnie zadziała w CML 2.0. Tak wygenerowane żądanie CSR podpisujemy teraz za pomocą naszego CA.
openssl ca -config etc/signing-ca.conf -in cml.virl.lan.csr -out cml.virl.lan.crt -extensions server_ext
W ten sposób wygenerowaliśmy klucz i podpisany naszym CA certyfikat. Możemy przystąpić do instalacji.
Instalujemy nowy certyfikat
Skoro nie ma dedykowanego formularza służącego do zmiany certyfikatu musimy podmienić go ręcznie. Niestety usługa SSH w CML 2.0 połączy nas z CLI do zarządzania symulacjami, a nie systemem operacyjnym. Mamy dwie alternatywy. Po pierwsze możemy zalogować się na konto administratora systemu za pomocą konsoli maszyny wirtualnej. Drugi sposób to wywołać linię poleceń z panelu System Maintenance Controls. Następnie musimy za pomocą na przykład scp przekopiować pliki z certyfikatem i kluczem do systemu operacyjnego maszyny wirtualnej z CML 2.0.
Interfejs CML 2.0 uruchomiony jest za pomocą nginx. Pliki konfiguracyjne znajdują się w katalogu /etc/nginx. Wśród nich plik z kluczem (privkey.pem) oraz certyfikatem (fullchain.pem). Najprościej wykonać kopie zapasowe tych plików oraz wgrać utworzone wcześniej własne klucz i certyfikat na ich miejsce. Pamiętajmy, że do wykonania tej operacji musimy podnieść swoje uprawnienia za pomocą sudo.
Na koniec wracamy do panelu System Maintenance Controls, przechodzimy do zakładki Services i odnajdujemy usługę The nginx HTTP and reverse proxy server. Wchodzimy w jej ustawienia i restartujemy. Po ponownym uruchomieniu usługi zobaczymy, że identyfikuje się ona za pomocą naszego certyfikatu. Jeżeli restart się nie powiedzie informacje o przyczynie powinny być wyświetlone na ekranie konsoli. U mnie, ku memu zdziwieniu, nginx nie wymagał aby do certyfikatu usługi były dołączone certyfikaty samego CA oraz Signing CA.
