Re: [Hbci4java-help] java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors

[Rolf V. <ro...@we...>]

> >> Any idea what could have happened? IŽm sure the old certificate
> >> wasnŽt in the list of trust-ancors too and that it was
> >> implemented to simply accept all certificates. The code of the
> >> application has not changed in half a year.

> > If your application hasn't changed, maybe the server was upgraded
> > or something alike. Maybe it got an "Extended Validation"
> > certificate instead of a plain one.

> Of cause they did get a new certificate. Why else would it fail.


They could have changed any of the settings that their webserver provides to them, or switched the software that is used on the webserver etc. Or they could have changed any other part of their infrastructure (Web Application Firewall or something similar).


> Extended validation has nothing to do with it. In fact, it is useless
> for HBCI as the certificate is never presented to the user at all.


Yes, it is useless, but still, they could have a policy in-house that prescribes that any new or renewed certificate should be an extended validation one. Keep in mind that you didn't provide us (this list) with any information about the hostname, location or owner of the server, so it's not possible to rule this things out.


> > It seems as if the application is doing a real check whether the
> > server's certificate is valid. So you could provide this list with
> > the following information:
> >
> > -> How you tried to implement the "simply accept all certificates"
> > part of the application. Maybe this class (classes) is not really
> > loaded and used, or it contains some sort of mistake.

> This is the mailing-list of HBCI4Java.
> Why would I use my own imlementation when
> "|client.passport.PinTan.checkcert"
>
> http://hbci4java.kapott.org/javadoc/org/kapott/hbci/manager/HBCIUtils.html
> is already provided and documented for exactly that purpose?


I'm not sure how long the option client.passport.PinTan.checkcert has been available and documented, it could very well have been that this option didn't exist in an older version of the library, so software that uses HBCI4Java could easily contain own code that does essentially the same thing. So whenever asking questions, you could mention how you did something (feature of the library, own code, etc.), because if you don't, nobody can know how you built it.


> I reviews my code and found a possibility that the abovementioned
> setting was not in effect at that time.
> IŽll try again soon.

> > -> Which host you tried to connect to. If the host has an official
> > certificate (that would be accepted by all major browsers), it
> > should not normally be necessary to accept all certificates.

> I very much doubt that my bank uses anything BUT an official
> certificate from one of the
> major commercial CAs.

> > In this case, you probably only want to add the root certificate of
> > the certificate authority,

> ThatŽs exactly what I wanted to avoid for my users are it is a PITA to
> add a trust-ancor
> to the default Java keystore. (First issue: itŽs password protected
> and they donŽt document
> the password.)


If I understand it correctly, you could use the parameter client.passport.PinTan.certfile to specify a file that you ship along with your code that will be used by HBCI4Java. This file could contain any (root or immediate) certificate that will be needed to communicate with the host.

Also, the password for the default Java keystore seems to be documented, it's either "changeit" or "changeme" (the latter only on MacOSX).

You could also check out the great open source (GNU GPL v2) software Portecle (http://portecle.sourceforge.net/) that can be used to inspect and modify Java keystores.


> > as well as the immediate certificates that are used in the chain.

> You do know that the server has to send the itermediate certificates along
> and usually does so?


Yes, that's what it should do, and it's the only thing that makes sense. But as far as I know, there are a few SSL hosts that don't send the correct chain, which can cause mayor headaches. I'm not sure whether there are any hosts for HBCI that have this problem, but I'm quite sure there are some HTTPS hosts that have this misconfiguration.


> > Accepting all certificates (including invalid ones) should only be
> > the last thing you do if everything else fails or if the server is
> > completely under your control and you don't want to spend any money
> > on a real certificate (for example, a dev server on a local
> > network).

> We are talking about a very large international bank here.
> Why do you think I would have any control over the server?


Well, you didn't tell us anything about the server involved, so I simply didn't know. Sorry.