Weblogic/Java 在与 IIS 的相互 SSL 集成中不发送客户端证书

Question

I'm having trouble understanding why Weblogic/Java are not sending the Client certificate requested by the server(IIS server) during SSL Handshake via the CertificateRequest message.

I have already checked and tried all the other questions/answer in SO such as : Java not providing client certificate for mutual SSL? and similar.

I have created a custom keystore called Identity.jks with only one Certificate entry and I've follwed the WL guides (and everything else I could find on the Internet) to do the right settings.

Here are the debug logs for the SSL handshake:

*** CertificateRequest
Cert Types: RSA, DSS, ECDSA
Supported Signature Algorithms: SHA512withRSA, SHA512withECDSA, SHA256withRSA, SHA384withRSA, SHA1withRSA, SHA256withECDSA, SHA384withECDSA, SHA1withECDSA, SHA1withDSA
Cert Authorities:
<Empty>
*** ServerHelloDone
Warning: no suitable certificate found - continuing without client authentication
*** Certificate chain
<Empty>

As you can see the server sends a CertificateRequest message but for some reasons the Cert Authorities is Empty . The client (Weblogic) in this case doesn't send the certificate. As you can see there is a warning message by the developers saying:

no suitable certificate found - continuing without client authentication

When I use SoapUI instead of Weblogic to communicate with the server the handshake succeeds. SoapUI sends the certificate contained in the Identity.jks keystore.

Can it be that SoapUI is less restrictive and sends the only certificate present in the keystore anyway while Weblogic is expecting from the server to find something in the Cert Authorities: <Empty> ?

Since I've setup weblogic to use only that key with that alias I expect it to send it...

Anyone knows what are the criteria that Weblogic uses to find a matching client certificate?

Is my interpretation of the logs correct?

Any idea/help is welcome.

Answer 1

I've had a similar problem with a Java HTTP client. Depending on your IIS version the server may or may not be sending the certificate list back. Newer version don't.

Ensure that you have the full certificate chain and your client certificate in the keystore.

Answer 2

Since there seems to be an interest, I'm answering my own question on how we fixed it.

When writing Java clients to communicate with other servers via Two-Way SSL we need to make sure that the SSL Context used to initiate the communication has been set with the Custom Identity Keystore and the Custom Trust keystore .

One convenient way to do this is to pass the Identity and Trust keystores as JVM options when a JVM process starts (on start of WebLogic or other web app server). JVM arguments can be passed in the server startup script (if present) or as command line argument.

The following is an example:

-Djavax.net.ssl.keyStore=D:\Path-to\identity.jks -Djavax.net.ssl.keyStoreType=JKS -Djavax.net.ssl.keyStorePassword=MyReallyComplexPassword -Djavax.net.ssl.trustStore=D:\Path-to\trust_keystore.jks  -Djavax.net.ssl.trustStoreType=JKS -Djavax.net.ssl.trustStorePassword=MyTrustStorePassword

Where the value of javax.net.ssl.keyStore is what we called the Custom Identity Keystore and the value of javax.net.ssl.trustStore is what we called the Custom Trust Keystore .

Note: Another way to accomplish the same thing would be to load-and-set the Identity & Trust keystores directly in the client's code itself, before firing the request to the server. There are multiple examples on-line that explain how to do this.

Important: When writing a client that should communicate via Two-Way SSL make sure to never blindly trust all certificates. Many client libraries give you a boolean option TrustAllCerts that can be useful during development however if you leave it in production Two-Way SSL will NOT work. This is because by telling the SSL context to trust any certificate, the Server Certificate Exchange Key is not checked (since you trust it anyway) and thus the CertificateRequest from the server is ignored. The client will continue without sending its client certificates but, because the server expects the client to send one, the handshake process will end in failure.