Does the CertMgr admin server have to be connected to the Internet to use Let's Encrypt?

HCL Domino Domino Forum
1

Domino/Notes Version: 12.0.2FP4
Add-on Product (if appropriate, e.g. Verse / Traveler / Nomad / Domino REST API):
Its Version:
Operating System:Windows 2019 10.0
Client (Notes, Nomad Web, Nomad Mobile, Android/iOS, browser version):

Problem/Query:
We have three servers: S1, S2, S3
S1 is the Admin server of the DD and of CertMgr/certstore.nsf. But CertMgr is running on all three servers and certstore.nsf is replicated on all three servers.
S1 and S2 are clustered mail servers.
S3 is a Traveler server and is the only one of the three servers that is exposed to the Internet.

Question: Can I implement Let’s Encrypt TLS certificates in this configuration? I ask because, from my reading of the documentation, it appears that S1 must have an Internet presence to communicate with ISRG to implement Let’s Encrypt certificates.

2

Hi rob,

You can implement Let’s Encrypt TLS certificates in this configuration by using the internet-exposed server (S3) for the certificate request.

Based on you observations, the server communicating with ISRG (Let’s Encrypt’s parent organization) often needs an Internet presence is correct, especially for the default HTTP-01 challenge. However, you can leverage your multi-server Domino environment to handle this.

How to Implement Let’s Encrypt

The key is that the Certificate Manager (CertMgr) task on S1 (the Admin server) initiates the request, but the internet-facing server (S3) is configured to handle the validation challenge. The CertMgr task on S1 only needs outgoing Internet access (typically port 443) to talk to the ACME server, but it does not need to be the one that receives the incoming validation request from Let’s Encrypt.

  1. The Internet-Facing Server (S3) Handles the Challenge

For the certificate request to be successful with the HTTP-01 challenge, Let’s Encrypt must be able to reach the public DNS of the server (which is S3 in your case) on port 80 to confirm control of the domain. S3 must be the server that receives the incoming connections from Let’s Encrypt on port 80 (or 443 for TLS-ALPN).

The Domino HTTP task on S3 has a built-in ACME extension that detects the validation request and looks up the challenge secret in the replicated certstore.nsf.

  1. The Admin Server (S1) Manages the Process

Even though S3 handles the incoming validation, the CertMgr task on the Admin server S1 will be used to generate the key pair, create the Certificate Signing Request (CSR), and communicate with the Let’s Encrypt ACME server over an outgoing connection.

The CertMgr task on S1 must have outgoing Internet access (typically on port 443) to talk to the Let’s Encrypt ACME server to submit the request and poll for the certificate. The CertMgr task on S1 will store the challenge information in certstore.nsf.

  1. Sharing the Certificate

Since the certstore.nsf is replicated on all three servers (S1, S2, S3) and is managed by the Admin server (S1), the certificate:

  • Will be requested by S1’s CertMgr task.
  • The validation challenge will be served by S3’s HTTP task.
  • Once issued, the certificate and private key are stored securely in the certstore.nsf database.
  • Because the database is replicated, all servers (S1, S2, and S3) with the CertMgr task running can access the certificate for their respective services (Mail, Traveler, etc.) if they are listed in the “Servers with access” field on the TLS Credentials document.

For more information, you may want to check below link:

Domino Certificate Manager (CertMgr)

Regards,
Shawn

2 Likes
3

Hello.
When using the HTTP-01 flow with Let’s Encrypt, inbound access to port 80 from Let’s Encrypt is required.
Additionally, the HTTP-01 flow can only issue certificates for that specific server.

If certificates for S1, S2, and S3 are required, the DNS-01 flow will be necessary. With DNS-01, you don’t need access to port 80 from Let’s Encrypt. You can also issue wildcard certificates.

Regards,
Shigemitsu Tanaka

1 Like
4

Thank you, Shawn. Great explanation. My server is now protected by an ISRG certificate!

1 Like