Daniel Nashed's Blog

Domino V12 CertMgr corporate CA deployment automation

Now that Domino V12 is released,  we can look into more deployment scenarios.
I have looked into many different scenarios over the couple of month during beta and played with many integrations and described them in earlier posts.
Let me describe the main use-cases and I see today. And I am very interested to hear what you would like to integrate with.

1. Servers in public internet

The first deployment scenario would be Let's Encrypt and other ACME compatible CAs with HTTP-01 challenges directly accessible in internet.
Usually the most simple way would be to leverage HTTP-01 challenges to confirm your web-server identify.
The only requirement is to run the DSAPI filter shipped with CertMgr to allow ACME HTTP-01 challenge integration.
You can of course also use DNS-01 challenges if your DNS provider has an interface to automate to create DNS TXT records
(there will be more DNS TXT integrations available, if you have one you want to use, I would be interested to hear).

2. Servers in intranet using public DNS domains.

Some companies use the same DNS names in intranet and extra net.Either via split DNS or other name resolution.
In that case you can either use the public facing server using HTTP-01 challenges or if the server isn't exposed, use DNS-01 API.

I have already setup a larger domain in production with wild-card DNS entries for sub-domains, where a single server requests the certificates from Let's Encrypt.
Interestingly this is the first cmd interface integration using AWS CLI for the Amazon Route 53 DNS integration.


3. ACME protocol internally with a SmallStep CA

As posted a while ago, you can setup your own internal CA or sub-ca to leverage the ACME protocol to deploy internal certificates.
This would work for Domino V12 and probably many other applications with an ACME interface.
Not all applications might offer flexible configuration. The Domino ACME implementation has been tested with different ACME providers and is easy and flexible to configure.
So you would basically use the ACME technology to distribute certificates after validating the requests in the same way Let's Encrypt validates servers in the public internet.
This would be a very elegant and easy to use flow -- provided your company allows you to host a sub-CA derived from your corporate CA.
But this would also work in parallel if you deploy a complete new CA and the corresponding trusted roots.

4. Manual flows integrating with any CA

Beside the ACME integration CertMgr offers manual flows.

[A] Create a request for a SAN certificate with one or multiple hosts
CertMgr automatically creates the private key and CSR for your.

[B] You copy&past the CSR to your CA for signing

[C] And finally past the certificate back into the certstore.nsf to have it automatically processed by CertMgr.

The certificate chain is automatically sorted with the certs you pasted and completed with existing trusted roots in certstore.nsf.
If you need additional trusted roots or intermediate certs, you can import them in the same way into certstore.nsf.

5. Custom flows based on the manual flow functionality

CertMgr has been designed for flexibility and extensibility. There are currently no other automated options out of the box. But you can integrate the back-end operations of the manual flow with your own CA operations.
Having an open interface for integration similar to what has been implemented for the DNS-TXT providers would be high on my wish list for the next version.

But if you want to integrate your current CA flow with CertMgr and certstore.nsf it's already possible today.
I have just implemented my own "mini ca" based on the existing flows leveraging what CertMgr already does for us automatically.

[I] Let CertMgr create a private key and a CSR.
[II] Write for example an agent to check documents in a certain status -- waiting for the manual copy CSR operation and let the agent transfer the CSR to your CA.
[III] Get the certificate and chain back (or have the chain already present in cerstore.nsf) and submit the request to CertMgr.
[IV] CertMgr will import the certificate and run the health check operations.

This simple flow would be possible today and I have used it already for my own integrations.
Once the certificate is stored in certstore.nsf you can get it deployed domain wide to the right servers and have a very easy to use interface with all information about your certificates.

I see a lot of room for automation and integration. Not all of it has to be provided by HCL.
But the design of CertMgr and certstore.nsf allows integration today.
And even if you don't fully automate the process, the manual flow is already great help!
No more manual operations! No old and none standard kyr files. Only standard PEM format.

-- Daniel

• Comments [0]