Right, Firefox and Chrome do use AIAs. I wish they wouldn't...
--
Sent from a phone, apologies for poor formatting.
On 9 December 2024 14:45:04 Theo Buehler <t...@theobuehler.org> wrote:
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
