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

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

*** In case you get this mail duplicated: According to my mail provider, it was sent to the list but never got back, so I'm trying to resend it one more time. ***


> Hi,
>
> On Mon, 2010-01-11 at 17:43 +0100, Marcus Wolschon wrote:
> > I was using 1.6.0.07 .
> > The certificate is the one Comdirect uses. I have no
> > idea how to obtain that as I have no client nor code that
> > can open an SSL-dialog for FinTS/HBCI and save the certificate
> > to a PEM or DER -file.
>
> Try to open the HBCI-PIN/TAN URL in the browser. This will give
> you an error (because you did not send a valid HBCI message), but
> nevertheless you can examine the certificate details, and especially
> examine the certificate CHAIN.
>
> For each certificate in the chain, check if it is contained in the
> Java-cacert-file. If not, go to the website of the corresponding CA
> - there you can download the certificates...


There's an easier way in case anyone wants to know:
The key is a great Firefox plugin that can be used to inspect the certificates that are used, as well as dump them to the hard disk. The Java keytool application is then able to import the files written by the plugin.

Name: Cert Viewer Plus
URL: https://addons.mozilla.org/en-US/firefox/addon/1964
Current Version: 1.5

Normally, the certificate of the bankserver itself is not needed, but everything above it. In this specific case:

PIN/TAN-URL: https://hbci.comdirect.de/pintan/HbciPinTanHttpGate

Certificate chain according to Firefox:
1.: "Builtin Object Token: Equifax Secure CA" (since 22.08.1998 18:41:51)
2.: "TC TrustCenter SSL CA I" (since 15.08.2008 18:45:15)
3.: "hbci.comdirect.de" (since 30.09.2009 12:45:25)

I think that it is sufficient to add certificates #1 and #2 to the keystore if they are not yet present, it should not be necessary to add #3.


> > b) that is not "inside the program" but would
> > require an advanced user that can be trusted to
> > perform such operations on the command-line
> > without help.
> > ...
> > How do you combine "not an option" and "the only way"?
> > Both are mutually exclusive answers.
>
> I thought about the following solution: YOU (as the developer of your
> special application) fetch the missing certificate(s) and create
> a cacert-style file from them using Java's keytool.
>
> This cacert-style file you could include in your application.
> You could set the certfile-kernel-parameter by default to point
> to the file provided by you.
>
> So no user of your application must do anything complicated.


Yes, but I would suggest to start with the file that is shipping with the latest Java SDK (which will contain most of the entries that are needed in practice). It is easy to to the following:
-> Take this file (The filename should be similar to "C:\Program Files\Java\jdk1.6.0_12\jre\lib\security\cacerts"). Copy it into the directory hierarchy of your project.
-> Dump the two certificates to the local hard disk with the mentioned plugin.
-> Add the two certificates to the cacerts file of your project.
-> Ship this "pimped" cacerts file along with your application, and configure the app to use your file automatically, ignoring the Java included file (that would normally be used).
-> Should work, even on Linux or MacOSX boxes, since the format of the cacerts file should be the same on every platform.


> > 1.6.0.07 I know their HTTP-certificare is a EV.cert from VeriSign
> > but I have no idea about their FinTS -certificate
>
> This is probably the same certificate, because in most cases the
> SSL decryption layer is far before the decision which backend-
> application has to handle the incoming request.


No, I think this is incorrect. In most cases, the PIN/TAN-URL contains a different hostname than the one that is used for the browser-based online-banking. In most cases, there are three different hosts (subdomains) for a single bank:

1.: One host (for example www.somebank.de) for the normal page with some content management system (or whatever) on it.
2.: One host (for example hbci.somebank.de) for the PIN/TAN-based HBCI banking.
3.: One host (for example banking.somebank.de) for the browser-based online banking.

Hosts #2 and #3 only communicate via HTTPS (PIN/TAN-based HBCI is layered on top of HTTPS), and #1 is typically not security critical (so simple HTTP is sufficient).

Host #3 (browser-based banking) typically supports extended validation (green bar), which is FAR more expensive than a normal certificate, but completely useless for HBCI, since the certificate is never shown to the user, so he won't know the difference. So host #2 (HBCI) typically supports only classic validation (blue bar).

In this case:
1.: http://www.comdirect.de/ (no validation / clear bar)
2.: https://hbci.comdirect.de/pintan/HbciPinTanHttpGate (blue bar)
3.: https://kunde.comdirect.de/lp/wt/login (green bar)

If your software only needs host #2, the certificate chain for this host is the only thing that is ever relevant to you.


> As already said above: try to open the HBCI-PIN/TAN-URL in your
> browser and examine the SSL certificate...
>
> Regards
> -stefan-

Rolf