Hi all,
I am running three Debian 8 servers as virtual machines on a Windows 2012R2 platform. The servers each host an installation of Owncloud which I would like to protect with Letsencrypt SSL.
The servers each have their own internal IP and share a dynamic external public IP managed by a DDNS provider. Each server is identified by a host name which is configured in my DNS server. The router is configured with port redirection for each server for external access.
I have managed to get a certificate installed on one of the servers and it works fine both internal access and external remote access but I cannot work out how to get the other two servers issued with correctly configured certificates.
So, I have been issued with a valid certificate for cloud1.example.com on 192.168.0.1 which was requested using the Letsencrypt package installed on the cloud1 server.
I requested an additional standalone certificate for cloud2 using the same package on cloud1 and moved those certificates and installed them on cloud2.example.com on 192.168.0.2. This works as expected when accessed internally on the network but throws up an error when accessed remotely and tries to point me to cloud1.example.com.
As I mentioned the port forwarding on the router is correctly set up because it works fine with self signed certificates.
I have also tried requesting a certificate for cloud2 by installing the Letsencrypt package on the cloud2 server but the request is refused due to the public IP already having a valid certificate for cloud1.
My question is how do I get individual certificates for each server when there is only one public IP?
Any help would be greatly appreciated
While it's probably not central to your problem that's almost certainly not why the request is refused. What error message is given when you try to do this?
Thank you for your response. If I try to generate a certificate directly from the cloud2.example.com server using ./letsencrypt-auto --apache2 -d cloud2.example.com I get the following error generated:
Failed authorization procedure. cloud2.example.com (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for TLS-SNI-01 challenge. Requested Lond-string-of-numbers-and-characters.acme.invalid from my.public.ip:443. Received certificate containing ‘cloud1.example.com’
IMPORTANT NOTES:
If you lose your account credentials, you can recover through
e-mails sent to my-email-address.
The following errors were reported by the server:
Domain: cloud2.example.com
Type: unauthorized
Detail: Incorrect validation certificate for TLS-SNI-01 challenge.
Requested
long-string-of-numbers-&-characters.acme.invalid
from my.public.ip:443. Received certificate containing
’cloud1.example.com’
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address.
Your account credentials have been saved in your Certbot
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates and private keys obtained by Certbot so
making regular backups of this folder is ideal.
Could it be because I am using the same ssl port (443) for the servers? I thought that was handled by apache2 sni?
Any help gratefully accepted.
These errors show the server answering doesn’t know how to complete the tls-sni challenge. Probably your setup means it’s talking to the wrong server. The acme.invalid names are part of the challenge, basically Let’s Encrypt connects to the DNS name you ask for & asks for a nonexistent vhost and it needs to see the right answer to prove the machine it connected to is under your control. I’m writing this on a phone, but hopefully this brief answer at least points you in the right direction.
Ok, thank you for your input. Is it worth requesting a new certificate to replace the two separate existing ones which would include all the sub domains in the one certificate?
Or does that only work if the sub domains are hosted on the same server?
Sorry for all the questions but I find the world of SSL although simple in theory, very confusing and tricky to implement
Given the error messages you described, I suppose that the key issue is this "port redirection". There are two scenarios here that I can think of which might be described this way and the options are different
The "port redirection" somehow arranges to watch SNI and connect a browser to the relevant server based on the name it asks for. In this case you can't use ACME's TLS SNI-based challenges, since you already rely on SNI just to get the connections to the right machine, but either the basic HTTP challenge ("webroot" mode in certbot) should work if these servers are accessible over plain unencrypted HTTP on port 80, or the DNS challenge (not in certbot yet? but several other clients can do it) might get you where you need to be
"Port redirection" just means certain ports have been set aside for each host (e.g. clown2 is 1443 and cloud2 has port 2443 and only cloud1 is available on port 443 HTTPS). In this case you may be obliged to use DNS challenges as Let's Encrypt only trusts a handful of reserved ports.
To get TLS SNI challenge support to work, the system that's actually looking at the SNI requests made by a client needs to know about ACME, otherwise it's going to see these bogus "acme.invalid" host names and just give back something that fails. In theory if you control that piece you could fix it, but it's unlikely to be your easiest way forward.
Thank you for your pointers as to where the problem may be. After some head scratching and trial & error, I have finally managed to get my network working correctly with multiple servers sharing a single public IP with SSL.
Your second point was the big clue for me and it turned out that all I needed to do was to assign my second and third server a non-standard port in the apache2 configuration files and configure the router to direct the traffic to those new ports.
The only disadvantage to this is the port number needs to be included in the URL but as these servers are purely for cloud services for my business, the solution is working well.
For future upgrade it may be that I get an ISP that offers static IP address, in which case I would assign a unique static public IP for each server. I assume that Letsencrypt would allow standalone SSL certificates for different public IP address but sharing the same domain name and TLD with just different sub domain names?
Thanks again for your help
Yes, Let’s Encrypt would issue those certificates. The problem you ran into with your existing setup was around passing Let’s Encrypt’s challenges, which are to prove you really control the names you’re asking it to issue certificates for. You would hopefully have an easier time passing those challenges with a public IP for each server, although plenty of people with less tricky setups have passed these challenges on a shared IP. Anyway, I’m glad you got something that works for you.