W poprzednim artykule omówiłem czynności wstępne związane z wygenerowaniem kluczy i certyfikatów. Czas teraz zająć się konfiguracją po stronie klienta ABL i przetestowaniem połączenia.
Gdy serwer przedstawia swój certyfikat klientowi, klient musi mieć (w celu weryfikacji) certyfikat zaimportowany do swojego magazynu certyfikatów.

OpenEdge udostępnia narzędzie certutil do importowania certyfikatu CA do magazynu certyfikatów OpenEdge w katalogu %DLC%\certs. W naszym przypadku składnia wygląda następująco:
certutil -import C:\OpenEdge128\keys\requests\mycert.cer

Każdy klient łączący się z instancją musi mieć kopię pliku certyfikatu wygenerowanego podczas importu (tutaj: 1cafad6a). Należy więc skopiować ten plik do katalogu %DLC%\certs po stronie klienta.

Teraz zajmiemy się PASOE. Przechodzimy do katalogu conf dla naszej instancji (tu: C:\WrkOpenEdge128\mypasoe\conf) i wykonujemy kopię zapasową pliku tomcat-keystore.p12 np. do pliku tomcat-keystore.p12.original.

Wykonujemy polecenie sslc, aby wyeksportować informacje z pliku PEM do magazynu kluczy Tomcat o nast. składni:
sslc pkcs12 -export -in [signed public key file name].pem -out tomcat-keystore.p12 -name [alias name]
W nazwie aliasu należy unikać dużych liter. Musimy pamiętać ustanowione wcześniej hasło dla PEM oraz podać dwa razy nowe hasło dla exportu (tutaj: MyExpPass).

sslc pkcs12 -export -in C:\OpenEdge128\keys\mycert.pem -out tomcat-keystore.p12 -name mysslkey

Teraz trzeba zaktualizować plik mypasoe/conf/catalina.properties a dokładnie dwa wpisy w sekcji JSSE keystore: psc.as.https.keypass musi mieć wartość naszego hasła do exportu, a psc.as.https.keyalias wartość aliasu, jak poniżej.

Po tych wszystkich zabiegach można przetestować połączenie. Zaczniemy od REST, czyli https:localhost:8814… Widać, że usługa zwraca dane.

Powinniśmy dodać także certyfikat do przeglądarki, ale tylko w przypadku prawdziwego certyfikatu, wydanego przez CA. Tutaj nie ma to znaczenia.

Teraz przetestujemy warstwę transportową APSV. Z procedury ABL łączymy się po https i uruchamiamy znaną już procedurę na appserwerze. Wszystko działa poprawnie.

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.