Artykuł opisuje konfigurację połączenia szyfrowanego dla serwera zainstalowanego na systemie Windows.
Aby skonfigurować SSL będziesz potrzebować paczki z kluczem prywatnym oraz z wszystkimi certyfikatami publicznymi aż do CA. Plik pfx wraz z hasłem do niego zostanie Ci przekazany przez osoby techniczne od strony klienta.
Zaimportowanie paczki z kluczem prywatnym oraz certyfikatami publicznymi
Plik pfx można zaimportować do systemu (jednocześnie konwertując do formatu pliku z rozszerzeniem jks) za pomocą programu keytool znajdującego się w %JAVA_HOME%\bin
keytool -importkeystore -srckeystore <ścieżka do pliku pfx> -srcstoretype pkcs12 -destkeystore <ścieżka i nazwa pliku wyjściowego jks> -deststoretype JKS
Najlepiej hasło dla "destination keystore" wpisać takie samo, jak hasło do certyfikatu, czyli "source keystore". Gdy hasło będzie zmienione, w server.xml trzeba będzie dodać jeden parametr.
W przypadku, gdy hasło zawiera znak "&", hasło należy zapisać "&", na przykład:
"Wdrozenie&" zapisać jako "Wdrozenie&".
Konfiguracja Tomcata
Wyedytuj plik %CATALINA_HOME%\conf\server.xml. Odkomentuj connector dla portu 8443 i dopisz do niego poniższe atrybuty z odpowiednio zmodyfikowanymi wartościami.
keystoreFile=<ścieżka do nowo utworzonego keystore> keystorePass=<hasło do nowo utworzonego keystore> keyAlias=<alias keystore>
Jeżeli w "destination keystore" wpisaliśmy swoje własne, nowe hasło, to w server.xml przy Connector dotyczącym https, należy dopisać po keystorePass parametr keyPass= <hasło do certyfikatu, czyli to co wpisaliśmy w "source keystore" w cmd)>
Konfiguracja SSL w przypadku dostarczenia certyfikatu w formie pliku .pfx
W tym przypadku nie musimy importować kluczy z .pfx, wystarczy wskazać lokalizacje, typ oraz hasło certyfikatu w ustawieniach %CATALINA_HOME%\conf\server.xml, następnie należy odblokować i edytować connector następującymi wartościami:
<Connector protocol="org.apache.coyote.http11.Http11NioProtocol" port="8443" maxThreads="200" scheme="https" secure="true" SSLEnabled="true" keystoreFile="/home/plusworkflow/plusworkflow-prod/server/conf/certyfikat.pfx" keystorePass="hasło_do_pfx" keystoreType="PKCS12" clientAuth="false" relaxedPathChars="[]|" relaxedQueryChars="[]|{}^\`"<>" URIEncoding="UTF-8" sslProtocol="TLS" maxHttpHeaderSize="65536" maxPostSize="40194304"/>
Jeżeli pojawi się problem ze znakami np. "the valid characters are defined in rfc 7230 and rfc 3986" - należy dodać ten wpis w konfiguracji connectora
relaxedPathChars="[]|" relaxedQueryChars="[]|{}^\`"<>"
Konfiguracja SSL dla wersji 4.2
<Connector port="443" protocol="org.apache.coyote.http11.Http11NioProtocol" maxThreads="200" scheme="https" secure="true" SSLEnabled="true" clientAuth="false" URIEncoding="UTF-8" sslProtocol="TLS" connectionTimeout="20000" maxHttpHeaderSize="65536" maxPostSize="40194304" relaxedPathChars="[]|" relaxedQueryChars="[]|{}^\`"<>" encodedSolidusHandling="decode"> <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" /> <SSLHostConfig> <Certificate certificateKeystoreFile="conf/workflowweb.pfx" certificateKeystorePassword="password" type="RSA"/> </SSLHostConfig> </Connector>
Ustawienie automatycznego przekierowania na szyfrowany port.
Wyedytuj plik %CATALINA_HOME%\webapps\ROOT\index.html. Atrybut content powinien zawierać odpowiedni link do systemu (protokół https)
Zrestartuj system i przetestuj czy jesteś automatycznie przekierowywany do wskazanego w pliku index.html URL'a JEŻELI
w katalogu ROOT nie znajduje się index.html należy go utworzyć
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title></title> <meta HTTP-EQUIV="REFRESH" content="0; url=http://localhost/PlusWorkflow/default.do"> </head> <body> </body> </html>
Dodatkowo należy pamiętać, aby w pliku web.xml odkomentować <welcome-file-list>
Konfiguracja SSL na Linuxie lub w przypadku dostarczenia certyfikatów w postaci klucza prywatnego (private.key) oraz pliku crt (czasem występującego w formacie .pem)
Konfiguracja SSL na linuxie w przypadku gdy dostarczone są pliki z certyfikatem server.crt cerver-ca.crt private_key.key
openssl pkcs12 -export -in server.crt -inkey private_key.key -out server.p12 -name tomcat -CAfile server-ca.cer -caname root -chain
Wykonując powyższe polecenie należy podać hasło które należy zapamiętać.
Przykładowe wywołanie
D:\suncode\ssl\OpenSSL-Win32\bin>openssl pkcs12 -export -in D:\suncode\ssl\695dc1aac5c591a5740a085fd572774d.pem -inkey D:\suncode\ssl\private.key -out server.p12 -name tomcat -CAfile D:\suncode\ssl\all_695dc1aac5c591a5740a085fd572774d.crt -caname root -chain
Jeśli powyższe polecenie zwraca błąd:
Error unable to get local issuer certificate getting chain.
to znaczy że podany plik z certyfikatami nie posiada całej ścieżki certyfikatów i należy się zastosować do poleceń ze strony:
Link ten opisuje iż podany plik z certyfikatami server-ca.cer musi zawierać certyfikat dla strony dla której to ustawiamy ale również certyfikaty root'a tj. wydawcy certyfikatu. Sprowadza się to często do wklejenia certyfikatu root'a (wszystkich poziomów) do pliku server-ca.cer.
UWAGA
W środowisku Windows nie jest dostępny program openssl. Można go jednak pobrać ze strony OpenSSL for Windows
Konfiguracja Tomcata
Należy otworzyć plik server.xml i w sekcji konfiguracji ssl podać:
<Connector port="443" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" URIEncoding="UTF-8" clientAuth="false" sslProtocol="TLS" keystoreFile="/path/to/server.p12" keystoreType="PKCS12" keystorePass="haslo_podane_wyzej" />
Automatyczne przekierowanie żądań http na https
Od wersji 4.2:
Wpis z web.xml można zastąpić użyciem parametru systemowego REDIRECT_FROM_HTTP_TO_HTTPS. Użycie parametru nadal wymaga zmian w server.xml w celu zdefiniowania Connectora (jest wyżej) dla https i przekierowania na wybrany port.
Poniżej wersji 4.2:
Aby dodać automatyczne przekierowanie żądań http na httpsnależy w pliku web.xml dodać sekcję <security-constraint>
................ <!-- Require HTTPS for everything except /img (favicon) and /css. --> <security-constraint> <web-resource-collection> <web-resource-name>HTTPSOnly</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> </security-constraint> <security-constraint> <web-resource-collection> <web-resource-name>HTTPSOrHTTP</web-resource-name> <url-pattern>*.ico</url-pattern> <url-pattern>/img/*</url-pattern> <url-pattern>/css/*</url-pattern> <url-pattern>/services/ReleaseService/*</url-pattern> </web-resource-collection> <user-data-constraint> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint> <welcome-file-list> <welcome-file>default.do</welcome-file> </welcome-file-list> .........................
Automatyczne ustawianie flagi SameSite w sesji
Od wersji Chrome 85, przeglądarka przestała domyślnie ustawiać SameSite = none. Powoduje to usuwanie sesji po przekierowaniu użytkownika z serwera zewnętrznego do systemu PlusWorkflow. Przykładowo jeżeli posiadamy wtyczkę do integracji z Mercateo - wysyłając dane zakupów ze sklepu do systemu, sesja zostanie usunięta przez przeglądarkę. Co skończy się wylogowaniem użytkownika. UWAGA: Ustawianie flagi przy parametrze SameSite musi być wykonywane podczas bezpiecznego połączenia SSL. W przeciwnym przypadku ciasteczko sesyjne nie zostanie akceptowane przez przeglądarkę.
Aby to zrobić wystarczy dodać w do pliku conf/context.xml tak <CookieProcessor> z odpowiednim parametrem.
Parametry:
- strict, lax - Używamy, gdy system PlusWorkflow nie potrzebuje logowania z sharepointów oraz integracji stricte z innymi systemami takimi jak Mercateo. Gdzie wymagane jest przejście na inną stronę i wysłanie danych ze strony do systemu. Z punktu widzenia bezpieczeństwa - najbezpieczniejsze opcje.
- none - Używamy w przeciwnym przypadku. Ciasteczko z tym parametrem działa pomiędzy stronami (cross-site).
<Context> <CookieProcessor sameSiteCookies="none" /> </Context>
Uruchomienie usługi tomcat'a na linuxie porcie 443 (to samo dotyczy portu 80)
Standardowo systemy Linux mają zablokowaną możliwość uruchamiania usług na użytkownikach nie-root'woych na portach poniżej 1024. System PlusWorkflow działa na użytkowniku plusworkflow więc aby uruchomić usługę na portach 443 lub 80 należy wykonac następujące polecenia:
W poniższych poleceniach z wskazaną ścieżką do Javy należy się najpierw upewnić jaka jest dokładna lokalizacja javy np. czy w ścieżce jest "/jre/jre"
sudo setcap cap_net_bind_service+ep /path/to/bin/java lub podając konkretną ścieżkę: sudo setcap cap_net_bind_service+ep /home/plusworkflow/plusworkflow-prod/jre/bin/java lub sudo setcap cap_net_bind_service+ep /home/plusworkflow/plusworkflow-prod/jre/jre/bin/java
Często bywa tak, że po wykonaniu powyższego nie ma możliwości uruchomienia javy i leci błąd:
/path/to/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory
wówczas należy wykonać następujące polecenia:
# echo "/home/plusworkflow/plusworkflow-prod/jre/lib/amd64/jli" > /etc/ld.so.conf.d/java-libjli.conf # ldconfig -v
Dla wersji 4.2
echo "/home/plusworkflow/test/jre/lib" | sudo tee /etc/ld.so.conf.d/java-libjli.so sudo ldconfig
aby cofnąć powyższe polecenie można wykonać:
sudo setcap cap_net_bind_service-ep /home/plusworkflow/plusworkflow-prod/jre/bin/java
2 Comments
Tomasz Wojciechowski
Jeśli klient nie może dostarczyć podpisany certyfikat to można w Javie wygenerować niepodpisany poniższą komendą:
keytool -genkey -keyalg RSA -alias budmat -keystore keystore.jks -storepass W@!qazX1 -validity 1800 -keysize 2048
Po wywołaniu tego polecenia pojawi się jeszcze kilka pytań w cmd
gdzie:
validity - ważność certyfikatu w dniach
storepass - hasło ustawiane w tomcacie w pliku server.xml
alias - alias
Dodatkowo można wygenerować certyfikat dla domeny oraz ip poprzez podanie dodatkowego poniższego parametru:
pozostałe parametry mniej ważne.
Anonymous
Aby skonfigurować certyfikat SSL Let's Encrypt na Ubuntu należy postępować zgodnie z instrukcją na stronie:
https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-20-04