SSL handshake failure "Cannot produce CertificateVerify signature"

[minfrin]

Describe the bug
When setting up a connection from Mountain Duck Windows to an Apache httpd 2.4.46 webdav server (Rocky 8), the attempt fails with the message:

Interoperability failure

Please contact your web hosting service provider for assistance.

An option appears to "Try again", but this option makes the error vanish, nothing is tried again.

I am the web hosting service provider in this case, but in the absence of any error message, there is no way I can assist.

To Reproduce
Steps to reproduce the behavior:

1. Add a new WebDAV server hosted on Rocky 8.

Expected behavior
Connected successfully.

Screenshots

Desktop (please complete the following information):

• OS: Windows 10
• Version 4.13.0.20526

Log Files
No logging entries are produced.

Additional context
It appears Mountain Duck lacks error handling. In the absence of error handling, there is no way the product can be supported by us.

[minfrin]

What I do notice on the server side is that when the "connect" button is pressed, mountain duck makes an attempt to connect to the server ignoring the path specified (/ is attempted instead) and ignoring the client certificate specified (the connection is made without a certificate).

[dkocher]

Please try with the latest snapshot build 4.13.1.20529.

[minfrin]

Do you have a link to the snapshot download? Google is not helping.

[dkocher]

Do you have a link to the snapshot download? Google is not helping.

Choose Preferences → Update → Snapshot Builds.

[minfrin]

Just tried the snapshot build, no change in behaviour.

The "Interoperability failure" message still appears, and there is still no error message saying what mountain duck thought was wrong.

[dkocher]

Just tried the snapshot build, no change in behaviour.

The "Interoperability failure" message still appears, and there is still no error message saying what mountain duck thought was wrong.

Can you get the debug log from Preferences → Connection → Log and send it to our support team.

[minfrin]

Digging into the debug log, we see the following error:

javax.net.ssl.SSLHandshakeException: Cannot produce CertificateVerify signature

Google finds the following person with the problem, who solved it be upgrading their JDK:

https://stackoverflow.com/questions/62930842/how-to-fix-sslhandshakeexception-invalid-certificateverify-signature

Here is the bug with Oracle:

https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8257606

Looks like upgrading the JDK will fix this.

[dkocher]

Can you confirm you can reproduce this with Cyberduck for Windows. I assume this is not reproducible with Cyberduck for macOS where we bundle a later JRE.

[dkocher]

https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8257606

Looks like upgrading the JDK will fix this.

Not sure as we are bundling 8u312b07 as of 1b90d74.

[dkocher]

References

• JDK-8260300: Restrict TLS signature schemes in 8u
• JDK-8226374 : Restrict TLS signature schemes and named groups

[minfrin]

Trying it on Windows with a smartcard - fail. Trying it on MacOS with a client cert in the keychain - success.

[minfrin]

Just tried v4.13.2 on Windows, no luck.

[minfrin]

Tried most recent snapshot on Windows, still no luck. Is there any news?

[dkocher]

Tried most recent snapshot on Windows, still no luck. Is there any news?

We will update this ticket when we have any news.

[ylangisc]

@minfrin I'm not quite sure that this issue is related to the referred JDK bugs as I can see that there is an issue signing the CertificateVerify on the smartcard itself. This might be an issue with the bundled sunmscapi.dll :

Caused by: java.security.SignatureException: An unexpected card error has occurred.

	at java.lang.reflect.Constructor.newInstance(Constructor.java:414) ~[?:1.8.0]
	at IKVM.Runtime.JNIEnv.ThrowNew(Unknown Source) ~[?:?]
	at sun.security.mscapi.CSignature.signCngHash(Native Method) ~[Cyberduck.Core.DLL:1.8.0_312]
	at sun.security.mscapi.CSignature$PSS.engineSign(CSignature.java:607) ~[Cyberduck.Core.DLL:1.8.0_312]
	at java.security.Signature$Delegate.engineSign(Signature.java:1382) ~[?:1.8.0]
	at java.security.Signature.sign(Signature.java:700) ~[?:1.8.0]
	at sun.security.ssl.CertificateVerify$T12CertificateVerifyMessage.<init>(CertificateVerify.java:608) ~[?:1.8.0]
	at sun.security.ssl.CertificateVerify$T12CertificateVerifyProducer.produce(CertificateVerify.java:760) ~[?:1.8.0]
...

Do you have the client certificate from the macOS keychain available on Windows for testing? I assume that this client cert would also work on Windows.

[minfrin]

It is the exception above the one above, looks like this:

Caused by: javax.net.ssl.SSLHandshakeException: Cannot produce CertificateVerify signature
	at sun.security.ssl.Alert.createSSLException(Alert.java:131) ~[?:1.8.0]
	at sun.security.ssl.TransportContext.fatal(TransportContext.java:324) ~[?:1.8.0]
	at sun.security.ssl.TransportContext.fatal(TransportContext.java:267) ~[?:1.8.0]
	at sun.security.ssl.CertificateVerify$T12CertificateVerifyMessage.<init>(CertificateVerify.java:610) ~[?:1.8.0]
	at sun.security.ssl.CertificateVerify$T12CertificateVerifyProducer.produce(CertificateVerify.java:760) ~[?:1.8.0]
	at sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:423) ~[?:1.8.0]
	at sun.security.ssl.ServerHelloDone$ServerHelloDoneConsumer.consume(ServerHelloDone.java:178) ~[?:1.8.0]

The client certificate on the Mac and the one on Windows are both issued the same way, the certificate on the Mac works, the certificate on Windows doesn't.

When connecting to an older RHEL6 server, both Windows and Mac work find with the same certificates. Connecting to RHEL8, it breaks on WIndows only.

I have been told that the Mac binary is shipped with a new JDK, while Windows is shipped using an old JDK. The old JDK has the java bug unfixed.

[ylangisc]

Interesting

When connecting to an older RHEL6 server, both Windows and Mac work find with the same certificates. Connecting to RHEL8, it breaks on WIndows only.

Any chance to post the algorithms used in your client certificate?

openssl x509 -text -noout -in [CLIENTCERT] | grep Algorithm

[minfrin]

I asked for the steps needed to work around the Java bug, and someone very kindly gave a detailed explanation:

https://security.stackexchange.com/a/267021/133532

I just managed to test with the reduced range of ciphers as recommended with all PSS removed, and Mountain Duck now successfully connects without crashing, on Windows, using the smartcard and certificate on board.

SSLOpenSSLConfCmd ClientSignatureAlgorithms ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA1:RSA+SHA1

We need this to work without the workaround.

[ylangisc]

I have setup a Rocky 9 WebDAV server requiring a client certificate. With the default configuration I'm able to successfully login with Cyberduck 8.5.2 on Windows. Tried to restrict to TLSv1.2 in /etc/crypto-policies/back-ends/opensslcnf.config, still successful. Finally I have restricted the signature algorithms to RSA_PSS only but still able to connect. The output of the sslscan --show-sigs 192.168.1.131 shows that the configuration is active (refer to Server Signature Algorithm(s):):

Version: 2.0.15
OpenSSL 3.0.7 1 Nov 2022

Connected to 192.168.1.131

Testing SSL server 192.168.1.131 on port 443 using SNI name 192.168.1.131

  SSL/TLS Protocols:
SSLv2     disabled
SSLv3     disabled
TLSv1.0   disabled
TLSv1.1   disabled
TLSv1.2   enabled
TLSv1.3   disabled

  TLS Fallback SCSV:
Connection failed - unable to determine TLS Fallback SCSV support

  TLS renegotiation:
Session renegotiation not supported

  TLS Compression:
OpenSSL version does not support compression
Rebuild with zlib1g-dev package for zlib support

  Heartbleed:
TLSv1.2 not vulnerable to heartbleed

  Supported Server Cipher(s):

  Server Key Exchange Group(s):
TLSv1.2  128 bits  secp256r1 (NIST P-256)
TLSv1.2  192 bits  secp384r1 (NIST P-384)
TLSv1.2  260 bits  secp521r1 (NIST P-521)
TLSv1.2  128 bits  x25519
TLSv1.2  224 bits  x448

  Server Signature Algorithm(s):
TLSv1.2  rsa_pss_rsae_sha256
TLSv1.2  rsa_pss_rsae_sha384
TLSv1.2  rsa_pss_rsae_sha512

  SSL Certificate:
Signature Algorithm: sha256WithRSAEncryption
RSA Key Strength:    2048

Subject:  tv-2.home
Altnames: DNS:tv-2.home
Issuer:   tv-2.home

Not valid before: Dec 14 19:08:52 2022 GMT
Not valid after:  Dec 14 19:08:52 2023 GMT

[ylangisc]

Interesting

When connecting to an older RHEL6 server, both Windows and Mac work find with the same certificates. Connecting to RHEL8, it breaks on WIndows only.

Any chance to post the algorithms used in your client certificate?

openssl x509 -text -noout -in [CLIENTCERT] | grep Algorithm

Still asking for this to be able to generate keys and certificates with the same parameters for testing.

[minfrin]

Client certs are as follows:

    Signature Algorithm: sha256WithRSAEncryption
            Public Key Algorithm: rsaEncryption
    Signature Algorithm: sha256WithRSAEncryption

Make sure you test with Mountain Duck, not Cyberduck, and make sure you use the current shipped production version of the JVM in Mountain Duck, not a newer JDK in a dev environment. New JDKs have fixed this bug, and you're shipping the newer JDK in Mountain Duck for Mac. I believe this is why Mac works, but Windows doesn't.

[minfrin]

In addition, I understand that TLSv1.3 forces the need for PSS, while with TLSv1.2 is negotiated. If you force it to TLSv1.3 on the server side it should always fail.

[ylangisc]

No luck with reproducing. As initially mentioned I'm not quite sure that the issue is the JDK we are using. (Btw, on Windows it's a IKVM converted JDK (to .NET IL) we use and there is no connection to any already installed JDK). As the underlying error is An unexpected card error has occurred. it's possible that we request (as indicated and supported by the server) your smart card to sign with RSA-PSS which it doesn't support. Not all cards support newer algorithms, also refer to OpenSC/OpenSC#1936. You could check the supported algorithms with pkcs11-tool -M. The tool is part of https://github.com/OpenSC/OpenSC.

[minfrin]

No luck with reproducing. As initially mentioned I'm not quite sure that the issue is the JDK we are using. (Btw, on Windows it's a IKVM converted JDK (to .NET IL) we use and there is no connection to any already installed JDK). As the underlying error is An unexpected card error has occurred. it's possible that we request (as indicated and supported by the server) your smart card to sign with RSA-PSS which it doesn't support. Not all cards support newer algorithms, also refer to OpenSC/OpenSC#1936. You could check the supported algorithms with pkcs11-tool -M. The tool is part of https://github.com/OpenSC/OpenSC.

This is the exact bug that's fixed in the JDK. Older JDKs are trying to announce support for RSA-PSS in error where it is not supported. After the JDK fix is applied (linked at the top of this ticket) the JDK no longer announces support RSA-PSS, there is no attempt to negotiate it, and everything works as it should.

Your IKVM converted JDK will be based on a specific version of Java, can you confirm what that is?

[ylangisc]

As mentioned by @dkocher it's 8.0.312.b07, also refer to https://github.com/iterate-ch/ikvm/releases/tag/8.0.312.b07-8. This version has support for RSA-PSS and it's completely fine to request such a signature from your smart card.
Can you please post the requested output from your smart card to see what algorithms are supported?

[ylangisc]

Got the confirmation through direct support for the assumption that the smart card does not have support for RSA-PSS. The updated version v2.2.7RC1 of the Aventra driver solves the problem.