SSL Client Authentiction - no suitable certificate found even though my client certificate matches to the list in 'Cert Authorities'

Question

This question may seem to be a duplicate of Warning: no suitable certificate found - continuing without client authentication but I'm experiencing a similar issue even when the client certificate was signed by the signers mentioned in the CertificateRequest message.

I'm just curious to know whether using self signed certificates (not trusted by CA) for both client and server (tomcat) is a limitation to the client authentication ?

I am trying to establish a connection to HTTPS Server using Client Authentication through a self signed certificate NOT trusted by any CA (created using keytool).

I have set the properties for keystore and truststore (also enabled the 'debug' all)

System.setProperty("javax.net.debug", "all");
System.setProperty("jdk.tls.client.protocols", "TLSv1.2");
System.setProperty("https.protocols", "TLSv1.2");
System.setProperty("javax.net.ssl.trustStore", 
"C:\\Users\\rmohanda\\Certificates\\composerClient.jks");
System.setProperty("javax.net.ssl.trustStorePassword", "changeit");
System.setProperty("javax.net.ssl.keyStore",  
"C:\\Users\\rmohanda\\Certificates\\composerClient.jks");
System.setProperty("javax.net.ssl.keyStorePassword", "changeit");`

At runtime, I'm facing an SSL Handshake exception as :

javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
    at sun.security.ssl.Alerts.getSSLException(Unknown Source)
    at sun.security.ssl.Alerts.getSSLException(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.recvAlert(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown 
     Source)
    at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
    at InstallCert_ORG.main(InstallCert_ORG.java:102)

Client keystore :

  Loading Client KeyStore- C:\Users\rmohanda\Certificates\composerClient.jks    
  adding as trusted cert:
  Subject: CN=Composer Client, OU=Genesys Composer, O=Genesys Composer, 
  L="Chennai ", ST=TN, C=IN
  Issuer:  CN=Composer Client, OU=Genesys Composer, O=Genesys Composer, 
  L="Chennai ", ST=TN, C=IN
  Algorithm: RSA; Serial number: 0x286e9e35
  Valid from Mon May 28 23:25:50 IST 2018 until Sat May 27 23:25:50 IST 2023

Debug Log :

 *** CertificateRequest
 Cert Types: RSA, DSS, ECDSA
 Supported Signature Algorithms: SHA512withRSA, Unknown (hash:0x6, 
 signature:0x2), SHA512withECDSA, SHA384withRSA, Unknown (hash:0x5, 
 signature:0x2), SHA384withECDSA, SHA256withRSA, SHA256withDSA, 
 SHA256withECDSA, Unknown (hash:0x3, signature:0x1), Unknown (hash:0x3, 
 signature:0x2), Unknown (hash:0x3, signature:0x3), SHA1withRSA, 
 SHA1withDSA, SHA1withECDSA
 Cert Authorities:
 <CN=Composer Client, OU=Genesys Composer, O=Genesys Composer, L="Chennai ", 
 ST=TN, C=IN>
 [read] MD5 and SHA1 hashes:  len = 171
 0000: 0D 00 00 A7 03 01 02 40   00 1E 06 01 06 02 06 03  .......@........
 0010: 05 01 05 02 05 03 04 01   04 02 04 03 03 01 03 02  ................
 0020: 03 03 02 01 02 02 02 03   00 81 00 7F 30 7D 31 0B  ............0.1.
 0030: 30 09 06 03 55 04 06 13   02 49 4E 31 0B 30 09 06  0...U....IN1.0..
 0040: 03 55 04 08 13 02 54 4E   31 11 30 0F 06 03 55 04  .U....TN1.0...U.
 0050: 07 13 08 43 68 65 6E 6E   61 69 20 31 19 30 17 06  ...Chennai 1.0..
 0060: 03 55 04 0A 13 10 47 65   6E 65 73 79 73 20 43 6F  .U....Genesys Co
 0070: 6D 70 6F 73 65 72 31 19   30 17 06 03 55 04 0B 13  mposer1.0...U...
 0080: 10 47 65 6E 65 73 79 73   20 43 6F 6D 70 6F 73 65  .Genesys Compose
 0090: 72 31 18 30 16 06 03 55   04 03 13 0F 43 6F 6D 70  r1.0...U....Comp
 00A0: 6F 73 65 72 20 43 6C 69   65 6E 74                 oser Client
 *** ServerHelloDone
 [read] MD5 and SHA1 hashes:  len = 4
 0000: 0E 00 00 00                                        ....
 Warning: no suitable certificate found - continuing without client 
 authentication
*** Certificate chain
<Empty>
***
*** ECDHClientKeyExchange
ECDH Public value:  { 4, 146, 75, 216, 252, 78, 7, 218, 254, 136, 127, 199, 
207, 80, 170, 251, 9, 188, 39, 206, 22, 74, 23, 63, 4, 39, 217, 73, 89, 143, 
4, 0, 116, 9, 234, 67, 240, 44, 91, 209, 165, 85, 22, 207, 75, 74, 86, 154, 
8, 239, 168, 138, 216, 35, 7, 56, 183, 7, 104, 139, 170, 104, 39, 229, 156 }
[write] MD5 and SHA1 hashes:  len = 77
0000: 0B 00 00 03 00 00 00 10   00 00 42 41 04 92 4B D8  ..........BA..K.
0010: FC 4E 07 DA FE 88 7F C7   CF 50 AA FB 09 BC 27 CE  .N.......P....'.

Though the certificate authorities in certificate request matches the client certificate as state above under Client Keystore heading, I'm still getting the handshare exception

Cert Authorities:
 <CN=Composer Client, OU=Genesys Composer, O=Genesys Composer, L="Chennai ", 
 ST=TN, C=IN>

Certificate warning and eventually gets aborted with exception:

 Warning: no suitable certificate found - continuing without client 
 authentication
*** Certificate chain
<Empty>
***

Note : I have NOT signed the client and server certificates by CA. For testing purpose, I am just using the self signed certificates which is not trusted by any certificate authority.

UPDATE :

Command: keytool -v -list -keystore composerClient.jks

C:\Users\users\XXX>keytool -v -list -keystore composerClient.jks
Enter keystore password:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 2 entries

Alias name: composerclient
Creation date: 28 May, 2018
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=Composer Client, OU=Genesys Composer, O=Genesys Composer, 
L="Chennai ", ST=TN, C=IN
Issuer: CN=Composer Client, OU=Genesys Composer, O=Genesys Composer, 
L="Chennai ", ST=TN, C=IN
Serial number: 286e9e35
Valid from: Mon May 28 23:25:50 IST 2018 until: Sat May 27 23:25:50 IST 2023
Certificate fingerprints:
         MD5:  88:69:29:39:6D:46:F9:C2:27:8B:2B:C5:C7:F2:90:EE
         SHA1: 3D:7A:39:C4:0C:C1:15:07:94:2B:D2:AE:05:E0:C8:77:D5:13:C1:8D
         SHA256: 
 CB:8D:CD:95:15:35:6C:90:16:DB:35:4B:95:30:
 DE:7B:F8:CC:01:F8:8C:64:A5:F4:AE:F6:93:DB:4E:DE:A4:72
         Signature algorithm name: SHA256withRSA
         Version: 3

Extensions:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 13 CA AF 09 CF DE E6 F4   89 92 DF CC 8A 34 69 38  .............4i8
0010: 6F CB 4A E0                                        o.J.
]
]



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


Alias name: tomcat
Creation date: 4 Jun, 2018
Entry type: trustedCertEntry

Owner: CN=Tomcat SSLServer, OU=Genesys Tomcat, O=Genesys Tomcat, L=Daly 
City, ST=California, C=US
Issuer: CN=Tomcat SSLServer, OU=Genesys Tomcat, O=Genesys Tomcat, L=Daly 
City, ST=California, C=US
Serial number: 7c49521
Valid from: Mon May 28 23:20:46 IST 2018 until: Sat May 27 23:20:46 IST 2023
Certificate fingerprints:
         MD5:  B9:68:14:FB:95:F5:E6:22:A9:07:32:AD:DA:7A:D6:DD
         SHA1: 75:05:3E:5D:20:32:57:34:D3:67:29:33:B9:30:DB:8F:07:FB:8E:9D
         SHA256: 
 A4:D6:AC:38:AD:47:78:D9:C0:0D:AD:CB:B3:27:3F:99:45:
 1A:73:C0:87:B6:0A:44:04:C3:FD:16:C7:98:9C:06
        Signature algorithm name: SHA256withRSA
        Version: 3

Extensions:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 90 B1 89 D6 D2 EC 71 87   FD 46 09 B4 A0 BC A7 98  ......q..F......
0010: D7 C5 5C AD                                        ..\.
]
]



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

are you sure that at the other end of your connection you are using same certs. Also anything else like expiry date , validaity date. Please check that — Sagar Kharab, Jun 05 '18 at 03:15
@SagarKharab, I have added the client certificate file (exported from JKS keystore) to the server keystore and vice versa. I also double checked that certificates are not expired. In fact, I have created the certs a couple of days back with validity specified as **-validity 1825**. — Raguram, Jun 05 '18 at 03:21
Your client certificate does not include the certificate chain. Add the client certificate along with certificate chain in the keystore. — pawinder gupta, Jun 05 '18 at 03:23
@pawindergupta , I'm using self signed certificates (which is not trusted by any CA) for both client and server and hence there is ONLY a single certificate associated for both client and server (no certificate chains exists for client and server). That said, I don't think that this could be an issue. Pls clarify if my understanding is wrong — Raguram, Jun 05 '18 at 03:35
Do you use the same keystore file for both client and server? — pawinder gupta, Jun 05 '18 at 04:04
@pawindergupta : No, I have separate keystore for client and server (client.jks and server.jks). — Raguram, Jun 05 '18 at 04:06
Is your client certificate suitable for client authentication at all, i.e. does it have the appropriate key usage and extended key usage extensions? Please show the relevant parts of the certificate (for example the output of `openssl x509 -text -in ...`). — Steffen Ullrich, Jun 05 '18 at 05:03
@SteffenUllrich, How to view those informations ? Could you pls text the full command ? — Raguram, Jun 05 '18 at 10:04
@Raguram: try `keystore -list -v`. This should also list the key usage etc extensions for the certificate — Steffen Ullrich, Jun 05 '18 at 10:52
@SteffenUllrich, **Extensions:** _#1: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: 13 CA AF 09 CF DE E6 F4 89 92 DF CC 8A 34 69 38 .............4i8 0010: 6F CB 4A E0 o.J. ] ]_ **Extensions:** _ #1: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: 90 B1 89 D6 D2 EC 71 87 FD 46 09 B4 A0 BC A7 98 ......q..F...... 0010: D7 C5 5C AD ..\. ] ]_ — Raguram, Jun 05 '18 at 13:04
@Raguram: this looks like a bit too few information. I would be expecting at least `KeyUsage` and `BasicConstraints` and probably other things. Can you please add the full output to your question and only redact things which clearly need to be redacted and explain what you've redacted unless its obvious? — Steffen Ullrich, Jun 05 '18 at 13:21
@SteffenUllrich, I have updated my question to contain the output to the command **keytool -v -list -keystore composerClient.jks** for the client keystore (JKS). Please have a look and let me know if anythiny is wrong ! — Raguram, Jun 06 '18 at 10:32
@Raguram: according to this the certificate has neither a BasicConstraints nor a KeyUsage extension. I have no idea how you've created this certificate but this might be the reason the code is complaining. — Steffen Ullrich, Jun 06 '18 at 10:43
@SteffenUllrich, I have created the certificates using keytool utility. The command that I have used is : `keytool -genkey -alias composerClient -keyalg RSA -validity 1825 -keystore composerClient.jks -storetype JKS` — Raguram, Jun 06 '18 at 11:19
@Raguram: try to recreate the certificate by adding `-ext KeyUsage:critical="digitalSignature,keyCertSign,keyEncipherment" -ext BasicConstraints:critical="ca:true" -ext ExtendedKeyUsage=clientAuth` to your command. — Steffen Ullrich, Jun 06 '18 at 11:45
@SteffenUllrich, I have created the JKS file by appending the parameters that you have given but still I'm getting the same error. I could see the keyusage and extensions now after recreating the client JKS file using the given commands. — Raguram, Jun 06 '18 at 13:42
@SteffenUllrich, `Extensions: #1: ObjectId: 2.5.29.19 Criticality=true BasicConstraints:[ CA:true PathLen:2147483647 ] #2: ObjectId: 2.5.29.37 Criticality=false ExtendedKeyUsages [ clientAuth ] #3: ObjectId: 2.5.29.15 Criticality=true KeyUsage [ DigitalSignature Key_Encipherment Key_CertSign ] #4: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: 0A 9B 6A F4 74 0F ED B5 36 41 55 1E 34 25 B0 0A ..j.t...6AU.4%.. 0010: C4 2D 83 BA .-.. ] ]` — Raguram, Jun 06 '18 at 13:43
@Raguram: then I don't know either what the problem might be. — Steffen Ullrich, Jun 06 '18 at 13:52
@SteffenUllrich : If possible, could you please share some sources (or examples) for client authentication. Your help would be greatly appreciated ! — Raguram, Jun 06 '18 at 17:42
@Raguram have you tried using same keystore at client and server? — leaqui, Jul 26 '18 at 10:44
@leaqui: Nope, that sounds weird. At real time, keystore would differ at client and server. — Raguram, Jul 30 '18 at 13:01
@DineshM Nope. I didn't get a chance to investigate this further. — Raguram, Dec 12 '19 at 17:17

score 1 · Answer 1 · answered Oct 18 '19 at 19:13

For posterity, one possible cause of this error is if you're using an http client different than the standard java one (e.g. Apache HttpClient, REST Assured). Those clients have to be individually configured and will not just inherit keystore / truststore values set via the java.net.ssl properties.

Here is an example of setting the keystore for Apache's HttpClient (adapted from this answer).

try (InputStream inStream = this.class.getResourceAsStream(KEYSTORE))
{
    KeyStore ks = KeyStore.getInstance(KEYSTORE_TYPE);
    ks.load(inStream, KEYSTORE_PASSWORD.toCharArray());

    KeyManagerFactory keyManagerFactory = KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
    keyManagerFactory.init(ks, KEYSTORE_PASSWORD.toCharArray());

    SSLContext sslContext = SSLContext.getInstance("TLS");
    sslContext.init(keyManagerFactory.getKeyManagers(), null, null);
    return HttpClients.custom().setSSLContext(sslContext).build();
}

Apache HC does use the sysprops if you call `HttpClients.createSystem()` `HttpClientBuilder.useSystemProperties()` or `SSLContexts.createSystemDefault()` — dave_thompson_085, Oct 18 '19 at 20:43

SSL Client Authentiction - no suitable certificate found even though my client certificate matches to the list in 'Cert Authorities'

1 Answers1