That's stock config for Debian and Ubuntu. It's good.
2 Likes
As @linkp noted that is the default one in Ubuntu and is fine.
I wanted to make sure you did not have anything odd like: listen 80 https.
That would be problematic in the ports.conf. This part of Apache config just defines which ports are available for your VirtualHosts. The VHosts control what happens with them.
By the way, the default SSL config file you removed probably also deleted some default settings you should have. That wouldn't explain what we see as you had it before. But, at some point you will want to review what that was and restore the proper parts.
A recap. These two openssl commands to port 80 and 443 both connect to a server returning a drupalsolent.dev cert. Only port 443 should work. Openssl to port 80 should fail
echo | openssl s_client -connect drupalsolent.dev:80
echo | openssl s_client -connect drupalsolent.dev:443
An openssl connect to internationalgospelchoir.uk on port 443 works as it should. But, using port 80 also connects and returns the drupal certificate. This is wrong but interesting result.
Similarly, HTTP (port 80) requests to drupal, internationalgospelchoir, and thesolentmetropolitan all give the same error. Perhaps odd that the bottom line is the drupal server name for all 3 domains. And, perhaps odd that it names port 80 which usually indicates the inbound port so my idea of the port crisscross happening "before" Apache might not be correct. Which is what made me wonder if Apache was crisscrossing the ports somehow (hence the ports.conf research).
curl -i http://internationalgospelchoir.uk
HTTP/1.1 400 Bad Request
Server: Apache/2.4.58 (Ubuntu)
...
Reason: You're speaking plain HTTP to an SSL-enabled server port.
Instead use the HTTPS scheme to access this URL, please.
<address>
Apache/2.4.58 (Ubuntu) Server at drupalsolent.dev Port 80
</address>
The VirtualHost for drupalsolent for port 80 has only two lines in it - the ServerName and a Redirect to HTTPS (see the stackoverflow link earlier).
Rebooting your server is not a bad idea but I don't have any further specific suggestions.
2 Likes
If you haven't tried setting up a new server yet you could show us output of these:
sudo ss -pant | grep -Ei ':80|apache'
sudo systemctl status --no-pager -l apache2
sudo ps -eF | grep apache | grep -v grep
sudo iptables -L
1 Like
rob@server03:~$ sudo ss -pant | grep -Ei ':80|apache'
LISTEN 0 511 *:80 *:* users:(("apache2",pid=562301,fd=4),("apache2",pid=561133,fd=4),("apache2",pid=560225,fd=4),("apache2",pid=560223,fd=4),("apache2",pid=560222,fd=4),("apache2",pid=560221,fd=4),("apache2",pid=559887,fd=4),("apache2",pid=559886,fd=4),("apache2",pid=559885,fd=4),("apache2",pid=559884,fd=4),("apache2",pid=530328,fd=4))
LISTEN 0 511 *:443 *:* users:(("apache2",pid=562301,fd=6),("apache2",pid=561133,fd=6),("apache2",pid=560225,fd=6),("apache2",pid=560223,fd=6),("apache2",pid=560222,fd=6),("apache2",pid=560221,fd=6),("apache2",pid=559887,fd=6),("apache2",pid=559886,fd=6),("apache2",pid=559885,fd=6),("apache2",pid=559884,fd=6),("apache2",pid=530328,fd=6))
SYN-RECV 0 0 [::ffff:157.245.32.67]:80 [::ffff:185.208.156.160]:55931
rob@server03:~$ sudo systemctl status --no-pager -l apache2
● apache2.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/apache2.service; enabled; preset: enabled)
Active: active (running) since Sat 2025-03-22 09:09:51 UTC; 1 day 13h ago
Docs: https://httpd.apache.org/docs/2.4/
Process: 530325 ExecStart=/usr/sbin/apachectl start (code=exited, status=0/SUCCESS)
Process: 540667 ExecReload=/usr/sbin/apachectl graceful (code=exited, status=0/SUCCESS)
Main PID: 530328 (apache2)
Tasks: 11 (limit: 4655)
Memory: 154.5M (peak: 192.1M)
CPU: 46.381s
CGroup: /system.slice/apache2.service
├─530328 /usr/sbin/apache2 -k start
├─559884 /usr/sbin/apache2 -k start
├─559885 /usr/sbin/apache2 -k start
├─559886 /usr/sbin/apache2 -k start
├─559887 /usr/sbin/apache2 -k start
├─560221 /usr/sbin/apache2 -k start
├─560222 /usr/sbin/apache2 -k start
├─560223 /usr/sbin/apache2 -k start
├─560225 /usr/sbin/apache2 -k start
├─561133 /usr/sbin/apache2 -k start
└─562301 /usr/sbin/apache2 -k start
Mar 22 09:09:51 server03 systemd[1]: Starting apache2.service - The Apache HTTP Server...
Mar 22 09:09:51 server03 apachectl[530327]: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message
Mar 22 09:09:51 server03 systemd[1]: Started apache2.service - The Apache HTTP Server.
Mar 23 00:00:02 server03 systemd[1]: Reloading apache2.service - The Apache HTTP Server...
Mar 23 00:00:03 server03 apachectl[540690]: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message
Mar 23 00:00:03 server03 systemd[1]: Reloaded apache2.service - The Apache HTTP Server.
rob@server03:~$ sudo ps -eF | grep apache | grep -v grep
root 530328 1 0 58225 34232 1 Mar22 ? 00:00:11 /usr/sbin/apache2 -k start
www-data 559884 530328 0 59721 86260 0 13:47 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 559885 530328 0 59213 84336 1 13:47 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 559886 530328 0 58677 83136 1 13:47 ? 00:00:01 /usr/sbin/apache2 -k start
www-data 559887 530328 0 79081 93324 1 13:47 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 560221 530328 0 78600 67632 0 14:33 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 560222 530328 0 59165 71748 0 14:33 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 560223 530328 0 59166 80500 0 14:33 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 560225 530328 0 59146 70304 1 14:33 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 561133 530328 0 59127 59688 1 16:33 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 562301 530328 0 59084 62716 0 18:47 ? 00:00:00 /usr/sbin/apache2 -k start
rob@server03:~$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
rob@server03:~$
thanks for following up again @MikeMcQ - above is my response to your question.
1 Like
No clues from that. All looks normal.
I would add a transferlog and an errorlog in each of the VirtualHosts for drupalsolent and internationalgospel. Both the port 80 and port 443 VHosts for each.
And, each log file name should be unique. For example, for port 80 drupal VirtualHost:
TransferLog "/var/log/drupal_accesslog80.log"
ErrorLog "/var/log/drupal_errorlog80.log"
After reloading Apache run https://letsdebug.net test for internationalgospelchoir and check all the logs for new and related records. Yes, even drupal's as it seems that might be involved even for your other domains.
Then, go to SSL Checker and check SSL for internationalgospelchoir on port 443. Check all the logs again.
Something very unusual is happening with the routing of HTTP(s) requests or even Apache's handling of them. If nothing else these logs will allow you to describe the problem in specific detail to your hosting company or some other network / Apache specialist.
I am a sucker for a good puzzle so I'm curious to see what you find.
1 Like
Your server's inability to handle HTTP requests prevents you from getting a cert using an HTTP Challenge. But, you could switch to using a DNS Challenge. Digital Ocean DNS is even supported by Certbot so might not be that difficult to start using: Welcome to certbot-dns-digitalocean’s documentation! — certbot-dns-digitalocean 0 documentation
Instead of using an HTTP request the D/O plugin will add a TXT record to your DNS and Let's Encrypt will validate against that.
The problem remains that your server is not handling HTTP requests for any other person either. Anyone trying (or defaulting to trying) HTTP requests to your domain will fail and will not get redirected to HTTPS as you intend.
Is this a big deal? Well, I guess that depends on your audience but I'd say yes that is important to get working. Some browsers today try HTTPS first so might not even know your HTTP is "broken". But, hard for me to say the overall impact of this on your audience.
2 Likes
Looks like this is solved - I have been able to renew thesolentmetropolitan.com and internationalgospelchoir.uk !!!
What I did was disable all of the other vhost .conf files except the above, as my terminal log shows.
I think you were onto something @MikeMcQ where you talked about some of the other vhosts files. That got me thinking that one of the other files was misconfigured. My suspicion/hunch is that a copy paste of a vhost file has left the original domain in there and not updated it with the correct domain. For example, I'm wondering if I made a copy of the drupalsolent.dev.conf file for thesolentmetropolitan.com.conf file and left the drupalsolent.dev domain in there, or something like that. I do think the problem is something like that where a copy-paste has gone wrong.
I will look into this further. For now, it seems like I don't need to build another server.
Thank you very much for your continued support @MikeMcQ and @linkp for your contribution as well.
I will try to follow up on the more specific root cause and close this post.
root@server03:/etc/apache2/sites-available# ls
000-default.conf internationalgospelchoir.uk.conf-2
drupalsolent.dev-le-ssl.conf staging.internationalgospelchoir.uk-le-ssl.conf
drupalsolent.dev.conf staging.internationalgospelchoir.uk.conf
eval1.labs.drupalsolent.dev-le-ssl.conf thesolentmetropolitan.com.conf
eval1.labs.drupalsolent.dev.conf www.drupalsolent.dev.conf
internationalgospelchoir.uk-le-ssl.conf www.internationalgospelchoir.uk-le-ssl.conf
internationalgospelchoir.uk.conf www.internationalgospelchoir.uk.conf
root@server03:/etc/apache2/sites-available# a2dissite 000-default.conf
Site 000-default already disabled
root@server03:/etc/apache2/sites-available# a2dissite drupalsolent.dev-le-ssl.conf
Site drupalsolent.dev-le-ssl disabled.
To activate the new configuration, you need to run:
systemctl reload apache2
root@server03:/etc/apache2/sites-available# a2dissite drupalsolent.dev.conf
Site drupalsolent.dev disabled.
To activate the new configuration, you need to run:
systemctl reload apache2
root@server03:/etc/apache2/sites-available# a2dissite eval1.labs.drupalsolent.dev-le-ssl.conf
Site eval1.labs.drupalsolent.dev-le-ssl disabled.
To activate the new configuration, you need to run:
systemctl reload apache2
root@server03:/etc/apache2/sites-available# a2dissite eval1.labs.drupalsolent.dev.conf
Site eval1.labs.drupalsolent.dev disabled.
To activate the new configuration, you need to run:
systemctl reload apache2
root@server03:/etc/apache2/sites-available# a2dissite staging.internationalgospelchoir.uk-le-ssl.conf
Site staging.internationalgospelchoir.uk-le-ssl disabled.
To activate the new configuration, you need to run:
systemctl reload apache2
root@server03:/etc/apache2/sites-available# a2dissite staging.internationalgospelchoir.uk.conf
Site staging.internationalgospelchoir.uk disabled.
To activate the new configuration, you need to run:
systemctl reload apache2
root@server03:/etc/apache2/sites-available# a2dissite www.drupalsolent.dev.conf
Site www.drupalsolent.dev disabled.
To activate the new configuration, you need to run:
systemctl reload apache2
root@server03:/etc/apache2/sites-available# systemctl reload apache2
root@server03:/etc/apache2/sites-available# ls
000-default.conf internationalgospelchoir.uk.conf-2
drupalsolent.dev-le-ssl.conf staging.internationalgospelchoir.uk-le-ssl.conf
drupalsolent.dev.conf staging.internationalgospelchoir.uk.conf
eval1.labs.drupalsolent.dev-le-ssl.conf thesolentmetropolitan.com.conf
eval1.labs.drupalsolent.dev.conf www.drupalsolent.dev.conf
internationalgospelchoir.uk-le-ssl.conf www.internationalgospelchoir.uk-le-ssl.conf
internationalgospelchoir.uk.conf www.internationalgospelchoir.uk.conf
root@server03:/etc/apache2/sites-available# exit
exit
rob@server03:~$ sudo certbot --apache
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Which names would you like to activate HTTPS for?
We recommend selecting either all domains, or all domains in a VirtualHost/server block.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: internationalgospelchoir.uk
2: www.internationalgospelchoir.uk
3: thesolentmetropolitan.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 3
Requesting a certificate for thesolentmetropolitan.com
Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/thesolentmetropolitan.com/fullchain.pem
Key is saved at: /etc/letsencrypt/live/thesolentmetropolitan.com/privkey.pem
This certificate expires on 2025-06-23.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.
Deploying certificate
Successfully deployed certificate for thesolentmetropolitan.com to /etc/apache2/sites-available/thesolentmetropolitan.com-le-ssl.conf
Congratulations! You have successfully enabled HTTPS on https://thesolentmetropolitan.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
* Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
* Donating to EFF: https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
rob@server03:~$
rob@server03:~$ sudo certbot --apache
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Which names would you like to activate HTTPS for?
We recommend selecting either all domains, or all domains in a VirtualHost/server block.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: internationalgospelchoir.uk
2: www.internationalgospelchoir.uk
3: thesolentmetropolitan.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 2
Renewing an existing certificate for www.internationalgospelchoir.uk
Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/www.internationalgospelchoir.uk/fullchain.pem
Key is saved at: /etc/letsencrypt/live/www.internationalgospelchoir.uk/privkey.pem
This certificate expires on 2025-06-23.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.
Deploying certificate
Successfully deployed certificate for www.internationalgospelchoir.uk to /etc/apache2/sites-enabled/www.internationalgospelchoir.uk-le-ssl.conf
Your existing certificate has been successfully renewed, and the new certificate has been installed.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
* Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
* Donating to EFF: https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
rob@server03:~$
2 Likes
Terrific!
Maybe but your "-S" display in first post showed pretty normal domain name layout. Some Apache distro's only show the ServerName value but Ubuntu should show all ServerAlias too. So, I wouldn't expect just a wrong domain name to be the explanation.
We also only saw Name-Based VHosts in that display. Nothing related to IP-Based which can cause funny "latching" problems.
Anyway, glad you got something working which you can (slowly) expand to the other domains you need to get working.
3 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.