IndexError: list index out of range

My domain is: wolk.rogez.be

I ran this command: certbot run

It produced this output:

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/wolk.rogez.be/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/wolk.rogez.be/privkey.pem
This certificate expires on 2024-10-07.
These files will be updated when the certificate renews.

Deploying certificate
Could not install certificate

NEXT STEPS:
- The certificate will need to be renewed before it expires. Certbot can automatically renew the certificate in the background, but you may need to take steps to enable that functionality. See https://certbot.org/renewal-setup for instructions.
An unexpected error occurred:
IndexError: list index out of range

My web server is (include version): apache2 (20120211)

The operating system my web server runs on is (include version): opensuse (20240704)

My hosting provider, if applicable, is: self hosted

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 2.11.0

SSL Labs SSL Report: wolk.rogez.be
Unable to connect to the server

script reported this error:

**An unexpected error occurred:**
**IndexError: list index out of range**

vhosts.d content:

<IfDefine SSL>
<IfDefine !NOSSL>

<VirtualHost *:80> 
  ServerAlias wolk.rogez.be
  ServerAdmin support@rogez.be
  Redirect permanent / https://wolk.rogez.be/
</VirtualHost>


<VirtualHost *:443>
	DocumentRoot "/srv/www/htdocs/rogezcloud"
	ServerName wolk.rogez.be:443
	ServerAdmin support@rogez.be
	ErrorLog /var/log/apache2/error_log
	TransferLog /var/log/apache2/access_log
	SSLEngine on
	SSLUseStapling  on
	SSLCertificateFile /etc/letsencrypt/live/wolk.rogez.be/fullchain.pem
	SSLCertificateKeyFile /etc/letsencrypt/live/wolk.rogez.be/privkey.pem
	CustomLog /var/log/apache2/ssl_request_log   ssl_combined
	
	<Directory "/srv/www/htdocs/rogezcloud">
        Options Indexes FollowSymLinks
    	AllowOverride All
     	Require all granted
    </Directory>
    
    <IfModule mod_headers.c>
  		Header always set Strict-Transport-Security "max-age=15552000;"
    </IfModule>

</VirtualHost>

</IfDefine>
</IfDefine>

The ssl certificates are successfully installed but ssl is not working for my website...
What can I do?

A few things ...

First, you have an AAAA record in your DNS for an IPv6 address. But, connections to it fail on both port 80 and 443. You should correct that address or remove the AAAA record if you do not support IPv6

Second, it looks like your port 443 is blocked for your IPv4 address. Port 80 works and is what allowed you to get a cert. Although, that was sort of lucky because Let's Encrypt prefers the IPv6 address but in some cases tries IPv4 too and that must have happened this time for you. Check your router and any other network config to ensure port 443 is open to you.

Third, I have never seen the "index out of range" error from Certbot. My guess is it had something to do with your nested IF statements. Do you even need them? I mean you are setting up an HTTPS VirtualHost so wouldn't those necessarily need the correct values for Apache to run right?

I am referencing these. Seems like you could just remove these 4 lines. See if that gets rid of the "index" error.

It is also possible these variables are not set right and your port 443 VirtualHost is not enabled. And, maybe that is why SSL Labs test cannot reach you. Try removing them.

<IfDefine SSL>
<IfDefine !NOSSL>
...
</IfDefine>
</IfDefine>
5 Likes

The HTTP vhost has no ServerName [only Alias]:

The HTTPS vhost defines the ServerName with a port:
[this may or may not be providing the desired/expected result]

And, as mentioned, if either of these variables is NOT as expected, the sections will NOT be used:

5 Likes

Kill your IPV6 record... Get your cert, then fix your IPV6 record.

4 Likes

ok thanks for all the responses, I tried to do some tests with all your advices...
I list them up:

first advice
first of all I followed your advice to remove the AAAA record...
after that nothing was loading anymore...
so it seemed here (locally) everything was working on http with ipv6 (I can assure ipv6 is working in my network cause I use it mostly over ipv4)

I have a firefox extension (IPvFoo) which shows the ip protocol in the address bar and it always shows the "6" when I load the url...
maybe there is some firewall problem because when I tried to connect from my 4G (external network) to my server it connects indeed only trough ipv4...

my router firewall is configured to forward port 80 and port 443 to my server ipv4 address.

another problem could have been that the virtual host file is not redirecting the url to the / rogezcloud subfolder for soe reason, while in the virtualhost file I defined:
DocumentRoot "/srv/www/htdocs**/rogezcloud**"

So I placed an index.php in the /htdocs folder with:
header("Location: Login – wolk.rogez.be");
now it is forwarding to the right subfolder...

Then the second advice: remove the

<IfDefine SSL>
<IfDefine !NOSSL>
...
</IfDefine>
</IfDefine>

when I did remove both IfDefine's, apache was not loading anymore with error:

Job for apache2.service failed because the control process exited with error code.
See "systemctl status apache2.service" and "journalctl -xeu apache2.service" for details.

so I tried to remove only one IfDefine...
then apache was starting again.

And the third advice: serverAlias vs serverName
I did not understand completely when I should put the port and when not...
But I replaced the serverAlias by serverName...
So now my VirtualHost file looks like this:

<IfDefine SSL>

<VirtualHost *:80> 
  DocumentRoot "/srv/www/htdocs/rogezcloud"
  ServerName wolk.rogez.be:80
  ServerAdmin support@rogez.be
  # Redirect permanent / https://wolk.rogez.be/
</VirtualHost>


<VirtualHost *:443>
	DocumentRoot "/srv/www/htdocs/rogezcloud"
	ServerName wolk.rogez.be:443
	ServerAdmin support@rogez.be
	ErrorLog /var/log/apache2/error_log
	TransferLog /var/log/apache2/access_log
	SSLEngine on
	SSLUseStapling  on
	SSLCertificateFile /etc/letsencrypt/live/wolk.rogez.be/fullchain.pem
	SSLCertificateKeyFile /etc/letsencrypt/live/wolk.rogez.be/privkey.pem
	CustomLog /var/log/apache2/ssl_request_log   ssl_combined
	
	<Directory "/srv/www/htdocs/rogezcloud">
        Options Indexes FollowSymLinks
    	AllowOverride All
     	Require all granted
    </Directory>
    
</VirtualHost>

</IfDefine>

I ran "certbot run" again but still have the same problem...

Also i checked my server firewall and think all ports nescessary are be open?
Screenshot from 2024-07-10 03-29-02

In my router the forwarding should be fine I guess?

So any more advive what could be wrong here?
And I guess for ipv6 no port forwarding is needed since I directly pointed the AAAA record to the server ip address..?

ps: I am a newbe to all of this but I really like to understand and fix the problem.

1 Like

What is important to get a cert and for access from the public internet is whether you can be reached from the public internet. The https://letsdebug.net site is helpful for testing this. From that you can see HTTP requests using IPv6 timeout but IPv4 succeed

Making a request to http://wolk.rogez.be/.well-known/acme-challenge/letsdebug-test
using initial IP 2a02:a03f:ea7a:9d13:7475:1e3f:81c8:dc69
Experienced error: dial tcp [2a02:a03f:ea7a:9d13:7475:1e3f:81c8:dc69]:80: 
i/o timeout

Making a request to http://wolk.rogez.be/.well-known/acme-challenge/letsdebug-test
using initial IP 81.240.238.113
Server response: HTTP 404 Not Found

Using SSL Labs you can see HTTPS (port 443) requests fail using either.
https://www.ssllabs.com/ssltest/analyze.html?d=wolk.rogez.be&hideResults=on

As noted earlier, the Let's Encrypt auth server does a fallback retry for IPv6 timeout when an IPv4 address exists. But, this is not good to rely on. A failing IPv6 AAAA record will cause anyone using IPv6 from the public internet to fail.

Does your firewall have separate rules for inbound IPv4 and IPv6? Some do. In any case, something is interfering with IPv6 requests

Then something is very wrong with your Apache setup. What were the detail messages after running the two commands it suggested.

They will probably explain why port 443 (HTTPS) requests are failing.

As for above, normally you don't specify the port number on the ServerName or ServerAlias names when using name-based VirtualHosts - which you are. I don't think that is causing these troubles but it will be cleaner if you remove the port numbers.

6 Likes

About the IPv6: as I suspected before ipv6 was only working on the local network, after removing the AAAA record letsdebug.net said "All OK"

SSL Report: wolk.rogez.be (81.240.238.113) still says:

Assessment failed: Unable to connect to the server 

Then I tried to issue the certificate again but I still get the same error:

IndexError: list index out of range

So I started debugging the VirtualHost file... Removing the "" gave back the apache error, logs under here, but no idea what kills it?

pico:/srv/www/htdocs # systemctl status apache2.service
× apache2.service - The Apache Webserver
     Loaded: loaded (/usr/lib/systemd/system/apache2.service; enabled; preset: disabled)
     Active: failed (Result: exit-code) since Wed 2024-07-10 17:26:39 CEST; 12s ago
   Duration: 6min 907ms
    Process: 646307 ExecStart=/usr/sbin/start_apache2 -DSYSTEMD -DFOREGROUND -k start (code=exited, status=1/FAILURE)
   Main PID: 646307 (code=exited, status=1/FAILURE)
     Status: "Reading configuration..."
        CPU: 70ms

Jul 10 17:26:39 pico systemd[1]: Starting The Apache Webserver...
Jul 10 17:26:39 pico systemd[1]: apache2.service: Main process exited, code=exited, status=1/FAILURE
Jul 10 17:26:39 pico systemd[1]: apache2.service: Failed with result 'exit-code'.
Jul 10 17:26:39 pico systemd[1]: Failed to start The Apache Webserver.
pico:/srv/www/htdocs # journalctl -xeu apache2.service
░░ The unit apache2.service has successfully entered the 'dead' state.
Jul 10 17:26:39 pico systemd[1]: Stopped The Apache Webserver.
░░ Subject: A stop job for unit apache2.service has finished
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ A stop job for unit apache2.service has finished.
░░ 
░░ The job identifier is 65888 and the job result is done.
Jul 10 17:26:39 pico systemd[1]: apache2.service: Consumed 7.727s CPU time.
░░ Subject: Resources consumed by unit runtime
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ The unit apache2.service completed and consumed the indicated resources.
Jul 10 17:26:39 pico systemd[1]: Starting The Apache Webserver...
░░ Subject: A start job for unit apache2.service has begun execution
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ A start job for unit apache2.service has begun execution.
░░ 
░░ The job identifier is 65888.
Jul 10 17:26:39 pico systemd[1]: apache2.service: Main process exited, code=exited, status=1/FAILURE
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ An ExecStart= process belonging to unit apache2.service has exited.
░░ 
░░ The process' exit code is 'exited' and its exit status is 1.
Jul 10 17:26:39 pico systemd[1]: apache2.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ The unit apache2.service has entered the 'failed' state with result 'exit-code'.
Jul 10 17:26:39 pico systemd[1]: Failed to start The Apache Webserver.
░░ Subject: A start job for unit apache2.service has failed
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ A start job for unit apache2.service has finished with a failure.
░░ 
░░ The job identifier is 65888 and the job result is failed.

Then I found another Apache config file for my nextcloud server in the conf.d folder:

Alias /rogezcloud "/srv/www/htdocs/rogezcloud/"
<Directory "/srv/www/htdocs/rogezcloud">
    Options +FollowSymLinks
    AllowOverride All

    <IfModule mod_dav.c>
      Dav off
    </IfModule>

    <IfModule mod_headers.c>
      Header always set Referrer-Policy no-referrer
      Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
    </IfModule>

    SetEnv HOME /srv/www/htdocs/rogezcloud
    SetEnv HTTP_HOME /srv/www/htdocs/rogezcloud
</Directory>

<Directory "/srv/www/htdocs/rogezcloud/data/">
  # just in case if .htaccess gets disabled
  Require all denied
</Directory>

<IfModule mod_rewrite.c>
  RewriteEngine on
  RewriteRule ^/\.well-known/host-meta /rogezcloud/public.php?service=host-meta [QSA,L]
  RewriteRule ^/\.well-known/host-meta\.json /rogezcloud/public.php?service=host-meta-json [QSA,L]
  RewriteRule ^/\.well-known/nodeinfo /rogezcloud/index.php/.well-known/nodeinfo [R=301,L]
  RewriteRule ^/\.well-known/webfinger /rogezcloud/index.php/.well-known/webfinger [R=301,L]
  RewriteRule ^/\.well-known/carddav /rogezcloud/remote.php/dav/ [R=301,L]
  RewriteRule ^/\.well-known/caldav /rogezcloud/remote.php/dav/ [R=301,L]
</IfModule>

Anything wrong here?

To make my server reachable trough ipv6 from outside I tried to define a new firewall rule on my "Unifi Security Gateway":
Accept Any Source on 80,443 to 80,443 on 2a02:a03f:ea7a:9d13:7475:1e3f:81c8:dc69 (my global server ipv6 address)

The ipv6 address I defined before as AAAA was this same server address, should that be correct?
Is there anything extra I should open in the opensuse firewall for ipv6 access from the wan?

thanks again for all your help.

1 Like

@kleajmp Even while the other comments are all also true and should be addressed, I don't like the "IndexError: list index out of range" error produced by Certbot. Can you please show the entire letsencrypt.log which produced that error?

1 Like

In addition to that log does this show anything?

sudo apache2ctl -t -D DUMP_VHOSTS

My guess is some required component for SSL is not installed / enabled. And, that this causes Apache start to fail when you try to enable a VirtualHost for port 443 (and ssl).

3 Likes

ok maybe this letsencrypt.log can show something interesting... some python stuff I do not yet understand... due to my very basic knowledge.

2024-07-10 17:23:59,915:DEBUG:certbot._internal.main:certbot version: 2.11.0
2024-07-10 17:23:59,915:DEBUG:certbot._internal.main:Location of certbot entry point: /bin/certbot
2024-07-10 17:23:59,915:DEBUG:certbot._internal.main:Arguments: []
2024-07-10 17:23:59,915:DEBUG:certbot._internal.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#apache,PluginEntryPoint#manual,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2024-07-10 17:23:59,920:DEBUG:certbot._internal.log:Root logging level set at 30
2024-07-10 17:23:59,920:DEBUG:certbot._internal.plugins.selection:Requested authenticator None and installer None
2024-07-10 17:24:00,004:DEBUG:certbot_apache._internal.configurator:Apache version is 2.4.59
2024-07-10 17:24:00,246:WARNING:certbot_apache._internal.configurator:ssl_module is statically linked but --apache-bin is missing; not disabling session tickets.
2024-07-10 17:24:00,246:DEBUG:certbot._internal.plugins.selection:Single candidate plugin: * apache
Description: Apache Web Server plugin
Interfaces: Authenticator, Installer, Plugin
Entry point: EntryPoint(name='apache', value='certbot_apache._internal.entrypoint:ENTRYPOINT', group='certbot.plugins')
Initialized: <certbot_apache._internal.override_suse.OpenSUSEConfigurator object at 0x7f77c712ab70>
Prep: True
2024-07-10 17:24:00,247:DEBUG:certbot._internal.plugins.selection:Selected authenticator <certbot_apache._internal.override_suse.OpenSUSEConfigurator object at 0x7f77c712ab70> and installer <certbot_apache._internal.override_suse.OpenSUSEConfigurator object at 0x7f77c712ab70>
2024-07-10 17:24:00,247:INFO:certbot._internal.plugins.selection:Plugins selected: Authenticator apache, Installer apache
2024-07-10 17:24:00,275:DEBUG:certbot._internal.main:Picked account: <Account(RegistrationResource(body=Registration(key=None, contact=(), agreement=None, status=None, terms_of_service_agreed=None, only_return_existing=None, external_account_binding=None), uri='https://acme-v02.api.letsencrypt.org/acme/acct/1828379537', new_authzr_uri=None, terms_of_service=None), 03554a6e37fb98a4c39f1a6f1e14f5d8, Meta(creation_dt=datetime.datetime(2024, 7, 9, 21, 56, 34, tzinfo=<UTC>), creation_host='suseone.rogezz', register_to_eff=None))>
2024-07-10 17:24:00,276:DEBUG:acme.client:Sending GET request to https://acme-v02.api.letsencrypt.org/directory.
2024-07-10 17:24:00,276:DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org:443
2024-07-10 17:24:00,674:DEBUG:urllib3.connectionpool:https://acme-v02.api.letsencrypt.org:443 "GET /directory HTTP/1.1" 200 746
2024-07-10 17:24:00,675:DEBUG:acme.client:Received response:
HTTP 200
Server: nginx
Date: Wed, 10 Jul 2024 15:24:00 GMT
Content-Type: application/json
Content-Length: 746
Connection: keep-alive
Cache-Control: public, max-age=0, no-cache
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800

{
  "dwDocz1LU7c": "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417",
  "keyChange": "https://acme-v02.api.letsencrypt.org/acme/key-change",
  "meta": {
    "caaIdentities": [
      "letsencrypt.org"
    ],
    "termsOfService": "https://letsencrypt.org/documents/LE-SA-v1.4-April-3-2024.pdf",
    "website": "https://letsencrypt.org"
  },
  "newAccount": "https://acme-v02.api.letsencrypt.org/acme/new-acct",
  "newNonce": "https://acme-v02.api.letsencrypt.org/acme/new-nonce",
  "newOrder": "https://acme-v02.api.letsencrypt.org/acme/new-order",
  "renewalInfo": "https://acme-v02.api.letsencrypt.org/draft-ietf-acme-ari-03/renewalInfo",
  "revokeCert": "https://acme-v02.api.letsencrypt.org/acme/revoke-cert"
}
2024-07-10 17:24:06,739:DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): e6.o.lencr.org:80
2024-07-10 17:24:06,934:DEBUG:urllib3.connectionpool:http://e6.o.lencr.org:80 "POST / HTTP/1.1" 200 345
2024-07-10 17:24:06,936:DEBUG:certbot.ocsp:OCSP response for certificate /etc/letsencrypt/archive/wolk.rogez.be/cert2.pem is signed by the certificate's issuer.
2024-07-10 17:24:06,940:DEBUG:certbot.ocsp:OCSP certificate status for /etc/letsencrypt/archive/wolk.rogez.be/cert2.pem is: OCSPCertStatus.GOOD
2024-07-10 17:24:06,946:DEBUG:certbot._internal.display.obj:Notifying user: Certificate not yet due for renewal
2024-07-10 17:24:11,258:INFO:certbot._internal.main:Keeping the existing certificate
2024-07-10 17:24:11,258:DEBUG:certbot._internal.display.obj:Notifying user: Deploying certificate
2024-07-10 17:24:11,297:DEBUG:certbot.reverter:Creating backup of /etc/apache2/httpd.conf
2024-07-10 17:24:11,297:DEBUG:certbot.reverter:Creating backup of /etc/apache2/vhosts.d/rogezcloud.conf
2024-07-10 17:24:11,354:INFO:certbot_apache._internal.configurator:Deploying Certificate to VirtualHost /etc/apache2/vhosts.d/rogezcloud.conf
2024-07-10 17:24:11,355:DEBUG:certbot._internal.error_handler:Encountered exception:
Traceback (most recent call last):
  File "/usr/lib/python3.12/site-packages/certbot/_internal/client.py", line 657, in deploy_certificate
    self.installer.deploy_cert(
  File "/usr/lib/python3.12/site-packages/certbot_apache/_internal/configurator.py", line 530, in deploy_cert
    self._deploy_cert(vhost, cert_path, key_path, chain_path, fullchain_path)
  File "/usr/lib/python3.12/site-packages/certbot_apache/_internal/configurator.py", line 689, in _deploy_cert
    self.parser.aug.set(path["cert_path"][-1], fullchain_path)
                        ~~~~~~~~~~~~~~~~~^^^^
IndexError: list index out of range

2024-07-10 17:24:11,355:DEBUG:certbot._internal.error_handler:Calling registered functions
2024-07-10 17:24:11,360:DEBUG:certbot._internal.display.obj:Notifying user: Could not install certificate
2024-07-10 17:24:11,360:DEBUG:certbot._internal.log:Exiting abnormally:
Traceback (most recent call last):
  File "/bin/certbot", line 33, in <module>
    sys.exit(load_entry_point('certbot==2.11.0', 'console_scripts', 'certbot')())
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/certbot/main.py", line 19, in main
    return internal_main.main(cli_args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/certbot/_internal/main.py", line 1894, in main
    return config.func(config, plugins)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/certbot/_internal/main.py", line 1464, in run
    _install_cert(config, le_client, domains, new_lineage)
  File "/usr/lib/python3.12/site-packages/certbot/_internal/main.py", line 1058, in _install_cert
    le_client.deploy_certificate(domains, path_provider.key_path, path_provider.cert_path,
  File "/usr/lib/python3.12/site-packages/certbot/_internal/client.py", line 657, in deploy_certificate
    self.installer.deploy_cert(
  File "/usr/lib/python3.12/site-packages/certbot_apache/_internal/configurator.py", line 530, in deploy_cert
    self._deploy_cert(vhost, cert_path, key_path, chain_path, fullchain_path)
  File "/usr/lib/python3.12/site-packages/certbot_apache/_internal/configurator.py", line 689, in _deploy_cert
    self.parser.aug.set(path["cert_path"][-1], fullchain_path)
                        ~~~~~~~~~~~~~~~~~^^^^
IndexError: list index out of range
2024-07-10 17:24:11,361:ERROR:certbot._internal.log:An unexpected error occurred:
2024-07-10 17:24:11,361:ERROR:certbot._internal.log:IndexError: list index out of range

then here is the unsuspected output of: sudo apache2ctl -t -D DUMP_VHOSTS:

apache2ctl: command not found

I read further here:
https://doc.opensuse.org/documentation/leap/reference/html/book-reference/cha-apache2.html
and tried the suggested command for opensuse: apachectl -t -D DUMP_VHOSTS
which outputted:

VirtualHost configuration:

no nothing more...
So I tried the command: apachectl -S
which outputted:

VirtualHost configuration:
ServerRoot: "/srv/www"
Main DocumentRoot: "/srv/www/htdocs"
Main ErrorLog: "/var/log/apache2/error_log"
Mutex ssl-stapling-refresh: using_defaults
Mutex rewrite-map: using_defaults
Mutex ssl-stapling: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/run/" mechanism=default 
Mutex mpm-accept: using_defaults
PidFile: "/run/httpd.pid"
Define: SYSCONFIG
Define: phpMyAdmin
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="wwwrun" id=454
Group: name="www" id=455

Hope you get any wiser with this?

My guess is some required component for SSL is not installed / enabled. And, that this causes Apache start to fail when you try to enable a VirtualHost for port 443 (and ssl).

Yes maybe, if any advice witch one..?

I will follow up, thanks a million times.

I am just as wise as before :slight_smile:

But, I see the likely problem. That -S option should have shown all the active VirtualHosts in your system same as dump_vhosts. But, there aren't any. Again, probably because of the faulty IF which does not trigger and so does not include your VirtualHost statements.

I've not seen that before so would have to chase google or Apache support forums same as you. I'll leave that to you or someone else here who might know.

This probably would work to show the same problem. You should see all your domains and which ports defined with them

sudo apachectl -t -D DUMP_VHOSTS

The --apache authenticator will make a temporary VirtualHost in some cases and this is likely one of those. That's why you got as far as you did.

I just noticed this. Not related to above but do you know why your domain redirects to that acloud system? Might point to yet another problem.

curl -i http://wolk.rogez.be
HTTP/1.1 301 Moved Permanently
Server: Apache
Location: https://acloud.acawa.be/
3 Likes

I can answer this one :slight_smile:

The 'acloud' system is a second well working nextcloud server (hosted on another computer) also here in my network (192.168.1.90). I'm trying to 'clone' this webserver to a new computer as being: 'rogezcloud' but with fresh config and user database. The problem is that with ipv4 I can only forward the 80 and 443 port to one server at the time, so for the moment my public ip is pointed back to the original acloud server.

But I can assure when I requested the ssl certificate for the new rogezcloud server the ip was forwarded to the right (rogezcloud) server. That is why I would like to make use of ipv6 because than I don't need any port forwarding... But also this (firewall) issue, is another problem I cannot get resolved for this moment.

Again, probably because of the faulty IF which does not trigger and so does not include your VirtualHost statements.

so the <IfDefine SSL></IfDefine> makes apache skip the VirtualHost configuration since SSL is not working for some reason, if I get you right?

Probably yes, that makes a lot of sense...
I compared all the installed apache modules from the ssl enabled (acloud) server with the new server I try to set up here (rogezcoud) and they are exactly the same.

I've not seen that before so would have to chase google or Apache support forums same as you. I'll leave that to you or someone else here who might know.

Yes this will be my journey for the next days I guess...
Any tips to get me started? Like copy the acloud ssl certificates and vertualhost config to this computer and see if it works or any other ideas?

1 Like

That is my wise guess, yes :slight_smile:

I would start by removing the IfDefine statement (and the endif one) and figure out why Apache fails to start. Try removing parts inside that block until it works. That might help isolate what is failing exactly.

I'd try removing the SSL related VirtualHost first. Then see if it starts. Or even just run apachectl with -S or -t -D DUMP_VHOSTS so you can see what a proper output looks like. Maybe run that command on one of your other systems so you know what you should see. Other distros may use apache2ctl or httpd but they each support those same options.

It seems very wrong to have that IF removed and Apache fail to start.

Perhaps try an opensuse support forum?

4 Likes

Now one big hooray for this case!

I found the evil deamon:

# SSLUseStapling on

after putting this line to comment the apache server did not crash any more...
I blindly copied this line from my 'acloud' config without knowing what it actually did, so yes, this proofs we are only human beings. I I still don't know why is was there... but good.

I cannot thank you enough for all the patience and great advice to get me to (step by step) solve this problem.

After I reissued the certbot run command and it completed directly without any errors, after that my https has gone working as it should!

Now only leaves me the ipv6 firewall issue... but I'll figure that out :wink:

Good night!

1 Like

My info may be stale but Apache's stapling support wasn't great (isn't great?).

The mod_md module does have good stapling support but in general stapling is an advanced feature. mod_md is very nice but not worth doing just for stapling except I suppose in specialized cases.

mod_md provides Apache with a built-in ACME client so just with config options in Apache you can get and manage certs without needing Certbot (or any other standalone ACME client)
https://httpd.apache.org/docs/current/mod/mod_md.html

4 Likes