TLS - ilość certyfikatów

0

Jak napiszę pytanie, to czasem odpowiedź sama się nasuwa ;-) A może ktoś będzie w stanie coś dobrego podpowiedzieć, wypunktować bzdurę.

Mam następującą architekturę:

Klient -> LB#1 (FQDN=www.big.foo) -> Server1(FQDN=s1.foo.bar)..SerwerN(sn.foo.bar) -> LB#2 -> InnyServer1(FQDN=i1.baz)..M(im.baz) -> ...

LB#1, LB#2 - load balancery z funkcją proxy SSL
FQDN - fully qualified domain name
Server/InnyServer - serwery hostujące aplikacje webowe

Klient wchodzi na stronę www.big.foo -> LB uderza do najmniej obciążonego serwera -> który to serwer może wywołać jakieś API (znowu load balancer przykrywa pulę serwerów).

Założenia są takie:

  1. Cały ruch ma być szyfrowany
  2. Między Server i InnyServer jest 2-way-SSL.

I teraz, ile certyfikatów potrzeba by:

  • działało
  • było "zgodne ze sztuką"/bezpieczne

Wydaje mi się:

  1. Server1..ServerN mogą współdzielić certyfikat, który będzie miał SubjectAlternateName www.big.foo + *.foo.bar (bez tego *.foo.bar chyba nie zadziała host name checking wspomniane w RFC dla HTTP over TLS?)

Podobnie współdzielony certyfikat dla InnyServer1..InnyServerM

  1. Ten jeden cert może być użyty jako Client Cert w komunikacji z "InnyServer"? (Musiałby akceptować tylko CA root + pośrednie CA + "Server cert")

Obsługi CA root + pośrednie CA nie uwzględniam, bo to taka wisienka na torcie w porównaniu do reszty.

Pytania:
a) Czy 1 certyfikat per pula serwerów w opisanym scenariuszu to pragmatyzm/zła praktyka? Jakby nie patrzeć, to klucz prywatny poniewiera się w wielu miejscach.
b) Czy wystawianie w certyfikacie w SubjectAlternateNames nazw wewnętrznych (niedostępne publicznie) jest akceptowalne? Chodzi o te *.foo.bar.
c) Wydaje mi się, że technicznie można by to załatwić jednym certyfikatem tylko dorzucić wiele wpisów SubjectAlternateName. Praktycznie wolałbym 2 certy (ze względu na to, że pule serwerów są w różnych strefach bezpieczeństwa).

Jakieś przemyślenia?

0

Po namyśle wydaje się, że rozwiązanie w postaci:

  1. Server1 - dla ruchu przychodzącego przedstawia się certyfikatem wystawionym z SubjectAlternateNames na *.big.foo
  2. Server1 - dla ruchu wychodzącego (do InnyServer) legitymuje się certyfikatem wystawionym z SAN=*.foo.bar
  3. Server1 - w trusted certs ma certyfikat wystawiony na *.baz (+ łancuch certyfikatów CA podpisującego)
  4. InnyServer - dla ruchu przychodzącego przedstawia się certyfikatem wysatwionym na SAN=*.baz
  5. InnyServer - w trusted certs ma: *.foo.bar + CA root + CA pośrednie podpisujące SAN=*.foo.bar

W sumie:

  • 2 x certyfikat serwera (Server / InnyServer)
  • 1 certyfikat klienta (Server->InnyServer na potrzeby 2-way-SSL)
  • łańcuchy certyfikatów CA (podpisujących *.big.foo,*.foo.bar,*.baz)

Tożsamość Server1 nie jest wykorzystywana jako certyfikat klienta, żeby nie eksponować FQDN wewnętrznych serwerów.

Nie widzę jakichś szczególnych korzyści z posiadania certyfikatów per instancja serwera, a wizja piekła zarządzania dużą liczbą certów jest przerażająca ;-)

Temat raczej do zamknięcia.

1

@yarel: zobacz sobie Vault oraz ACME protocol. W ten sposób możesz dynamicznie generować nowe certy ze swojego CA i mieć po jednym certyfikacie na wewnętrzny serwer.

1 użytkowników online, w tym zalogowanych: 0, gości: 1