Я пытаюсь устранить проблему с подписанными банками, не работающими под appletviewer.Моя главная цель - запустить его вне браузера, поэтому я попытался использовать appletviewer - если у вас есть другие предложения, дайте мне знать.
Вот контекст:
Вот проблема:
- У меня есть jar myjar.jar, который содержит апплет внутри
- Он работает правильно в браузере, но не при запуске под appletviewer
Баночка подписана:
$ jarsigner -verify -certs -verbose -keystore /etc/ssl/certs/java/cacerts myjar.jar
...
smk <file size> <file date> <file name>
X.509, CN=xxx, OU=xxx, OU=xxx, O=xxx, L=xxx, ST=xxx, C=xxx
[certificate is valid from m/d/y h:m PM to m/d/y h:m PM]
X.509, CN=yyy, OU=yyy, OU=yyy, O=yyy, C=yyy
[certificate is valid from m/d/y h:m PM to m/d/y h:m PM]
[KeyUsage extension does not support code signing]
X.509, OU=zzz, O=zzz, C=zzz (alias1)
[certificate is valid from m/d/y h:m PM to m/d/y h:m PM]
...
jar verified.
и, хотяпромежуточный сертификат подписи (yyy выше) отсутствует, корневой (zzz - или alias1):
$ keytool -list -v -keystore /etc/ssl/certs/java/cacerts -storepass changeit|grep alias1
alias1, Mmm d, yyyy, trustedCertEntry,
Запуск:
$ appletviewer myhtml.html
дает:
Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission preferences)
Набор вопросов 1:
- Предполагается ли, что при наличии корневого сертификата все следующие промежуточные сертификаты считаются приемлемыми для целей проверки?В вышеприведенном случае необходимо ли указывать yyy в файле cacerts?
- Когда jar подписан, как myjar.jar, предполагается, что appletviewer должен работать без ограничений?
- Есть ли лучший способ запустить его, чтобы избежать этого?
- Почему в браузере это работает иначе, чем в appletviewer?
Не зная выше, я попытался добавить сертификат в другой локальный файл, называемый cacerts2.Я могу подтвердить, что:
- перечисляет keytool, что сертификат в cacerts
вывод jarsigner теперь выглядит так:
$ jarsigner -verify -certs -verbose -keystore cacerts2 myjar.jar
...
smk <file size> <file date> <file name>
X.509, CN=xxx, OU=xxx, OU=xxx, O=xxx, L=xxx, ST=xxx, C=xxx
[certificate is valid from m/d/y h:m PM to m/d/y h:m PM]
X.509, CN=yyy, OU=yyy, OU=yyy, O=yyy, C=yyy (alias2)
[certificate is valid from m/d/y h:m PM to m/d/y h:m PM]
[KeyUsage extension does not support code signing]
X.509, OU=zzz, O=zzz, C=zzz (alias1)
[certificate is valid from m/d/y h:m PM to m/d/y h:m PM]
...
jar verified.
Обратите внимание, что теперь у меня есть промежуточный псевдоним (yyy - или alias2), присутствующий в выходных данных и проверенный как на alias1, так и на alias2.Запуск приложения для просмотра апплетов выглядит следующим образом:
$ appletviewer -J-Djavax.net.ssl.trustStore=cacerts2 -J-Djavax.net.ssl.trustStorePassword=changeit myhtml.html
по-прежнему приводит к тому же исключению.
Вопрос задан 2:
- Указанный выше правильный способ подачиtrust store?
- Означает ли вышесказанное, что appletviewer будет использовать его так же, как jarsigner при передаче команды -keystore для целей проверки?
Третье, что я попробовал, этосделать файл политики следующим образом (это в mypolicy.policy):
keystore "cacerts2";
// Tried with this and without the next line:
//keystorePasswordURL "cacerts.pass";
// where file cacerts.pass has only "changeit" / "changeit\n" in it (tried both)
// Tried the following three:
grant signedBy "alias1" {
//grant signedBy "alias2" {
//grant {
permission java.lang.RuntimePermission "preferences";
};
и запустить так:
$ appletviewer -J-Djava.security.policy=mypolicy.policy myhtml.html
и вот так:
$ appletviewer -J-Djavax.net.ssl.trustStore=cacerts2 -J-Djavax.net.ssl.trustStorePassword=changeit -J-Djava.security.policy=mypolicy.policy myhtml.html
Результаты:
- грант без каких-либо подписанных спецификаций сработал, поэтому я могу подтвердить, что политика подобрана
- грант с любым подписанным бэком не удался
Вопросset 3:
- Это правильный способ указать policy и signatureBy?Я считаю документы из Oracle неполными по этой теме
- Используется ли даже файл политики, когда подписан jar?
- Есть еще идеи?:)