-
Bug
-
Resolution: Not a Bug
-
Major
-
None
-
fuse-7.10-GA
-
None
-
False
-
False
-
%
-
-
Todo
-
-
Since JDK 1.8_272, the JVM has by default issued a client certificate request during the SSL handshake, that puts ECDSA at the head of the list of accepted signing mechanisms. This is a change from earlier versions, which put RSA in that position.
During the handshake, the client is expected to send whichever certificate it has, according to server preference. Because Java is prepared to accept an RSA certificate and indicates as much in the handshake, a client should send an RSA certificate if it has one, and if it doesn't have an ECDSA certificate. It should send an ECDSA certificate if it has one, but the server is willing to accept RSA.
RSA is, of course, still almost universally used, even though most security authorities prefer ECDSA.
Unfortunately, some clients seem to ignore the list of preferences from the server, and only interpret the first entry on the list, which is ECDSA. If these clients don't have an ECDSA certificate, but have only an RSA certificate, they send nothing. The server shows an exception with message "Empty Server Certificate Chain" (the term "server" here is a bit misleading).
One client that fails in this way is SoapUI – at least with its default certificate management settings. If it is provided with an RSA certificate in a Java keystore, it won't send that certificate to CXF. Instead, it will send an empty certificate chain.
This means that an some webservices clients, including SoapUI, will fail to provide their RSA client certificates, even though the CXF JVM is willing to accept them.