Стандарт, обычно используемый для проверки сертификата, приведен в 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