US server: vpn-us.companydomain.com (new deployment in progress)
TLS configuration: Using Let’s Encrypt with automatic certificate issuance enabled on the servers
Issue Description
Currently, Let’s Encrypt certificate provisioning is active on the France server using vpn.companydomain.com. We have now deployed a second server in the US with its own hostname (vpn-us.companydomain.com) and would like it to also use automatic Let’s Encrypt provisioning.
However, since Pritunl manages TLS certificate generation via the shared MongoDB backend, only one hostname can be managed at a time across the cluster. Attempting to enable Let’s Encrypt for the US hostname overrides the existing configuration for the France server, and vice versa. As a result:
If vpn.companydomain.com is validated, only France-based clients can authenticate successfully.
If we switch to validating vpn-us.companydomain.com, only US clients succeed, and France connections fail.
This prevents us from running both servers in parallel with valid TLS and limits our ability to offer reliable regional access.
Question
What is the recommended way to support multiple Pritunl hosts (with different hostnames) using Let’s Encrypt certificates when running a shared MongoDB backend and single organization?
Is the only supported solution to:
Deploy separate organizations for each region, or
Move TLS termination outside of Pritunl (e.g., use a reverse proxy like NGINX with a wildcard certificate)?
If there is any built-in or documented way in Pritunl to support this multi-host/multi-domain scenario while preserving central management and SSO, please advise.
The solution to this would be to manually configure a wildcard certificate but that can’t be done with the automated Lets Encrypt support. But no configuration should require clients to use different domains. Internal connection related HTTPS requests from the Pritunl Client service can go directly to the host without a valid certificate. The requests have their own multi-layer encryption+authentication using HMAC, NaCl and RSA. These requests don’t need a valid SSL certificate and will ignore certificate checking. The single sign-on connection authentication that occurs in the web browser doesn’t need to occur on the same host as the VPN connection.
Below are all the addresses and how to configure them. Correct these addresses and use either a load balancer or choose one of the hosts for the Connection Single Sign-On Domain.
Hosts Tab
Host Public Address: The public IPv4 address or domain of the Pritunl host. This should always be the public IP of the host for all configurations even when using a load balancer.
Host Public IPv6 Address: The public IPv6 address or domain of the Pritunl host. This should always be the public IP of the host for all configurations even when using a load balancer.
Host Sync Address: In the advanced host settings. The public address or domain that the web server of the Pritunl servers can be accessed from. If a load balancer is configured that address should be set here.
Top Right Settings
Connection Single Sign-On Domain: Only shown when using single sign-on connection authentication. The public address or domain that is used to validate single sign-on requests through the Pritunl web server for a new VPN connection. If a load balancer is configured that address should be set here.
Thanks for the detailed explanation. I now understand that the SSO validation from the client doesn’t require a valid certificate, as the internal client-server requests are encrypted separately.
But I never had issue on the SSO side, it works fine, and I have a message informing that the authentication is succesfull.
Our current configuration uses a shared MongoDB Atlas backend with multiple hosts, and Let’s Encrypt is enabled in the Settings tab. The issue is that:
Once Let’s Encrypt is enabled, it’s active globally (stored in MongoDB), so every server tries to issue a certificate for the same domain.
Since the servers have different public IPs, only one server can succeed with the HTTP-01 challenge.
The second server fails the ACME challenge and is unable to serve users correctly.
Disabling Let’s Encrypt globally on any server would break production clients.
The certificate renewal process will only run on one host. Through a scheduled task it’s randomly selected which host will handle the renewal process. That host will initiate the certificate with the Lets Encrypt API then through the database all hosts will be able respond to the certificate challenge. The host that receives the Lets Encrypt challenge would be determined by which host has the DNS record for that domain. It doesn’t need to be the same host that initiated it. If it isn’t working check that the Lets Encrypt domain is configured to one of the Pritunl hosts and verify that server has TCP port 80 open to the internet.