Error getting SSL certificate

Help
1

Hi there. I wonder if you can help me out. I have a Raspberry Pi 2 that I'm trying to create an SSL on. Possibly the error is to do with the fact that I have an SSL certificate with godaddy.com, for severindouble.com, that doesn't expire till the 21st of May 2022. I followed the Debian 9 instructions with apache. Below is also the error message I got from running hello-world. The domain name is also with godaddy, but I have re-directed it to the Pi which works, but reveals the ip address. Another task to sort out!

My domain is: severindouble.com

I ran this command: hello-world

It produced this output:

ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
Hello World!

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
Please enter the domain name(s) you would like on your certificate (comma and/or
space separated) (Enter 'c' to cancel): Requesting a certificate for severindouble.com
Performing the following challenges:
http-01 challenge for severindouble.com
Waiting for verification...
Challenge failed for domain severindouble.com
http-01 challenge for severindouble.com

Certbot failed to authenticate some domains (authenticator: apache). The Certificate Authority reported these problems:
Domain: severindouble.com
Type: unauthorized
Detail: Invalid response from http://severindouble.com/.well-known/acme-challenge/fft85mGVjrhAIKfPi9w2Y0q6tuDyvttQwNh0onrjv9I [15.197.142.173]: 404

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.

Cleaning up challenges
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): Apache 2.4.52

The operating system my web server runs on is (include version): Linux raspberrypi 5.10.103-v7+

My hosting provider, if applicable, is: N/A

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): 1.25.0

1 Like
2

Hi @doubleoseverin, and welcome to the LE community forum :slight_smile:

Please show the output of:
apachectl -t -D DUMP_VHOSTS

2 Likes
3

Here you go:

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
VirtualHost configuration:
*:80 127.0.1.1 (/etc/apache2/sites-enabled/000-default.conf:1)

4

It looks like your apache isn't configured to serve a website at all.

It just stays there serving something on localhost.

1 Like
5

Your domain severindouble.com has DNS pointing to AWS Elastic Load Balancer connected to an EC2 instance.

That is not the right domain name or DNS entries to reach your Raspberry Pi

Name:   severindouble.com
Address: 15.197.142.173
Name:   severindouble.com
Address: 3.33.152.147

And this:

curl -i severindouble.com/.well-known/acme-challenge/Test123

HTTP/1.1 404 Not Found
Date: Tue, 29 Mar 2022 14:51:05 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 48
Connection: keep-alive
Server: ip-10-123-122-155.ec2.internal
X-Request-Id: 87d0770b-007f-465e-9c1c-04b5992f35b3
2 Likes
6

Ok, so how do I sort all this out. The website is accessible over the internet as I have port forwarded the raspberry pi. Thanks for all your help thus far

8

Not sure. Do you need an ELB and EC2 involved? Could you just point the DNS to your Pi?

If you do need that there may be a problem with your redirects for Let's Encrypt. You redirect requests for http://severindouble.com to an IP address. BUT, requests to the /.well-known/acme-challenge URL I showed above to not redirect to that IP so do not reach your Pi.

Also though, Let's Encrypt will follow redirects but not for IP addresses - only domain names.

Does this help?

3 Likes
9

127.0.1.1 is close to home [but not exactly home "127.0.0.1"]

Agreed that 127.* IPs can only be reached by other 127.* IPs [and only locally].

1 Like
10

Home is 127.0.0.0/8 :wink:

11

That's a really BIG home!
If you check your /etc/hosts file, I think you might find a smaller home.

= ?

1 Like
12

Yeah, the literal localhost name might point to only a couple of those. IPv6 doesn't have such big homes, anyway.

Each service might chose an address in that /8. (I mean, systemd-resolved listens on 127.0.0.53 or something like that)

Another unclear thing is where am I connecting when I go to http://0.0.0.0 :smiley: (that's supposed to mean... any?)

13

That actually connects?

1 Like
14

It's only ever used by daemons that run on your local machine. I don't know why it works, tho.

15

It's a "trick" [some kind of "alias"].
0.0.0.0 = 0

ping 0.0.0.0
PING 0.0.0.0 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.020 ms

ping 0
PING 0 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.025 ms

ping 0.0.0.1
connect: Invalid argument
2 Likes
16

Yep, it's some "come on, really?" situation.

1 Like
17

Pinging any number lower than 1.0.0.0 returns "Invalid argument"
But all IPs can be represented in decimal format...
So, 1.0.0.0 = (1*256^3)+(0*256^2)+(0*256)+0 = 16777216

ping 16777216
PING 16777216 (1.0.0.0) 56(84) bytes of data.
64 bytes from 1.0.0.0: icmp_seq=1 ttl=54 time=5.79 ms
64 bytes from 1.0.0.0: icmp_seq=2 ttl=54 time=4.84 ms
^C
--- 16777216 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 4.842/5.316/5.790/0.474 ms

ping 16777215
connect: Invalid argument

But somehow "zero" is the exception to that rule.

1 Like
18

That's a bug. All other IPs in 0.0.0.0/8 are valid (albeit meaningless)

(No, not really, they're only valid as a source)


              +----------------------+----------------------------+
              | Attribute            | Value                      |
              +----------------------+----------------------------+
              | Address Block        | 0.0.0.0/8                  |
              | Name                 | "This host on this network"|
              | RFC                  | [RFC1122], Section 3.2.1.3 |
              | Allocation Date      | September 1981             |
              | Termination Date     | N/A                        |
              | Source               | True                       |
              | Destination          | False                      |
              | Forwardable          | False                      |
              | Global               | False                      |
              | Reserved-by-Protocol | True                       |
              +----------------------+----------------------------+

                    Table 1: "This host on this network"
19

By definition: It is MORE than localhost.
Although one can argue it must be within this localhost (since that network is not routable).

1 Like
20

There should be some distinction between an "empty" and a "zero" IP address.
But I suppose representing "empty" in an integer field would be "zero".

1 Like
21

Yes, it's a lot more than localhost, when used as a source.

As a source 0.0.0.0 means any address on any interface for this host.

And it looks like every other IP in 0.0.0.0/8 means the same.