¿Cómo solucionar problemas de TLSv1 handshake con autenticación mutua?

Question

Me está costando mucho tiempo conseguir que mi cliente de servicios web converse con mi servicio web, que está protegido al requerir certificados de clientes. Estoy utilizando JAX-WS 2.1 y la solicitud del servicio web pasa primero a través de IIS antes de ser reenviada a JBoss después de la autenticación.

Estoy utilizando un certificado autofirmado para el certificado del cliente y está instalado en el servidor de Windows 2003 en su sección "Autoridades de certificación de raíz de confianza".

Si trato de acceder al WSDL para el servicio con Internet Explorer, me piden un certificado para enviar y elijo el que he creado y todo parece funcionar bien. Esto me lleva a creer que todos los certificados son correctos y confiables por todos los "personas" correctas.

A continuación Puedo ver que el servidor está incluyendo una referencia a mi "happyFunBall" como una autoridad que confía debido a su inclusión en el parte CertificateRequest del apretón de manos:

*** CertificateRequest 
Cert Types: RSA, DSS` 
Cert Authorities: 
    ... 
<CN=Symantec Root CA, O=Symantec Corporation> 
<CN=DoD Root CA 2, OU=PKI, OU=DoD, O=U.S. Government, C=US> 
<CN=Microsoft Root Authority, OU=Microsoft Corporation, OU=Copyright (c) 1997 Microsoft Corp.> 
<CN=happyFunBall, O=blah.blah.com, C=US> 
<CN=DoD PKI Med Root CA, OU=PKI, OU=DoD, O=U.S. Government, C=US> 
<CN=ECA Root CA 2, OU=ECA, O=U.S. Government, C=US> 
<CN=Symantec Root 2005 CA, O=Symantec Corporation, C=US> 
<CN=Microsoft Root Certificate Authority, DC=microsoft, DC=com> 
    ... 
*** ServerHelloDone 

estoy más o menos un novato en esta materia, por lo que podría faltar algunas cosas muy elementales y podría no incluir toda la información relevante ... De todos modos, generé mi certificado de cliente usando keytool y es del tipo "PKCS12". Así que cuando inicio mi cliente, que tienen las siguientes propiedades del sistema definido:

javax.net.ssl.keyStore="C:\placeWhereFunBallLives\funBall.p12" 
javax.net.ssl.keyStorePassword=<password> 
javax.net.ssl.keyStoreType=PKCS12 

he recibido un 403 desde el servidor cuando hago la llamada al servicio web. Me parece que la implementación subyacente de TLS/SSL no encuentra el certificado del cliente para enviar o, por algún motivo, no lo envía aunque intente encontrarlo.

¿Qué debo ver después de un apretón de manos exitoso? Después del fragmento anterior hay esto:

*** Certificate chain 
*** 
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1 
main, WRITE: TLSv1 Handshake, length = 157 
SESSION KEYGEN: 
PreMaster Secret: 
0000: 03 01 37 1B 02 E4 DB 34 87 A4 4C D0 03 83 74 0B ..7....4..L...t. 
0010: 8D 31 A0 B1 70 B8 31 F8 EB 72 AB 88 3B 69 B5 43 .1..p.1..r..;i.C 
0020: 19 EA 24 BD 59 50 16 7D C0 99 DC A6 EC 4F EF 64 ..$.YP.......O.d 
CONNECTION KEYGEN: 
Client Nonce: 
0000: 4B 56 1E E4 66 09 1D 6C EE 95 F1 47 3E 12 DA 22 KV..f..l...G>.." 
0010: 63 8E 23 93 76 7D FB CB 27 7B 2E C5 8E DC 93 C2 c.#.v...'....... 
Server Nonce: 
0000: 4B 56 1E E4 A7 70 0F 2F 1A 17 0D 8F 2D 79 7D AE KV...p./....-y.. 
0010: 70 0E C9 5C 16 A9 B5 25 B0 99 22 B3 F8 89 D8 EC p..\...%.."..... 
Master Secret: 
0000: C3 ED 84 D6 63 CD 6C 59 94 14 06 4B 37 EC EE C4 ....c.lY...K7... 
0010: AE 99 97 1B 0E B9 61 25 AF DB C4 54 30 C5 4C 80 ......a%...T0.L. 
0020: 47 74 47 E8 B0 B5 13 32 BA 93 62 33 B6 CA C4 A8 GtG....2..b3.... 
Client MAC write Secret: 
0000: 3C E8 3A 6A B2 74 F0 ED 6C FE DE 70 77 E8 EB 36 <.:j.t..l..pw..6 
Server MAC write Secret: 
0000: BD 41 C5 EB 3B ED E9 E0 0C 61 28 C2 11 7A 75 1C .A..;....a(..zu. 
Client write key: 
0000: 79 43 DD AD 44 B0 A0 61 1D EB 71 AB 4F 39 9D EF yC..D..a..q.O9.. 
Server write key: 
0000: C9 43 22 2A 48 50 FA 67 E0 01 1B 8A 48 0F C8 CF .C"*HP.g....H... 
... no IV used for this cipher 
main, WRITE: TLSv1 Change Cipher Spec, length = 17 
*** Finished 
verify_data: { 52, 94, 173, 217, 26, 70, 12, 243, 6, 71, 27, 163 } 
*** 
main, WRITE: TLSv1 Handshake, length = 32 
main, READ: TLSv1 Change Cipher Spec, length = 17 
main, READ: TLSv1 Handshake, length = 32 
*** Finished 
verify_data: { 56, 254, 211, 144, 48, 35, 4, 235, 65, 127, 237, 94 } 
*** 
%% Cached client session: [Session-2, SSL_RSA_WITH_RC4_128_MD5] 

Heeeeeeelp!

Answer 1

Bien, entonces descubrí cuál era el problema (o al menos un síntoma del problema) y pensé que lo compartiría aquí con fines de tipo histórico.

que utilizan herramienta de claves para generar thusly mi almacén de claves del cliente:

keytool -genkeypair -alias funBall -keyalg rsa -dname "CN=happyFunBall,O=thing.thing.com,C=US" -keystore <keystoreLocation>/funBall.p12 -keypass <password> -storetype PKCS12 -storepass <password> 

y luego me lo firmó con esta herramienta de claves comando :

keytool -selfcert -alias funBall -validity 1825 -keystore <keystoreLocation>/funBall.p12 -keypass <password> -storetype PKCS12 -storepass <password> 

Al parecer, esto no es bueno. El comando "-selfcert" anterior necesitaba un parámetro "-dname" establecido en el mismo valor que el utilizado en "-genkeypair", porque de lo contrario la cadena de certificados o lo que sea (que no entiendo completamente) no es correcta y el el certificado no se reconocerá como válido para la lista dada por el servidor en su CertificateRequest.

Answer 2

¿Ha configurado también el almacén de confianza para su conexión?