Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I am observing an issue in which the TLS handshake is failing between a Java Client and a web service hosted under IIS 7. Upon wiresharking the attempt it seems that the problem is the list of trusted authorities provided in the Certificate Request Frame does not include the Intermediate CA which signed the client cert that is intended to be used. In looking at the RFC it states that the frame should include

A list of the distinguished names of acceptable certificate authorities. These distinguished names may specify a desired distinguished name for a root CA or for a subordinate CA; thus, this message can be used both to describe known roots and a desired authorization space.

To me this means that the intermediate should have been included. Is there some hidden setting to force the Intermediate CA to be include or am I incorrect in my interpretation of the spec. If I am incorrect I do not see how the proper client cert could ever be identified.

Edit: To give a little more background. The trust chain in question in from Entrust and is three levels deep, the CA, an Intermediate CA and the leaf. In this case the service is secured by a Server Cert signed by the intermediate and the client is calling using a Client Cert signed by the same intermediate.

share|improve this question
    
Is updating the java certificate store of the java client with the proper intermediate/root certificate out of the question? –  k1DBLITZ Apr 15 '13 at 14:04
    
@k1DBLITZ From what we can tell the java keystore does have the proper intermediate and root certificates loaded into the respectively named stores. –  Tedford Apr 15 '13 at 15:20
    
Odd, from my experiences if the client has the proper chain then you're good to go. Is the java client on a windows machine or unix machine? Java doesn't take advantage of the windows key/certificate store, it has its own. I'm assuming the java client is connecting via and can resolve the CN on the certificate issued to the web service, yes? –  k1DBLITZ Apr 15 '13 at 19:04
    
@k1DBLITZ The java client is running out of a tomcat instance hosted on windows 2k8. The certs have been installed into tomcat's keystore. Yes the common name matches the publicly available hostname of the box running the webservice. –  Tedford Apr 17 '13 at 20:00

2 Answers 2

This is a known issue in Windows if the certificate isn't imported correctly into IIS, most likely done via a script or the IIS MMC. I've experienced the same issue with Firefox not validating a server's SSL cert with such a configuration.

The solution for me was to delete, and reimport the certs from the root down to the web server one by one into the Computer store not using the IIS tool but using the CertMgr tool.

To manage the certs directly, you can do so by going to MMC (just type MMC from start -> run). Then add the Certificates snap-in for your local machine. That gives you more visibility into the certificates.

share|improve this answer
    
Great advice, unfortunately that is how they were imported in the first place and we have already tried removing and readding the full chain. –  Tedford Apr 9 '13 at 21:14
    
@Tedford Are you sure the full chain is correct, valid, and up to date? One of the intermediates may be old, reference an old CRL/AIA etc –  makerofthings7 Apr 9 '13 at 22:00
    
I updated the question to hopefully provide a better illustration of the setup. The MMC plug in reports the chain as complete and we are able to secure the hosted service utilizing a cert signed by the intermediate. When calling that service with different client cert (only 1 level deep) the call is completed without issue. So from a service perspective the chain is fine. –  Tedford Apr 9 '13 at 23:55
1  
@Tedford Serverfault.com may be your best bet on this one. –  makerofthings7 Apr 10 '13 at 0:29

It's possible to work around the somewhat liberal IIS interpretation of the SSL/TLS spec by exporting your client certificate in PEM format (base64 ASCII), appending the public certificates for the CAs in the trust chain, and then importing the certificate back into the keystore under the same alias.

To clarify: it's not enough to have all the certificates in the chain in the keystore - they have to be imported with the client certificate itself as a bundle. See this thread at StackOverflow for details: why doesn't java send the client certificate during SSL handshake?

I've just used this method to resolve this exact issue with a Java client and an IIS 7.5 server.

EDIT:

Note that after you import the certificate in bundle form (with its CAs) you won't notice any new entries with keytool -list. Also, if you export the alias again, you'll still only get the client certificate itself. The only difference you'll notice is an extra couple of KB on the file.

Use a tool like KeyStore Explorer to see all of the certificates associated with a keystore entry. In fact, KeyStore Explorer also lets you append certificates to the in-keystore certificate chain for any entry, as an alternative to the export/edit/import route.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.