# CentOS Stream 9 simply won't work **URL:** \ **Category:** Help\ **Created:** [October 23, 2022, 7:14am UTC](https://community.letsencrypt.org/t/centos-stream-9-simply-wont-work/186584 "2022-10-23T07:14:19Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![VishwaJay](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/vishwajay/32/65006_2.png) [@VishwaJay](https://community.letsencrypt.org/u/VishwaJay)\ **Post date:** [October 23, 2022, 7:14am UTC](https://community.letsencrypt.org/t/centos-stream-9-simply-wont-work/186584/1 "2022-10-23T07:14:20Z")
**My domain is:** screensmith.biz (with 4 subdomains) **I ran this command:** `certbot --apache` **It produced this output:** ```nohighlight 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 self._initialized.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__ self.update_runtime_variables() File "/var/lib/snapd/snap/certbot/2414/lib/python3.8/site-packages/certbot_apache/_internal/override_centos.py", line 169, in update_runtime_variables super().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 self.update_defines() 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: 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. ---
**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\ **Post date:** [October 23, 2022, 7:16am UTC](https://community.letsencrypt.org/t/centos-stream-9-simply-wont-work/186584/2 "2022-10-23T07:16:57Z")
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](https://github.com/certbot/certbot/issues/9386). For the time being, you would have to use ``` certbot certonly --webroot -w /path/to/webroot ``` instead. ---
**Author:** ![VishwaJay](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/vishwajay/32/65006_2.png) [@VishwaJay](https://community.letsencrypt.org/u/VishwaJay)\ **Post date:** [October 23, 2022, 4:59pm UTC](https://community.letsencrypt.org/t/centos-stream-9-simply-wont-work/186584/3 "2022-10-23T16:59:19Z")
> [@\_az](#): > > `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? ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [October 23, 2022, 5:03pm UTC](https://community.letsencrypt.org/t/centos-stream-9-simply-wont-work/186584/4 "2022-10-23T17:03:12Z")
> [@VishwaJay](#): > > Which webroot would I use, since there are 4 subdomains? 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 2.6.0 documentation](https://eff-certbot.readthedocs.io/en/stable/using.html#webroot) ---
**Author:** ![VishwaJay](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/vishwajay/32/65006_2.png) [@VishwaJay](https://community.letsencrypt.org/u/VishwaJay)\ **Post date:** [October 23, 2022, 5:08pm UTC](https://community.letsencrypt.org/t/centos-stream-9-simply-wont-work/186584/5 "2022-10-23T17:08:56Z")
For some reason, I was looking at the documentation for another version .... _(sigh)_ Thanks! ---
**Author:** ![VishwaJay](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/vishwajay/32/65006_2.png) [@VishwaJay](https://community.letsencrypt.org/u/VishwaJay)\ **Post date:** [October 23, 2022, 5:17pm UTC](https://community.letsencrypt.org/t/centos-stream-9-simply-wont-work/186584/6 "2022-10-23T17:17:21Z")
Using that command, which included absolute paths from the root directory for each, I received: ```nohighlight Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems: Domain: screensmith.biz Type: unauthorized Detail: 70.35.194.245: Invalid response from http://screensmith.biz/.well-known/acme-challenge/TTT4HlG2y1xPJ1hxvNkTzss1-_cInIZr4NK_PkbXmVw: 404 Domain: www.screensmith.biz Type: unauthorized Detail: 70.35.194.245: Invalid response from http://www.screensmith.biz/.well-known/acme-challenge/YDZBd8PAadWmwsEOiF9O9DrsnmAkkuqoG-40OaKt4G4: 404 ``` (same with subdomains) ```nohighlight 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. ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [October 23, 2022, 5:30pm UTC](https://community.letsencrypt.org/t/centos-stream-9-simply-wont-work/186584/7 "2022-10-23T17:30:24Z")
> [@VishwaJay](#): > > Dot files are hidden from the world by default. That's just the way it keeps things like `.htaccess` from being world-readable. 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`? ---
**Author:** ![VishwaJay](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/vishwajay/32/65006_2.png) [@VishwaJay](https://community.letsencrypt.org/u/VishwaJay)\ **Post date:** [October 23, 2022, 5:39pm UTC](https://community.letsencrypt.org/t/centos-stream-9-simply-wont-work/186584/8 "2022-10-23T17:39:24Z")
> [@Osiris](#): > > 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? ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [October 23, 2022, 5:42pm UTC](https://community.letsencrypt.org/t/centos-stream-9-simply-wont-work/186584/9 "2022-10-23T17:42:22Z")
> [@VishwaJay](#): > > Likely, it's a permissions error ... I was reading the "unauthorized" result in the failure, and not the 404. 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. > [@VishwaJay](#): > > So ... without exposing root to apache, how might I be able to fix that? 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. ---
**Author:** ![VishwaJay](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/vishwajay/32/65006_2.png) [@VishwaJay](https://community.letsencrypt.org/u/VishwaJay)\ **Post date:** [October 23, 2022, 5:46pm UTC](https://community.letsencrypt.org/t/centos-stream-9-simply-wont-work/186584/10 "2022-10-23T17:46:12Z")
> [@Osiris](#): > > I'm not sure what you mean by "exposing root to apache"? 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). > [@Osiris](#): > > 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. 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? ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [October 23, 2022, 5:50pm UTC](https://community.letsencrypt.org/t/centos-stream-9-simply-wont-work/186584/11 "2022-10-23T17:50:20Z")
> [@VishwaJay](#): > > 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). 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. > [@VishwaJay](#): > > 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. 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. ---
**Author:** ![VishwaJay](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/vishwajay/32/65006_2.png) [@VishwaJay](https://community.letsencrypt.org/u/VishwaJay)\ **Post date:** [October 23, 2022, 6:30pm UTC](https://community.letsencrypt.org/t/centos-stream-9-simply-wont-work/186584/12 "2022-10-23T18:30:36Z")
> [@Osiris](#): > > any user who has come before you did not need to add Apache to the root group, so why would you suddenly? 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. > [@Osiris](#): > > You can use the `--debug-challenges` option to temporarily pause Certbot with the challenge files in place and debug Apache. 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: ```nohighlight 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 ``` ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [October 23, 2022, 6:39pm UTC](https://community.letsencrypt.org/t/centos-stream-9-simply-wont-work/186584/13 "2022-10-23T18:39:37Z")
> [@VishwaJay](#): > > 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. 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` ---
**Author:** ![VishwaJay](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/vishwajay/32/65006_2.png) [@VishwaJay](https://community.letsencrypt.org/u/VishwaJay)\ **Post date:** [October 23, 2022, 6:50pm UTC](https://community.letsencrypt.org/t/centos-stream-9-simply-wont-work/186584/14 "2022-10-23T18:50:55Z")
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. ---
**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\ **Post date:** [October 27, 2022, 8:08am UTC](https://community.letsencrypt.org/t/centos-stream-9-simply-wont-work/186584/15 "2022-10-27T08:08:12Z")
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. ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [November 26, 2022, 8:08am UTC](https://community.letsencrypt.org/t/centos-stream-9-simply-wont-work/186584/16 "2022-11-26T08:08:27Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.