X509: certificate signed by unknown authority for https://tardigrade.io/trusted-satellites


-p 192.168.x.x:14002:14002
-p 28967:28967
-e ADDRESS=“ddnsdomain.net:28967
as I enter the console from inside the same LAN.

The place where the domain is at is only at address, and that is OK.

It took around 4 hours.

Yes it was signed correctly.

I repeated the process listed above three times.

Seems a problem with letsencrypt certificate. I believe CA-Authorities on the container does not have LetsEncrypt root cert.

2020-12-17T04:18:20.714Z ERROR trust Failed to fetch URLs from source {“source”: “https://tardigrade.io/trusted-satellites”, “error”: “HTTP source: Get “https://tardigrade.io/trusted-satellites”: x509: certificate signed by unknown authority”, “errorVerbose”: “HTTP source: Get “https://tardigrade.io/trusted-satellites”: x509: certificate signed by unknown authority\n[tstorj.io/storj/storagenode/trust.](http://tstorj.io/storj/storagenode/trust.(*HTTPSource)

Thank you stefan.

At the moment I am running the node as listed in this other post thread:

Works like a charm, no need for docker, no need for root privileges, integrated in os as standalone, just perfect.

What are you waiting for to develop a .deb package?
I could do it by myself and share it =)

The problem with aarch64 image. Please, use the arm32v6 instead

Yeah this bug does not affect arm32 image.

But as I stated, I am using native binaries mounted as services at OS level. I really prefer this way:

  • Less overhead
  • Lack of docker knowledge
  • I can pack the whole node up inside a drive, in case of OS reinstall, as it where some days ago…
  • Friendly use for debianists and ubuntu users.

Just telling some.

The same issue here.

The same workaround here:

The next version should have a fix and we will need to pull the image manually and change the docker run back to the latest


Get this error in the tail of my logs. Checked and the server can resolve anything plus it is downloading and uploading within the docket container. Not sure if I should be concerned about this on?

2020-12-23T00:44:27.808Z WARN trust Failed to fetch URLs from source; used cache {“source”: “https://tardigrade.io/trusted-satellites”, “error”: “HTTP source: Get “https://tardigrade.io/trusted-satellites”: x509: certificate signed by unknown authority”, “errorVerbose”: “HTTP source: Get “https://tardigrade.io/trusted-satellites”: x509: certificate signed by unknown authority\n\tstorj.io/storj/storagenode/trust.(*HTTPSource).FetchEntries:63\n\tstorj.io/storj/storagenode/trust.(*List).fetchEntries:90\n\tstorj.io/storj/storagenode/trust.(*List).FetchURLs:49\n\tstorj.io/storj/storagenode/trust.(*Pool).fetchURLs:240\n\tstorj.io/storj/storagenode/trust.(*Pool).Refresh:177\n\tstorj.io/storj/storagenode/trust.(*Pool).Run:114\n\tstorj.io/storj/private/lifecycle.(*Group).Run.func1:57\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57”}

PING tardigrade.io ( 56(84) bytes of data.
64 bytes from ( icmp_seq=1 ttl=106 time=149 ms
64 bytes from

Looks like it can be resolved as well

Have you running your node on FreeNAS?
If so the solution is

I run a synology. The Cert on the machine and from lookup is ok. This message seems to indicate a Cert problem outside my network does it not?

@Alexey @stefanbenten looks like the root cause on the server-side:

Certificate #1: is OK but Certificate #2:

Please inform your responsible person about it because it definitely a big issue and security breach.

The same issue on storj.io site:

Unless these were just fixed I dont see the same errors.
Nevermind I didn’t see the second one to expand. I to see the second one.

no, it not fixed, you can check it with ssllabs and compare for example with github.com.

Certificate #2 - is a big issue.

Yeah your right, but it doesnt even look related to storj at all, Both are using the same one though.

1 Like

It a wrong configuration on the server side, and Certificate #2 should NOT be here.

we’re looking into this and appreciate the report - have been discussing this rapidly with various folks in the company – but just wanted to pop back here for a minute and give an update so you kow we are investigating!


We’ve been investigating this issue and while we don’t completely understand all the details, we know enough that it shouldn’t be cause for alarm. Here is some useful insight from @Egon:

Based on my really-late-night look at it.
It is a netlify.com certificate. We use Netlify to manage our web pages. As an example https://www.ssllabs.com/ssltest/analyze.html?d=app.netlify.com&s= shows the exact same certificate.
When a server hosts multiple domains on the same IP, it can send all the certificates at once (rather than the one for a particular domain). I’m not familiar with our netlify setup, but I’m guessing our internal previews might be served from domain that’s under .netlify.com. However, SNI extension can be used to distinguish which exact cert to use. In this case SNI for *.netlify.com is missing. I’m not sure whether this is intentional or not. Either way http clients should be able to pick the correct cert based on Subject.

You can verify that the certificate served by app.netlify.com (here) and the second certificate from these comments by @Odmin are the same by checking the SHA256 hashes.


And more great information, from the one and only @littleskunk:

There is an easy workaround
Affected storage nodes can add this to their config:
storage2.trust.sources: "/mnt/ssd/syncthing/Sync/Transfer/trustedsatellites.txt"
and save the content of the trusted satellite list in that file
That way you can keep your storage node running over the holidays and don’t need to worry about any errors.

File content: