nginx upstream ssl parameter error

Linux-haladó

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.

  • 644 megtekintés

( Kayapo | 2025. 07. 11., p – 13:47 )

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

----
올드보이

( mauzi v | 2025. 07. 11., p – 14:30 )

Szerkesztve: 2025. 07. 11., p – 14:30

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.

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

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?

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

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.

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

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.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

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.

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.

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

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

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

( buga v | 2025. 07. 11., p – 15:04 )

Ha megemeled "debug" szintre az error logolást, nem kapsz részletesebb hibaüzenetet?

( igor | 2025. 07. 11., p – 16:33 )

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

( NevemTeve | 2025. 07. 11., p – 17:06 )

Szerkesztve: 2025. 07. 11., p – 17:17

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                        |              +-------------------------+
+-------------------------------+

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! :)

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

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.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

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.

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.

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

( pentike | 2025. 07. 12., szo – 23:31 )

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}
    },
 

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.

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)

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

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.

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.

( AMDFan | 2025. 07. 14., h – 14:45 )

Szerkesztve: 2025. 07. 14., h – 14:46

torolheto hsz