PASOE i SSL cz. I

W niniejszym i następnym artykule chciałbym poruszyć ważny temat certyfikatów i połączenia PASOE z aplikacja kliencką z zastosowaniem protokułu SSL (TLS). TLS wyewoluował z protokołu SSL (zastępując go gdy jest to możliwe) i jest to standardowy protokół implementujący szyfrowanie wymagane w komunikacji HTTPS.

PASOE umożliwia określenie portu HTTPS podczas tworzenia instancji. Przypomnijmy sobie przykładową komendę:
pasman create -v -f -p 8813 -P 8814 -s 8815 %WRKDIR%\mypasoe
gdzie port komunikacji po HTTPS jest określony przez parametr -P (tutaj 8814).

Do nawiązania połączenia serwer-klient wykorzystywana jest technologia szyfrowania asymetrycznego lub inaczej Public Key Infrastructure (PKI). Po nawiązaniu połączenia i wymianie kluczy można już stosować mniej skomplikowane algorytmy szyfrowania symetrycznego. Prześledzimy tutaj przykładowy proces prowadzący do uzyskania i zaimportowania certyfikatu oraz zaimportowania certyfikatów do magazynów klucza po obu stronach. Każdy certyfikat cyfrowy powinien być podpisany przez wystawiający go urząd certyfikacji (CA). Może on być również certyfikatem z podpisem własnym (tzw. self-signed) ale tylko dla zastosowania w fazie testowania i rozwoju, i w żadnym razie nie w środowisku produkcyjnym.
Cały ten proces wymaga użycia narzędzi OpenEdge:

• PKIUTIL – do generowania pary kluczy: prywatny, publiczny, a następnie importowania certyfikatu do magazynu kluczy dla serwerów
• CERTUTIL – do importowania nowych certyfikatów dla klientów
• SSLC – w OpenEdge dodano implementacje OpenSSL. Można ją wykorzystać opcjonalnie do utworzenia certyfikatu z podpisem własnym wygenerowanym dla klucza prywatnego (dla testów) oraz do wielu innych operacji.

Zaczniemy od wygenerowanie pary kluczy prywatny/publiczny.

Otwieramy proenv jako administrator
Przechodzimy do katalogu %DLC%\keys\requests

pkiutil -keysize 2048 -newreq mycert
Będziemy musieli utworzyć hasło PEM (tutaj: Mypass1) – to nasze hasło należy zapisać bo będzie jeszcze nam potrzebne.
Będziemy pytani o szereg informacji składających się na tzw. Distinguished Name (DN): symbol kraju, województwo, organizacja itd. Nie wszystkie są niezbędne, ale najważniejsze z nich to nazwa organizacji i domeny dla naszego serwera. Przykładowe dane widać poniżej.

Otwieramy proenv jako administrator
Przechodzimy do katalogu %DLC%\keys\requests

Zostały w nim utworzone pliki:
1. mycert.pk1 – klucz prywatny, którego pilnie strzeżemy
2. mycert.pk10 – klucz publiczny + informacje o Twojej organizacji. Służy on do utworzenia tzw. żądania podpisania certyfikatu (CSR), które należy przesłać do urzędu certyfikacji (CA).

Po przesłaniu pliku klucza publicznego (mycert.pk10 w tym przykładzie) do CA, powinniśmy uzyskać podpisany certyfikat TLS, który jest zazwyczaj plikiem z rozszerzeniem .crt lub .cer.
My posłużymy się jednak tutaj certyfikatem z własnym podpisem wygenerowanym dla klucza prywatnego. Przypominam, że można go stosować wyłącznie dla celów testowych.
(Również dla celów testowych możemy skorzystać z darmowego serwisu getaCert).

sslc req -key C:\OpenEdge128\keys\requests\mycert.pk1 -new -x509 -days 360 -out C\OpenEdge128\keys\requests\mycert.cer

Jeśli otrzymalibyśmy certyfikat z CA należałoby go skopiować do katalogu %DLC%\keys\requests\

Następnie musimy wygenerować plik PEM (Privacy-enhanced Electronic Mail), zawierający prywatny klucz serwera oraz certyfikat.
Wykonujemy następujące polecenie (będziemy musieli podać wcześniej utworzone hasło!):
pkiutil -import mycert C:\OpenEdge128\keys\requests\mycert.cer

Plik mycert.pem pojawi się w katalogu %DLC%\keys

Na tym kończę ten odcinek, w następnym zajmiemy się klientem i przetestowaniem połączenia SSL.