On Mon, Dec 09, 2024 at 02:21:41PM +0000, Stuart Cassoff wrote:
> $ cd /usr/ports/x11/dbus-tcl && make fetch
> ===> Checking files for dbus-tcl-3.1
> >> Fetch https://chiselapp.com/user/schelte/repository/dbus/uv/dbus-3.1.tar.gz
> TLS handshake failure: certificate verification failed: unable to get local
> issuer certificate
> >> Fetch https://ftp.openbsd.org/pub/OpenBSD/distfiles/dbus-3.1.tar.gz
> dbus-3.1.tar.gz
> 100% |
> ***********************************************************************************************|
> 158 KB 00:00
>
As you can see from the output of openssl s_client -connect chiselapp.com:433,
it sends the wrong intermediate in its cert chain:
Certificate chain
0 s:/CN=chiselapp.com
i:/C=US/O=Let's Encrypt/CN=R10
1 s:/C=US/O=Let's Encrypt/CN=R11
i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
The issuer of cert 0 is R10, but it sends R11.
This should be fixed by the server operator.
> The site has a valid Letsencrypt cert, according to Firefox and Chrome.
The cert is indeed valid if you have R10 available.
I suspect chrome and firefox have the LE intermediates baked in (or go
fetch it from the Authority Info Access extension) so as to be able to
cope with such misconfigurations.
> I could add this to the port:
> FETCH_CMD = /usr/bin/ftp -V ${_PROGRESS} -C -S dont
> But I doubt that's recommended or desired.
>
> Any help with this would be greatly appreciated.
>
>
> Stu
>
