How to get Lets encrypt certificate for Virtual/Cluster IP address

I'm running an active-passive cluster for a web application running on NGINX.

One of the the two servers will be available at any given time under a virtual IP ( pacemaker is used as the cluster resource manager and corosync provides the communication layer).

How would I configure both the web application server(nginx-node1/nginx-node2) to present a Lets encrypt SSL certificate for the FQDN(nginxlb.example.com) that identifies the cluster ?

Currently, I can access both the web application nodes using cluster FQDN
http://nginxlb.example.com

What i am trying to accomplish is to access the cluster using https://nginxlb.example.com

Thanks

Where are you terminating TLS?

You have several options.

1 Like

Do you have a shared filesystem between the cluster nodes? That is common for configuration data between cluster hosts, but I'm not sure about guests.

Having an ACME client on each, which uses the shared fs for storage of its Let's Encrypt data, could be one way to go. In that scenario, it wouldn't matter much which node is the current master.

2 Likes

I want to decrypt SSL encrypted data traffic in the load balancer since the web applications are running in the private network.

Currently i am not using shared filesystem between the cluster nodes.

Then your best option is to terminate TLS at the load balancer. You just configure that nginx reverse proxy to get a certificate, and that's it*

* : you'll probably have to adjust some headers because reverse proxying https->http doesn't always work out of the box

1 Like

The other suggestion that comes to mind is to use acme.sh in stateless mode: Stateless Mode · acmesh-official/acme.sh Wiki · GitHub.

  • Each server would have an independent certificate for nginxlb.example.com. You wouldn't share these between the servers.
  • You'd register an ACME account using acme.sh on one server, then you'd copy over /root/.acme.sh to the second server. The effect of this would be to have the same ACME account on both servers.
  • You'd configure nginx to return a synthetic challenge response, hardcoded to this ACME account, per the wiki article I linked.
  • At this point, either server can request or renew a certificate for nginxlb.example.com, even if it is not the current active cluster node. This is because both servers will statically return the correct HTTP challenge response, no matter what.

The upside of this setup is that it has very few moving parts. It is an exotic setup, but I think it should work for you.

5 Likes

I don't think OP has an LB. It's a 2-node cluster where 1 out of the 2 servers has control of the public IP, at any one time.

If they do have an LB, I totally agree with you by the way! Haha.

4 Likes

I wasn't sure, but then I read

And what I understand from that is:

  • there is a load balancer
  • the nodes don't have publicly routable IP addresses

I don't know. @Michel1 tell us more, please.

1 Like

Yes, All the nodes in the setup don't have publicly routable IP addresses. All the servers are within private network.

Also the back end web application nodes running on NGINX are actually load balancer for multiple superset web applications.

Client ----> FQDN of web server(NGINX) cluster -> Two NGINX load balancers -> Multiple superset applications

NGINX-features_High-Availability

But my setup of two NGINX load balancers nodes are on active-passive.

I am not sure I understand how many levels you have.

public internet -> nginx lb -> application

or

public internet -> lb -> nginx -> application

?

Because if you have a single public IP and nginx answers there, it's easy. If you have multiple public IPs then you need some orchestration (like stateless mode).

So you're telling me you have two load balancers in a some kind of IP-level round-robin, with a single A record?

How is the configuration for these two load balancers synced?

1 Like

Hi
I just copied the certificate from one NGINX load balancer node ( nginx-node1.example.com ) to another ( nginx-node2.example.com ) in the cluster to make it work.

Thanks @_az and @9peppe !

1 Like

That's one way to do it. It's not the best way, you'd have to repeat this every couple of months. Letting each node get a certificate independently should be better.

1 Like

That's true but getting certificates independently for each node will results in a different certificates for the same domain ?

Yes, and that's fine.

2 Likes

I can use iscsi shared Storage for lets encrypt folder between two nodes to mitigate the problems in the long run.

Thanks

2 Likes