Abruf von Dividendenterminen über divvyDiary schlägt fehl

AtomicDad · September 10, 2026, 11:26am

Seit unbekannter Zeit (ist erst heute aufgefallen) werden keine Dividendentermine mehr von DivvyDiary an PP übertragen.

Das Fehlerprotokoll ist für alle meine Wertpapiere voll mit dem selben Fehler.

Hier das Beispiel für HPE:

Thu Sep 10 13:16:21 CEST 2026
Hewlett Packard Enterprise Comp

javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at java.base/sun.security.ssl.Alert.createSSLException(Unknown Source)
	at java.base/sun.security.ssl.TransportContext.fatal(Unknown Source)
	at java.base/sun.security.ssl.TransportContext.fatal(Unknown Source)
	at java.base/sun.security.ssl.TransportContext.fatal(Unknown Source)
	at java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(Unknown Source)
	at java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.onConsumeCertificate(Unknown Source)
	at java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.consume(Unknown Source)
	at java.base/sun.security.ssl.SSLHandshake.consume(Unknown Source)
	at java.base/sun.security.ssl.HandshakeContext.dispatch(Unknown Source)
	at java.base/sun.security.ssl.HandshakeContext.dispatch(Unknown Source)
	at java.base/sun.security.ssl.TransportContext.dispatch(Unknown Source)
	at java.base/sun.security.ssl.SSLTransport.decode(Unknown Source)
	at java.base/sun.security.ssl.SSLSocketImpl.decode(Unknown Source)
	at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(Unknown Source)
	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
	at org.apache.hc.client5.http.ssl.AbstractClientTlsStrategy.executeHandshake(AbstractClientTlsStrategy.java:245)
	at org.apache.hc.client5.http.ssl.AbstractClientTlsStrategy.upgrade(AbstractClientTlsStrategy.java:211)
	at org.apache.hc.client5.http.ssl.DefaultClientTlsStrategy.upgrade(DefaultClientTlsStrategy.java:48)
	at org.apache.hc.client5.http.impl.io.DefaultHttpClientConnectionOperator.upgradeToTls(DefaultHttpClientConnectionOperator.java:263)
	at org.apache.hc.client5.http.impl.io.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:227)
	at org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:547)
	at org.apache.hc.client5.http.impl.classic.InternalExecRuntime.connectEndpoint(InternalExecRuntime.java:164)
	at org.apache.hc.client5.http.impl.classic.InternalExecRuntime.connectEndpoint(InternalExecRuntime.java:174)
	at org.apache.hc.client5.http.impl.classic.ConnectExec.execute(ConnectExec.java:144)
	at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
	at org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ProtocolExec.java:192)
	at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
	at org.apache.hc.client5.http.impl.classic.ContentCompressionExec.execute(ContentCompressionExec.java:138)
	at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
	at org.apache.hc.client5.http.impl.classic.HttpRequestRetryExec.execute(HttpRequestRetryExec.java:112)
	at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
	at org.apache.hc.client5.http.impl.classic.RedirectExec.execute(RedirectExec.java:110)
	at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
	at org.apache.hc.client5.http.impl.classic.InternalHttpClient.doExecute(InternalHttpClient.java:185)
	at org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:245)
	at org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:188)
	at org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:162)
	at name.abuchen.portfolio.util.WebAccess.executeWith(WebAccess.java:294)
	at name.abuchen.portfolio.util.WebAccess.get(WebAccess.java:257)
	at name.abuchen.portfolio.online.impl.DivvyDiaryDividendFeed.getDividendPayments(DivvyDiaryDividendFeed.java:53)
	at name.abuchen.portfolio.ui.jobs.UpdateDividendsJob.run(UpdateDividendsJob.java:66)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at java.base/sun.security.validator.PKIXValidator.doBuild(Unknown Source)
	at java.base/sun.security.validator.PKIXValidator.engineValidate(Unknown Source)
	at java.base/sun.security.validator.Validator.validate(Unknown Source)
	at java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(Unknown Source)
	at java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(Unknown Source)
	... 39 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at java.base/sun.security.provider.certpath.SunCertPathBuilder.build(Unknown Source)
	at java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(Unknown Source)
	at java.base/java.security.cert.CertPathBuilder.build(Unknown Source)
	... 44 more

Ich nutze die aktuellste Version von PP unter Win11. Es ist kein Blocker im Netzwerk, die Seite divvydiary.com kann problemlos aufgerufen werden.
Ich habe den API Key bereits einmal erneuert. Dies hat aber auch keinen Erfolgt gezeigt. Ich nutze DD in der kostenlosen Variante.

Tritt der Fehler/das Verhalten auch bei anderen auf?

[Update]
Version 0.86.0 zeigt das selbe Verhalten.

Sn1kk3r5 · September 10, 2026, 2:51pm

Hast du bei DD mal alles gelöscht und neu hochgeladen?

J_A_E_R · September 10, 2026, 3:49pm

Bei mir gibt es keine Fehler beim Sync zwischen PP und DD.

Und ich habe auch nur einen kostenlosen DD Account.

kimmerin · September 10, 2026, 4:41pm

Ins Blaue geschossen: Du hast einen Virenscanner/Weltrettungsservice (z.B. ZScaler) laufen, der sich über eine Man-In-The-Middle-Attacke in die verschlüsselte Kommunikation zwischen PP und dem DD-Server reingeschaltet hat.

Damit dir das nicht auffällt, installiert diese Software ihr Zertifikat in die Liste vertrauenswürdiger Zertifikate, der dein Betriebssystem und deine chromium-basierten Browser blind vertrauen. Java hat seine eigene Verwaltung, was das Vertrauen von Zertifikaten angeht (Firefox auch BTW), daher werden diese gefrankensteinten Zertifikate dann entsprechend angemeckert.

Hier noch ein Weg, wie du prüfen kannst, ob meine Vermutung korrekt ist. Geh mit dem Browser deiner Wahl auf https://divvydiary.com und öffne die Sicherheitsinformationen zur Domain (hier mit Firefox):

Das sollte dir schon mal anzeigen, dass es sich um ein von Let’s Encrypt signiertes Zertifikat handelt. Wenn nicht, oder weil du neugierig bist, kannst du zu den weiteren Details gehen:

Das öffnet einen Dialog, mit dem man sich dann die Details zum Serverzertifikat aufmachen kann:

Das sollte dir dann eine Zertifikatskette wie folgt anzeigen:

Jede andere Kette ist phishy.

AtomicDad · September 11, 2026, 5:14am

Hm, dann scheint da etwas “phishy” zu sein.

Ein Wireguardproxy scheint diese Kette zu zerstören. Warum aber erst seit “nicht so langer Zeit” (aktuell kann ich das auf die letzten ein bis zwei Monate eingrenzen), weiß ich nicht. Muss da wohl tiefer im Netzwerk absteigen und schauen warum.

AtomicDad · September 20, 2026, 3:51pm

Ich hatte etwas Zeit und das Thema analysiert.

Die Zertifikatskette ist durch die eingesetzte Infratstruktur nicht Java kompatibel. Wie vermutet vertraut Java dieser Veränderungen der Kette nicht.

Als schnellen Fix kann man das eigene Root-Zertifikat in die von PP mitgelieferte cacerts schreiben. Das ist natürlich nichts dauerhaftes.

Hier werde ich aber versuchen, dass ganze mit einem eigene Truststore updatesicher zu gestalten.