Bug 1672285 - FreeRADIUS should not generate certificates at package installation
Summary: FreeRADIUS should not generate certificates at package installation
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: freeradius
Version: 8.0
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: 8.0
Assignee: Alex Scheel
QA Contact: Filip Dvorak
lmcgarry
URL:
Whiteboard:
: 1857230 (view as bug list)
Depends On: 1574783 1672284 1717880 1720667
Blocks: 1842946
TreeView+ depends on / blocked
 
Reported: 2019-02-04 13:16 UTC by Stephen Gallagher
Modified: 2021-02-02 13:17 UTC (History)
10 users (show)

Fixed In Version: freeradius-3.0-8030020200806223029.1e4bbb35
Doc Type: Bug Fix
Doc Text:
.FreeRADIUS no longer generates certificates during package installation Previously, FreeRADIUS generated certificates during package installation, resulting in the following issues: * If FreeRADIUS was installed using Kickstart, certificates might be generated at a time when entropy on the system was insufficient, resulting in either a failed installation or a less secure certificate. * The package was difficult to build as part of an image, such as a container, because the package installation occurs on the builder machine instead of the target machine. All instances that are spawned from the image had the same certificate information. * It was difficult for an end-user to generate a simple VM in their environment as the certificates would have to be removed and regenerated manually. With this update, the FreeRADIUS installation no longer generates default self-signed CA certificates nor subordinate CA certificates. When FreeRADIUS is launched via `systemd`: * If all of the required certificates are missing, a set of default certificates are generated. * If one or more of the expected certificates are present, it does not generate new certificates.
Clone Of: 1672284
Environment:
Last Closed: 2020-11-04 03:58:12 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 5767041 0 None None None 2021-02-02 13:17:28 UTC
Red Hat Product Errata RHSA-2020:4799 0 None None None 2020-11-04 03:58:21 UTC

Description Stephen Gallagher 2019-02-04 13:16:03 UTC
+++ This bug was initially created as a clone of Bug #1672284 +++

Description of problem:
FreeRADIUS currently generates a self-signed CA certificate as well as subordinate certificates and some passwords while installing the freeradius package. This is against the Fedora Packaging Guidelines[1] for several good reasons:

1) If freeradius is installed via kickstart, the certificates may be generated at a time when entropy on the system is insufficient, resulting in either a failed installation (scriptlet returns non-zero) or a less-secure certificate.

2) The package cannot easily be built as part of an image (such as a container or ostree image) because the package installation occurs on the builder machine, not the target machine and thus all instances of it that are spawned from the image will have the same certificate information.

3) It makes it difficult for an end-user to generate a common VM in their environment. They can remove the certificates manually, but there's no simple way to regenerate them on the cloned children. The user must know how to do this themselves, manually.

Fedora packaging guidelines[1] now mandate that the behavior here should be that this certificate generation does not occur in an RPM scriptlet, but that it instead takes place as part of a systemd unit that is launched prior to (and blocks the start of) the main service unit for the package. Specific details on how to accomplish this are provided on the guidelines page. I am also available to help with the implementation if needed.

Moving the auto-generation from the scriptlet to the systemd unit addresses all three of the issues mentioned above.



Version-Release number of selected component (if applicable):

freeradius-3.0.17-4.fc30
freeradius-3.0-820190131191847.fbe42456


How reproducible:
Every time

Steps to Reproduce:
1. Install the `freeradius` package in Fedora/RHEL 8
2. Check the contents of /etc/raddb/certs


Actual results:
ca.pem, server.crt and many other certificates are present.

Expected results:
The certificates should not be present until the first time the service is launched.


Additional info:

[1] Fedora Packaging Guidelines:
https://fedoraproject.org/wiki/Packaging:Initial_Service_Setup

Comment 20 Alex Scheel 2020-07-22 11:13:20 UTC
*** Bug 1857230 has been marked as a duplicate of this bug. ***

Comment 35 errata-xmlrpc 2020-11-04 03:58:12 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: freeradius:3.0 security and bug fix update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:4799

Comment 36 Alex Scheel 2020-11-23 13:23:30 UTC
It came to my attention recently that some customers don't like this behavior.


To avoid this, use a systemd override file (execute `sudo systemctl edit radiusd.service` to create one) with the contents:

[Service]
ExecStartPre=
ExecStartPre=/usr/sbin/radiusd -C

to disable certificate generation at service startup.

This can be tested with `sudo systemctl restart radiusd.service`.

Please refer to the systemd docs for more information about unit file overrides.


I do not recommend editing the original systemd unit file we ship with FreeRADIUS RPM in RHEL as it is package configuration and subject to change in a future release.


Note You need to log in before you can comment on or make changes to this bug.