Philip Martin <phi...@codematters.co.uk> writes:
> Looking back at the original mail it looks as if the error is produced
> by x509parse.c:x509_get_alg() via svn_x509_parse_cert(), in particular
> it is probably this assumption:
>
> /*
> * assume the algorithm parameters must be NULL
> */
> err = asn1_get_tag(p, end, &len, ASN1_NULL);
> if (err)
> return svn_error_create(SVN_ERR_X509_CERT_INVALID_ALG, err, NULL);
>
> if (*p != end)
> {
> err = svn_error_create(SVN_ERR_ASN1_LENGTH_MISMATCH, NULL, NULL);
> return svn_error_create(SVN_ERR_X509_CERT_INVALID_ALG, err, NULL);
> }
Marc provided more information and I can reproduce the problem by using
the openssl option:
-sigopt rsa_padding_mode:pss
when signing a server key. The server cert that is created looks like:
$ openssl x509 -text -in server-cert.crt
...
Signature Algorithm: rsassaPss
Hash Algorithm: sha256
Mask Algorithm: mgf1 with sha256
Salt Length: 0xDE
Trailer Field: 0xBC (default)
...
I've setup my client to trust the issuer of these server certs but
attempts to access a repository still fail:
$ svn ls https://...
Error validating server certificate for 'https://localhost:8887':
- The certificate has an unknown error.
...
(R)eject or accept (t)emporarily?
Note the reason for the failure is "unknown error" which corresponds to
SVN_AUTH_SSL_OTHER and SERF_SSL_CERT_UNKNOWN_FAILURE. I can choose to
temporarily accept and the operation proceeds, but accepting permanently
is not available because that is never offered for SVN_AUTH_SSL_OTHER.
If I try the Java example code tools/examples/ExampleAuthn.java I get a
java exception:
at org.apache.subversion.javahl.remote.RemoteFactory.open(Native Method)
at
org.apache.subversion.javahl.remote.RemoteFactory.openRemoteSession(RemoteFactory.java:200)
at ExampleAuthn.main(ExampleAuthn.java:102)
Caused by: org.apache.subversion.javahl.ClientException: Found invalid
algorithm in certificate
Unexpected ASN1 tag
which is the original problem report. Our JavaHL code calls
svn_x509_parse_cert() when handling server cert failures, see
AuthnCallback.c:AuthnCallback::SSLServerCertInfo::SSLServerCertInfo()
and the Java exception is raised when svn_x509_parse_cert() returns an
error. The command line client only uses svn_x509_parse_cert() in the
"svn auth" command.
If I try to get Firefox to accept the RSASSA-PSS cert it gives me the
error SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED with an explanation:
The certificate was signed using a signature algorithm that is
disabled because it is not secure.
but I think that is misleading and RSASSA-PSS is too new rather than
obsolete. A few months ago OpenSSL gained some RSASSA-PSS support:
https://github.com/openssl/openssl/pull/4368
https://github.com/openssl/openssl/issues/2878
The underlying issue is that Subversion/serf/openssl is not able to
validate certs signed with RSASSA-PSS. The standard client allows the
user to temporarily ignore the problem and proceed, JavaHL doesn't give
the user that option. If we were to extend svn_x509_parse_cert() to
parse parameters then JavaHL would be able to behave like the command
line client.
In Marc's case getting a new server cert that is not RSASSA-PSS might be
the best solution.
--
Philip
