Apache - reverse proxy - certificate átpaszírozása

Üdv!

Van egy igen nagy problémám.

A helyzet a következő. Van egy gép (R, 172.21.35.200), ami reverse proxyzik egy másik gépre (B, 172.21.22.216). Néhány egyszerű dolog van benne definiálva, pl.:


ProxyPass /certificates https://172.21.22.216/certificates
ProxyPassReverse /certificates https://172.21.22.216/certificates
ProxyPass /common https://172.21.22.216/common
ProxyPassReverse /common https://172.21.22.216/common
ProxyPass /derek https://172.21.22.216/derek
ProxyPassReverse /derek https://172.21.22.216/derek

Ez szépen is működik, minden https- en zajlik,

:80

nem nagyon játszik.

Van egy kliens program, amivel szeretném elérni (B), de (R)- en keresztül. Ha a desktopomról (D) elindítok egy kérést, pl.

 https://172.21.35.200/derek

, az szépen landol is (D)- n. Na most eddig ok, de a kliens program használna tanusítványokat is, de az ilyen kérésekből már egy byte sem jut el (B)- hez. (R) logjában ezt találom:


[Tue May 18 12:33:11 2010] [info] [client 172.21.21.61] Connection to child 65 established (server 127.0.1.1:443)
[Tue May 18 12:33:11 2010] [info] Seeding PRNG with 648 bytes of entropy
[Tue May 18 12:33:11 2010] [debug] ssl_engine_kernel.c(1861): OpenSSL: Handshake: start
[Tue May 18 12:33:11 2010] [debug] ssl_engine_kernel.c(1869): OpenSSL: Loop: before/accept initialization
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1873): OpenSSL: read 11/11 bytes from BIO#b76c5f80 [mem: b76cb770] (BIO dump follows)
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1806): +-------------------------------------------------------------------------+
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1845): | 0000: 16 03 00 00 52 01 00 00-4e 03                    ....R...N.       |
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1849): | 0011 - <SPACES/NULS>
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1851): +-------------------------------------------------------------------------+
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1873): OpenSSL: read 76/76 bytes from BIO#b76c5f80 [mem: b76cb77b] (BIO dump follows)
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1806): +-------------------------------------------------------------------------+
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1845): | 0000: 4b f2 5e 6a d1 37 94 73-55 2e 4f a1 fc 2e 54 ea  K.^j.7.sU.O...T. |
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1845): | 0010: b6 eb a2 c3 f2 d7 11 d5-56 74 08 85 3e b4 d6 63  ........Vt..>..c |
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1845): | 0020: 00 00 26 00 39 00 38 00-35 00 16 00 13 00 0a 00  ..&.9.8.5....... |
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1845): | 0030: 33 00 32 00 2f 00 05 00-04 00 15 00 12 00 09 00  3.2./........... |
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1845): | 0040: 14 00 11 00 08 00 06 00-03 02 01                 ...........      |
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1849): | 0076 - <SPACES/NULS>
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1851): +-------------------------------------------------------------------------+
[Tue May 18 12:33:11 2010] [debug] ssl_engine_kernel.c(1869): OpenSSL: Loop: SSLv3 read client hello A
[Tue May 18 12:33:11 2010] [debug] ssl_engine_kernel.c(1869): OpenSSL: Loop: SSLv3 write server hello A
[Tue May 18 12:33:11 2010] [debug] ssl_engine_kernel.c(1869): OpenSSL: Loop: SSLv3 write certificate A
[Tue May 18 12:33:11 2010] [debug] ssl_engine_kernel.c(1269): [client 172.21.21.61] handing out temporary 1024 bit DH key
[Tue May 18 12:33:11 2010] [debug] ssl_engine_kernel.c(1869): OpenSSL: Loop: SSLv3 write key exchange A
[Tue May 18 12:33:11 2010] [debug] ssl_engine_kernel.c(1869): OpenSSL: Loop: SSLv3 write server done A
[Tue May 18 12:33:11 2010] [debug] ssl_engine_kernel.c(1869): OpenSSL: Loop: SSLv3 flush data
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1873): OpenSSL: read 5/5 bytes from BIO#b76c5f80 [mem: b76cb770] (BIO dump follows)
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1806): +-------------------------------------------------------------------------+
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1845): | 0000: 15 03 00 00 02                                   .....            |
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1851): +-------------------------------------------------------------------------+
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1873): OpenSSL: read 2/2 bytes from BIO#b76c5f80 [mem: b76cb775] (BIO dump follows)
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1806): +-------------------------------------------------------------------------+
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1845): | 0000: 02 2a                                            .*               |
[Tue May 18 12:33:11 2010] [debug] ssl_engine_io.c(1851): +-------------------------------------------------------------------------+
[Tue May 18 12:33:11 2010] [debug] ssl_engine_kernel.c(1874): OpenSSL: Read: SSLv3 read client certificate A
[Tue May 18 12:33:11 2010] [debug] ssl_engine_kernel.c(1893): OpenSSL: Exit: failed in SSLv3 read client certificate A
[Tue May 18 12:33:11 2010] [info] [client 172.21.21.61] SSL library error 1 in handshake (server 127.0.1.1:443)
[Tue May 18 12:33:11 2010] [info] SSL Library Error: 336151570 error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate Subject CN in certificate not server name or identical to CA!?
[Tue May 18 12:33:11 2010] [info] [client 172.21.21.61] Connection closed to child 65 with abortive shutdown (server 127.0.1.1:443)

Van valakinek bármi ötlete, hogy ezt a problémát hogyan lehetne feloldani? Tényleg bármilyen megoldás érdekel, akár az is, hogy az apache2- t másra cseréljük. Az egyetlen, ami nem játszik, az az, hogy a portot forwardoljuk, pedig ez elég egyszerű lenne.

1181 megtekintés

ha az a bajod (nem értelmeztem a logot), hogy a kliens user certtel szeretné magát authentikálni a szerveren, de útközben van egy man-in-the-middle attackot játszó proxy szerver, akkor a válasz "nem nyert", a "hamis" szerver nem tudja az igazinak továbbadni a user certet, mert ahhoz a kliensnél levő privát kulcsra lenne szüksége, de az csak az igazi kliensnél van meg.

0 szavazat

A hozzászóláshoz be kell jelentkezni

Igen, pontosan errol van szo. Tudom, ez egy vedelem, de ha minden adattal rendelkezem, akkor megoldhato valahogy? Tudom, tudom, a portforward siman megoldana, de most az nem jatszik sajnos.

0 szavazat

A hozzászóláshoz be kell jelentkezni

ha a kliens(ek) privát kulcsával/aival is rendelkezel, akkor elméletileg megoldható, csak a megfelelő sw-t meg kell találni/írni.

0 szavazat

A hozzászóláshoz be kell jelentkezni

Igy utananezve a kliensek kulcsa szinkronizalhato lenne a reverse proxyra, de innen hogyan tovabb? Korulbelul 200- 2000 userrol lenne szo, ez meg annyira nem lehet gond, de milyen szoftverrel, mit hova? :- ).

Koszi.

0 szavazat