Does someone try to hack my Owncloud Desktop client?



First of all, please excuse my spelling mistakes. If this is not the correct website for my question, just let me know.

Expected behaviour

I have a perfectly fine owncloud instance running on my raspberry pi, connected to the internet via a DDNS service and a CNAME Record on my own domain. The Desktop client worked without problems for a few months now. Additionally, the server is SSL secured by symantec.

Actual behaviour

Today i got a very weird message: The ssl certificate doesn't match my domain. Owncloud desktop stated that the certificate was for, while my actual domain is (something like) I've attached a screenshot of the error message to this post.
When accessing chrome states, the website is secure and the certificate matches the domain name. I've never seeen in my life.
Is someone trying to get into my owncloud? If yes: How and what can I do? If no: Why am I getting this error message?

Server configuration

Operating system: Raspbian Linux v. 4.9.35-v7

Web server: Apache 2.4.10

Database: MySQL 5.5.57-0+deb8u1 - (Raspbian)

PHP version: 5.6.30-0+deb8u1

ownCloud version: 10.0.3

Storage backend (external storage): 128GB USB

Client configuration

Client version: 2.3.4 (build 8624)

Operating system: Windows 10 64 bit

OS language: German

Installation path of client: C:\Program Files (x86)\ownCloud


The log files don't seem to help at all.Please excuse my spelling mistakes. if this is not the correct website for my question, please let me know.

Thanks for your help! Let me know if you need any additional information.


I discovered, that the ip-address, points to is the same ip, my home network had yesterday. Is it possible, that Owncloud Desktop doesn't check the DNS entry for my dynamic dns service frequently enough, so it points to the person who gets the ip assigned next?


Hey @joschahen! Thanks for reporting! Don't worry; as far as I can see nobody is trying to hack into your client! It's way more likely a problem on the DDNS configuration - those usually take some time to propagate and your browser might be using a different DNS server than the rest of your system (which the client will use to determine the final address of your instance).

Since the client is getting a different (both containing a different domain: "" and untrusted) SSL certificate on that address than the previous one stored in your keychain is requiring you to accept manually the new one, which is wrong.

If the client is indeed relying on an older IP your server used to have (like you indicate on your edit) and it's not a DNS server/propagation issue; it'd be a problem on our end. Can you do a fast test and try to add an account from scratch and see if the client reaches your server with the URL you used for the other account?

Thanks a bunch!