0

I have an application that connects to a remote web service deployed on HTTPS. Our application uses FIPS-140 Level-1 for SSL/TLS connectivity, and is based on JCE providers of RSA (the company).

com.rsa.jsse.JsseProvider.JsseProvider()
RsaJsse version 6.14

com.rsa.jsafe.provider.JsafeJCE.JsafeJCE()
JsafeJCE version 6.11

Recently the web service team made changes on their end to enable DH ciphers. After that change, the cipher that gets selected for SSL is TLS_DHE_RSA_WITH_AES_256_GCM_SHA384. However, the certificate chain validation seems to fail with below exception:

java.lang.IllegalArgumentException: Invalid authentication type: DHE_RSA
    at com.rsa.sslj.x.cj.checkClientTrusted(Unknown Source)
    at com.example.MyX509TrustManager.checkServerTrusted(ReloadableX509TrustManager.java:65)
    at com.rsa.sslj.x.aE.a(Unknown Source)
    at com.rsa.sslj.x.bg.a(Unknown Source)
    at com.rsa.sslj.x.bg.a(Unknown Source)
    at com.rsa.sslj.x.bg.a(Unknown Source)
    at com.rsa.sslj.x.aH.a(Unknown Source)
    at com.rsa.sslj.x.aH.a(Unknown Source)
    at com.rsa.sslj.x.ap.c(Unknown Source)
    at com.rsa.sslj.x.ap.a(Unknown Source)
    at com.rsa.sslj.x.ap.j(Unknown Source)
    at com.rsa.sslj.x.ap.i(Unknown Source)
    at com.rsa.sslj.x.ap.h(Unknown Source)
    at com.rsa.sslj.x.aS.startHandshake(Unknown Source)
    at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:261)
    at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:118)

Can anyone please guide me what is the meaning of "Invalid authentication type: DHE_RSA"? Prior to DH Cipher enablement in back end webservice, this authentication type used to be "RSA", and we never faced any issue.

I read in the comments of this question that this error can come if algorithm is not FIPS-140 approved. Can that be the case here?

Please note that method com.example.MyX509TrustManager.checkServerTrusted does not do anything special - it is written to skip certificate chain validation in certain special cases, else it will delegate to java.net.ssl.TrustManager#checkClientTrusted - in this case TrustManager is instance of an RSA class whose name is obfuscated in RSA jars.

UPDATE:

It seems that com.rsa.sslj.x.cj.checkClientTrusted expects the algorithm used in public key should be DHE_RSA, since the algorithm used in remote web service's certificate chain is RSA - it reports an error saying Invalid authentication type. Remote web service team had recently added dhparam to their SSL configuration to avoid logjam vulnerability, but they have not done any changes to their certificate. Not sure why our SSL client has started failing to connect to remote service since then, and is there anything I need to do for our application or remote web services team need to something. Any inputs in this regard will be highly helpful

  • How is that DHE_RSA string generated? Is somebody doing regex on the cipher suite name and extracting that maybe? What string values are available for "authentication type" in general? Does it work if you force auth type to RSA? (Authentication really is "RSA": A short term session key (agreed upon via DHE) is authenticated by the long term auth key in the RSA certificate.) (List here.) – StackzOfZtuff Apr 29 '17 at 7:06
  • @StackzOfZtuff: since com.rsa.jsse needs to be compatible with real Suncle JSSE it is presumably doing more or less the same things as hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/… in void serverCertificate(CertificateMesg mesg) which uses the values from static enum KeyExchange in hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/… – dave_thompson_085 Apr 29 '17 at 8:35
1

Your custom checkServerTrusted should not be forwarding to the standard checkClientTrusted but to the standard checkServerTrusted. The authType for Server is a keyexchange name, but for Client it is an algorithm name -- THESE ARE NOT IN GENERAL THE SAME and in the case you just encountered they are and should be different.

FIPS140 only specifies and restricts algorithms, not higher-level constructs like TLS keyexchanges, ciphersuites, and protocols. DH is approved (by 800-56A) only with some constraints that don't work for TLS, but it is allowed for a case that covers DHE_RSA by the FIPS1402 Implementation Guidance D.8 and is listed as implemented that way in almost your JSAFE version at CMVP #2057. OTOH SP800-52 does restrict TLS for most of the same systems as FIPS140, and r1 in 2014 does not allow DHE_RSA, but #2057 predates 2014. So I'm pretty sure there's no FIPS problem here.

  • Thanks for the answer. I did try to pass to checkServerTrusted, but I do not recall what issue I ran into - let me retry that and get back with observations. – Wand Maker Apr 29 '17 at 19:14
  • If I call checkServerTrusted, I get exception java.security.cert.CertificateException: the certificate chain is not trusted, Parameters must be PKIXParameters or be CertPathWithOCSPParameters containing PKIXParameters – Wand Maker May 2 '17 at 15:29
  • The PXIX error I mentioned in previous comment seems to be due to the fact that root CA list (X509TrustManagerImpl#trustedCerts) against which I need to validate certificate chain was empty. I will fix that. Your suggestion to use checkServerTrusted seems to be the solution. Thanks for the help – Wand Maker May 3 '17 at 9:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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