Czy to jest złą praktyką używanie standardowego magazynu kluczy Java

Jako zaufany sklep dla tomcat używaliśmy standardowego magazynu kluczy Java ($JAVA_HOME/jre/lib/security/cacerts). A ten serwer tomcat komunikuje się z jakimś innym serwerem. Ostatnia aktualizacja systemu operacyjnego (AIX) najwyraźniej przepisała plik pod numerem $JAVA_HOME/jre/lib/security/cacerts, co spowodowało utratę certyfikatów i wiele problemów z aplikacją hostowaną w tomcat.Czy to jest złą praktyką używanie standardowego magazynu kluczy Java

Patrząc na to, czy to jest złą praktyką przekazywanie na $ JAVA_HOME/jre/lib/security/cacerts? Jakie są alternatywne (lepsze | standardowe) sposoby rozwiązania tego scenariusza?

Źródło

2011-10-25 ring bearer

java_home może się różnić w zależności od platformy, będziesz chciał na to uważać. Osobiście wyszukałbym inny folder ulowy. – Tim

Pod względem tego, co znajduje się w pliku cacerts, nie musi to być gorsza praktyka niż poleganie na domyślnych certyfikatach urzędu certyfikacji zainstalowanych w systemie operacyjnym lub przeglądarce, ale to nie znaczy, że jest świetny.

Sun/Oracle mają trochę „Ważna uwaga” gdzieś w środku JSSE Reference Guide about this:

UWAGA: JDK statki o ograniczonej liczbie zaufanych głównych certyfikatów w/lib/security/plik cacerts. Jako dokument udokumentowany w keytool, Twoim obowiązkiem jest utrzymywanie (to jest dodawania/usuwania) certyfikatów zawartych w tym pliku, jeśli korzystasz z tego pliku jako magazynu zaufanych certyfikatów.

W zależności od konfiguracji certyfikatów serwerów, z którymi się kontaktujesz, możesz potrzebować dodać dodatkowe certyfikaty główne. Uzyskaj wymagane certyfikaty główne od odpowiedniego dostawcy.

Pod względem konfiguracji, dla konkretnych zastosowań, gdzie miałem do zainstalowania „lokalne” certyfikatów CA, uważam, że bardziej stabilne, aby korzystać z lokalnego magazynu zaufanych certyfikatów (na przykład, podany z javax.net.ssl.trustStore).

Źródło

2012-01-18 02:32:57 Bruno

Nie jestem pewien, ale zakładając, że twoje założenia są poprawne, zachowaj ostrożność podczas umieszczania pliku kluczy. Gorąco polecam umieszczenie go w folderze Apache.

Domyślnie w produkcie WebSphere Magazyn kluczy działa w ten sposób, ponieważ przynosi ona własnej JVM :)

Źródło

2011-10-25 20:31:29

GlassFish ma również swój własny magazyn kluczy i cacerts. – Hiro2k

to nie jest złą praktyką, jeśli masz procesie budowy, który będzie powtórzyć importu.

Źródło

2011-10-25 23:13:28 EJP

Tak, to jest zła praktyka.

Najlepszą praktyką jest ograniczenie do minimum zaufanych certyfikatów.
Powinieneś więc używać własnego magazynu kluczy z certyfikatami zaufanymi przez Twoją aplikację.

Źródło

2011-10-28 20:05:40 Cratylus

To narusza cały cel PKI. Chodzi o to, że obecność zaufanych katalogów głównych umożliwia utworzenie łańcucha zaufania, dzięki czemu można ufać dowolnemu certyfikatowi podpisanemu przez zaufany urząd certyfikacji. Konflikujesz uwierzytelnianie, do czego służą PKI i certyfikaty, z autoryzacją, która jest problemem w domenie aplikacji.Zasadniczo łamane jest łączenie tych dwóch oddzielnych funkcji. – EJP

@EJP: Kiedy masz punkt końcowy komunikujący się tylko z określonymi jednostkami w sieci, dlaczego miałbym zezwolić na to, aby certyfikaty były zaufane, które są zaufane przez * dowolny * CA skonfigurowany w moim systemie (niezależnie od tego, czy jest to Linux, certyfikaty Java, certyfikaty systemu Windows itp)? – Cratylus

Aktualizacja systemu AIX jest łatką. Każda łatka nie może usuwać/nadpisywać danych użytkownika. Proponuję, aby użytkownicy dotknięci tego rodzaju utratą danych poprosili IBM o naprawienie procedury łatania. Dla porównania łatka serwera httpd nie zastępuje/nie usuwa konfiguracji, mimo że znajduje się w katalogu programu.

Źródło

2016-02-21 23:09:00 user250343

Czy to jest złą praktyką używanie standardowego magazynu kluczy Java

Odpowiedz

Powiązane problemy