I have a Java v8 based client provided by an unresponsive vendor that still ships an old JDK where this bug is not yet fixed:


To work around the bug, I want to disable the RSASSA-PSS cipher. I am struggling to find what the RSASSA-PSS cipher is called in the world of OpenSSL.

What modification must I make to the following line to disable RSASSA-PSS?

  • RSASSA-PSS is not a ciphersuite, or cipher; it is a signature algorithm. It is only used in 1.3, and is controlled (only) by the sigalgs extensions -- which Apache can't configure. Do you need client auth aka client cert aka mutual auth for your application? If you can turn it off the client-side bug won't happen. Otherwise you must turn off protocol 1.3 and limit yourself to 1.2 (or lower, but anything below 1.2 is now considered unsafe and often prohibited). Commented Dec 12, 2022 at 4:29
  • The server that refuses to cooperate has TLS1.3 disabled already (certs are required in this case), and it hasn't made a difference. Is RSASSA-PSS a properly of the certificate? Commented Dec 12, 2022 at 8:33
  • I came up with a decent answer after all, so see that. Commented Dec 13, 2022 at 4:55

1 Answer 1


First, my original comment was wrong. I didn't realize that both OpenSSL and Java (JSSE) implement PSS signatures in TLS1.2 as an extension, so using 1.2 doesn't solve the problem by itself. (But 1.3 requires protocol signatures using RSA to be PSS, even when the cert signatures are allowed or required to be v1_5, so if either your server cert or the desired client cert is RSA you still can't use 1.3 for a client with broken PSS.)

However, on checking more thoroughly, apache can configure this at least in 2.4.8 up (assuming a suitable OpenSSL, which you obviously have). You need to use the SSLOpenSSLConfCmd directive but apache's link to OpenSSL is stale, it is now https://www.openssl.org/docs/man1.1.1/man3/SSL_CONF_cmd.html#SUPPORTED-CONFIGURATION-FILE-COMMANDS (but probably not much longer, 1.1.1 is going EOL soon). The following gives me a CertReq with no PSS schemes in 1.2 (and this time I tested instead of ass-u-ming):


For convenience I used the old (1.2) two-part naming because the 1.3 combined names are longer, and left out the SHA224 schemes (which I don't think anyone used), ed25519 and ed448 which a Java 8 client can't use, and the DSA schemes which are rare, but if your client(s) use them add them back.

To your additional Q: Is RSASSA-PSS a properly of the certificate? Yes, but not the way you want :-( A certificate for an RSA key can have a PSS-specific value for the identifying OID which requires use of PSS for that key -- but I don't know of any CA that issues certs with this new OID. OTOH a cert with the older generic OID (which is still pretty much universal) permits use of PSS; in 1.3 nomenclature these are the rsa_pss_rsae schemes versus the rsa_pss_pss schemes. In any case the bug you linked appears to occur in the setup for selecting a client cert, and processing could not be affected by the content of a cert that hasn't been selected yet. (To be clear, if you meant the server cert nothing in the server cert ever affects client signatures, neither in 1.2 or 1.3.)

  • Got a chance to confirm the workaround, and we have success - the JDK with the problem now connects when it crashed in the past. Thank you hugely for the detailed explanation. Commented Dec 14, 2022 at 16:40

You must log in to answer this question.

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