Certyfikaty podpisane SSL do użytku wewnętrznego

Question

Mam rozproszoną aplikację składającą się z wielu komponentów, które komunikują się za pośrednictwem protokołu TCP (na przykład JMS) i protokołu HTTP. Wszystkie komponenty działają na wewnętrznym sprzęcie, z wewnętrznymi adresami IP i nie są dostępne publicznie.

Chcę, aby komunikacja była bezpieczna przy użyciu protokołu SSL. Czy ma sens kupowanie podpisanych certyfikatów od znanego urzędu certyfikacji? A może powinienem użyć samopodpisanych certyfikatów?

Moje zrozumienie zalet zaufanych certyfikatów polega na tym, że organ jest podmiotem, któremu można zaufać przez ogół społeczeństwa - ale jest to problem tylko wtedy, gdy opinia publiczna musi mieć pewność, że podmiot w określonej domenie jest którzy mówią, że są.

Dlatego w moim przypadku, gdy ta sama organizacja jest odpowiedzialna za komponenty na obu końcach komunikacji, a wszystko pomiędzy nimi, publicznie zaufany organ byłby bezcelowy. Innymi słowy, jeśli wygeneruję i podpiszę certyfikat dla mojego własnego serwera, wiem, że jest godny zaufania. Nikt spoza organizacji nigdy nie zostanie poproszony o zaufanie do tego certyfikatu. To jest moje rozumowanie - czy mam rację, czy jest jakaś potencjalna korzyść z używania certyfikatów znanego organu?

Answer 1

Powiedziałbym, że jest to dość bezpieczne, chyba że podejrzewasz, że infiltrator ninja zamieni twój serwer na ciebie.

Trzecia strona jest po to, aby utrudnić sobie po prostu "podniesienie poziomu" & generowania "nowego certyfikatu. Ktoś mógłby odtworzyć samopodpisany certyfikat na nowej maszynie z tymi samymi szczegółami, nie byłby to ten sam certyfikat, musiałbyś dodać do niego wyjątek, ale użytkownicy prawdopodobnie nie zauważyliby różnicy .

Answer 2

Nie ma potrzeby używania zewnętrznego publicznego urzędu certyfikacji w zamkniętym projekcie społeczności. W wielu większych organizacjach obsługują one wewnętrzną PKI, aby wydawać certyfikaty dla takich projektów wewnętrznych. Zaletą korzystania z PKI jest to, że można ustanowić relację zaufania między różnymi komponentami na podstawie jednego, bezpiecznie dystrybuowanego certyfikatu głównego/kotwicy zaufania.

Jeśli jednak projekt pozwolił użytkownikom wewnętrznym na bezpieczne łączenie się z usługą wewnętrzną za pośrednictwem przeglądarki internetowej, warto rozważyć użycie publicznego certyfikatu wystawionego przez CA. Alternatywą jest upewnienie się, że każda przeglądarka, która może potrzebować połączyć się z twoją usługą, zaufała twojemu certyfikatowi root; to ma zapobiegać komunikatom ostrzegawczym przeglądarki.

Answer 3

Dopóki twój system działa wewnątrz twojej grupy i nie ma planów jego rozbudowy (a plany się zmieniają, więc miej to na uwadze), to dobrze jest ustawić własną prostą infrastrukturę PKI.

Jeśli rozwiniesz się poza swoją organizację, wystarczy, że przekażesz certyfikat główny stronom, z którymi będziesz się komunikować. Daje to właściwie drobną kontrolę nad swoimi partnerami, jak bardzo chcą oni zaufać w stosunku do publicznej infrastruktury CA.