Fórum Root.cz
Hlavní témata => Server => Téma založeno: M25artin 03. 08. 2020, 20:40:19
-
Zdravim linuxové borce. Mám následující problém. Po instalaci Tomcat serveru (Ubuntu distro) mi běží služba na portu 8080. Což nechci a chci, aby mi běžela na HTTPS. Mám certifikáty (CA.crt, .key, .crt). Nevím už co dělám špatně, ale nedaří se mi to rozjet. Postupuji následujícím způsobem:
Pomocí příkazu jsem si prevedl oba certikáty (.key, .crt) do keystore
openssl pkcs12 -export -in <path/to/cert>.crt -inkey
<path/to/key>.key -out <keystore-name> -name <alias>
Pak jsem provedl pomocí příkazu import CA certu do keystore
keytool -import -alias root -keystore <your_keystore_filename>
-trustcacerts -file <filename_of_the_chain_certificate>
A nakonec upravil server.xml
<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile="<path/to/keystore>" keystorePass="<keystore_pass_from_above>"
keystoreAlias="<alias>" keystoreType="PKCS12" />
Pak restart serveru a nic se neděje :( Díky moc
-
Použij Apache nebo nginx jako frontend https://confluence.atlassian.com/adminjiraserver/integrating-jira-with-apache-using-ssl-938847754.html
-
Jiný lehčí způsob není? Nedělám někde nějakou stupidní chybu?
-
Nastavit Tomcat přímo na HTTPS, ale to není doporučovaná varianta
-
Pokud Tomcat po restartu neposlouchá na portu 8443, evidentně se ta vaše konfigurace neuplatnila. Pokud ale Tomcat nastartoval, asi v konfiguračním souboru není žádná chyba, takže nejspíš needitujete ten správný konfigurační soubor.
Nastavit Tomcat přímo na HTTPS, ale to není doporučovaná varianta
To platilo tak před dvaceti lety…
-
Editoval jsem server.xml což je správný soubor. Když si vytvořím takové to generic uložiště certifikátů:
keytool -genkey -keysize 2048 -keyalg RSA -sigalg SHA256withRSA -alias tomcat -keystore era6.jks -keypass tajneHeslo -storepass tajneHeslo -dname "CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown"
tak mi to server naběhne na https. Pokud převedu certifikáty co jsem obdržel do PKCS12 + importnu tam CA. Tak nenaběhne :D Opravdu nevím co dělam už špatně googlim jak o život a zatím nic.
-
https://confluence.atlassian.com/adminjiraserver/running-jira-applications-over-ssl-or-https-938847764.html
Sekce Troubleshooting něco nenapoví?
-
org.apache.coyote.http11.Http11NioProtocol je java connector, proto je třeba do keystoreFile dát jks keystore vyrobený právě pomocí keytool, který do .jks umí zkonvertovat .p12
Viz https://tomcat.apache.org/tomcat-8.5-doc/ssl-howto.html
Nocméně doporučoval bych spíše apr connector
https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#SSL_Support_-_Connector_-_NIO_and_NIO2
org.apache.coyote.http11.Http11AprProtocol
Ten sice vyžaduje zkompilované openssl knihovny atd.
Já jsem narazil na limity, kdy jsem chtěl v tomcatu virtuální ssl weby s autentizací klientským certifikátem, tak jsem skončil s Apache Server - mod ajp reversní proxy - tomcat. Prostě jinak to nefungovalo, což nebude Váš případ.
-
https://confluence.atlassian.com/adminjiraserver/running-jira-applications-over-ssl-or-https-938847764.html
Sekce Troubleshooting něco nenapoví?
Já bych vám napověděl, že Jira je něco jiného než Tomcat. ::)
-
tak mi to server naběhne na https. Pokud převedu certifikáty co jsem obdržel do PKCS12 + importnu tam CA. Tak nenaběhne :D Opravdu nevím co dělam už špatně googlim jak o život a zatím nic.
To, že nenaběhne, je dobrá zpráva. Znamená to, že je někde chyba a že editujete ty správné soubory. Chyba by měla být vypsaná v logu.
Máte v tom úložišti certifikátů certifikáty správně pojmenované a máte tam správné heslo? Musí to být shodné s tím, co používá Tomcat. Osobně raději pro práci s Java KeyStore používám KeyStore Explorer (https://keystore-explorer.org/), používání je intuitivnější než používání té řádkové utility.
-
Po použití connectoru <Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
a restartu serveru vidím tohle v logu :(
tomcat8[21657]: Command line argument: -Dorg.apache.catalina.security.SecurityListener.UMASK=0027
tomcat8[21657]: Command line argument: -Dignore.endorsed.dirs=
tomcat8[21657]: Command line argument: -Dcatalina.base=/var/lib/tomcat8
tomcat8[21657]: Command line argument: -Dcatalina.home=/usr/share/tomcat8
tomcat8[21657]: Command line argument: -Djava.io.tmpdir=/tmp
tomcat8[21657]: Loaded APR based Apache Tomcat Native library [1.2.21] using APR version [1.6.5].
tomcat8[21657]: APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true].
tomcat8[21657]: APR/OpenSSL configuration: useAprConnector [false], useOpenSSL [true]
tomcat8[21657]: OpenSSL successfully initialized [OpenSSL 1.1.1d 10 Sep 2019]
tomcat8[21657]: Initializing ProtocolHandler ["https-openssl-nio-8443"]
-
Netrap sa a daj pred toho tomcata nginx v reverse proxy mode ako radil niekto vyssie. Strata vykonu limitne nulova, ale usetri to strasne vela nervov.
-
Po použití connectoru <Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
a restartu serveru vidím tohle v logu :(
Nerozumím tomu smutnému smajlíku. V tom logu žádná chyba není. Funguje to takhle nebo ne? Mimochodem, doufám, že zkoušíte přístup na port 8443, který tam máte nakonfigurovaný, a ne na standardní HTTPS port 443.
-
To bude nejaka ptakovina, SSL na Tomcatu normalne funguje.
Nejpve si over, zda to neco vraci na: curl -k https://127.0.0.1:8443
Pokud ano, zkontroluj lokalni firewall.
-
Když si vytvořím self-signed cert do keystore uložiště tak mi tomcat najede na portu 8443. Pokud si vytvořím viz první příspěvek ze svých certů (jeden .key a jeden .crt) jeden pkc12 soubor, ktery ihned importnu do noveho keystore a vzapeti tam importnu CA cert. Pak zadam cestu k tomu keystore do stejne konfigurace tak mi tomcat s tim mym certem nenajede.
Postupoval jsem podle této stránky: https://faqs.cascadecms.com/en/articles/2142280-enabling-ssl-via-tomcat-with-an-existing-certificate
-
Když server nenastartuje, co je v logu za chybu? KeyStore Explorer vám to úložiště otevře a je tam vše správně?
Importovat zvlášť certifikát serveru a zvlášť certifikát CA podle mne přes keytool nejde, nespojí se to do jednoho záznamu. Buď je potřeba vložit i ten certifikát CA do PFX a to pak naimportovat v jednom kroku přes keystore. A nebo použijte ten KeyStore Explorer, tam to můžete přidat postupně, a rovnou vidíte, zda je ten certifikační řetězec správně.
-
Moc děkuji!!! KeyStore Explorer mi pomohl. Tomcat na portu 8843 funguje i s certifikatem. Teď už jen musím nastavit, aby jel jen na 443 a problém vyřešen :)
-
https://confluence.atlassian.com/adminjiraserver/running-jira-applications-over-ssl-or-https-938847764.html
Sekce Troubleshooting něco nenapoví?
Já bych vám napověděl, že Jira je něco jiného než Tomcat. ::)
To by ste sa divil, ale JIRA bezi ako webapp na Tomcate a ten navod z JIRA je aplikovatelny aj na tazatelovu situaciu...
-
Moc děkuji!!! KeyStore Explorer mi pomohl. Tomcat na portu 8843 funguje i s certifikatem. Teď už jen musím nastavit, aby jel jen na 443 a problém vyřešen :)
Na kontrolu spravnosti vygenerovaneho keystoru odporucam tuto utilitku: https://github.com/MichalHecko/SSLPoke (https://github.com/MichalHecko/SSLPoke)
Teraz este vyriesit privilegovane porty - odporucam sa pozriet po utilitke authbind (Debian) napr. aj modifikovanim startup.sh, napr.:
1) Install authbind
2) Make port 443 available to authbind (you need to be root):
touch /etc/authbind/byport/443
chmod 500 /etc/authbind/byport/443
chown tomcat /etc/authbind/byport/443
3) Change /usr/share/tomcat/bin/startup.sh
exec authbind --deep "$PRGDIR"/"$EXECUTABLE" start "$@"
# OLD: exec "$PRGDIR"/"$EXECUTABLE" start "$@"
alebo v pripade napr. Redhat odporucam:
setcap 'cap_net_bind_service=+ep' /usr/lib/jvm/bin/java
ktory mne na Redhatoch a Centosoch nikdy nefungoval poriadne, nakolko je tam problem s:
java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory
treba povolit loadovanie kniznice
sudo vim /etc/ld.so.conf.d/java.conf
Jeho obsah je napr. tento riadok: /usr/java/jdk1.8.0_191-amd64/lib/amd64/jli
sudo ldconfig
idealne je to pekne riesit na urovni SystemD, rovno v unite povolit capabilities:
AmbientCapabilities=CAP_NET_BIND_SERVICE
Ale inak, zlaty Debian
-
Netrap sa a daj pred toho tomcata nginx v reverse proxy mode ako radil niekto vyssie. Strata vykonu limitne nulova, ale usetri to strasne vela nervov.
Tiez som si kedysi myslel, ale najdu sa pripady, kedy zdanie klame:
Uplne bezna situacia, v spojeni s kontainermi, kde samozrejme Docker nie uplne funguje tak, ze dependsOn neznamena, ze kontainer je v 100% stave ready a dochadza k tomu, ze NGINX nabehne skor, ako je mozne resolvnut DNS kontainera, ktory je v "proxy_pass"...
Netestoval som na Docker Swarm alebo Kubernates, tam moze byt situacia mierne odlisna.
Vo vysledku je to error pri nabehu nginx....ako, toto sa Vam stane vzdy, ked vam NGINX nabehne skor, ako je mozne resolvnut DNS zaznam targetu v proxy_pass, aj mimo kontainery,ale tam sa to deje vzdy....
Riesenia:
1. extendnut NGINX image, a doplnit utilitku, ktora pocka na nabeh ostatnych kontainerov (ble, a co ak niektory z kontainerov nenabehne nikdy ?) - https://github.com/eficode/wait-for (https://github.com/eficode/wait-for)
2. nastavit restart policy pre NGINX - opat, co ak nenabehne niektory z proxy_pass targetov vobec ?
3. odrbat nginx, nastavenim aliasov alebo nejakeho ineho DNS resolvera...
Tejto teme (3) sa dost venuju tu, zial, mne sa to nikdy nepodarilo takto odrbat:
- https://stackoverflow.com/questions/32845674/setup-nginx-not-to-crash-if-host-in-upstream-is-not-found (https://stackoverflow.com/questions/32845674/setup-nginx-not-to-crash-if-host-in-upstream-is-not-found)
- https://stackoverflow.com/questions/50248522/nginx-will-not-start-with-host-not-found-in-upstream/50358455 (https://stackoverflow.com/questions/50248522/nginx-will-not-start-with-host-not-found-in-upstream/50358455)
Ak vie niekto, ako to vyriesit bodom 3 alebo aj nejako inak, sem s radou - mne premenne nesli.
Zlaty Apache
-
To by ste sa divil, ale JIRA bezi ako webapp na Tomcate a ten navod z JIRA je aplikovatelny aj na tazatelovu situaciu...
Nedivil. Vím, že Jira používá Tomcat. Akorát jsem se na ten návod díval, a je tam dost věcí specifických pro Jiru. Tazatele by to jen mátlo.
-
Teď už jen musím nastavit, aby jel jen na 443 a problém vyřešen :)
V systemd jednotce, kterou Tomcat spouštíte, nastavíte:
[Service]
CapabilityBoundingSet=cap_net_bind_service
Tím pádem bude moci služba naslouchat na nízkých portech, i když neběží pod rootem. Pak už jen v konfiguráku Tomcatu přepíšete port 8443 na port 443.
-
Vyřešeno. Díky moc Filip Jirsák!!!
Připsat v systemd jednotce pomohlo.
[Service]
CapabilityBoundingSet=cap_net_bind_service
Zase jsem se něco naučil :D Ještě jednou moc díky.
-
To je dobře. Rádo se stalo. :)
-
Odkazoval jsem Vás na tomcat doc: https://tomcat.apache.org/tomcat-8.5-doc/ssl-howto.html
Změnťe protokol na ...apr...: a připravte si p12 certifikát v server.crt a klíč v server.pem, tady v příkladu bez hesla:
<!-- Define an SSL Coyote HTTP/1.1 Connector on port 8443 -->
<Connector
protocol="org.apache.coyote.http11.Http11AprProtocol"
port="8443" maxThreads="200"
scheme="https" secure="true" SSLEnabled="true"
SSLCertificateFile="/usr/local/ssl/server.crt"
SSLCertificateKeyFile="/usr/local/ssl/server.pem"
SSLVerifyClient="optional" SSLProtocol="TLSv1+TLSv1.1+TLSv1.2"/>