1

I have configured JBOSS 5 with SSLVerifyClient="require"

  1. Client contains, server CA certs and there own certs(JDK 1.8).
  2. Server contains, client CA certs and there own certs(JDK 1.6).

For this case both CA's are different, when we are trying to communicate to that server and getting tlsv1 alert decrypt error

I have no clues what was the exception it is ?

During Curl,

Unknown SSL protocol error in connection

During OpenSSL:

SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A 
SSL_connect:error in SSLv3 flush data 
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Shankar
  • 219
  • 1
  • 4
  • 14
  • Is java 6 supports SHA256RSA ? – Shankar Aug 20 '19 at 17:08
  • (1) Wow that's old (2) Yes j6 supports SHA256withRSA -- and even if it didn't it couldn't cause this alert (3) which end is reporting the alert? (4) Is your server in fact using Java SSL (JSSE), or 'native' = ApacheAPR = OpenSSL? Jboss supports both, although the method(s) to select it varied with version and I don't remember specifics for 5. (5) Are you sure there isn't anything in the network 'between' your client and server that might be modifying the data, such as an IDS, IPS, DLP, WAF? – dave_thompson_085 Aug 24 '19 at 09:37
  • Yes j6 supports SHA256withRSA - Do we have any specific build version ? This error while communication Mutual Authentication, but it is not occurring one way authentication. – Shankar Aug 25 '19 at 11:36
  • It doesn't depend on version, and in any case as I said any problem involving an RSA signature could not cause this alert (although it could cause _others_). It makes no sense to me for this to be related to mutual auth, unless there's some hidden internal linkage like a mismatched callback corrupting something. I would _still_ check the network first, then compare traces or if possible logs from both ends. – dave_thompson_085 Aug 25 '19 at 17:01

1 Answers1

2

The issue is probably (estimate based on OpenSSL output) that used algorithm mode is not supported by other side, or is considered deprecated/breached (i.e. TLSv1 is considered deprecated for more than a year).

I would recommend to capture handshake with tcpdump/wireshark. Since it seems that handshake is failing, you should be able to look into unencrypted handshake phase. Otherwise, since you have access to the private keys for the certs, you should be able to decrypt captured communication in wireshark too.

If supported-algorithm mismatch is not the issue, my second guess is DNS related. In some cases, it is not enough that client proved his identity with certificate, but there has to be a match among for example his DNS record (PTR) and CommonName field in the certificate.

Halis
  • 247
  • 1
  • 10
  • That alert is not caused by 'mode' (?) or protocol unsupported, which have different alerts, or anything about the cert, which also do. Wireshark is a possibility, or _if using Java_ (see my comment on Q) set sysprop `javax.net.debug=ssl` (which decodes for you, and includes some endpoint state and events as well as the wire data). Especially if OP can test Java client (even a dummy test client) to Java server and compare (JSSE) key computation at both ends. ... – dave_thompson_085 Aug 24 '19 at 09:42
  • ... Having server key would only allow Wireshark to decrypt data for plain-RSA key exchange, not DHE-RSA (or anyDHE-any) which Q shows is used here -- and then only if the encryption is correct, which is in doubt. Forcing RSA key exchange to allow manual decrypt might be useful but will be tedious. And even for j6, cert hostname match should be to SubjectAltName (SAN) if present, which for a real (CA-issued) cert it has been for at least a decade. ... – dave_thompson_085 Aug 24 '19 at 09:43
  • ... PS: that openssl s_client output does NOT mean TLSv1(.0) was used, only that the handshake produced SSL3/TLS1 format data in the 'struct ssl_st'. The actual protocol version would be in a different line that may be omitted for unsuccessful handshake. Also neither j6 nor j8, nor any OpenSSL to date, considers TLS1.0 obsolete (though some authorities like PCISSC do). – dave_thompson_085 Aug 24 '19 at 09:48
  • Is there any options to support both SHA1 and SHA2 certificate on both JBOSS 5.1.0 ?(JDK 1.6.x) client and server ? – Shankar Aug 25 '19 at 11:39
  • @Shankar: Jboss doesn't know about cert details at all. _If_ you are using JSSE on Jboss, (any) JDK1.6 supports (all) SHA2-RSA -- at least by default; I _think_ Oracle backported the disableAlgorithm stuff to later, paid-support versions of 6, and IF so and IF that is configured wrong it could cause an alert saying something like 'invalid certificate' -- but NOT 'decrypt error'. 'decrypt error' in TLS has a definite meaning and it has nothing to do with RSA. – dave_thompson_085 Aug 25 '19 at 17:06
  • @dave_thompson_085 But in Jboss logs It is showing JBOSS PKIX path not found. – Shankar Aug 26 '19 at 12:55
  • @Shankar: then that's either on a different connection (or operation) or it's being ignored, because 'decrypt error' alert simply is not used for any kind of cert error ever. Moreover, CertPath>BuilderValidator – dave_thompson_085 Aug 27 '19 at 16:57
  • @dave_thompson_085 Would you recommend something to get trace those logs on client and server side. So I can facilitate to get correct info. – Shankar Aug 27 '19 at 17:00
  • @Shankar: as I said, set system property `javax.net.debug` to the value `ssl`. For Jboss as I recall this should be done as `-Djavax.net.debug=ssl` in environment variable JAVA_OPTS which is set in some script (or Windows batch) file(s) that I don't remember exactly. For your client, you haven't told us anything, but usually that same option somehow on the command that runs the `java` executable. – dave_thompson_085 Aug 29 '19 at 14:45
  • Below are the error: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at – Shankar Sep 05 '19 at 11:00