Ошибка: KeyUsage не разрешает цифровые подписи - Java-апплет + взаимный SSL - PullRequest
2 голосов
/ 23 июня 2011

Мы разработали веб-приложение Java, работающее в Tomcat под IIS в Windows 2008. На веб-сайте в IIS включен двухсторонний (взаимный) SSL, требующий от клиента аутентификации с использованием сертификата x.509 (PKI) как части SSLи это прекрасно работает со всеми нашими сертификатами, использующими IE.

На сайте также есть java-апплет под названием ViewOne ImageViewer.Это хорошо работает с двусторонним SSL с некоторыми из наших сертификатов, но с другими мы получаем исключение на клиенте (java 1.6) во время SSL-рукопожатия после того, как пользователь выбрал свой сертификат аутентификации:

security: KeyUsage не допускает цифровые подписи

Наиболее очевидное различие между сертификатами заключается в том, что EKU (расширенное использование ключей) не присутствует в сертификатах, которые не работают.Работающий сертификат имеет EKU «Аутентификация клиента - 1.3.6.1.5.5.7.3.2».

Кто-нибудь знает, необходим ли EKU 1.3.6.1.5.5.7.3.2 для запуска Java-апплета илиесли это можно установить где-нибудь?Или ошибка может быть из-за чего-то еще?

Спасибо!

1 Ответ

4 голосов
/ 23 июня 2011

Стандарт, обычно используемый для проверки сертификата, приведен в RFC 5280: Профиль сертификата инфраструктуры открытого ключа Internet C.509 и список отзыва сертификатов (CRL) .Сертификаты могут иметь (как минимум) два расширения для их использования: Использование ключа и Расширенное использование ключа .

  • Использование ключа

Расширение Key Usage не говорит конкретно о клиентских сертификатах.Однако, если это расширение присутствует, необходимо установить флаг digitalSignature, поскольку во время рукопожатия SSL / TLS сообщение CertificateVerify TLS подписывается закрытым ключом для этого сертификата.Это требуется в соответствии с этим разделом RFC 5280:

Бит digitalSignature устанавливается, когда открытый ключ субъекта используется для проверки цифровых подписей, помимо подписей в сертификатах (бит 5) и CRL (бит6), например, используемые в службе аутентификации объекта, службе аутентификации источника данных и / или службе целостности.

(Большинство наборов шифров также требуют keyAgreement.)

  • Расширенное использование ключа

Этот, если конкретнее, о клиентских сертификатах (если расширение присутствует, что рекомендуется, но не всегда так):

   id-kp-clientAuth             OBJECT IDENTIFIER ::= { id-kp 2 }
   -- TLS WWW client authentication
   -- Key usage bits that may be consistent: digitalSignature
   -- and/or keyAgreement

Более подробную информацию об этом можно найти в данной технической заметке NSS (это должно применяться ко всем продуктам).

Когда вы получаете " security: KeyUsage не допускает цифровые подписи", похоже, это указывает на то, что (не расширенное) использование ключа присутствует в сертификате, который вы пытаетесь использовать в качестве клиентского сертификата, ночто digitalSignature не включено.(Это то, что должен был сделать ЦС, выдавший эти сертификаты.)

Это не относится к апплету.Однако, возможно, что URL-адрес самого апплета защищен проверкой подлинности с помощью сертификата клиента, что может привести к сбою из-за этих расширений.

Одна сторона сервера, поскольку вы работаете за IIS, это IISобрабатывает проверку сертификата TLS / SSL.Apache Tomcat не должно заботиться о том, откуда он получил сертификат.(В Java вы можете настроить способ проверки сертификата путем настройки пользовательских TrustManager s, но это применимо только в том случае, если Java (JSSE) обрабатывает само соединение SSL / TLS; оно не применяется, когдаTomcat стоит за IIS, Apache Httpd или даже когда он использует APR.) Я не уверен, как настроить это с IIS, но есть опция в netsh http add sslcert , которая называется [ usagecheck= ] enable | disable, что звучиткак бы это могло помочь.Это может быть слишком мягким, хотя.(Используйте с осторожностью.)

При этом кажется, что вы получаете сообщение об ошибке на стороне клиента еще до того, как сертификат будет отправлен.Я должен признать, что я не пробовал, но вы могли бы использовать определенный KeyManager, который заставил бы использовать этот сертификат.Я не совсем уверен, сработает ли это.

Как примечание, апплет подписи - это другое дело.Чтобы подписать апплет, сертификат должен иметь расширенное использование ключа для anyExtendedKeyUsage или для id-kp-codeSigning .(Подписание будет работать иначе, но запуск апплета не будет.) Вы можете найти больше информации здесь: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5056088

...