Daniel Nashed's Blog

Leveraging the potential of Domino CertMgr + What’s new in 14.5.1

Domino CertMgr introduced in Version 12.0 is one of the modern corner stones of Domino security.

This includes the TLS Cache and certstore.nsf which is used for many other security features today.

It is built on open standards and can be customized and leveraged outside Domino.
Certificates are stored in PEM format in text fields.
When generating exportable keys, they are stored in plain text PEM format encrypted with the modern (PKCS#8 + PBKDF2 + AES-256-CBC) encryption.

CertMgr supports multiple flows:

• Manual import
• ACME protocol with HTTP-01 and DNS-01 challenges
• Import/Export
• MicroCA

See details her --> https://opensource.hcltechsw.com/domino-cert-manager/certificate_flows/


Those flows can be mixed and matched and can be also extended for your own needs.
Specially the manual flow is designed to allow to export CSRs to for example send it to an external CA.
And import certificates once issued by an external CA.

The past operation can be automated by just writing the certificate into the right field and setting the status of the TLS Credentials document to the right state.

Details of the TLS Credentials document are documented here --> https://opensource.hcltechsw.com/domino-cert-manager/tls_credentials_anatomy/

Once created exportable TLS Credentials can be used outside Domino and can be even automatically updated querying certificates remotely from CertMgr.
See details here --> https://opensource.hcltechsw.com/domino-cert-manager/deploying_outside_dominio/

For exporting and importing TLS Credentials there is a script lib with a documented LS2SCAP call-out to use it for your own export and import applications.

Auto filter complete, auto sort and auto complete functionality

All mentioned flows support the same "automatical" certificate handling.
In most applications you have to specify the right order, specify exactly the certificates needed and add the root and intermediate certificates.

With Domino CertMgr you don't need to care about any of this manually.

The certificate chain provided is automatically sorted
The sorting happens from checking the public key to match it against the leaf certificate.
From the leaf certificate the chain is built backwards up to the root certificate.
Any certificates which don't match the chain or are duplicated are automatically filtered out.

If the chain is not complete CertMgr looks up trusted roots stored in certstore.nsf trust store.
This works for root certificates and also for intermediate certificates.
The resulting chain should be always complete and in the right order.

This functionality is available since version 12.0 and available for all flows without separate configuration.


Using TLS Credentials outside of Domino

When using Domino managed TLS Credentials outside Domino it becomes essential to monitor expiration.
Certificates in certstore.nsf are monitored by CertMgr automatically. Certificates are updated where the flow allows it and statistics are updated with number of certificates in green, yellow, red state.

For external used TLS Credentials there is a separate health check by URL, which daily checks all configured URLs, updates statistics and optionally sends one summary mail with warning and errors:

https://help.hcl-software.com/domino/14.5.0/admin/secu_certificate_url_health_check.html

All the functionality described is intended to simplify certificate management and make Domino a first class citizen in certificate management.

New functionality in 14.5.1 EA1
There isn't much to add, but in 14.5.1 EA1 there are some smaller enhancement based on customer feedback.

e-mail attribute in manual and ACME flow

Some customers require an e-mail attribute in the common name for their internal certificate flows.
The field was always present since 12.0 but has not been exposed in the UI,
Now with 14.5.1 it is an official feature of CertMgr for manual flows and also the ACME protocol (even most public ACME servers ignore it, but internal customer flows might need it).

Custom Expiration in MicroCA flow

The Domino MicroCA started as a very simple private CA for the AppDevPack.
But meanwhile it is used for JConsole Certs and can be leveraged for Domino IQ and other flows.

It is very useful for internal certificates for example behind a reverse proxy.
Because certificates are automatically renewed, distributed by replication via certstore.nsf and instantly updated by the TLS cache, they are a very good fit for those type of scenarios.
But the MicroCA does not provide any CRL end-point or OCSP option.

To comply with modern requirements the MicroCA now supports custom certificate expiration. So you could set it even as low as 3 days today.
The MicroCA flow would auto renew it as soon the renewal interval has been reached.

There is a new field on the TLS Credentials form Validity period shown in MicroCA mode.
The internal field was already present since 12.0. But the field has now exposed in the UI and is officially supported.

Subject Key Identifier (SKI) and Authorized Key Identifier for MicroCA

Those have been two missing extensions expected from modern CAs.
They have been added in 14.5.1 as well to comply with modern requirements.

New certificates would get those extensions automatically beginning with 14.5.1 EA1.
A new MicroCA would get a SKI when created with 14.5.1 too.
If you have special requirements and integration ideas let me know.

-- Daniel

• Comments [0]