Your message dated Tue, 18 Nov 2025 18:02:52 +0100
with message-id
<CAAe0PDyLuey3btKXChjP_9Gz=GubN2Zj=tudzsk-5hkqwum...@mail.gmail.com>
and subject line Re: Bug#1120927: freeradius: Segmentation fault with 3-chain
certificate
has caused the Debian Bug report #1120927,
regarding freeradius: Segmentation fault with 3-chain certificate
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1120927: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1120927
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: freeradius
Version: 3.2.7+dfsg-1+deb13u1
Severity: serious
Dear Maintainer,
Our setup is working fine, with a Sectigo DV certificate chain in
/etc/freeradius/ssl/fullchain.pem & /etc/freeradius/ssl/privkey.pem, with a
Radsec setup (so private_key_file and certificate_file are set in
3.0/sites-available/tls, as well as in 3.0/mods-available/eap), we routinely
verify this via a distant rad_eap test (doing Radius-over-Radsec-over-Radius).
Today, I had to update that certificate (which is close to expiring), moving
from this chain:
* certificate
* Sectigo ECC Domain Validation Secure Server CA
* USERTrust ECC Certification Authority
to this chain:
* certificate
* Sectigo Public Server Authentication CA DV E36
* Sectigo Public Server Authentication Root E46
* USERTrust ECC Certification Authority
… and it now segfaults whenever we try to access the radius-to-radsec proxy.
In other words, the fullchain.pem which before contained 2 certificates (the
certificate and 1 intermediary), now contains 3 certificates (the certificate,
and 2 intermediaries), and with this the server segfaults.
I have not yet managed to extract a stacktrace or a core dump, I would be all
ears to get this solved.
Best,
OdyX
-- System Information:
Debian Release: 13.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.12.41+deb13-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages freeradius depends on:
ii freeradius-common 3.2.7+dfsg-1+deb13u1
ii freeradius-config 3.2.7+dfsg-1+deb13u1
ii libc6 2.41-12
ii libcrypt1 1:4.4.38-1
ii libct4 1.3.17+ds-2+deb13u1
ii libfreeradius3 3.2.7+dfsg-1+deb13u1
ii libgdbm6t64 1.24-2
ii libjson-c5 0.18+ds-1
ii libpam0g 1.7.0-5
ii libperl5.40 5.40.1-6
ii libreadline8t64 8.2-6
ii libsqlite3-0 3.46.1-7
ii libssl3t64 3.5.4-1~deb13u1
ii libsystemd0 257.9-1~deb13u1
ii libtalloc2 2:2.4.3+samba4.22.6+dfsg-0+deb13u1
ii libwbclient0 2:4.22.6+dfsg-0+deb13u1
ii perl 5.40.1-6
Versions of packages freeradius recommends:
ii freeradius-utils 3.2.7+dfsg-1+deb13u1
Versions of packages freeradius suggests:
pn freeradius-krb5 <none>
ii freeradius-ldap 3.2.7+dfsg-1+deb13u1
pn freeradius-mysql <none>
pn freeradius-postgresql <none>
pn freeradius-python3 <none>
pn snmp <none>
--- End Message ---
--- Begin Message ---
Version: 3.2.8+dfsg-1
Control: tags -1 +patch +upstream
Control: forwarded -1
https://github.com/FreeRADIUS/freeradius-server/issues/5515
Hello there Bernhard,
Fantastic! I spent the afternoon trying to reproduce a minimal case in
Docker (and had succeeded just when I saw your email).
It turns out… I have built this patch in a trixie chroot and deployed
it to our production server, and the segfault is gone!
So I'm marking this as fixed in the version in testing/unstable.
Should we get to prepare a stable update? It'd be really nice to get
this fixed for everyone using stable, happy to help!
Best,
OdyX
On Tue, 18 Nov 2025 17:12:57 +0100 Bernhard Schmidt <[email protected]> wrote:
> > Our setup is working fine, with a Sectigo DV certificate chain in
> > /etc/freeradius/ssl/fullchain.pem & /etc/freeradius/ssl/privkey.pem, with a
> > Radsec setup (so private_key_file and certificate_file are set in
> > 3.0/sites-available/tls, as well as in 3.0/mods-available/eap), we routinely
> > verify this via a distant rad_eap test (doing
> > Radius-over-Radsec-over-Radius).
> >
> > Today, I had to update that certificate (which is close to expiring), moving
> > from this chain:
> >
> > * certificate
> > * Sectigo ECC Domain Validation Secure Server CA
> > * USERTrust ECC Certification Authority
> >
> > to this chain:
> >
> > * certificate
> > * Sectigo Public Server Authentication CA DV E36
> > * Sectigo Public Server Authentication Root E46
> > * USERTrust ECC Certification Authority
> >
> > … and it now segfaults whenever we try to access the radius-to-radsec proxy.
> >
> > In other words, the fullchain.pem which before contained 2 certificates (the
> > certificate and 1 intermediary), now contains 3 certificates (the
> > certificate,
> > and 2 intermediaries), and with this the server segfaults.
> >
> > I have not yet managed to extract a stacktrace or a core dump, I would be
> > all
> > ears to get this solved.
>
> This sounds a bit like this problem
>
> https://github.com/FreeRADIUS/freeradius-server/issues/5515
> https://github.com/FreeRADIUS/freeradius-server/commit/286415adce9bc9e8cf974810f5be941dc2131056
>
> which is resolved in 3.2.8.
>
> Do you have a chance to check with this patch applied?
freeradius_1120927.debdiff
Description: Binary data
--- End Message ---
