Sziasztok!
Van egy Tomcatem, előtte egy nginx az alábbi konfiggal.
# Location block that proxies requests to the Bonita runtime service.
location /bonita/ {
proxy_pass https://bonita_runtime; # Proxies requests to the defined upstream group bonita_runtime.
proxy_ssl_verify off;
proxy_ssl_protocols TLSv1.2 TLSv1.3;
proxy_ssl_ciphers HIGH:!aNULL:!MD5;
proxy_ssl_server_name on;
proxy_http_version 1.1; # Sets the HTTP version used in the proxy request.
proxy_set_header Host $host; # Sets the Host header.
proxy_set_header X-Real-IP $remote_addr; # Passes the real IP address of the client.
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # Appends the client's IP to X-Forwarded-For header.
proxy_set_header X-Forwarded-Proto $preserve_x_forwarded_proto; # Forwards the original request scheme.
proxy_set_header X-Forwarded-Host $preserve_x_forwarded_host; # Forwards the original host requested.
proxy_set_header X-Forwarded-Port $preserve_x_forwarded_port; # Forwards the original port requested.
include snippets/cookies.conf; # Modifies the cookie path to remove '/bonita'.
}
Tomcat 443-on figyel SSL Connectorral, sima RSA2048 self-signed certtel.
Közvetlenül hívva curllal szépen válaszol. nginx-en keresztül viszont az alábbi hibát kapom:
2025/07/11 09:24:07 [error] 35#35: *23 SSL_do_handshake() failed (SSL: error:0A000417:SSL routines::ssl/tls alert illegal parameter:SSL alert number 47) while SSL handshaking to upstream, client: 172.177.0.1, server: , request: "GET /bonita/apps/appDirectoryBonita HTTP/1.1", upstream: "https://172.177.0.8:443/bonita/apps/appDirectoryBonita", host: "172.177.0.10:8443"
{"http.url":"/bonita/apps/appDirectoryBonita","http.version":"HTTP/1.1","http.status_code":503,"http.method":"GET","http.referer":"","http.useragent":"curl/8.5.0","time_local":"11/Jul/2025:09:24:07 +0000","remote_addr":"172.177.0.1","remote_user":"","dest_upstream_addr":"172.177.0.8:443","request_time":0.002,"request":"GET /bonita/apps/appDirectoryBonita HTTP/1.1","body_bytes_sent":"8626","response_content_type":"text/html","X-Forwarded-For":"172.177.0.1","X-Forwarded-Proto":"https","X-Forwarded-Host":"172.177.0.10","X-Forwarded-Port":"443"}
2025/07/11 09:24:07 [info] 35#35: *23 client 172.177.0.1 closed keepalive connection
google, chatgpt azt mondja, protokoll verzió nem stimmel. Belőttem egy Traefik-et is, az simán csatlakozik a Tomcathez, tehát az nginx a szar csak már kifogytam az ötletekből, hogy mit kéne rajta beállítani meg megnézni és az nginx log level is debugon van, de ennél több nem jön ki belőle.
- 643 megtekintés
Hozzászólások
Gondolom a curl az -k kapcsolóval sikeres. A legjobb tippem, hogy a self-signed-cert a probléma. Azt nem tudja validálni az nginx
----
올드보이
- A hozzászóláshoz be kell jelentkezni
Persze.
- A hozzászóláshoz be kell jelentkezni
Mit mond erre:
openssl s_client -tls1_2 -connect <tomcat_ip:port>
A hangsúly a TLS 1.2 verzión van. Ha valami régi tomcat / régi JAVA, akkor vígan lehet, hogy csak TLS 1.1 van, vagy még az sem.
- A hozzászóláshoz be kell jelentkezni
CONNECTED(00000003)
---
Certificate chain
0 s:C = hu, ST = bud, L = bud, O = test, OU = teller, CN = bonita
i:C = hu, ST = bud, L = bud, O = test, OU = teller, CN = bonita
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
v:NotBefore: Jul 10 22:03:41 2025 GMT; NotAfter: Oct 8 22:03:41 2025 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDWzCCAkOgAwIBAgIIawdt9osoEMQwDQYJKoZIhvcNAQELBQAwXDELMAkGA1UE
BhMCaHUxDDAKBgNVBAgTA2J1ZDEMMAoGA1UEBxMDYnVkMQ8wDQYDVQQKEwZtaWty
dW0xDzANBgNVBAsTBnRlbGxlcjEPMA0GA1UEAxMGYm9uaXRhMB4XDTI1MDcxMDIy
MDM0MVoXDTI1MTAwODIyMDM0MVowXDELMAkGA1UEBhMCaHUxDDAKBgNVBAgTA2J1
ZDEMMAoGA1UEBxMDYnVkMQ8wDQYDVQQKEwZtaWtydW0xDzANBgNVBAsTBnRlbGxl
cjEPMA0GA1UEAxMGYm9uaXRhMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAiMoP+ym2mnv1L/OV4dBWRIum7idp8B+5v1dv7Bo/9fiuDuq+8iFgyOACbrM0
M0TSHPY/jg+E89HHBibLpECR1J8a0rfPpiJglww2HD/QBLEhob6Rlej3+5WJbQzK
9yABTQTTatHhN2+2depI25VvGIBpNG/NlNyD5b7jDRXFcJJpU/QysME+khhWO0EG
eiMO3S+BOVVmvPr+C95eR1ZQDD9D1YT/1J5WYghxQxRXgeKzp3HMSOy4q9X2PU1l
9AlBJy4nsRIXDtl2lTKG5MC5iqh2GcZ1OQ/1V69jOfZXP83eVA6VJ17XuxUGhxZJ
OHQUIJdjvTesZkuQ4l9x+orNyQIDAQABoyEwHzAdBgNVHQ4EFgQUZE4RN2rGTxHT
5aH4TQS0hHxb5ZwwDQYJKoZIhvcNAQELBQADggEBAGyQG7MOc9pIQWur9Tp5eViO
5sicfKNAbCj8gzr/W0L6eKHb3G56A17og0BiuS1CdWu/v7b1mjgYFArZmx8vinhv
O4Xlk8asCgA6lFCN2Qkfy5onGwFUFvd37C0J7Ytk5/6WTIg+y5Bmco3ate6f1O/H
HwOfZ9NwZKXxrTHHSQ1ZPkLsSf5574OiKmqByZiv3Fta+nvKIS8BaaDpJH8+lN1e
QQ3N0AWxHGfbtjey1hbHcxdVtTrRro3YFhtQRvYcP2RVmdS6OD5qZJ+dV3zkkN/Y
X7eSulfWGezIpiHcqQ09jxtQr6CMRD9vI4O0t7LOKA1aUZmuT0+/emwnLoJiDL0=
-----END CERTIFICATE-----
subject=C = hu, ST = bud, L = bud, O = test, OU = teller, CN = bonita
issuer=C = hu, ST = bud, L = bud, O = test, OU = teller, CN = bonita
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2454 bytes and written 281 bytes
Verification error: self-signed certificate
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 9C7151117180EF3CA51B7393EE11F3E73582D6757639956D177669A0CDC01B9D
Session-ID-ctx:
Master-Key: 68541CAF5FB755507F5802A4E94369C3C47CEF9BC1C407F9D3DC39893FD4ED97139BA49C5AFB5760C9B46FC77DF979B1
- A hozzászóláshoz be kell jelentkezni
Rém buta kérdés, de az nginx-től SNI-ben biztosan megfelelő hosztnév megy át?
Nekem már ez sem tetszik a CURL kimenetedben: "host: 172.177.0.10:8443"
Az upstreamed a 172.177.0.8:443, milyen tanúsítványt ad, ha más van az SNI-ben? Honnan jön a 8443-as port? Az nginx van azon?
- A hozzászóláshoz be kell jelentkezni
8443-on nginx figyel, 443 a tomcat (hogy ne keverjem össze őket :))
Ezen még nem gondolkodtam, hogy tomcat hogy kezeli mert
# keytool -list -v -keystore /opt/bonita/server/conf/localhost-rsa.jks
Enter keystore password:
Keystore type: PKCS12
Keystore provider: SUN
Your keystore contains 1 entry
Alias name: tomcat
Creation date: Jul 10, 2025
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=bonita, OU=***, O=***, L=bud, ST=bud, C=hu
Issuer: CN=bonita, OU=***, O=***, L=bud, ST=bud, C=hu
Serial number: 6b076df68b2810c4
Valid from: Thu Jul 10 22:03:41 GMT 2025 until: Wed Oct 08 22:03:41 GMT 2025
Certificate fingerprints:
SHA1: C6:EA:2C:07:3D:CB:B8:2E:34:B7:52:55:AA:0B:F2:B9:55:77:D3:EB
SHA256: E7:66:82:28:B2:F5:1E:0A:B1:8D:D0:7F:B2:49:2E:2E:23:28:B5:28:15:B7:E1:51:C1:53:68:EF:48:09:0B:94
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3
illetve
<Connector port="443" protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="150" SSLEnabled="true">
<SSLHostConfig>
<Certificate certificateKeystoreFile="conf/localhost-rsa.jks"
type="RSA" />
</SSLHostConfig>
</Connector>
én azt mondanám tökmindegy mi az SNI, mivel ez az egy van, ezzel szolgálja ki a kérést. De
nginx.conf: ssl_verify off;
illetve curl és traefik eléri faszán
- A hozzászóláshoz be kell jelentkezni
Itt első olvasásra pár dolog nagyon félrement, ha pl. maradni akarunk az alapértemezett portoknál és csak az eltéréseket kellene konfigurálni.
8443-on nginx figyel, 443 a tomcat (hogy ne keverjem össze őket :))
Már össze is keverted, ha nem elírás a dolog. Tomcat 8443-at ajánlott használni HTTPS- hez. Nginx-nél ugyanez pedig a 443-as port.
én azt mondanám tökmindegy mi az SNI, mivel ez az egy van, ezzel szolgálja ki a kérést.
Nem mindegy az SNI, mert ahhoz van cert készítve. (Ha jól látom nem wildcard) - jelenlegi SNI ami kell az a `bonita`, különben a Tomcat nem fogja helyesen kezelni a kérést.
illetve curl és traefik eléri faszán
A Traefik ugyanazon a hoston fut, mint a Tomcat? Ja és az Nginx és a Tomcat is egy hoston fut? Traefik és Nginx nem üti egymást portban, ha egy hoston futnak?
Ahogy mások is írták Nginx-ben ki kellene kapcsolni a proxy_ssl_server_name funkciót.
- A hozzászóláshoz be kell jelentkezni
"Nem mindegy az SNI, mert ahhoz van cert készítve. (Ha jól látom nem wildcard) - jelenlegi SNI ami kell az a `bonita`, különben a Tomcat nem fogja helyesen kezelni a kérést."
Ez mondjuk szerintem implementáció függő. Pl. Apache HTTP-nél az SNI alapján találja meg a virtualhost-ot amin belül van configolva a használandó cert, nem a CN alapján keres tudtommal. De Tomcatnél nem tudom hogy van, mert az meg gondolom a keystore-t használja.
- A hozzászóláshoz be kell jelentkezni
Igen és nem. A Tomcat se butább mint az Apache (nem véletlenül: egy a gyártó), ő is alapvetően SNI alapján keres certet, csak nyilván ha 1 azaz egy darab cert van neki bekonfigurálva, azt adja vissza.
De itt nem a Tomcat a kérdés. Az a kérdés, hogy az nginx elfogadja-e a certet a Tomcattől, ha a common name nem passzol. Te magad írod, hogy a Tomcat kiszolgál HTTPS-en, tehát NEM a Tomcat a kérdés.
- A hozzászóláshoz be kell jelentkezni
Bocs, ezt nem vettem észre.
Én nem azt írtam, hogy a Tomcat butább mint a HTTPD, hanem azt, hogy más _lehet_ az implementáció.
HTTPD-nél nincs keystore, te írod be a virtualhostba, hogy a filerendszeren található melyik certet használja, abban az esetben, ha az SNI-ben található név egyezik a virtualhosttal.
Tomcatnél nem emlékszem már hogy működik ez, de azt is el tudom képzelni, hogy simán végignyálazza a java keystore-t, és ott keres egyezést.
- A hozzászóláshoz be kell jelentkezni
Bingo! Működik!
A proxy_server_name off -on átsiklottam alább amikor igor írta. Hálásan köszi, hogy felhívtad rá a figyelmemet!
- A hozzászóláshoz be kell jelentkezni
Egy kis guglizással ezt találtam Tomcathez:
https://stackoverflow.com/questions/20190464/howto-setup-tomcat-serving…
<SSLHostConfig hostName="domain1" >
domain1-nek szerepelnie kell az SNI-ben.
- A hozzászóláshoz be kell jelentkezni
Szerintem a Host header vizsgálata jó nyom, és akár magyarázza is mi történik.
Ez a http protokoll sajátja, amennyiben http esetén 80, https esetén 443-as porton csatlakozunk, akkor a host headerbe nem kerül be a port, de ha másik portot adunk meg, akkor bekerül a portszám a host headerbe.
A teóriám: amikor nginx-en keresztül hívjuk meg a tomcatet, akkor mivel az nginx 8443-as porton figyel, bekerül a host headerbe a 8443, és ezután a tomcat azt vizsgálja, hogy létezik-e ilyen "virtualhost" (172.177.0.10:8443).
Mivel a tomcat valószínűleg nem várja a port számot a host headerbe, ezért nem is akar SSL handshake-et csinálni.
Érdemes lenne átrakni 8443-ra a tomcatet egy teszt erejéig.
- A hozzászóláshoz be kell jelentkezni
Áttettem, semmi változás. :(
- A hozzászóláshoz be kell jelentkezni
És a 8443-on figyelő tomcatet továbbra is tudtad https-en kérdezgetni curl-el gond nélkül?
btw: Én a tomcat debug logokban is nézelődnék.
szerk: itt a teszt lényege az lenne, hogy curl-el is úgy kérdezgesd a tomcat-et ahogyan az nginx teszi, tehát a host headerben legyen benne a hostname után a ":8443"
nem tudom milyen virtualhost vagy SNI megoldás van a tomcatnél, de szerintem ott hasal a történet, hogy a hostname alapján, nem jó certtel szolgál ki a tomcat.
- A hozzászóláshoz be kell jelentkezni
Igen, 8443-on is megy mint a kisangyal. Tomcat logokban minden rendben, portos host esetén is normál választ ad
curl -vk -H "Host: 172.177.0.8:8443" https://172.177.0.8:8443/bonita/apps/appDirectoryBonita
* Trying 172.177.0.8:8443...
* Connected to 172.177.0.8 (172.177.0.8) port 8443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / RSASSA-PSS
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
...
- A hozzászóláshoz be kell jelentkezni
Ezt nezted esetleg?
https://www.claudiokuenzler.com/blog/1103/nginx-reverse-proxy-ssl-alert…
- A hozzászóláshoz be kell jelentkezni
Nem még, megnézem köszi! Viszont ezek elég frissnek tűnnek. (openssl s_client -connect -tls1_3 )
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: C1E582800D40264A4AF22D3278CC12DAAA96B04BB57984A29261380254595C36
Session-ID-ctx:
Resumption PSK: 385E8450B4EDC880D283976EE339B33D6DCAEBD14C66312234768C93C697BE22707E8344066AE06BC7E0FE675A021534
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 86400 (seconds)
TLS session ticket:
0000 - 0e 48 3d 75 68 19 f1 66-b3 8f 2a a6 32 0c 83 7d .H=uh..f..*.2..}
0010 - 0b 66 11 01 2b 5e 25 14-af 9d 14 cf fc d8 4a d7 .f..+^%.......J.
0020 - fc b9 65 bc 84 5f 6a db-60 ba 25 f9 14 0a 30 91 ..e.._j.`.%...0.
0030 - 73 b0 93 c5 04 be f5 6c-7d 6e f4 2b 87 b7 31 42 s......l}n.+..1B
0040 - 93 de 4d dd 54 9d 60 1b-aa 89 f5 ec 6b a4 0a c9 ..M.T.`.....k...
- A hozzászóláshoz be kell jelentkezni
Ha megemeled "debug" szintre az error logolást, nem kapsz részletesebb hibaüzenetet?
- A hozzászóláshoz be kell jelentkezni
már debugon van :(
error_log /var/log/nginx/error.log debug; # error_log directive: Specifies the path and level for the error log.
- A hozzászóláshoz be kell jelentkezni
Problad meg kerlek proxy_ssl_server_name off; beallitassal is.
Illetve ez a curl mit mond?
curl -v -I -k -L -H "Host: bonita" https://172.177.0.10:8443
- A hozzászóláshoz be kell jelentkezni
* Connected to 172.177.0.10 (172.177.0.10) port 8443
* ALPN: curl offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [21 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [454 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [80 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [52 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / id-ecPublicKey
* ALPN: server accepted http/1.1
* Server certificate:
* subject: C=hu; ST=bud; L=bud; O=****; OU=***; CN=uiproxy
* start date: Jul 10 09:41:04 2025 GMT
* expire date: Aug 9 09:41:04 2025 GMT
* issuer: C=hu; ST=bud; L=bud; O=***; OU=***; CN=uiproxy
* SSL certificate verify result: self-signed certificate (18), continuing anyway.
* Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA256
* using HTTP/1.x
} [5 bytes data]
> HEAD / HTTP/1.1
> Host: bonita
> User-Agent: curl/8.5.0
> Accept: */*
>
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [265 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [265 bytes data]
* old SSL session ID is stale, removing
{ [5 bytes data]
< HTTP/1.1 503 Service Temporarily Unavailable
< Server: nginx/1.27.4
< Date: Fri, 11 Jul 2025 16:40:57 GMT
< Content-Type: text/html
< Content-Length: 8626
< Connection: close
< ETag: "67c1e485-21b2"
<
0 8626 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
* Closing connection
{ [5 bytes data]
* TLSv1.3 (IN), TLS alert, close notify (256):
{ [2 bytes data]
* TLSv1.3 (OUT), TLS alert, close notify (256):
} [2 bytes data]
HTTP/1.1 503 Service Temporarily Unavailable
Server: nginx/1.27.4
Date: Fri, 11 Jul 2025 16:40:57 GMT
Content-Type: text/html
Content-Length: 8626
Connection: close
ETag: "67c1e485-21b2"
de ez az nginx frontend portja. Azzal nincs gond. Az upstream ssl nem megy.
- A hozzászóláshoz be kell jelentkezni
Köszi szépen, most működik! A proxy_ssl_server_name off volt a megoldás, csak ezen átsiklottam az előbb.
- A hozzászóláshoz be kell jelentkezni
Namostan a tomcat cert-je a CN=bonita
névre szól, a proxy meg a bonita_runtime
-hoz kapcsolódik?
Legjobb lenne, ha curl
működne -k
helyett --cacert ezaneve.cert.pem
opcióval
Szerk: szabad ábrát rajzolnod, nem büntet meg érte senki, hogy pl.:
+-------------------------------+ +-------------------------+
| :8443 nginx-proxy |------------->| :443 Tomcat? on Java? |
| forward to bonita_runtime:443 | | önaláírt cert CN=bonita |
| ? cert | +-------------------------+
+-------------------------------+
- A hozzászóláshoz be kell jelentkezni
ssl_verify offon van neki, elvileg mindegy mi a CN
- A hozzászóláshoz be kell jelentkezni
Ha az ssl_verify off, akkor miért kell az egész TLS dolog az nginx és a Tomcat között? Akkor már nem egyszerűbb plain text http? (Szerk: ez a topiknyitónak szól, nem neked)
- A hozzászóláshoz be kell jelentkezni
Ezt nem teljesen értem. Attól hogy, hogy ssl_verify off, a forgalom még titkosítva lesz. És gondolom ez a cél.
- A hozzászóláshoz be kell jelentkezni
Nem, ez egy játszós környezet OpenID Connect integráció bemutatására. Az alapprobléma az volt, hogy a Tomcat a http Connector esetén rosszul generálta ki a redirect uri-t és nem sikerült megtalálnom sehol a beállítást, hogy ezen változtasson. Ezért az a kerülő megoldás született, hogy menjen https-en és akkor jó lesz a redirect uri amivel továbbítja a logint az IDP-hez.
És mivel játszós környezet, nem akartam aláírással szórakozni, ezért lett a self-signed cert és a proxy_ssl_verfify off;
Csak azt gondoltam, hogy ez mindent vivő jollyjoker ami nginx oldalon igaz is, csak ugye ez meg a másik oldal ahol a Tomcat visszadobta a kapcsolatot a proxy_ssl_server_name on; -nal beállított SNI miatt. Valószínűleg, ha a java ssl logolását bekapcsolom, ott kibukott volna a dolog.
Mindenesetre nagyon köszönöm mindenkinek a segítséget! Sokat tanultam ebből! :)
- A hozzászóláshoz be kell jelentkezni
És mivel játszós környezet, nem akartam aláírással szórakozni, ezért lett a self-signed cert és a proxy_ssl_verfify off;
Én self-signed cert helyett inkább azt szoktam csinálni, hogy az első alkalommal csinálok az ügyfélnek egy organizational CA certet (ha tudod, hogy mit csinálsz, akkor nem több 5 percnél) és a későbbiekben azzal aláírom az összes szükséges szerver certjüket. A CA certet egy mozdulattal be lehet importálni az összes szükséges szerverre, kliensre, keystoreba, bármibe, és onnantól teljes a kényelem.
- A hozzászóláshoz be kell jelentkezni
> Az alapprobléma az volt, hogy a Tomcat a http Connector esetén rosszul generálta ki a redirect uri-t
Nem inkább erről (vagyis az igazi problémáról) kellett volna topikot nyitni?
- A hozzászóláshoz be kell jelentkezni
Ugyanez jutott eszembe.
- A hozzászóláshoz be kell jelentkezni
Nyitok majd arról is, semmi izgalom, de egyrészt először működőképessé kellett tenni a rendszert, polírozgatni ráér később, másrészt piszkálta a csőröm, hogy ez így nem megy és főleg az, hogy miért nem megy.
- A hozzászóláshoz be kell jelentkezni
Ha az ssl_verify off, az csak egy látszatbiztonság. Közbeékelődhet valaki, olvashatja és módosíthatja a forgalmat.
- A hozzászóláshoz be kell jelentkezni
Azért, mert a proxy_ssl_verify off csak azt jelenti, hogy ne vizsgálja a tanusítvány megbízhatóságát, ettől még a kapcsolat HTTPS lesz, ami jó dolog, mert a titkosított kapcsolat akkor is biztonságosabb a nem-titkosítottnál, ha a tanusítványkiadó amúgy nem a publikus tanusítványkiadók egyike, vagy épp self-signed a cert. Ugyanis a kapcsolat a privát kulcs nélkül nem visszafejthető, márpedig ha az biztonságban van, mindegy mi a tanusítvány machine-to-machine kommunikáció esetében.
És igen, értem a félelmet a MITM támadástól (ugye ezért jó, ha megbízható a cert, hogy nem lehet fakelni), de a MITM támadás egy dolog, amire ez a kapcsolat sérülékeny, a titkosítatlan HTTP meg negyvenötmillió másik támadásra sérülékeny. Nem azt mondom, hogy kiváló ez így, de megfelelő környezetben nem alapvetően rossz. Ha a forgalom nem megy át az interneten, hanem két, belső hálón levő gép között megy, vagy uram bocsá' localhoston belüli a kommunikáció, a közbeékelődéses támadás kockázata bizonyos esetben akár elfogadhatóan alacsony is lehet, ha a hálózat amúgy megfelelően van védve.
- A hozzászóláshoz be kell jelentkezni
Ha a forgalom nem megy át az interneten, hanem két, belső hálón levő gép között megy, vagy uram bocsá' localhoston belüli a kommunikáció
Szerintem pont az ilyen izolált környezetekre való a plain text.
És valóban, ha valaki csak olvasni tudja a forgalmat, akkor tényleg csak a privát kulcs ismeretében tudja visszafejteni, perfect forward secrecy esetén még annak ismeretében sem tudja visszafejteni.
De erről az a véleményem, hogyha már le van generálva az a certificate, be van rakva az egyik oldalra, kezelve van a privát kulcsa, akkor a kliens oldalon igen is stimmeljen hozzá minden, ne kelljen kikapcsolni a verifikációt. Főleg ha a kliens is egy szerver valójában, nem pedig sok külön gép. Ebből lesznek azok a papíron fasza auditok, hogy SSL van? igen van! checkbox oké, közben mégsem tekinthető biztonságosnak a hálózati forgalom.
- A hozzászóláshoz be kell jelentkezni
Nagy különbség van a plain-text és a bármilyen okból nem megbízhatónak nyilvánított titkosított kapcsolat között.
Csak egy példa: hazai adatközpont random munkatársa aki hozzáfér a hálózathoz egy sima packet capture-el láthatja a plain textben küldözgetett adatokat.
Az hogy a cert chainnel mi van az egy teljesen külön téma szerintem.
- A hozzászóláshoz be kell jelentkezni
hazai adatközpont random munkatársa
Ezt azért vesd össze azzal, amit én írtam: "izolált környezet"
- A hozzászóláshoz be kell jelentkezni
Ebből lesznek azok a papíron fasza auditok, hogy SSL van? igen van! checkbox oké
Plain HTTP forgalom tcp/80-on? Nálunk azt tilos! (Hiába fejted ki, hogy a bootstrapping folyamat csak http-n támogatott és az onnan letöltött adatot ellenőrzi a kliens gpg-vel). Átraktuk másik portra. Plain HTTP magas porton? Így mehet, semmi probléma :D
- A hozzászóláshoz be kell jelentkezni
Miután a mai nap családozással kipihentem magam, gondoltam játszom egyet ezzel az SNI-SAN dologgal. Szóval itt most egy kis subtopic következik.
Ugye onnan indulunk, hogy a proxy_ssl_server_name off; -tól elindult a forgalom.
Ezen felbátorodva gondoltam egyet és generáltam egy új kulcsot a Tomcat alá CN=bonita és SAN=dns:bonita.poc.local -alias tomcat adatokkal, majd nginx-et beállítottam, hogy
proxy_ssl_server_name on;
proxy_ssl_name bonita;
Hurrá! Továbbra is megy! Mondjuk kicsit érdekes, hogy nem a SAN-t nézi ha már van, de oké fallback ág. De próba próbája az ellenpróba!
proxy_ssl_server_name on;
proxy_ssl_name hello;
és így is meeeegy????? Belőttem a Tomcaten az ssl logolást a JAVA_OPTS -ban -Djavax.net.debug=ssl,handshake,data,trustmanager és ezt látom (a ciphereket kivettem mert így is hosszú a log)
javax.net.ssl|DEBUG|96|https-jsse-nio-443-exec-8|2025-07-12 20:59:37.768 GMT|null:-1|Consuming ClientHello handshake message (
"ClientHello": {
"client version" : "TLSv1.2",
"random" : "7719DE22725B3FE030EC454E4E369CEABBE9598D96389F95F3BA6E9196C03499",
"session id" : "267EA3301C2597464282422D4F52E3D2830994754A65A10BEBE33CA48DAA87F5",
"cipher suites" : "[TLS_AES_256_GCM_SHA384(0x1302), TLS_CHACHA20_POLY1305_SHA256(0x1303), TLS_AES_128_GCM_SHA256(0x1301), TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384(0xC02C), TLS_ECDHE_RSA_WITH_AES_256_GCM_Sjavax.net.ssl|DEBUG|96|https-jsse-nio-443-exec-8|2025-07-12 20:59:37.768 GMT|null:-1|Consuming ClientHello handshake message (
"ClientHello": {
"client version" : "TLSv1.2",
"random" : "7719DE22725B3FE030EC454E4E369CEABBE9598D96389F95F3BA6E9196C03499",
"session id" : "267EA3301C2597464282422D4F52E3D2830994754A65A10BEBE33CA48DAA87F5",
"cipher suites" : "[TLS_AES_256_GCM_SHA384(0x1302), TLS_CHACHA20_POLY1305_SHA256(0x1303), ...
, TLS_DHE_RSA_WITH_AES_128_CBC_javax.net.ssl|DEBUG|96|https-jsse-nio-443-exec-8|2025-07-12 20:59:37.768 GMT|null:-1|Consuming ClientHello handshake message (
"ClientHello": {
"client version" : "TLSv1.2",
"random" : "7719DE22725B3FE030EC454E4E369CEABBE9598D96389F95F3BA6E9196C03499",
"session id" : "267EA3301C2597464282422D4F52E3D2830994754A65A10BEBE33CA48DAA87F5",
"cipher suites" : "[TLS_AES_256_GCM_SHA384(0x1302), TLS_CHACHA20_POLY1305_SHA256(0x1303), ...
TLS_EMPTY_RENEGOTIATION_INFO_SCSV(0x00FF)]",
"compression methods" : "00",
"extensions" : [
"server_name (0)": {
type=host_name (0), value=hello
},
"ec_point_formats (11)": {
"formats": [uncompressed, ansiX962_compressed_prime, ansiX962_compressed_char2]
},
"supported_groups (10)": {
--
javax.net.ssl|ALL|96|https-jsse-nio-443-exec-8|2025-07-12 20:59:37.778 GMT|null:-1|X509KeyManager class: sun.security.ssl.SunX509KeyManagerImpl
javax.net.ssl|ALL|96|https-jsse-nio-443-exec-8|2025-07-12 20:59:37.778 GMT|null:-1|No X.509 cert selected for EC
javax.net.ssl|ALL|96|https-jsse-nio-443-exec-8|2025-07-12 20:59:37.778 GMT|null:-1|No X.509 cert selected for EdDSA
javax.net.ssl|ALL|96|https-jsse-nio-443-exec-8|2025-07-12 20:59:37.778 GMT|null:-1|No X.509 cert selected for RSASSA-PSS
javax.net.ssl|DEBUG|96|https-jsse-nio-443-exec-8|2025-07-12 20:59:37.778 GMT|null:-1|Staping disabled or is a resumed session
javax.net.ssl|ALL|96|https-jsse-nio-443-exec-8|2025-07-12 20:59:37.778 GMT|null:-1|Stapling is disabled for this connection
javax.net.ssl|DEBUG|96|https-jsse-nio-443-exec-8|2025-07-12 20:59:37.778 GMT|null:-1|Ignore, context unavailable extension: status_request
javax.net.ssl|DEBUG|96|https-jsse-nio-443-exec-8|2025-07-12 20:59:37.779 GMT|null:-1|Produced server Certificate message (
"Certificate": {
"certificate_request_context": "",
"certificate_list": [
{
"certificate" : {
"version" : "v3",
"serial number" : "0098ABBD14A169B621",
"signature algorithm": "SHA256withRSA",
"issuer" : "CN=bonita, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown",
"not before" : "2025-07-12 20:10:51.000 GMT",
"not after" : "2025-10-10 20:10:51.000 GMT",
"subject" : "CN=bonita, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown",
"subject public key" : "RSA",
"extensions" : [
{
ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
DNSName: bonita.poc.local
]
},
{
ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 61 6A 14 29 F8 5A 1B D0 D4 5F 0E DA 94 41 FC 51 aj.).Z..._...A.Q
0010: 1D 82 3B E5 ..;.
]
]
}
]}
"extensions": {
<no extension>
}
},
]
}
)
SHA(
...
0FF)]",
"compression methods" : "00",
"extensions" : [
"server_name (0)": {
type=host_name (0), value=hello
},
"ec_point_formats (11)": {
"formats": [uncompressed, ansiX962_compressed_prime, ansiX962_compressed_char2]
},
"supported_groups (10)": {
Szóval a client_hello szépen beküldi, hogy
"server_name (0)": {
type=host_name (0), value=hello
},
a Tomcat meg kiszolgálja a certet amiben sehol nem szerepel az, hogy hello. Akkor most hogy is van ez a cert feloldás?
Ha már ott voltam, csak a teljesség kedvéért megnéztem, mit küld az nginx ha a proxy_ssl_name nincs megadva, csak a proxy_ssl_server_name on; Ezt:
"extensions" : [
"server_name (0)": {
Illegal server name, type=host_name(0), name=bonita_runtime, value={626F6E6974615F72756E74696D65}
},
- A hozzászóláshoz be kell jelentkezni
Ha a kliens küld valamit SNI-ben, de a szervernek épp olyan cert-je nincs, akkor a legtöbb szerver válaszol "valamelyik" certificate-jével, tipikusan be lehet állítani, hogyha több is van, hogy melyik legyen a fallback erre az esetre.
Ilyen esetben ha a kliens ellenőrzi a szerver cert-et, akkor a kliens hibát jelez. Ha nem ellenőriz, akkor mehet tovább a dolog, és sok szerver ilyenkor nem is foglalkozik már az SNI értékkel és certificate-tel a virtual host kiválasztásakor, hanem csak a Host headert nézi.
Az ajánlásom továbbra is az, ha ragaszkodsz a TLS-hez, akkor ne kikapcsold a kliensen a certificate ellenőrzést, hanem akkor legyen megoldva, hogy a kliens bízzon a szerver tanúsítványt aláíró CA-ban, és a hostnév is stimmeljen.
- A hozzászóláshoz be kell jelentkezni
Köszi ez hasznos volt.
Tehát akkor a probléma ha jól értem: az nginx technikailag enged megadni RFC-nek nem megfelelő hostname-et a proxy_pass-ban (underscore a hostname-ben), és ha nem adsz meg proxy_ssl_name-ben semmit amivel ezt felülírod, akkor: "By default, the host part of the proxy_pass URL is used. "
Tehát SNI-ben "Illegal server name" kerül átadásra, ez pedig kiakasztja a tomcat-et ("ssl/tls alert illegal parameter" az eredeti error)
- A hozzászóláshoz be kell jelentkezni
Igen, mivel te magad írtad, hogy az
nginx.conf: ssl_verify off;
Mivel ez be van állítva, az nginx-et pont nem érdekli a cert tartalma.
A Tomcat oldalon is valami nagyon el van konfigurálva ha bármilyen névre válaszol.
Úgy látom nincs tapasztalatod a web szerverekkel, certekkel, proxy témával. Ez önmagában nem baj, mert ez is tanulható és azért vagyunk itt, hogy segítsünk egymásnak.
Ha tűzoltásról van is szó, akkor sem lehet félmunkát csinálni, mert ez így több problémát vitt a rendszerbe, mint megoldást.
Csak egy jótanács:
Sztem. az lenne a legjobb, ha elkezdenél tervezni, dokumentálni. Ez a projekt tökéletes példa arra, hogy beletanulj a dokumentálásba. Na nem a nyers konfigurációkat kell bele lemásolni, hanem össze kéne írni pár dolgot:
- A rendszer célja
- Elvárások a rendszerrel kapcsolatban vagyis a felmerült igények rögzítése
- Megvalósítási terv, lépések szakmai szemmel.
- Tervrajz a megoldáshoz, implementációhoz.(Elemek, IP címek, kommunikációs portok, titkosítás, és kommunikáció irányok)
- Megvalósítás ütemezése (kisebb szakaszokra/feladatokra bontás ha szükséges)
- Megvalósítás
- Tesztelés
- Megvalósítas során a tervtől eltérő megvalósítás visszavezetése a dokumentációba.
- Üzemeltetői dokumentáció
- Rendszer átadása
Ez mind a teljesség igénye nélkül, mert sok dologról még nem is tudtam írni, mint SLA, hozzáférés kezelés stb.
Viszont sokat segítene átlátni a problémákat a rendszereddel.
Ezekkel nem elvenni akarom a kedvedet, hanem rávilágítani arra, hogy ha megfelelő sorrendben haladsz akkor tudsz rendszert építeni bármiből is.
- A hozzászóláshoz be kell jelentkezni
Van egy olyan érzésem, hogy nem olvastad végig a posztot amire válaszoltál. Én úgy látom megvan a probléma.
- A hozzászóláshoz be kell jelentkezni
A valódi probléma az, amit írtam fentebb is. Kevésbé szofisztikáltan megfogalmazva: Össze-vissza tákolt megoldás helyett újra kéne gondolni az egészet és normálisan megvalósítani. Az, hogy a problémák sorra esnek ki logokban az nem véletlen...
Próbáltam a kérdezőt a helyes irányba fordítani. Ennyi és nem több.
- A hozzászóláshoz be kell jelentkezni
Véletlenül nem manager vagy? ;)
Bocs, de kicsit azt látom, hogy high levelen próbálsz megoldást találni low-level problémákra, amiket nem dokumentáció írással lehet megoldani, hanem a dokumentáció elolvasásával.
Egyébként ez egy hatalmas iparági probléma.
- A hozzászóláshoz be kell jelentkezni
Na az az egy még nem vagyok 😂
Valószínűleg elkerülte a figyelmed az eredeti probléma, amit utólag megosztott a posztoló:
Az alapprobléma az volt, hogy a Tomcat a http Connector esetén rosszul generálta ki a redirect uri-t
Tehát az Nginx csak a hiba eltakarása, de nem a megoldása. Igen dokumentációkat kéne olvasnia hozzá és erre próbálom rávezetni anélkül, hogy elvenném a kedvét az egésztől. Ugyanis ha leül és tervezni kezd rájön, hogy bizony utána kell menni dolgoknak és ez neki sokkal nagyobb siker lesz, mintha itt leírjuk a komplett megoldást neki.
Ugyanakkor életem során rengeteg ehhez hasonló megoldást kellett újra implementálni, mert a kedves előd lelépett mindenféle dokumentáció, átadás nélkül. Aztán senki sem mert hozzányúlni, mert fogalma se volt, hogy mi miért van benne, és évekig nézegették, hogy ott fut. Aztán találtak egy olyan embert, mint én aki leült megértetette mit akart a költő, újratervezte, dokumentálta, újraimplementálta sokszor nagyságrendekkel egyszerűbben a megoldást.
Szóval én a minőségi megoldás híve vagyok, mert csak az üzemeltethető hosszú távon.
- A hozzászóláshoz be kell jelentkezni
Ok, egyetértek azzal amit írsz.
Viszont a posztolóról nem tudjuk, hogy milyen szakmai múltja van, és nem is kért segítséget abban, hogy hogyan tervezzen rendszereket, viszont volt egy konkrét hiba ami itt a topicban elég szépen debugolva lett, és te az utolsó erről szóló posztjára válaszoltál egy szerintem ahhoz nem kapcsolódó hozzászólással.
Az alapproblémáról viszont nem osztott meg túl sok információt, és nem is erről szólt a topik. Na mindegy is, minden további csak fölösleges bytepazarlás.
- A hozzászóláshoz be kell jelentkezni
torolheto hsz
- A hozzászóláshoz be kell jelentkezni