View Source

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

PlusWorkflow > Konfiguracja połączenia szyfrowanego (SSL) > image2016-7-27 13:59:14.png

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&".

Po wydaniu polecenia zapisz sobie hasło i wygenerowany alias dla nowego keystore (jak na powyższym zrzucie). Przyda się podczas konfiguracji Tomcata.

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>

PlusWorkflow > Konfiguracja połączenia szyfrowanego (SSL) > image2016-7-27 14:7:1.png
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)>

Zwróć uwagę na porty. Jeśli system nasłuchuje na porcie 80 to zmień port szyfrowanego połączenia na 443 a także atrybut redirectPort dla wszystkich connectorów. Koniecznym może się okazać również otwarcie portu 443 w zaporze.

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="[]|{}^\`&quot;&lt;&gt;"
	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="[]|{}^\`&quot;&lt;&gt;"

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ć.

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:

https://knowledge.rapidssl.com/support/ssl-certificate-support/index?page=content&actp=CROSSLINK&id=SO17070

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.

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>

................
</jsp-config>
  <resource-ref>
    <description>PlusWorkflow Default Connection Resource</description>
    <res-ref-name>PlusWorkflowResource</res-ref-name>
    <res-type>javax.sql.DataSource</res-type>
    <res-auth>Container</res-auth>
  </resource-ref>
  
    <!-- 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:

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

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

aby cofnąć powyższe polecenie można wykonać:

sudo setcap cap_net_bind_service-ep /home/plusworkflow/plusworkflow-prod/jre/bin/java