Wszyscy "kochają" JAVĘ... a od kiedy to Oracle przejął ją od SUN'a to co rusz mamy nowe problemy.
Tym razem padło na jre7u51 - czyli na tę chwilę najnowsza wersja (miałem to już w poprzednich wersjach, ale nie bolało. Teraz sprawa zrobiła się nagląca).
Sam nie wiem co mnie podkusiło do aktualizacji. Być może konieczność każdorazowego odkładania aktualizacji przy wchodzeniu na kolejne urządzenie spod marki IBM. Historycznie IBM mocno "współpracował" z SUN'em i dlatego 99% produktów tego giganta oparte jest o to ustrojstwo.
Ale do rzeczy...
Łączę się przykładowo z aplikacją webową do zarządzania przełącznikiem SAN. Wiadomo - adresik i przekierowanie na EZSwitch, pobranie apletu... i bum
Taka to niespodzianka...
Ale to nam nie straszne... sądząc, że to prościzna wchodzę do Java Control Panel (cmd: javaws -viewer), przechodzę na zakładkę "Security" i dodaję adres przełącznika do listy wyjątków (swoją drogą security level juz mam na najniższym poziomie - czyli Medium (jaką to ciekawą skalę ma Oracle!).
Kolejna próba i to samo... klikamy szczegóły a tam szum javy:
Ale rzuca mi się CertPathValidator i jakieś PKIX path validation... tylko gdzie tego szukać, bo w GUI nie ma... Może to coś ukrytego związanego z opcja dotyczącą certyfikatów (validacja OCSP?).
No to znowu Java Control Panel, zakładka "Advanced" i wyłączamy opcję onlinowego weryfikowania certyfikatów (czyli zaznaczamy w "Perform certificate revocation checks on" opcję "Don't not check (not recommended)".
Przy okazji notujemy w pamięci, że to menu zmienia się co druga wersję Javy bo kiedyś jeszcze było coś jak "Allow user to grant permissions to content from an untrusted authority" co chyba załatwiłoby nasz problem... ale terazjuż tego nie ma... zonk!
Kolejny test i to samo... buuu... jak ja się dostanę do tego przełącznika... (jest ssh, ale ja chce obrazki pooglądać!)
Jesteśmy twardzi - walka trwa dalej... google nasz pan - każe nam:
1. usunąć zawartość cache - włącznie z aplikacjami, resource;ami itp
2. usunąć trusted.certs z katalogu javy i profilu usera
--- nic co by działało...
Ale chwila... bawiąc się z tymi plikami trafiamy na coś co się nazywa java.security (w katalogu Javy w podkatalogach: "jre/lib/security/java.security").
To może być plik z ustawieniami z JCP, a jak wiadomo GUI czasami potrafi coś ukrywać... no to otwieramy znowu siano (ale to wina notatnika).
No to jedziemy czymś sensowniejszym i czytamy (zaznaczyłem co ciekawsze):
# Algorithm restrictions for certification path (CertPath) processing
#
# In some environments, certain algorithms or key lengths may be undesirable
# for certification path building and validation. For example, "MD2" is
# generally no longer considered to be a secure hash algorithm. This section
# describes the mechanism for disabling algorithms based on algorithm name
# and/or key length. This includes algorithms used in certificates, as well
# as revocation information such as CRLs and signed OCSP Responses.
#
# The syntax of the disabled algorithm string is described as this Java
# BNF-style:
# DisabledAlgorithms:
# " DisabledAlgorithm { , DisabledAlgorithm } "
#
# DisabledAlgorithm:
# AlgorithmName [Constraint]
#
# AlgorithmName:
# (see below)
#
# Constraint:
# KeySizeConstraint
#
# KeySizeConstraint:
# keySize Operator DecimalInteger
#
# Operator:
# <= | < | == | != | >= | >
#
# DecimalInteger:
# DecimalDigits
#
# DecimalDigits:
# DecimalDigit {DecimalDigit}
#
# DecimalDigit: one of
# 1 2 3 4 5 6 7 8 9 0
#
# The "AlgorithmName" is the standard algorithm name of the disabled
# algorithm. See "Java Cryptography Architecture Standard Algorithm Name
# Documentation" for information about Standard Algorithm Names. Matching
# is performed using a case-insensitive sub-element matching rule. (For
# example, in "SHA1withECDSA" the sub-elements are "SHA1" for hashing and
# "ECDSA" for signatures.) If the assertion "AlgorithmName" is a
# sub-element of the certificate algorithm name, the algorithm will be
# rejected during certification path building and validation. For example,
# the assertion algorithm name "DSA" will disable all certificate algorithms
# that rely on DSA, such as NONEwithDSA, SHA1withDSA. However, the assertion
# will not disable algorithms related to "ECDSA".
#
# A "Constraint" provides further guidance for the algorithm being specified.
# The "KeySizeConstraint" requires a key of a valid size range if the
# "AlgorithmName" is of a key algorithm. The "DecimalInteger" indicates the
# key size specified in number of bits. For example, "RSA keySize <= 1024"
# indicates that any RSA key with key size less than or equal to 1024 bits
# should be disabled, and "RSA keySize < 1024, RSA keySize > 2048" indicates
# that any RSA key with key size less than 1024 or greater than 2048 should
# be disabled. Note that the "KeySizeConstraint" only makes sense to key
# algorithms.
#
# Note: This property is currently used by Oracle's PKIX implementation. It
# is not guaranteed to be examined and used by other implementations.
#
# Example:
# jdk.certpath.disabledAlgorithms=MD2, DSA, RSA keySize < 2048
#
#
jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024
No i mamy w jednym miejscu naszego PKIX i CertPathValidator z tego "szumu" ze szczegółów błędu.
Wracamy do błędu i widać jeszcze "algorithm constraints check failed" i sprawa staje się jasna, bo patrząc co to robi... blokuje MD2 i RSA mniejsze niż 1024bity.
Wracamy do błędu i widać jeszcze "algorithm constraints check failed" i sprawa staje się jasna, bo patrząc co to robi... blokuje MD2 i RSA mniejsze niż 1024bity.
Hmm...
a jakby tu coś... hmm... no to zmieniamy 1024 na 512 i zapisujemy pliczek.
Restart przeglądarki i ... oooo... działa...
Swoją drogą notka drogiego Oracle'a też jest fajna: "It is not guaranteed to be examined and used by other implementations.". Cóż za treściwe uprzedzenie...
Hurra... mogę teraz mieszać w SAN'ie
