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:
- Cały ruch ma być szyfrowany
- 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ę:
- 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
- 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?