Summary: | www-servers/apache-2.4.62: default config references SSL cert that doesn't exist by default | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Calvin Buckley <calvin> |
Component: | Current packages | Assignee: | Apache Team - Bugzilla Reports <apache-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | binhost, calvin, eschwartz, floppym, shimarin |
Priority: | Normal | Keywords: | PullRequest |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://github.com/gentoo/gentoo/pull/42258 https://bugs.gentoo.org/show_bug.cgi?id=956634 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
emerge -av www-server/apache
ssl-cert eclass patch |
Description
Calvin Buckley
2025-05-22 16:26:26 UTC
Installing apache should install that certificate. It does this only when the associated .pem file does not exist. Perhaps you have a /etc/ssl/apache2/server.pem file left that prohibits the generation of the certificate? This was a new install, so there would be no previous Apache config. The only thing that I could think of that may throw it off is that I'm using the binary packages whenever possible. Perhaps those don't create the certificate vs. a normal emerge from source? Created attachment 929353 [details]
emerge -av www-server/apache
Attaching the emerge output since I forgot, in case it helps for i.e. post-install stuff that didn't get triggered.
(In reply to Calvin Buckley from comment #2) > This was a new install, so there would be no previous Apache config. The > only thing that I could think of that may throw it off is that I'm using the > binary packages whenever possible. Perhaps those don't create the > certificate vs. a normal emerge from source? That is a possibility, I have cc'ed the binhost people so that they can have a look. (In reply to Calvin Buckley from comment #2) > This was a new install, so there would be no previous Apache config. The > only thing that I could think of that may throw it off is that I'm using the > binary packages whenever possible. Perhaps those don't create the > certificate vs. a normal emerge from source? Binary packages run pkg_postinst only after being installed. Its (pkg_postinst) output is not part of the built package. apache-2.eclass defines apache-2_pkg_postinst() { if use ssl && [[ ! -e "${EROOT}/etc/ssl/apache2/server.pem" ]]; then SSL_ORGANIZATION="${SSL_ORGANIZATION:-Apache HTTP Server}" install_cert /etc/ssl/apache2/server [...] } and this code snippet is executed at `emerge --getbinpkg www-servers/apache` time, *not* on the build server. From your log,
>>> /etc/apache2/httpd.conf
* Generating OpenSSL configuration for CA ... [ ok ]
* Generating 4096 bit RSA key for CA ... [ !! ]
*
* The location of SSL certificates has changed. If you are
* upgrading from www-servers/apache-2.2.13 or earlier (or remerged
* *any* apache version), you might want to move your old
* certificates from /etc/apache2/ssl/ to /etc/ssl/apache2/ and
* update your config files.
This is from within that conditional block...
install_cert() {
[...]
# Generate a CA environment #164601
gen_cnf 1 || return 1
# will print: Generating OpenSSL configuration
gen_key 1 || return 1
# will print: Generating ${SSL_BITS} bit RSA key
gen_csr 1 || return 1
# will print: Generating Certificate Signing Request
gen_crt 1 || return 1
# will print: Generating self-signed X.509 Certificate
[...]
}
But only the first two run. Oops. The status is "[ !! ]" indicating failure.
Created attachment 929561 [details, diff]
ssl-cert eclass patch
Could you apply this patch to ssl-cert.eclass and reinstall apache? Hopefully this will generate a more useful error message in the build log.
There's no change after applying the patch. Do I need to not use the binary package for this to be applied? ``` [...] >>> /etc/apache2/httpd.conf * Generating OpenSSL configuration for CA ... [ ok ] * Generating 4096 bit RSA key for CA ... [ !! ] * * The location of SSL certificates has changed. If you are * upgrading from www-servers/apache-2.2.13 or earlier (or remerged * *any* apache version), you might want to move your old * certificates from /etc/apache2/ssl/ to /etc/ssl/apache2/ and * update your config files. * * Attention: cgi and cgid modules are now handled via APACHE2_MODULES flags * in make.conf. Make sure to enable those in order to compile them. * In general, you should use 'cgid' with threaded MPMs and 'cgi' otherwise. * Attention: The tls module based on rustls-ffi has been moved to its own package. * emerge www-apache/mod_tls to continue using the tls module. >>> www-servers/apache-2.4.63-r1 merged. [...] ``` (In reply to Calvin Buckley from comment #8) > There's no change after applying the patch. Do I need to not use the binary > package for this to be applied? Yes. The pkg_postinst shell code at the time the binary package got built, is what is stored in the binary package for later running. Building `www-servers/apache-2.4.63-r1` after having merged Mike's patch, it seems it actually succeeds somehow: ``` [...] >>> /usr/lib64/apache2/modules/mod_authn_file.so * Generating OpenSSL configuration for CA ... [ ok ] * Generating 4096 bit RSA key for CA ... [ ok ] * Generating Certificate Signing Request for CA ... [ ok ] * Generating self-signed X.509 Certificate for CA ... Certificate request self-signature ok subject=C=US, ST=California, L=Santa Barbara, O=Apache HTTP Server, OU=For Testing Purposes Only, CN=localhost CA, emailAddress=root@localhost [ ok ] * Generating OpenSSL configuration ... [ ok ] * Generating 4096 bit RSA key ... [ ok ] * Generating Certificate Signing Request ... [ ok ] * Generating authority-signed X.509 Certificate ... Certificate request self-signature ok subject=C=US, ST=California, L=Santa Barbara, O=Apache HTTP Server, OU=For Testing Purposes Only, CN=localhost, emailAddress=root@localhost [ ok ] * Generating PEM Certificate ... [ ok ] * * The location of SSL certificates has changed. If you are * upgrading from www-servers/apache-2.2.13 or earlier (or remerged * *any* apache version), you might want to move your old * certificates from /etc/apache2/ssl/ to /etc/ssl/apache2/ and * update your config files. * * Attention: cgi and cgid modules are now handled via APACHE2_MODULES flags * in make.conf. Make sure to enable those in order to compile them. * In general, you should use 'cgid' with threaded MPMs and 'cgi' otherwise. * Attention: The tls module based on rustls-ffi has been moved to its own package. * emerge www-apache/mod_tls to continue using the tls module. >>> www-servers/apache-2.4.63-r1 merged. ``` The generated certificate is in `/etc/ssl/apache2`. But, If I try using the same version as binpkg from emerge, however, it fails as previously mentioned: ``` [...] >>> /etc/apache2/httpd.conf * Generating OpenSSL configuration for CA ... [ ok ] * Generating 4096 bit RSA key for CA ... [ !! ] * * The location of SSL certificates has changed. If you are * upgrading from www-servers/apache-2.2.13 or earlier (or remerged * *any* apache version), you might want to move your old * certificates from /etc/apache2/ssl/ to /etc/ssl/apache2/ and * update your config files. * * Attention: cgi and cgid modules are now handled via APACHE2_MODULES flags * in make.conf. Make sure to enable those in order to compile them. * In general, you should use 'cgid' with threaded MPMs and 'cgi' otherwise. * Attention: The tls module based on rustls-ffi has been moved to its own package. * emerge www-apache/mod_tls to continue using the tls module. >>> www-servers/apache-2.4.63-r1 merged. ``` Hmm, maybe just add a /usr/local/bin/openssl wrapper script that redirects stdout/stderr to /tmp/sslcert.log and wait for the binary package to call the wrapper. Reinstalling the binary package after removing /etc/ssl/apache2 again, same error condition as last time, and nothing interesting in stdio from openssl: ``` utmgentoo /var/db/repos/gentoo # cat /tmp/ssl.err ** openssl genrsa -rand /var/tmp/portage/www-servers/apache-2.4.63-r1/temp/environment:/var/tmp/portage/www-servers/apache-2.4.63-r1/temp/eclass-debug.log:/etc/resolv.conf -out /var/tmp/portage/www-servers/apache-2.4.63-r1/temp/264461ca.key 4096 utmgentoo /var/db/repos/gentoo # cat /tmp/ssl.out ** openssl genrsa -rand /var/tmp/portage/www-servers/apache-2.4.63-r1/temp/environment:/var/tmp/portage/www-servers/apache-2.4.63-r1/temp/eclass-debug.log:/etc/resolv.conf -out /var/tmp/portage/www-servers/apache-2.4.63-r1/temp/264461ca.key 4096 utmgentoo /var/db/repos/gentoo # cat /usr/local/bin/openssl #!/usr/bin/env bash set -euo pipefail echo " ** openssl $@" >> /tmp/ssl.out echo " ** openssl $@" >> /tmp/ssl.err /usr/bin/openssl "$@" | tee -a /tmp/ssl.out 2>> /tmp/ssl.err ``` (In reply to Calvin Buckley from comment #12) > utmgentoo /var/db/repos/gentoo # cat /usr/local/bin/openssl > #!/usr/bin/env bash > set -euo pipefail > echo " ** openssl $@" >> /tmp/ssl.out > echo " ** openssl $@" >> /tmp/ssl.err > /usr/bin/openssl "$@" | tee -a /tmp/ssl.out 2>> /tmp/ssl.err > ``` Don't bother with tee. For this use case it is unnecessary complexity and is hiding the fact that the error stream for the openssl tool isn't being redirected at all -- only the error stream for "tee". ah, forget I was capturing stderr from the wrong thing. I love unix! ``` utmgentoo /var/db/repos/gentoo # cat /tmp/ssl.out ** openssl genrsa -rand /var/tmp/portage/www-servers/apache-2.4.63-r1/temp/environment:/var/tmp/portage/www-servers/apache-2.4.63-r1/temp/eclass-debug.log:/etc/resolv.conf -out /var/tmp/portage/www-servers/apache-2.4.63-r1/temp/264967ca.key 4096 utmgentoo /var/db/repos/gentoo # cat /tmp/ssl.err ** openssl genrsa -rand /var/tmp/portage/www-servers/apache-2.4.63-r1/temp/environment:/var/tmp/portage/www-servers/apache-2.4.63-r1/temp/eclass-debug.log:/etc/resolv.conf -out /var/tmp/portage/www-servers/apache-2.4.63-r1/temp/264967ca.key 4096 Can't load /var/tmp/portage/www-servers/apache-2.4.63-r1/temp/eclass-debug.log into RNG 209024ABFFFF0000:error:12000079:random number generator:RAND_load_file:Cannot open file:../openssl-3.3.3/crypto/rand/randfile.c:107:Filename=/var/tmp/portage/www-servers/apache-2.4.63-r1/temp/eclass-debug.log utmgentoo /var/db/repos/gentoo # cat /usr/local/bin/openssl #!/usr/bin/env bash set -euo pipefail echo " ** openssl $@" >> /tmp/ssl.out echo " ** openssl $@" >> /tmp/ssl.err /usr/bin/openssl "$@" >> /tmp/ssl.out 2>> /tmp/ssl.err ``` ``` # Location of some random files OpenSSL can use: don't use # /dev/u?random here -- doesn't work properly on all platforms SSL_RANDOM="${T}/environment:${T}/eclass-debug.log:/etc/resolv.conf" ``` (In reply to Sam James from comment #15) > ``` > # Location of some random files OpenSSL can use: don't use > # /dev/u?random here -- doesn't work properly on all platforms > SSL_RANDOM="${T}/environment:${T}/eclass-debug.log:/etc/resolv.conf" > ``` https://docs.openssl.org/1.1.1/man1/rand/#notes """ NOTES¶ Prior to OpenSSL 1.1.1, it was common for applications to store information about the state of the random-number generator in a file that was loaded at startup and rewritten upon exit. On modern operating systems, this is generally no longer necessary as OpenSSL will seed itself from a trusted entropy source provided by the operating system. The -rand and -writerand flags are still supported for special platforms or circumstances that might require them. It is generally an error to use the same seed file more than once and every use of -rand should be paired with -writerand. """" *** Bug 791184 has been marked as a duplicate of this bug. *** An old dupe: bug 791184. openssl is trying to use ${T}/eclass-debug.log to seed its random number generator. It seems this file does not exist when the binpkg is being merged. ssl-cert.eclass mentions that /dev/[u]random should not be used since it "doesn't work properly on all platforms". This comment dates back to 2003 and is likely nonsense. Modern openssl will use the getrandom() syscall on Linux anyway. I would propose we drop SSL_RANDOM and the -rand option from ssl-cert.eclass. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=bf8a9809c6529960579264d2102ced61c9779960 commit bf8a9809c6529960579264d2102ced61c9779960 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2025-05-26 03:07:43 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2025-05-27 18:14:49 +0000 ssl-cert.eclass: do not pass -rand to openssl Let openssl find a suitable entropy source instead of using some random log files for "random" bytes. Bug: https://bugs.gentoo.org/956442 Signed-off-by: Mike Gilbert <floppym@gentoo.org> eclass/ssl-cert.eclass | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=511c5d9c5f92f4b2994f11435e3936b7286318be commit 511c5d9c5f92f4b2994f11435e3936b7286318be Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2025-05-25 16:49:21 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2025-05-27 18:14:48 +0000 ssl-cert.eclass: use edob for openssl calls Bug: https://bugs.gentoo.org/956442 Signed-off-by: Mike Gilbert <floppym@gentoo.org> eclass/ssl-cert.eclass | 40 ++++++++++++++++++---------------------- 1 file changed, 18 insertions(+), 22 deletions(-) My understanding is that the changes in ssl-cert.eclass should fix this. Please re-open if this is still a problem. |