Newbie - Unable to find a virtual host listening on port 80 with server behind home NAT

Help
1

The issue is that my webserver is behind my home NAT (80 -> 8080, 443 -> 443 - not enabled on apache yet).

As you can see below, certbot complains there is not a virtual host on 80, which is actually correct. Do I have to create such VH? Can I tell certbot it has to take care of the VH on 8080?

thanks in advance

My domain is:
thecampanileproject.org
www.thecampanileproject.org

I ran this command:
sudo certbot --apache -v

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache

Which names would you like to activate HTTPS for?
We recommend selecting either all domains, or all domains in a VirtualHost/server block.

1: thecampanileproject.org
2: www.thecampanileproject.org

Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel):
Requesting a certificate for thecampanileproject.org and www.thecampanileproject.org
Performing the following challenges:
http-01 challenge for thecampanileproject.org
http-01 challenge for www.thecampanileproject.org
Enabled Apache rewrite module
Cleaning up challenges
Unable to find a virtual host listening on port 80 which is currently needed for Certbot to prove to the CA that you control your domain. Please add a virtual host for port 80.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

My web server is (include version):

Server version: Apache/2.4.52 (Ubuntu)
Server built: 2023-05-03T20:02:51

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

Linux campanile 6.2.6-76060206-generic #202303130630~1679424972~22.04~4a8cde1 SMP PREEMPT_DYNAMIC Tue M x86_64 x86_64 x86_64 GNU/Linux

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

1 Like
2

Hi @ste4nari, and welcome to the LE community forum :slight_smile:
If you are doing external port 80 to internal port 8080, then:
Try using (with Apache vhost):
image

OR [if you haven't created, nor want to create, a vhost (in Apache) to handle port 8080]
image
AND
image
[that way certbot can server the content needed on port 8080 for you]

See: User Guide — Certbot 2.7.0.dev0 documentation (eff-certbot.readthedocs.io)

2 Likes
3

Try this out:

sudo certbot \
certonly \
--standalone \
--http-01-port 8080 \
-d thecampanileproject.org -d www.thecampanileproject.org \
--dry-run

If that "works", then just remove the "\ --dry-run" [tail].

1 Like
4

Sorry for the multiple posts...

But I just noticed that both names don't resolve in DNS:
The "www" name shows an IP, but the bare domain does not.
That will be a problem for HTTP-01 authentication.
:frowning:

If you can't get an IP for it...
You can just get a cert for the "www" name:

sudo certbot \
certonly \
--standalone \
--http-01-port 8080 \
-d www.thecampanileproject.org \
--dry-run
1 Like
5

@rg305 I'm not sure if standalone is a very good idea. It almost never is. For some reason, looking at the log, Certbot doesn't seem to have an issue with getting a certificate. Although I don't see any certs issued at crt.sh nor Censys Search.. Hmm, weird.. Why wouldn't Certbot complain about any failed challenges? :thinking:

@ste4nari What's the reason behind the whole mapping 80 to 8080?

1 Like
6

@Osiris,
It never got around to it.
Using --apache as the authentication required it to find a vhost to use - and it could not find one.
So, it stopped before anything else.
But even if it was to proceed, DNS is a problem with the bare domain name.

2 Likes
7

Seems like things are changing as we type...

curl -Ii http://www.thecampanileproject.org:80/
HTTP/1.1 403 Forbidden
Date: Wed, 18 Oct 2023 07:47:19 GMT
Server: Apache/2.4.52 (Ubuntu)
Content-Type: text/html; charset=iso-8859-1

I'd like to see the output of:

sudo apachectl -t -D DUMP_VHOSTS

OR
at least a response ... :zzz:

2 Likes
8

It looks like the --apache configurator listens to the --http-01-port option:

But just for the www subdomain. The apex domain still doesn't have an A, AAAA or CNAME configured. (Note that a CNAME on an apex domain is not always the best option, as CNAMEs don't allow other RRs next to it, although I believe there are exceptions in the RFCs, I dunno which RRs those exceptions are.)

1 Like
9

Hi Rudy and thanks.
Specifying the port and the domain www.thecampanileproject.org worked. The 403 is ok, I need to redirect the / to /campanile (i.e. https://www.thecampanileproject.org/campanile works as expected).

I need to figure out the thecampanileproject.org issue. certbot suggests the following:

Certbot failed to authenticate some domains (authenticator: apache). The Certificate Authority reported these problems:
Domain: thecampanileproject.org
Type: dns
Detail: no valid A records found for thecampanileproject.org; no valid AAAA records found for thecampanileproject.org

I'll move from there.

One more question: if I reach the site with https://www.thecampanileproject.org/campanile, Firefox marks it as not secure... is that the correct behaviour?

image

1 Like
10

Instead, you could just change the DocumentRoot to point to that folder directly.

2 Likes
11

No.
If the cert covers that name, it should be secure for all files and folders.

2 Likes
12

thanks Osiris, that's probably the fix!

1 Like
13

You have mixed content on your website.

3 Likes
14

Ohh... I see, you are right, trying with a direct page it marks it secure! Many thanks!

2 Likes
15

Do you understand how to fix "mixed content"?
[that's when a site serves secure and insecure content on the same page]

2 Likes
16

Yep thanks. The only challenge will be finding the time to fix it :wink:

3 Likes
17

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