[chirp_devel] Any idea why certs are rejected by curl/wget in Fedora 27?
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-2018..., 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?
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 https://community.letsencrypt.org/t/curl-refuses-to-accept-my-cert-saying-the-certificate-issuer-is-not-recognized/40917. The underlying problem: the certificate chain is incomplete on the web server.
Easy way to test: use ssllabs analyze page https://www.ssllabs.com/ssltest/analyze.html?d=trac.chirp.danplanet.com.
Why does accessing trac.chirp.danplanet.com from a browser work? The browser cached the missing validation chain.
I submitted ticket 5663 https://chirp.danplanet.com/issues/5663 for the problem.
Neil Katin
On 2018-03-25 13:35, Nolan Darilek via chirp_devel wrote:
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-2018..., 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
Thanks for doing all this legwork!
On 03/25/2018 05:07 PM, Neil Katin via chirp_devel wrote:
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 https://community.letsencrypt.org/t/curl-refuses-to-accept-my-cert-saying-the-certificate-issuer-is-not-recognized/40917. The underlying problem: the certificate chain is incomplete on the web server.
Easy way to test: use ssllabs analyze page https://www.ssllabs.com/ssltest/analyze.html?d=trac.chirp.danplanet.com.
Why does accessing trac.chirp.danplanet.com from a browser work? The browser cached the missing validation chain.
I submitted ticket 5663 https://chirp.danplanet.com/issues/5663 for the problem.
Neil Katin
On 2018-03-25 13:35, Nolan Darilek via chirp_devel wrote:
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-2018..., 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
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
Others have had this issue. The underlying problem: the certificate chain is incomplete on the web server.
It's actually not that. It's that certbot-auto was configuring my older apache in a way that caused it not to load the intermediate certs from the full chain. I've fixed it now.
I submitted ticket 5663 for the problem.
And I've deleted it. The issue tracker is for CHIRP bugs, not transient infrastructure issues.
Thanks to both of you for letting me know. I'm not sure how I haven't noticed since I converted the site to letsencrypt a few months ago.
--Dan
participants (3)
-
Dan Smith -
Neil Katin -
Nolan Darilek