SSL fails on ubuntu with apache

Help
1

Hello, all I am running into an issue with getting SSL setup on my new web server. I used the following website to try and install my SSL. I have looked for this error on the web, and even contacted go daddy as the IP's in the error are from DNS entries on godaddy. I have a feeling they are blocking the request. I have opened up port 403 on the server that has a static IP issued from comcast. Both TCP and UDP.

Ref: Install Let’s Encrypt SSL Certificate for Apache on Ubuntu 22.04 LTS

My domain is:

I ran this command:
sudo certbot --apache

It produced this output:
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: marine-captain.com
2: www.marine-captain.com

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 marine-captain.com and www.marine-captain.com

Certbot failed to authenticate some domains (authenticator: apache). The Certificate Authority reported these problems:
Domain: marine-captain.com
Type: unauthorized
Detail: 15.197.225.128: Invalid response from http://marine-captain.com/.well-known/acme-challenge/UBMcoaZuDOdyuSE3EbhJ0dgjvhlIhwM12QVQmyH41uY: 403

Domain: www.marine-captain.com
Type: unauthorized
Detail: 15.197.225.128: Invalid response from http://www.marine-captain.com/.well-known/acme-challenge/dX7yx7j3b4PTmAyfuQdhhr7FWLR9eoOoPMLeTWzpZfs: 403

Hint: The Certificate Authority failed to verify the temporary Apache configuration changes made by Certbot. Ensure that the listed domains point to this Apache server and that it is accessible from the internet.

Some challenges have failed.
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):
Intel NUC, with ubuntu 24.04, apache, PHP, mariaDB, and phpmyadmin

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

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 3.0.1

2

Welcome @yachtcapt

Yeah, you need to modify your GoDaddy DNS setup. The public DNS should point directly to the public IP of your server. Instead, it is setup to use Domain Forwarding.

We see this fairly often. Below is a good explanation of what to do

Your DNS right now has these two IP addresses. These are services inside of AWS that GoDaddy uses for the Forwarding feature

Name:   marine-captain.com
Address: 3.33.251.168
Address: 15.197.225.128
2 Likes
3

Thanks so much for the quick reply. I was able to get my SSL setup on marine-captain.com. I tried this tuturial to make my static IP automatically forward to my domain

https://portforwarded.com/install-lets-encrypt-ssl-certificate-for-apache-on-ubuntu-22-04-lts/

After changing the conf files per this tutorial I got an error in apache ..... I checked with due diligence on the conf files so I am not sure why it broke apache. I was able to back the conf file before making the changes and it restored it.

Any help greatly appreciated.

4

Yes, looks good. HTTPS is working for marine-captain.com and its www subdomain. And, HTTP redirects to HTTPS for both names. All is good. Also see: SSL Server Test: marine-captain.com (Powered by Qualys SSL Labs)

What is this about? I looked at that portforward site article. What, exactly, are you trying to copy. Just explain in your own words but use more than you have so far :slight_smile:

3 Likes
5

Thanks Mike, what I mean is that my static IP can still be pulled up.

http://50.214.75.161/

The article says there is a way to do the that in the conf files in apache. I tried using the instructions in the article but for some reason it broke apache when I did a restart. Fortunately I had the forethought to back up those conf files before I did that.

The goal is to have the IP address directed to the domain name automatically .....

6

Hi @yachtcapt, this maybe only supplemental information
Let’s Encrypt offers Domain Validation (DV) certificates but NOT IP Address validation certificates presently.

Here details on Apache can be found in documentation and forums:

1 Like
7

Ah, yes, it can. I don't know that most people care what happens when something connects directly using your IP address. I don't see it on that page you linked so I don't know what they said should work or exactly what you tried.

But, you can setup an Apache default VirtualHost to process any request that doesn't match your name-based VirtualHost. Be careful not to do it in a way that creates an IP-based VirtualHost since mostly Name-Based VirtualHost are used and mixing the two types is complex.

The simplest way to make a default VirtualHost is just to make sure it is the first one (alphabetically) that Apache processes. You can see the sequence and default with this

sudo apache2ctl -t -D DUMP_VHOSTS

A default VirtualHost can be pretty simple. When I use them I don't redirect them anywhere though. I deny the request (with a 403 or something). Requests coming in on your IP address directly are faulty. Likely a bot or crawler. All valid requests should be arriving using a domain name.

Even just like this as long as it is first

<VirtualHost *:80>
    DocumentRoot "/var/www/html"       # or whatever
    ServerName defaultname
    # Other directives here as you wish (disable logging, reject 403, ...)
</VirtualHost>

Making one of these work for HTTPS (port 443) is harder. It has to have proper cert and SSL config. For such a default VHost I recommend using a self-signed nonsense cert. Do not just point to one of your valid certs (my personal preference).

2 Likes
8

Why?

1 Like
9

from what I have read its a security step .....

10

Where did you read that?

Maybe you read that you should NOT use HTTP.
Maybe you read that you should NOT use HTTP to an IP.
But redirecting HTTP requests [to an IP] to a name is NOT a very good security step.

2 Likes
11

it was sited in this tuturial ....

12

redirect the IP to https:// using a 301 but don't redirect the IP to a domain name

http://50.214.75.161/ to https://50.214.75.161/ is good
http://50.214.75.161/ to https://domain.com is bad

it doesn't matter if it complains about the certificate in this scenario

or redirect to a 403 denied page like suggested already.

example:

C:\Users\J>curl http://192.168.0.1/ -L --insecure -v
*   Trying 192.168.0.1:80...
* Connected to 192.168.0.1 (192.168.0.1) port 80
> GET / HTTP/1.1
> Host: 192.168.0.1
> User-Agent: curl/8.9.1
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Location: https://192.168.0.1/
< Date: Mon, 16 Dec 2024 07:23:15 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< Transfer-Encoding: chunked
* Ignoring the response-body
<
* Connection #0 to host 192.168.0.1 left intact
* Clear auth, redirects to port from 80 to 443
* Issue another request to this URL: 'https://192.168.0.1/'
*   Trying 192.168.0.1:443...
* Connected to 192.168.0.1 (192.168.0.1) port 443
* ALPN: curl offers http/1.1
* ALPN: server accepted http/1.1
* using HTTP/1.x
> GET / HTTP/1.1
> Host: 192.168.0.1
> User-Agent: curl/8.9.1
> Accept: */*
>
* schannel: remote party requests renegotiation
* schannel: renegotiating SSL/TLS connection
* schannel: SSL/TLS connection renegotiated
* schannel: remote party requests renegotiation
* schannel: renegotiating SSL/TLS connection
* schannel: SSL/TLS connection renegotiated
< HTTP/1.1 200 OK
< Content-Type: text/html
< Date: Mon, 16 Dec 2024 07:23:15 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< Transfer-Encoding: chunked
<
<!DOCTYPE html>

its up to the person making the http request to not send anything important before the renegotiation, or to put it another way, that first request will be insecure no matter what.

1 Like
13

At what time mark in that video?

3 Likes
14

around 7 minutes in

15

I watched from 7m-11m and don't understand his point.

Looks like he wants to tolerate receiving HTTPS requests with the IP address in the URL but that won't work with Let's Encrypt certs anyway. The domain name in the URL must match a domain in the cert and LE certs don't allow IP addresses.

I don't know why you'd care what happens when someone uses your IP to reach you anyway. Those are not legit requests. Use a default VHost like I described if you want to catch (and block) them. His technique won't even work if you have multiple VHosts for various names. SNI is used to select the VHost with Apache name-based hosts and this needs a proper hostname (domain). I think he was relying on Apache using the first (and in his case only) VHost as the default.

I gave up watching when he wasn't sure if he needed to restart Apache after making config file changes. Yes, of course you do :slight_smile:

3 Likes
16

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