Certificate for server hostname?

1

Hi guys,

I’m currently attempting to setup a SSL certificate for my servers hostname (so I can use it for site non-specific reasons like FTP access, since I host multiple sites off the one server).

The server has 17 IP addresses allocated to it, one primary (xxx.xxx.xxx.216/64) and 16 secondary (xxx.xxx.xxx.240/28). My current IPTables rules follow;

Chain INPUT (policy DROP)
num  target     prot opt source               destination
...
15   ACCEPT     tcp  --  0.0.0.0/0            xxx.xxx.xxx.216       tcp dpt:22
16   ACCEPT     tcp  --  0.0.0.0/0            xxx.xxx.xxx.240       tcp dpt:21
17   ACCEPT     tcp  --  0.0.0.0/0            xxx.xxx.xxx.240       multiport dports 1024:65535
18   ACCEPT     tcp  --  0.0.0.0/0            xxx.xxx.xxx.241       tcp dpt:80
19   ACCEPT     tcp  --  0.0.0.0/0            xxx.xxx.xxx.241       tcp dpt:443
20   ACCEPT     tcp  --  0.0.0.0/0            xxx.xxx.xxx.242       tcp dpt:25
21   ACCEPT     tcp  --  0.0.0.0/0            xxx.xxx.xxx.242       tcp dpt:110
22   ACCEPT     tcp  --  0.0.0.0/0            xxx.xxx.xxx.242       tcp dpt:143
23   ACCEPT     tcp  --  0.0.0.0/0            xxx.xxx.xxx.242       tcp dpt:587
24   ACCEPT     tcp  --  0.0.0.0/0            xxx.xxx.xxx.242       tcp dpt:993
25   ACCEPT     tcp  --  0.0.0.0/0            xxx.xxx.xxx.242       tcp dpt:995
26   ACCEPT     udp  --  0.0.0.0/0            xxx.xxx.xxx.243       udp dpt:9987
27   ACCEPT     tcp  --  0.0.0.0/0            xxx.xxx.xxx.243       tcp dpt:10011
28   ACCEPT     tcp  --  0.0.0.0/0            xxx.xxx.xxx.243       tcp dpt:30033
29   ACCEPT     tcp  --  0.0.0.0/0            xxx.xxx.xxx.243       tcp dpt:41144
30   ACCEPT     tcp  --  0.0.0.0/0            xxx.xxx.xxx.244       tcp dpt:21
31   ACCEPT     tcp  --  0.0.0.0/0            xxx.xxx.xxx.244       multiport dports 1024:65535
32   ACCEPT     tcp  --  0.0.0.0/0            xxx.xxx.xxx.245       tcp dpt:8192
33   ACCEPT     tcp  --  0.0.0.0/0            xxx.xxx.xxx.245       multiport dports 25565:25570

As you can see from the IPTables records, Apache runs on .241, however the hostname has a reverse which points to .216 and Apache does not run on .241. Therefore, it’s not possible to validate the hostname via the first option, Apache. My issue arises when I try validate through a standalone server, the following error is given;

The program apache2 (process ID 4303) is already listening on TCP port 80. 
This will prevent us from binding to that port. 
Please stop the apache2 program temporarily and then try again.

My Apache configuration looks like this;

# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default.conf

Listen xxx.xxx.xxx.241:80

<IfModule ssl_module>
        Listen xxx.xxx.xxx.241:443
</IfModule>

<IfModule mod_gnutls.c>
        Listen xxx.xxx.xxx.241:443
</IfModule>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

As you can see, Apache is not listening on xxx.xxx.xxx.216, I’m unsure as to why this error is showing, what can I do to validate my servers hostname?

2

If I check the source code for already_listening(), it seems to me it only checks the port and does not consider IP addresses at all…?

By the way, about “(…) however the hostname has a reverse which points to .216 (…)”: an IP address has a reverse hostname, a hostname has a forward to an IP address. I assume you’re just meaning the hostname resolves to another IP address than your Apache server is listening to…

3

Looks like it. Should I submit an issue on the GitHub repo about this?

4

That’s probably the fastest way of fixing this properly yes… In the mean time, you could always edit the source of standalone.py for a temporary fix… If Let’s Encrypt really listens to another IP, you could just bypass the check altogether.

5

I think there's a typo in this sentence. I assume you meant "Apache does not run on .216?"

Also, with that fixed, I'm still not sure what you mean by "has a reverse." Do you mean reverse DNS lookup for the IP address, or something else?

6

I think with “has a reverse” he means “resolves to” :stuck_out_tongue:

7

To be honest, reading that back it’s the most unclear sentence I’ve ever wrote lol.

What is was trying to say is Apache runs on a different IP to the one the hostname points to, which means my only option (without obviously setting Apache to run on the servers main IP) is to use Let’s Encrypt’s standalone option. I don’t know why I even mentioned the reverse DNS since its not applicable here.

My issue is, the LE client will fail even if Apache is only binding to a specific IP and not the IP LE needs to use.

Corresponding GitHub issue is here; https://github.com/letsencrypt/letsencrypt/issues/2326

Hopefully I have made things a little clearer.

8

This is a known issue from the earliest origins of the standalone configurator, unfortunately:

1 Like
9

Sorry, I didn’t see that issue, good to know it’s a known issue already, thanks!

10

letsencrypt-auto tries to automatically do all the magic required to set up Letsencrypt. It works (reasonably) well, if you have a pretty standard configuration. But if you have a more complex setup, I would seriously look at alternatives.

I have had great luck with letsencrypt.sh, and I’d probably also take a close look at acmetool. The latter offers proxy mode, which seems like a pretty unique, but also very handy solution to the problem.