I replicated your issue on a Fedora 26 VM.

TL:DR: trac.chirp.danplanet.com (and chirp.danplanet.com) are misconfigured.

Others have had this issue.  The underlying problem: the certificate chain is incomplete on the web server.

Easy way to test: use ssllabs analyze page.

Why does accessing trac.chirp.danplanet.com from a browser work?  The browser cached the missing validation chain.

I submitted ticket 5663 for the problem.

Neil Katin

I'm working on creating a Chirp flatpak. flatpak-builder creates
packages by downloading and installing modules independently. So, for
instance, the Chirp flatpak consists of builds of the pygobject module,
pyserial, pygtk, pycairo, and ultimately Chirp.


When the flatpak manifest attempts to download, say,
https://trac.chirp.danplanet.com/chirp_daily/daily-20180324/chirp-daily-20180324.tar.gz,
the SSL cert is rejected as invalid. This happens for flatpak-builder,
curl, and wget on Fedora 27. Firefox works just fine.


Thoughts on what might be happening here? The obvious answer is that the
non-Firefox programs are using the system's certificate store, and the
cert for trac.chirp.danplanet.com doesn't validate against that for some
reason. I don't know enough about TLS or the cert for
trac.chirp.danplanet.com to know why that might be, though.


For the moment I'm uploading whatever daily build I'm including in the
flatpak to my own server whose cert *does* validate, but that adds an
additional step that makes automation more difficult. I'd really like to
debug why I can't download these files in F27 without disabling
certificate validation, which I can't with flatpak-builder in any case.
Thoughts?


_______________________________________________
chirp_devel mailing list
chirp_devel@intrepid.danplanet.com
http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers