Поведение доверенного менеджера Java для сертификатов с истекшим сроком действия

Question

Игнорирует ли реализация java TrustManager, если срок действия сертификата истек?
Я попробовал следующее:
- Используя keytool и параметр -startdate "1970/01/01 00:00:00" Я создал хранилище ключей P12 с просроченным сертификатом.
- Iэкспортировал сертификат:

Keystore type: PKCS12
Keystore provider: SunJSSE

Your keystore contains 1 entry

Alias name: fake
Creation date: 5 ╠ά± 2011
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=Malicious, OU=Mal, O=Mal, L=Fake, ST=GR, C=GR
Issuer: CN=Malicious, OU=Mal, O=Mal, L=Fake, ST=GR, C=GR
Serial number: -1c20
Valid from: Thu Jan 01 00:00:00 EET 1970 until: Fri Jan 02 00:00:00 EET 1970
Certificate fingerprints:
         MD5:  A9:BE:3A:3D:45:24:1B:4F:3C:9B:2E:02:E3:57:86:11
         SHA1: 21:9D:E1:04:09:CF:10:58:73:C4:62:3C:46:4C:76:A3:81:56:88:4D
         Signature algorithm name: SHA1withRSA
         Version: 3


*******************************************

Я использовал этот сертификат в качестве сертификата сервера для Tomcat.
Затем, используя Apache httpClient, я подключился к tomcat, но сначала я добавил сертификат с истекшим сроком в доверенное хранилище клиента (с использованием TrustManager

TrustManagerFactory tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());

и загрузкой сертификата с истекшим сроком действия).
Я ожидал, что соединение не будет установлено.
Вместо этого соединение будет установлено успешно.
Использование System.setProperty("javax.net.debug", "ssl");
Я вижу:

***
Found trusted certificate:
[
[
  Version: V3
  Subject: CN=Malicious, OU=Mal, O=Mal, L=Fake, ST=GR, C=GR
  Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5

  Key:  Sun RSA public key, 1024 bits
  modulus: 10350555024148635338735220482157687267055139906998169922552357357346372886164908067983097037540922519808845662295379579697361784480052371935565129553860304254832565723373586277732296157572040989796830623403187557540749531267846797324326299709274902019299
  public exponent: 65537
  Validity: [From: Thu Jan 01 00:00:00 EET 1970,
               To: Fri Jan 02 00:00:00 EET 1970]
  Issuer: CN=Malicious, OU=Mal, O=Mal, L=Fake, ST=GR, C=GR
  SerialNumber: [   -1c20]

]

Я вижу, что при рукопожатии TLS сертификат с истекшим сроком действия отправляется соединителем Tomcat.
Но клиент (т.е. TrustManager) не отклоняет соединение.
Это поведение по умолчанию?
Предполагается ли мне настроить траст-менеджер для проверки срока действия?

ОБНОВЛЕНИЕ:
Я обнаружил, что в действительности используется TrustManager X509TrustManagerImpl.Здесь X509TrustManagerImpl говорит о том, что этот класс имеет минимальную логику. Может быть, я использую неправильный TrustManager?

ОБНОВЛЕНИЕ2: Из javadoc X509TrustManager неясно, проверяет ли он срок действия сертификата

void checkServerTrusted(X509Certificate[] chain,String authType)
                                throws CertificateException  

Учитывая частичное илиЗавершите цепочку сертификатов, предоставленную одноранговым узлом, создайте путь сертификата к доверенному корню и верните, если он может быть проверен и является доверенным для аутентификации SSL сервера на основе типа аутентификации. Тип аутентификации является частью алгоритма обмена ключами представленных наборов шифров.в виде строки, такой как «RSA», «DHE_DSS».Примечание: для некоторых экспортируемых наборов шифров алгоритм обмена ключами определяется во время выполнения во время рукопожатия.Например, для TLS_RSA_EXPORT_WITH_RC4_40_MD5 тип authType должен быть RSA_EXPORT, когда для обмена ключами используется эфемерный ключ RSA, и RSA, когда используется ключ из сертификата сервера.Проверка чувствительна к регистру.

Спасибо

Answer 1

У меня только что была похожая проблема при переопределении checkServerTrusted.

Оказывается, что если вам нужно проверить срок действия, вы можете вызвать X509Certificate.checkValidity(), и он выдаст исключение CertificateExpiredException или CertificateNotYetValidException. Оба из них расширяют CertificateException, так что они могут быть с радостью брошены checkServerTrusted.

Чтобы решить вашу проблему, вы можете реализовать новый X509TrustManager, который создает ваш оригинальный экземпляр в своем конструкторе, реализует все методы как вызовы исходного экземпляра и добавляет вызов к checkValidity для каждого сертификата в certs[] внутри checkServerTrusted.

Answer 2

Я считаю, что IBM JSSE проверяет срок действия, в то время как Sun не делает.

Answer 3

Я не пробовал ваш пример, но теперь мне регулярно приходится регенерировать свои серверные сертификаты (для нашего сервера разработки), так как их сертификаты имеют довольно короткий срок действия.

В нашем случае клиент не имеет самих сертификатов сервера в хранилище доверенных сертификатов, а только сертификат нашего ЦС (с более длительным сроком действия), и когда клиент пытается подключиться к серверу, обе стороны получают исключение SSLEx (которое может быть обернуто в другое исключение в вашем случае).

Я полагаю, что менеджер доверия предполагает что-то вроде "если вы дадите мне сертификаты с истекшим сроком действия, которым я буду доверять, я сделаю это". Вместо этого попробуйте наш подход (он также избавляет вас от необходимости обновлять клиент каждый раз, когда истекает срок действия сертификата сервера).