HTTP -> HTTPS not working

Help
#1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:Waitati.com

I ran this command:certbot-auto enhance -d waitati.com --redirect

It produced this output:
Asked me which certificate to use (waitati.com)
Asked me which domain (waitati.com, one choice)
Created redirect file: le-redirect-waitati.com.conf
Rollback checkpoint is empty (no changes made?)

My web server is (include version):
Apache2: Version: 2.4.18-2ubuntu3.14

The operating system my web server runs on is (include version):
Ubuntu 16.04

My hosting provider, if applicable, is: VPS

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.0.0

When visiting http://waitati.com I am taken to: /var/www/html/index.html

There is no configuration file with that document root.
I am stumped

1 Like
#2

There is probably some name overlap…
Please show output of:
apachectl -S

#3 
$ apachectl -S
AH00526: Syntax error on line 23 of /etc/apache2/sites-enabled/Metiria.nz-le-ssl.conf:
SSLCertificateFile: file '/etc/letsencrypt/live/metiria.nz-0001/fullchain.pem' does not exist or is empty
Action '-S' failed.
The Apache error log may have more information.

I reran certbot-auto for metiria.nz but still getting error.

sudo wc /etc/letsencrypt/live/metiria.nz-0001/fullchain.pem
  58   62 3546 /etc/letsencrypt/live/metiria.nz-0001/fullchain.pem
#4

Disabling the offending site does not help.
The problem is repeated on another.

#5

You will have to walk through the config.
Please show:

grep -Ei 'include|sslcert|servername|serveralias|virt|listen' /etc/apache2/apache2.conf
ls -l /etc/apache2/sites-enabled/
grep -Ei 'include|sslcert|servername|serveralias|virt|listen' /etc/apache2/sites-enabled/
ls -l /etc/letsencrypt/live/
#6

There are two domains/sites: sharron.nz and whynotcofe.com

Both display /var/www/html/index.html using http and as expected with https

:/etc/apache2/sites-enabled$ grep -Ei ‘include|sslcert|servername|serveralias|virt|listen’ *
Sharron.nz-le-ssl.conf:<VirtualHost *:443>
Sharron.nz-le-ssl.conf: ServerName sharron.nz
Sharron.nz-le-ssl.conf: ServerAlias www.sharron.nz
Sharron.nz-le-ssl.conf: # include a line for only one particular virtual host. For example the
Sharron.nz-le-ssl.conf: #Include conf-available/serve-cgi-bin.conf
Sharron.nz-le-ssl.conf:Include /etc/letsencrypt/options-ssl-apache.conf
Sharron.nz-le-ssl.conf:SSLCertificateFile /etc/letsencrypt/live/sharron.nz-0001/fullchain.pem
Sharron.nz-le-ssl.conf:SSLCertificateKeyFile /etc/letsencrypt/live/sharron.nz-0001/privkey.pem
Sharron.nz-le-ssl.conf:
whynotcofe.com-le-ssl.conf:<VirtualHost *:443>
whynotcofe.com-le-ssl.conf: # The ServerName directive sets the request scheme, hostname and port that
whynotcofe.com-le-ssl.conf: # redirection URLs. In the context of virtual hosts, the ServerName
whynotcofe.com-le-ssl.conf: # match this virtual host. For the default virtual host (this file) this
whynotcofe.com-le-ssl.conf: # However, you must set it for any further virtual host explicitly.
whynotcofe.com-le-ssl.conf: ServerName whynotcofe.com
whynotcofe.com-le-ssl.conf: ServerAlias *.whynotcofe.com
whynotcofe.com-le-ssl.conf: # include a line for only one particular virtual host. For example the
whynotcofe.com-le-ssl.conf: #Include conf-available/serve-cgi-bin.conf
whynotcofe.com-le-ssl.conf:Include /etc/letsencrypt/options-ssl-apache.conf
whynotcofe.com-le-ssl.conf:SSLCertificateFile /etc/letsencrypt/live/whynotcofe.com/fullchain.pem
whynotcofe.com-le-ssl.conf:SSLCertificateKeyFile /etc/letsencrypt/live/whynotcofe.com/privkey.pem
whynotcofe.com-le-ssl.conf:
:/etc/apache2$ grep -Ei ‘include|sslcert|servername|serveralias|virt|listen’ apache2.conf

virtual hosts, and extra configuration directives as flexible as possible, in

* ports.conf is always included from the main configuration file. It is

supposed to determine listening ports for incoming connections which can be

global configuration fragments, or virtual host configurations,

If you do not specify an ErrorLog directive within a

container, error messages relating to that virtual host will be

logged here. If you do define an error logfile for a

Include module configuration:

IncludeOptional mods-enabled/.load
IncludeOptional mods-enabled/.conf

Include list of ports to listen on

Include ports.conf

access here, or in any related virtual host.

Include of directories ignores editors’ and dpkg’s backup files,

Include generic snippets of statements

IncludeOptional conf-enabled/*.conf

Include the virtual host configurations:

IncludeOptional sites-enabled/*.conf
:/etc/apache2$ ls mods-enabled/
access_compat.load authn_core.load autoindex.conf dir.conf mime.load proxy.conf setenvif.load status.load
alias.conf authn_file.load autoindex.load dir.load mpm_prefork.conf proxy_http.load socache_shmcb.load
alias.load authz_core.load cgi.load env.load mpm_prefork.load proxy.load ssl.conf
auth_basic.load authz_host.load deflate.conf filter.load negotiation.conf rewrite.load ssl.load
auth_digest.load authz_user.load deflate.load mime.conf negotiation.load setenvif.conf status.conf

#7

This seems incorrect.

Please show:

1 Like
#8

$ ls -l /etc/apache2/sites-enabled/
total 0
lrwxrwxrwx 1 root root 41 Dec 9 14:02 Sharron.nz-le-ssl.conf -> …/sites-available/Sharron.nz-le-ssl.conf
lrwxrwxrwx 1 root root 42 Nov 30 12:21 whynotcofe.com-le-ssl.conf -> …/sites-available/whynotcofe.com-le-ssl.conf

$ sudo ls -l /etc/letsencrypt/live/
[sudo] password for worik:
total 44
drwxr-xr-x 2 root root 4096 Dec 9 12:04 git.worik.org
drwxr-xr-x 2 root root 4096 Jul 3 2017 killmartha.com
drwxr-xr-x 2 root root 4096 Nov 30 12:23 sharron.nz
drwxr-xr-x 2 root root 4096 Dec 9 13:00 sharron.nz-0001
drwxr-xr-x 2 root root 4096 Dec 9 12:19 psychokingdogs.com
-rw-r–r-- 1 root root 740 Nov 10 2018 README
drwxr-xr-x 2 root root 4096 Dec 9 12:16 whynotcofe.com
drwxr-xr-x 2 root root 4096 May 29 2019 worik.nz
drwxr-xr-x 2 root root 4096 May 29 2019 worik.org
drwxr-xr-x 2 root root 4096 May 29 2019 worik.org-0001
drwxr-xr-x 2 root root 4096 Jun 7 2019 www.metiria.nz

#9

Your initial post refers to a name that is not specifically included in your config [perhaps it has been disabled]

The Apache config is “missing” some information:

Based on your last post:

you might want to try changing “/metiria.nz-0001/” to “/www.metiria.nz/” in file
/etc/apache2/sites-available/Metiria.nz-le-ssl.conf before you re-enable that site.

You need to get it to the point where apachectl -S can run without any errors before proceeding to correct any naming issues.
I would enable all the sites needed, rerun it, look for errors, and correct them all.
Or you will only postpone those problems until you do enable those sites.
[feel free to post here and ask questions if needed]

1 Like
#10

Methinks what I need to do is delete all the certificates and start again.
I have two domains that require certificates and I am uneasy about laying out my entire config in public trying to track down what is clearly a obscure bug, when I am unlikely to hit rate limits, and even if I do waiting a week for LETSENCRYPT is quicker than this.

So how do I do that?

I could just delete everything in site and hope for the best, but there must be a way to uninstall the certificates sytematically

#11

That is easy to say; but from where I’m standing it doesn’t look that clear and I see no bug.
That logic doesn’t align with the failed apachectl -S and ignoring it won’t get it fixed.

If you want to remove a cert, you will have to remove the file that uses the cert first; meaning you have first to disable the ssl enabled files and then delete the cert.
Repeat that process for as many sites and certs as you need to delete.
If that can get a good apachectl -S output, then it may not be a total waste.
You can start from that and build on it step by step and check each step with that command.

1 Like
#12

There are two files for each cert (public and private?)

$ sudo ls /etc/letsencrypt/archive/worik.nz
cert1.pem  cert3.pem   chain2.pem  fullchain1.pem  fullchain3.pem  privkey2.pem
cert2.pem  chain1.pem  chain3.pem  fullchain2.pem  privkey1.pem    privkey3.pem

That is a lot of files.

Would it be simpler to delete /etc/letsencrypt?

#13

That was easy.
I changed the port to 80, deleted the certificate entries from the configuration files, reran certbot-auto and everything is working properly.

I do not think I got very good advice here. Sorry to say that, but I felt micro managed. I understand this is a free service, so this is not much of a complaint (I know it is complaining). I really appreciate the service. I know now that I am on my own with it, that is OK. A price worth paying. Keep up the good work.

Also apachectl -S is still complaining the “fullchain.pem” file does not exist. Or is empty. It is neither, albeit a link. I examined my configuration file for non printing characters (!) but there were none. So this is a bug in apachectl. That is worth remembering

 apachectl -v
Server version: Apache/2.4.18 (Ubuntu)
Server built:   2019-10-08T13:31:25
1 Like
#14

Port 80 is what has to be open to listen to. That’s probably why certbot couldn’t connect. 443 is your redirect from http to https.

#15

I have to disagree. You mist be missing something.
As long as that is complaining you will have some sort of problem.

#16

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