JNLP의 JAR 리소스는 동일한 인증서로 서명하지 않습니다.
-
08-07-2019 - |
문제
나는 몇 년 동안 웹 스타트와 함께 일해 왔으며 항아리에 서명 한 경험이 있습니다. 웹 시작으로 RCP 앱을 배포하려는 첫 번째 시도를하고 있으며 실제로 동일한 인증서로 모든 항아리에 서명했지만이 오류가 계속됩니다.
다른 사람이 이것을 발견 한 적이 있습니까? 그렇다면 수정 방법에 대한 아이디어가 있습니까?
다른 팁
이것은 당신이 도서관으로 사용하는 이미 서명 된 항아리의 오래된 명백한 항목 일 수 있습니다. WebStart를 통해 Jogl 에서이 문제를 겪었습니다. 이 시도:
모든 항아리를 압축하고 모든 메타 인프 디렉토리를 제거하고 항아리로 다시 서명하십시오.
JNLP/WebStart는 주어진 항아리에 대해 Jarsigner.exe를 통해 여러 서명/서명을 좋아하지 않는다는 것을 알았습니다. Bouncycastle과 같은 항아리 (Presigned)와 같은 항아리가 회사의 인증서와 함께 다시 서명되면, 육안 검사를 통해 새로운 인증서와 서명이 JAR에서 올바르게 수행된다고 믿게됩니다. 그러나 JNLP는 Meta-Inf에서 첫 번째 (알파벳순?) 서명 만 읽을 수 있으므로 다른 항아리 (각 항아리에 단 하나, 회사, 서명이있는)와 일치하지 않는다고 불평하는 것은 불평합니다.
나는 Matthew가 PESIGINED BOUNCYCASTLE 항아리와 묘사 한 것과 똑같은 경험을 가졌습니다. 그러나 JRE 버전 1.6.0_14 이상이 여러 서명을 가진 항아리를 기꺼이 받아 들일 것임을 알았습니다. 따라서 위에서 설명한 JNLP '구성 요소 확장 메커니즘'을 사용할 필요가 없었습니다.
추신은 1.6.0_14 릴리스 노트 에서이 수정에 대한 명백한 언급을 찾지 못했습니다. 그러나 여러 서명 된 JAR이 모든 버전 (최소 14-17 + 24)에서 작동하는지 확인했습니다.
FAQ 중 하나에 대한 설명을 참조하십시오. 다른 인증서로 서명 한 여러 개의 JAR 파일을 어떻게 사용합니까?
올바른 해결책.
내 프로젝트에서 발생한 일은로드 밸런서 풀에 몇 가지 인스턴스가 있다는 것입니다. 이전 버전의 코드와 새 버전이있는 인스턴스가 있습니다. 따라서 동일한 인증서로 서명되지 않은 인증서가 있습니다 ...
다음 스크립트에는 /일부 /lib 디렉토리의 각 JAR에있는 RSA 인증서의 일련 번호가 나열되어 있으며 잘못된 인증서로 서명 한 항아리를 찾는 데 도움이됩니다.
for f in $( find /some/lib -type f -name '*.jar' )
do
serial=$( unzip -p $f 'META-INF/*.RSA' |
openssl pkcs7 -inform der -print -noout |
grep --max-count=1 serialNumber | cut -d: -f2- | tr -d ' ' )
printf "%40s: %s\n" "$serial" "$f"
done