2016-09-11 21 views
5

Mam następującą konfigurację:konfiguracji reverse proxy HTTPS z wieloma certyfikatami z Apache

  • jeden publiczny adres IP
  • 2 różne nazwy domeny wskazujące na samym IP powyżej: domain1.com i domain2.com
  • dwa różne certyfikaty SSL: jeden dla domain1.com i jeden dla domain2.com
  • 2 maszyny fizyczne w sieci LAN (192.168.1.10 i 192.168.1.20) uruchomione Apache2 Debianem 8,5

Przetestowałem oba serwery niezależnie przesyłając ruch do portu 443 do jednego z komputerów. Działają ładnie.

Teraz jestem spedycja wszystkie port 443 żądań przybywających do publicznego adresu IP do pierwszego serwera na 192.168.1.10 i chciałbym ten serwer działa jako serwer HTTPS dla https://domain1.com i przekierowywania żądań dla https://domain2.com zająć 192.168. 1.20

Próbowałem skonfigurować odwrotne proxy na pierwszym komputerze. Przekierowuje żądania dla domeny2 do komputera pod adresem 192.168.1.20, ale służy certyfikatowi dla domeny 1. Jak skonfigurować odwrotne proxy, aby przedstawić odpowiedni certyfikat dla każdego z moich serwerów?

z góry dziękuję. julia

+0

serwer musi wybrać certyfikat do użycia na podstawie rozszerzenia SNI (wskazanie nazwy serwera). Spójrz na wsparcie SNI w Apache, prawdopodobnie to obsługuje. – Adrien

+0

Dziękuję. Spojrzałem na SNI, ale nie mogłem go uruchomić. Jestem trochę nowicjuszem z linux :( –

+0

czy możesz wysłać swój blok serwera do maszyny proxy? – UltrasoundJelly

Odpowiedz

0

Najprostszym "rozwiązaniem" (no, obejście) byłoby użycie pojedynczego certyfikatu zawierającego oba hosty. Jeśli nie możesz tego zrobić, musisz skonfigurować Apache SNI, tak jak: SSL with Virtual Hosts Using SNI

+0

to nie odpowiada na moje pytanie, ponieważ wszystkie certyfikaty muszą być zainstalowane na komputerze z uruchomionym apache.) Tak więc ruch z tej maszyny do inne serwery w moim Lan nie są już https, ale http. –

+0

Tylko dlatego, że masz certyfikat dla domeny 2 na pierwszym serwerze, ruch w sieci LAN nie ulegnie zmianie, nadal jest to https i jest przekazywane do portu 443 drugiego serwera. –

0

Jak niektórzy sugerowali, próbowałem użyć odwrotnego proxy Apache2. To jakoś działa, ale musisz zainstalować wszystkie certyfikaty na komputerze z uruchomionym Apache2. Tak więc ruch na sieci nie jest już https, który nie spełnia moje wymagania.

Rozwiązaniem jest użycie haproxy. Ten pakiet można skonfigurować jako przejście dla protokołu HTTPS. Istnieje wiele przykładów takich aplikacji w Internecie. Robi dokładnie to, o co proszę: mogę hostować wiele serwerów https w sieci LAN za routerem nat z jednym publicznym adresem IP. Ruch jest wysyłany przez haproxy jako https do wskazanego serwera w sieci LAN. Jeśli ktoś jest zainteresowany, chętnie podzielę się moim plikiem konfiguracyjnym, rozwiązując dokładnie problem, który przedstawiłem w moim pytaniu.

+0

Tak, proszę podzielić się, chciałbym zobaczyć, jak uniknąłeś posiadania certyfikatów domain2 na routerze nat. –

+0

Oto moja konfiguracja do dodania na końcu domyślnego pliku haproxy.cfg: –

0

Robert M: oto moja konfiguracja zostać dodane na końcu pliku domyślnym haproxy.cfg:

frontend ft_https 
    mode tcp 
    option tcplog 
    bind *:443 

    tcp-request inspect-delay 5s 
    tcp-request content accept if { req.ssl_hello_type 1 } 

    acl domain1_com req.ssl_sni -m end domain1.com # all url ending with domain1.com 
    acl domain2_com req.ssl_sni -i www.domain2.com # exactly www.domain2.com 

    use_backend b_domain1_com if domain1_com 
    use_backend b_domain2_com if domain2_com 
    default_backend b_default 

    backend b_default 
    mode tcp 
    option tcplog 
    server srv_default 127.0.0.1:1443 

    backend b_domain1_com 
    mode tcp 
    option tcplog 
    server srv_domain1 192.168.1.10:1443 

    backend b_domain2_com 
    mode tcp 
    option tcplog 
    server srv_domain2 192.168.1.20:443 

Musiałem zmienić port https na Apache na pierwszym serwerze, ponieważ do 1443 zarówno haproxy, jak i apache nie mogą łączyć się z tym samym portem 443, który znajduje się na tym samym komputerze, ale jest on niewidoczny dla użytkownika.