Revisiting an old certificate problem.

I'll probably force a migration before bothering to do that. This _is_ a 10 year old system, even if none of the hardware is actually that old, and I'd be paying for a lot of hours of someone learning how everything is set up because of that.

As for the warning, understood, but as I pointed out, this is an empty test system that I am/was using just to try to identify where my problems are coming from. I was hoping that there was a way for the ispconfig system to regenerate the vhost files from the database.

I'll get back to cross-comparison of the files. I'll need to get to a system that has dual screens (or more), I guess.

 

I think I've made progress, and I can see exactly why it's being skipped.
In the bottom of apache2.conf, there are two relevant calls - in the NEW system.

Here's the section from mine.

ISPConfig is using *.conf files, and they're not being called up because - ta-da - conf files are expected to be in conf-available and conf-enabled.

Once I remove the *.vhost line, telling apache to read _everything_, now apachectl configtest returns this -

The second one, from ispconfig.conf, is simply - Alias /awstats-icon "/usr/share/awstats/icon" (I just commented this out)
The first one, from 000-default.conf, is -
AliasMatch ^/.well-known/acme-challenge/(.*)$ /var/www/html/.well-known/acme-challenge/$1

That one is also present in roundcube.conf, yet is commented out - so I'm not sure what it's referring to for an overlap, unless it's talking about itself. Here's the two lines in 000-default.conf

Now, I will admit that my 000-default.conf is VERY different from the 'modern' 000-default.conf. I'll attach mine in a CODE box just so people can be baffled. I'm going to be stripping parts of it out while I test.

Code:

<VirtualHost *:80>
        ServerAdmin webmaster@localhost

        DocumentRoot /var/www
        <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>
        <Directory /var/www/>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride None
                Require all granted
        </Directory>

        ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
        <Directory "/usr/lib/cgi-bin">
                AllowOverride None
                Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
                Require all granted
        </Directory>

        ErrorLog ${APACHE_LOG_DIR}/error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        CustomLog ${APACHE_LOG_DIR}/access.log combined

    Alias /doc/ "/usr/share/doc/"
    <Directory "/usr/share/doc/">
        Options Indexes MultiViews FollowSymLinks
        AllowOverride None
        Require host 127.0.0.0/255.0.0.0 ::1/128
    </Directory>

        #Add Alias For Lets Encrypt WebRoot Authentication Using ACME
        AliasMatch ^/.well-known/acme-challenge/(.*)$ /var/www/html/.well-known/acme-challenge/$1
        Alias /.well-known/acme-challenge/ /var/www/html/.well-known/acme-challenge/
        <Directory "/var/www/html/.well-known/acme-challenge/">
                Options None
                AllowOverride None
                ForceType text/plain
                RedirectMatch 404 "^(?!/\.well-known/acme-challenge/[\w-]{43}$)"
        </Directory>



</VirtualHost>

 

To follow up, I'm now actually seeing the _correct_ directory. It looks like the changes since it was ispconfig using /var/www/.well_known.. vs the current location have significantly drifted.

part of why I've been documenting everything as I go along is to try to help other people in the same situation, to save them from thirty or forty hours of troubleshooting (I've been working on this problem for a couple of years now).

 

Now I think I'm seeing the issue mentioned earlier with certbot - certbot wants to run its own web browser to capture the challenge (it wasn't doing that earlier, oddly enough). So, I'm pulling it and putting in the snap to see if that makes a difference.

 

It was a VERY common setup early on. You can still find references to it online, even with the preponderance of sites purging out old information.
edit - In any case, it still points to the old apache being '*.vhost' calls, and ISPConfig decided to put .conf files into that folder.

 

Okay - Hopefully the final update. With the snap, the main domain I'm having issues with has an SSL certificate that's taken.
Once I fix THEIR script problem, then I'll see about reworking my primary certificate so that it goes back through ISPConfig again, rather than the hack I put in place when this problem first came about.

 

I'm sorry you feel that way. I can guarantee that this system has ALWAYS had an ISPConfig install, and everything that has been installed into it has gone through the filter of "how to do X on ISPConfig". It may not have been _built into_ ISPConfig - I don't think that you guys supported it yourselves for a very long time, which meant that I had to have it to support my mail server. My original certificates were paid for.
I can probably go back to old backups and find the date range when it was activated.

 

I was using ISPConfig since old days too, but not as long as yours except perhaps since Ubuntu 8/10/12 and I upgraded from time to time as well. Yes there were some hiccups but there were handled just fine and were resolved.

From my side so far I can only see that your problem is with certbot and not with ISPConfig but supplying the "ReadMe First" data won't hurt if you want us to help you better.

If you simply wanna try further, you can ditch certbot altogether and use acme.sh in its place because this is very much possible as me and several others have done this to some of our ISPConfig servers and it works.

This remains to be seen as we also do not know how many manual things you have done to your servers but I'd say it is also worth a try.

 

It wasn't actually certbot - which I kept repeating. Yes, certbot showed that the snapd version was more functional than the apt version, but that wasn't the problem.

As I went down the list, it turns out that at some point during the various upgrades, the apache.conf directives went from requiring *.vhost to basically 'everything in the sites-enabled folder'. As mine had been carried over with the *.vhost directives from previous revisions, it ignored the .load and .conf files completely. Once those were actually loading into Apache - which explains why it seemed to be an apache problem - then the rest of the errors were reasonably easy to troubleshoot.

Now, I'm troubleshooting other issues, but those are more things like "Customers not upgrading their wordpress, and I'm not being paid to check them." I may end up trying to load php 7 in as an additional PHP, just for those few sites until I can rattle their cages to say "Hey! You haven't touched your site in 7 years!"

 

Sorry, but I migrated to nginx since Ubuntu 1604, so can't help much with that, except to note that in nginx I'd make sure to include the path/.conf in the .vhost if I wish to load them together, so is there anywhere in apache2 they would require something alike?

 

If you look at post 24 - https://forum.howtoforge.com/threads/revisiting-an-old-certificate-problem.93536/page-2#post-462850
you'll see where it is.

It turns out there are two IncludeOptions statements, one said to include from conf-enabled/*.conf, the other sites-enabled/*.vhost. In the new, clean installs of ISPConfig, apache says 'IncludeOptions sites-enabled/' - and that's it. No *.vhost.

So, in this case, my server was doing exactly what it was told to do. In the 'sites' folder, read the .vhost files for sites. The .conf files, such as the 999-acme.conf, were completely ignored. Once I removed the '*.vhost', and told it to load everything, suddenly I received some different errors that were reasonably easy to fix, and THEN I saw certbot trying to kick apache out of the way That's when I did your recommended with the snapd - which addressed that issue.

 

So does it work now because we can't tell?