omportamiento de @Java trustmanager en certificados caducados

La implementación de TrustManager de Java ignora si un certificado ha expirado?
Intenté lo siguiente:
- Utilizandokeytool y parámetro-startdate "1970/01/01 00:00:00" Creé un almacén de claves P12 con un certificado caducado.
- Exporté el certificado:

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


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

Usé este certificado como certificado de servidor para Tomcat.
Luego, usando un httpClient de apache, me conecté a tomcat, pero primero agregué el certificado caducado al almacén de confianza del cliente (usando un TrustManager

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

y cargando el certificado caducado).
Esperaba que la conexión fallara.
En cambio, la conexión tiene éxito.
UtilizandoSystem.setProperty("javax.net.debug", "ssl");
Veo

***
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]

]

Veo que en el protocolo de enlace TLS el certificado caducado se envía por el conector Tomcat.
Pero el cliente (es decir, el TrustManager) no rechaza la conexión.
¿Es este el comportamiento predeterminado?
¿Supongo que debo configurar el administrador de confianza de alguna manera para verificar la caducidad?

ACTUALIZAR
Encontré que el TrustManager real utilizado es X509TrustManagerImpl. Aquí X509TrustManagerImpl dice que esta clase tiene una lógica mínima. ¿Puedo estar usando el TrustManager incorrecto?

ACTUALIZACIÓN2: Del javadoc X509TrustManager no está claro si verifica la caducidad del certificado

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

Dada la cadena de certificados parcial o completa proporcionada por el par, cree una ruta de certificado a una raíz confiable y devuelva si se puede validar y es confiable para la autenticación SSL del servidor en función del tipo de autenticación. El tipo de autenticación es la porción del algoritmo de intercambio de claves de los conjuntos de cifrado representados como una cadena, como "RSA", "DHE_DSS". Nota: para algunos conjuntos de cifrado exportables, el algoritmo de intercambio de claves se determina en tiempo de ejecución durante el protocolo de enlace. Por ejemplo, para TLS_RSA_EXPORT_WITH_RC4_40_MD5, el authType debe ser RSA_EXPORT cuando se utiliza una clave RSA efímera para el intercambio de claves y RSA cuando se utiliza la clave del certificado del servidor. La comprobación distingue entre mayúsculas y minúsculas.

Gracia

Respuestas a la pregunta(3)

Su respuesta a la pregunta