CentOS Stream 9 simply won't work

My domain is: screensmith.biz (with 4 subdomains)

I ran this command: certbot --apache

It produced this output:

2022-10-23 06:22:29,885:DEBUG:urllib3.connectionpool:http://localhost:None "GET /v2/connections?snap=certbot&interface=content HTTP/1.1" 200 97
2022-10-23 06:22:30,815:DEBUG:certbot._internal.main:certbot version: 1.31.0
2022-10-23 06:22:30,815:DEBUG:certbot._internal.main:Location of certbot entry point: /snap/certbot/2414/bin/certbot
2022-10-23 06:22:30,815:DEBUG:certbot._internal.main:Arguments: ['--apache', '--preconfigured-renewal']
2022-10-23 06:22:30,815:DEBUG:certbot._internal.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#apache,PluginEntryPoint#manual,PluginEntryPoint#nginx,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2022-10-23 06:22:30,833:DEBUG:certbot._internal.log:Root logging level set at 30
2022-10-23 06:22:30,834:DEBUG:certbot._internal.plugins.selection:Requested authenticator apache and installer apache
2022-10-23 06:22:31,262:DEBUG:certbot_apache._internal.configurator:Apache version is 2.4.53
2022-10-23 06:22:31,388:WARNING:certbot_apache._internal.apache_util:Error in checking parameter list:
2022-10-23 06:22:31,389:DEBUG:certbot._internal.plugins.disco:Misconfigured PluginEntryPoint#apache: Apache is unable to check whether or not the module is loaded because Apache is misconfigured.
Traceback (most recent call last):
  File "/var/lib/snapd/snap/certbot/2414/lib/python3.8/site-packages/certbot/_internal/plugins/disco.py", line 160, in prepare
  File "/var/lib/snapd/snap/certbot/2414/lib/python3.8/site-packages/certbot_apache/_internal/configurator.py", line 368, in prepare
    self.parser = self.get_parser()
  File "/var/lib/snapd/snap/certbot/2414/lib/python3.8/site-packages/certbot_apache/_internal/override_centos.py", line 79, in get_parser
    return CentOSParser(
  File "/var/lib/snapd/snap/certbot/2414/lib/python3.8/site-packages/certbot_apache/_internal/override_centos.py", line 164, in __init__
    super().__init__(*args, **kwargs)
  File "/var/lib/snapd/snap/certbot/2414/lib/python3.8/site-packages/certbot_apache/_internal/parser.py", line 79, in __init__
  File "/var/lib/snapd/snap/certbot/2414/lib/python3.8/site-packages/certbot_apache/_internal/override_centos.py", line 169, in update_runtime_variables
  File "/var/lib/snapd/snap/certbot/2414/lib/python3.8/site-packages/certbot_apache/_internal/parser.py", line 299, in update_runtime_variables
  File "/var/lib/snapd/snap/certbot/2414/lib/python3.8/site-packages/certbot_apache/_internal/parser.py", line 305, in update_defines
    self.variables = apache_util.parse_defines(self.configurator.options.ctl)
  File "/var/lib/snapd/snap/certbot/2414/lib/python3.8/site-packages/certbot_apache/_internal/apache_util.py", line 153, in parse_defines
    matches = parse_from_subprocess(define_cmd, r"Define: ([^ \n]*)")
  File "/var/lib/snapd/snap/certbot/2414/lib/python3.8/site-packages/certbot_apache/_internal/apache_util.py", line 208, in parse_from_subprocess
    stdout = _get_runtime_cfg(command)
  File "/var/lib/snapd/snap/certbot/2414/lib/python3.8/site-packages/certbot_apache/_internal/apache_util.py", line 241, in _get_runtime_cfg
    raise errors.MisconfigurationError(
certbot.errors.MisconfigurationError: Apache is unable to check whether or not the module is loaded because Apache is misconfigured.
2022-10-23 06:22:31,406:DEBUG:certbot._internal.plugins.selection:Single candidate plugin: * apache
Description: Apache Web Server plugin
Interfaces: Installer, Authenticator, Plugin
Entry point: apache = certbot_apache._internal.entrypoint:ENTRYPOINT
Initialized: <certbot_apache._internal.override_centos.CentOSConfigurator object at 0x7fb10326dfa0>
Prep: Apache is unable to check whether or not the module is loaded because Apache is misconfigured.

My web server is (include version): Apache 2.4.53

The operating system my web server runs on is (include version): CentOS Stream 9

My hosting provider, if applicable, is: Ionos, if it matters. The server runs on an unmanaged (e.g., "self-managed") VPS with fairly scant resources.

I can login to a root shell on my machine (yes or no, or I don't know): Yes.

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): No

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 1.31.0

Additional info: This is a VPS that I'm free to reinstall. But my project is in limbo until I get SSL working, since I can't install some of the other tools I'd use otherwise (for example: logging in is simply not wise).

The subdomains are served as virtual hosts, and there isn't a suitable configuration that gets me all the way through the process.

Even a certbot certonly complains about Apache being misconfigured.

I did get a little farther with certbot --apache-ctl httpd --apache but ultimately it failed because it's trying to run httpd configtest rather than the correct verstion of that: httpd -t which runs a syntax check on the files.

If I have to start over from a new install on a fresh ISO from the core distro, that's possible.

The Apache plugin doesn't work with RHEL9-based distros at the moment: --apache doesn't work on RHEL9, need to use `httpd` rather than `apachectl` · Issue #9386 · certbot/certbot · GitHub.

For the time being, you would have to use

certbot certonly --webroot -w /path/to/webroot



Which webroot would I use, since there are 4 subdomains?

Or do I simply have to generate a separate one for each?

Or ... do I just add the -d switch for each?

The webroot of those 4 subdomains. You can enter multiple webroot-paths (with -w), e.g. one per subdomain. See the webroot plugin documentation at User Guide — Certbot 1.31.0 documentation


For some reason, I was looking at the documentation for another version .... (sigh)


1 Like

Using that command, which included absolute paths from the root directory for each, I received:

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
  Domain: screensmith.biz
  Type:   unauthorized
  Detail: Invalid response from http://screensmith.biz/.well-known/acme-challenge/TTT4HlG2y1xPJ1hxvNkTzss1-_cInIZr4NK_PkbXmVw: 404

  Domain: www.screensmith.biz
  Type:   unauthorized
  Detail: Invalid response from http://www.screensmith.biz/.well-known/acme-challenge/YDZBd8PAadWmwsEOiF9O9DrsnmAkkuqoG-40OaKt4G4: 404

(same with subdomains)

Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.

Dot files are hidden from the world by default. That's just the way it keeps things like .htaccess from being world-readable.

Reconfiguring that is going to expose part of the server's security (implicated by .htaccess for example) and is really not a great thing.

On my Apache (Gentoo), files starting with .ht are being blocked, probably resulting in a 403 error and not a 404 file not found error.

You're getting a 404 file not found error. Are you sure that's due to the configuration which blocks .htaccess?


Likely, it's a permissions error ... I was reading the "unauthorized" result in the failure, and not the 404.

So ... without exposing root to apache, how might I be able to fix that?

The "unauthorized" is the ACME servers conclusion for the challenge, it's not actually the result from the webserver. The webservers result can be found at the end of the "Detail" part, which is "404" in your case.

I'm not sure what you mean by "exposing root to apache"? You've likely not entered the webroot-paths correctly according to you Apache configuration. Or there is some Apache configuration which says Apache should return "404 file not found" errors when the challenge file is being accessed.


I mean, very literally, adding apache to the root group (since creating new files from certbot almost certainly is done with owner/group as root).

Were that the case, would I be able to access the index.html or index.php or whatever from any subdomain?

They're all working, all accessible, and all absolutely visible.

I even tested from a tablet, which I've never visited the subdomains with before.

I copied/pasted from the conf files, which I have in a text editor on my desktop, so ... I really do think those are correct.

Anything else I can check?

I would not recommend that. It should not be necessary at all. At least, any user who has come before you did not need to add Apache to the root group, so why would you suddenly? Doesn't make much sense to me. I'm pretty sure Certbot adds the challenge files world-readable.

It could be some configuration blocking access to the .well-known path, as you said before.

You can use the --debug-challenges option to temporarily pause Certbot with the challenge files in place and debug Apache.


Well, it doesn't like the new httpd command, either, so go figure. CentOS Stream 9 isn't a workalike to CentOS 7 (which I had before). New distro, new commands, and new ways ... that's where I think the biggest part of the issue is.

Oddly, that isn't what fixed it, though that was additional clues and such ... ultimately, this was just my reluctance to show my work (e.g., show the actual, full command).

What I hadn't considered was that the sort order from multiple directories has to match up exactly with the sort order from multiple domains. It's getting confused because www.* is an alias for the main domain, and so it's counting that as an extra subdomain (throwing off the counts and mis-ordering the files it's trying to drop).

So, adding a SECOND instance of the correct directory (e.g., identical -w for each -d alias) to align with the alias (rather than just adding the domain by itself) worked perfectly.

What worked:

certbot certonly --webroot -w /path/to/primary/domain -d example.com -w /path/to/primary/domain -d www.example.com -w /path/to/subdomain_1 -d sub1.example.com -w /path/to/subdomain_2  -d sub2.example.com -w /path/to/subdomain_3 -d sub3.example.com 

Weird. It should be enough to have them arranged as -w /path/to/A -d A -d www.A -w /path/to/B -d B -d www.B


That's what I'd expect to work, but it simply didn't work that way, for some reason I can't fathom.

Adding a second (identical) -w as the associated directory to the immediately-following -d is what solved my issue.

Possibly a bug? No idea why it would essentially ignore the path on a second URL immediately following it.

EDIT: (bangs face on desk) In the previous lines (exploring further), I was apparently trying to use the -w after the alias/domain directory ... so, the "bug" is in my brain.

1 Like

The issue with the Apache plugin on RHEL9 and derivatives will be fixed in the next version of Certbot, 1.32.0, to be released in the first week of November.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.