It produced this output:
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. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you’re using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
The following errors were reported by the server:
Domain: www.eaglesmgt.com
Type: unauthorized
Detail: Incorrect validation certificate for tls-sni-01 challenge.
Requested
fdf176ffc08094803e9d651ea62979dc.ee6c83a85bcfe73272f7f0371242dddc.acme.invalid
from 96.67.78.180:443. Received 2 certificate(s), first certificate
had names “eaglesman.net, mail.eaglesman.net, www.eaglesman.net”
Domain: eaglesmgt.com
Type: unauthorized
Detail: Incorrect validation certificate for tls-sni-01 challenge.
Requested
b0740a34298941a03b9596b224f4d4d3.0aaa8100be9001eb1cbc0137b49a385f.acme.invalid
from 96.67.78.180:443. Received 2 certificate(s), first certificate
had names “eaglesman.net, mail.eaglesman.net, www.eaglesman.net”
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.
My web server is (include version): Nginx 1.10.3
The operating system my web server runs on is (include version): Ubuntu Server 16.04.3 LTS
My hosting provider, if applicable, is: None
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
How is the routing from the firewall to the various servers handled?
I don’t believe that the --nginx method is going to work in this setting because it needs to be run directly on the server that receives the inbound TLS connection (and dynamic port forwarding is unlikely to work, because the name that the certificate authority asks for via SNI in the TLS ClientHello is a randomized one that’s not directly visibly connected to the existing domain name). When some other device receives the TLS connections on port 443, --nginx isn’t really applicable, but other methods may be.
I have one server on the primary IP with port forwards and the second on an alias IP with forwards in and routing out. Now that you have seen the domain, can you mask for privacy?
Also, what method should I use? Do I need to just generate one key and place it on both physical machines?
I’m sorry, I still didn’t quite understand your setup. Is the IP address the only thing used to distinguish where inbound requests should go, or is there some kind of protocol inspection going on? In this case, is it pretty much equivalent to having two servers on separate public IP addresses?
It looks to me like the IP addresses that these domain names resolve to are very dissimilar, so I feel like I’ve misunderstood something because I don’t imagine that they actually route to the same network.
Sorry, I have had knee replacement and have been unable to resolve this. I was desperately hoping to resolve this before my surgery but alas.
Thank you for your help. Both servers are behind one firewall and it has the ability to shell out alias IPs. I have one server on the native IP and the second on an alias. I don’t understand what protocol inspection you are referring to as they are both identical in services, etc. So 110 on IPA goes to boxA and 110 on IPB goes to boxB. Although they are set as different IPs, I wonder that my problem is because they are actually going through the same interface(?)
Any help appreciated.
that an inbound connection to port 443 on 96.67.78.180 would get forwarded directly to port 443 of the same server that you ran this command on, at the TCP level, without TLS termination being performed by the firewall?
443 is supposed to get forwarded directly to the server the command was run on. Correct no man in the middle. Yeah, I was wondering if I should just get the cert for both, then put on the firewall to better filter. But not now. I hope I am able to give you the answers you are looking for.
you should presumably run that on 96.67.78.180. But the certificate that the validator encountered was the certificate that should be served from 96.67.78.181.
To think through this a little further, there is some way that someone trying to connect to 96.67.78.180 can talk to a web server that is serving a certificate for eaglesman.net. But that should be impossible according to the way that you described your IP forwarding setup, because that IP address should never be forwarded to the eaglesman.net machine. Yet apparently it is.
Indeed, that’s what I see right now using
openssl s_client -connect 96.67.78.180:443
—the default certificate that comes back is the eaglesman.net certificate. But supposedly this IP address wouldn’t reach the eaglesman.net server, right?
