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
Improve this question
4
  • Is java 6 supports SHA256RSA ?
    – Shankar
    Aug 20, 2019 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, 2019 at 9: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, 2019 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, 2019 at 17:01

1 Answer 1

Reset to default
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.

Improve this answer
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, 2019 at 9: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, 2019 at 9: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, 2019 at 9: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, 2019 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, 2019 at 17:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .