Domino on Linux/Unix, Troubleshooting, Best Practices, Tips and more ...

 
alt

Daniel Nashed

 

WSL - Select static subnet and pinned IP address

Daniel Nashed  22 January 2022 15:35:05

WSL is a very cool solution to run Linux applications.
But there is a limitation, which makes it difficult to use for Domino servers.

WSL assigns a random sub-net on every start.
I raised an issue at the WSL GitHub project
https://github.com/microsoft/WSL/issues/7820.
For now I wrote a small helper tool to work-around this limitation.

Here is the source code and the binary:

https://github.com/nashcom/nshwsl

I only focused on re-creating the network and I am adding the IP as an alias.
There is also API to create a new end-point, but I am leaving this part to Microsoft to fix.

I hope this helps others..

-- Daniel

Which type of internet CA and certificates are you using in test and production?

Daniel Nashed  22 January 2022 12:44:50
As you might now I looked into many different CAs for testing and mostly use Let's Encrypt and other ACME based certs for production.
With ACME the type of certificates has dramatically changed.

For testing I built my own CA based on OpenSSL C code just to understand how it works.
There are other CAs like HashiCorp or the SmallStep CA.
Many of those CAs can be used as Sub-CAs in a corporate environments.

So for example you could use the SmallStep CA to distribute certs using the ACME protocol.

Is this something you are using today? Or are you using the more classical approach to use a CA from Microsoft as part of your AD?


e-mail CSR test lab offering

For test environments I have created my own lab CA to use e-mail to receive CSRs.
It's based on a pre-delivery agent requesting the certificate via HTTPS using the Lotus Script HTTP class to request a cert from my CA service using the native based OpenSSL code.
If anyone is interested to test manual flows for CertMgr, I can provide an e-mail CSR services for test lab environments with my own service.

It was also the perfect CA to use for the lab we setup in the DNUG CertMgr and certificates workshop.
I can't give away the CA itself. But there are many others to look into, which make more sense to use.


Your feedback

But I would also like to understand what you are using today in your environment for corporate certificates and also external trusted certificates.

Which internal CA do you use and how does the flow look like to get certificates?


Here are two references for CAs I am using in my lab and I have blogged about earlier.
And I am also adding an example certificate from my lab CA. I am using ECDSA with NIST-P521 and SHA512 signatures.
Also to test out if all of the software I am using fully supports ECDSA certs.

HashiCorp

https://www.hashicorp.com/products/vault

SmallStep CA

https://smallstep.com/acme-registration-authority/


Example Certificate

The signature for the leaf itself is still SHA-256 for now.

#0
Subject    : DE/NRW/Hilden/NashCom/IT/notes.nashcom.de
SAN        : *.nashcom.loc
Issuer     : X2 Server MiniCA/DominoLab

Not Before : 2022.01.13 21:09:44
Not After  : 2023.01.14 21:09:44 (expires in 357.0 days)

Serial     : 08EA0B176C796E5B4671015625F96979
Sign Alg   : ecdsa-with-SHA256
KeyUsage   : DigitalSignature
Extensions : KeyUsage, ExtKeyUsage
ExtKeyUsage: TLS Web Client Authentication, TLS Web Server Authentication
Key        : ECDSA NIST P-521
ASN1 OID   : secp521r1


AuthKeyId  : 88:B3:3A:E1:0B:FA:A7:6A:47:C5:BB:BF:0C:F0:71:ED:E4:3D:9D:E7
SubjKeyId  : 9D:6E:92:5C:AD:88:8D:49:A7:C9:5B:09:89:B5:02:33:6E:7D:7C:86
MD5        : C0:6A:F3:88:63:81:10:C2:B2:01:5D:EF:A8:D6:C3:F5
SHA1       : 87:D3:27:F1:8F:D7:9A:5F:EE:D8:39:D0:20:10:8D:B6:07:72:EC:B3
SHA256     : AB:E7:8D:AD:A9:99:B0:C9:27:4F:18:82:69:33:E9:DF:B3:34:B3:66:5C:D6:29:3E:F1:B3:86:C9:27:FD:E0:E1

-----BEGIN CERTIFICATE-----
MIICpzCCAgmgAwIBAgIQCOoLF2x5bltGcQFWJflpeTAKBggqhkjOPQQDAjAvMRkw
FwYDVQQDDBBYMiBTZXJ2ZXIgTWluaUNBMRIwEAYDVQQKDAlEb21pbm9MYWIwHhcN
MjIwMTEzMjEwOTQ0WhcNMjMwMTE0MjEwOTQ0WjBmMQswCQYDVQQGEwJERTEMMAoG
A1UECAwDTlJXMQ8wDQYDVQQHDAZIaWxkZW4xEDAOBgNVBAoMB05hc2hDb20xCzAJ
BgNVBAsMAklUMRkwFwYDVQQDDBBub3Rlcy5uYXNoY29tLmRlMIGbMBAGByqGSM49
AgEGBSuBBAAjA4GGAAQBIF7mICl23KzG8xJB4vcaeCMvPLDCjZH/d2FBRghm9+xB
v3cbwEczNqB0bLWbzS8EqcrlLc3Ijhtq5IHthAAUTo4BqcqSSN21R/8WCjrwHz24
p/1u8JMwLXqeGlysTLdT4RyciAIwgvE5nuTblgIfmS+HNUwCjzKt+TQ8rsuthXgW
xo2jgYwwgYkwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMBMA4GA1UdDwEB
/wQEAwIFoDAdBgNVHQ4EFgQUnW6SXK2IjUmnyVsJibUCM259fIYwHwYDVR0jBBgw
FoAUiLM64Qv6p2pHxbu/DPBx7eQ9necwGAYDVR0RBBEwD4INKi5uYXNoY29tLmxv
YzAKBggqhkjOPQQDAgOBiwAwgYcCQTXhCQ+OIqcpCRgyBmt/QYfbGiOVRyWdSnke
2PZRL01xsUPdICamsm99BshH2/u3vH1VtLpa924uSr4JupgkW+SnAkIAzvV5fU0/
PE6GFj81B7PU5qvSPvSsVDQpiQzVTcQ8xqXNj7oICFbMTqkP5KZ4vgzw7xHK528q
ytPx5NGq7Nk76b4=
-----END CERTIFICATE-----

#1
Subject    : X2 Server MiniCA/DominoLab
Issuer     : MiniCA-EC521/DominoLab

Not Before : 2021.07.26 05:31:28
Not After  : 2031.07.27 05:31:28 (expires in 9.5 years)

Serial     : 52C00B80CF7996CC5903A8CEB5B28A66
Sign Alg   : ecdsa-with-SHA512
KeyUsage   : CrlSign
Extensions : BasicConstraints, CA, KeyUsage
Key        : ECDSA NIST P-521
ASN1 OID   : secp521r1


AuthKeyId  : B3:C7:6D:6D:91:00:2A:EC:9D:3A:7A:06:46:6B:93:91:36:75:39:D0
SubjKeyId  : 88:B3:3A:E1:0B:FA:A7:6A:47:C5:BB:BF:0C:F0:71:ED:E4:3D:9D:E7
MD5        : 80:FF:91:E2:91:78:21:A4:D8:9F:4A:82:26:99:BF:CA
SHA1       : 3D:88:6E:18:03:F3:49:EC:51:BB:30:6D:06:A9:C1:7F:F6:60:CF:D7
SHA256     : B9:CD:37:F7:26:F8:8B:29:ED:7A:AD:84:A9:51:C0:D9:36:DE:17:CE:20:48:44:BB:CC:3F:82:F9:C9:E9:10:1D

-----BEGIN CERTIFICATE-----
MIICQzCCAaSgAwIBAgIQUsALgM95lsxZA6jOtbKKZjAKBggqhkjOPQQDBDArMRUw
EwYDVQQDDAxNaW5pQ0EtRUM1MjExEjAQBgNVBAoMCURvbWlub0xhYjAeFw0yMTA3
MjYwNTMxMjhaFw0zMTA3MjcwNTMxMjhaMC8xGTAXBgNVBAMMEFgyIFNlcnZlciBN
aW5pQ0ExEjAQBgNVBAoMCURvbWlub0xhYjCBmzAQBgcqhkjOPQIBBgUrgQQAIwOB
hgAEAMxHJRWA3lvRLvLS8BN5KceJbTG2ZaUyYsLwPSRyaBidO5UvlMNWYrc6zW4J
aitaAfTcJ4NRNsp9Dmg/tHN7uKUlAMBbN9u1u6ceI4dC+7KJJOwQe5oDQO7eRwLH
eSCQPlcfpTRZDmW14GcqPDi+AhAY6oI360H2sFIk6F2XynOhl83Po2MwYTAOBgNV
HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUiLM64Qv6p2pH
xbu/DPBx7eQ9necwHwYDVR0jBBgwFoAUs8dtbZEAKuydOnoGRmuTkTZ1OdAwCgYI
KoZIzj0EAwQDgYwAMIGIAkIBQU4r/BW8S8KKCHQthgIF29/UIz7f9Sbbps+k9TH/
V8cFiRkwX4/ILMmMqF/1YS1VOozGUKkJhPDWxQFC9QtL0IgCQgE85CqBtW3w3Gna
Swj7ousWo5wpH/jszDBVLG85+hdURJShPg6bMT/LAm7JD+djiPCdscsB3f+Qb7l8
5kizTqIwgA==
-----END CERTIFICATE-----

#2
Root       : MiniCA-EC521/DominoLab
Not Before : 2021.07.25 21:51:05
Not After  : 2031.07.26 21:51:05 (expires in 9.5 years)

Serial     : 50206CAFF845BDD08D4ABE6FBFCD2BAC
Sign Alg   : ecdsa-with-SHA512
KeyUsage   : CrlSign
Extensions : BasicConstraints, CA, SelfSigned, KeyUsage
Key        : ECDSA NIST P-521
ASN1 OID   : secp521r1


SubjKeyId  : B3:C7:6D:6D:91:00:2A:EC:9D:3A:7A:06:46:6B:93:91:36:75:39:D0
MD5        : F8:44:85:17:76:24:D1:E6:E9:BF:52:2D:86:86:00:66
SHA1       : 62:82:D0:D2:55:D0:36:36:6C:74:0D:10:BA:EC:02:D8:54:AF:2E:5E
SHA256     : 27:AB:C6:0C:CD:19:C1:5F:BA:8C:4F:FF:C4:28:8F:96:F8:D2:D7:62:FF:F7:D6:35:B1:EE:3F:EA:65:5E:D5:C0

-----BEGIN CERTIFICATE-----
MIICHTCCAX+gAwIBAgIQUCBsr/hFvdCNSr5vv80rrDAKBggqhkjOPQQDBDArMRUw
EwYDVQQDDAxNaW5pQ0EtRUM1MjExEjAQBgNVBAoMCURvbWlub0xhYjAeFw0yMTA3
MjUyMTUxMDVaFw0zMTA3MjYyMTUxMDVaMCsxFTATBgNVBAMMDE1pbmlDQS1FQzUy
MTESMBAGA1UECgwJRG9taW5vTGFiMIGbMBAGByqGSM49AgEGBSuBBAAjA4GGAAQA
lrz/VRwjX4boxQblNcT078oNr1Fc013lw26FDSQNaKTdCa0ZyqKZeKGDF1QU35Av
rDxXSq8ye774BSjjaxe7H2EBn+oYQd2vVyYtZ45/neREkUVMJzEsnMBzhmuB4OfE
D8oUZh/SQSmDiwMXNuuphPaMEqgxs2oUZ+QJeQkgmGyiDgKjQjBAMA4GA1UdDwEB
/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSzx21tkQAq7J06egZG
a5ORNnU50DAKBggqhkjOPQQDBAOBiwAwgYcCQgErm7b8JJr9SXMUqf9DxmHAUUH/
4RMXmzFUqAcQC3Q28vdiXrEp6jqoZsnkAJ7emWuwfazRcYQEwztEWfaYFGprAwJB
QLv/YMYBAWMzSoYmHSKNwQS5Uvs57nZtJLrFH19hVcQvI2OUqbuZ0hXdFy0ty6hx
CCzGtxuYgTFDUzkohRWx7lU=
-----END CERTIFICATE-----

Domino 12.0.1 CertStore Workshop final preparations for next week

Daniel Nashed  15 January 2022 09:37:24

Image:Domino 12.0.1 CertStore Workshop final preparations for next week


This is going to be the most interesting workshop I ever did.
I spent a lot of time preparing the workshop about awesome new Domino 12 functionality that deserves it to be features like this.

The presentation is done and the automated server setup is prepared.
I am working on some detailed fit and finish to make it an awesome experience as well :-)

Fully automated Domino lab setup

We will use One-Touch Domino setup for Linux with One-Touch setup in combination with my new templating to bring up lab servers.
This will be the first, but definitely not the last workshop using this technology to provide a lab server for every participant.

Domino 12 with One-Touch setup makes it easy to automate setups.


Domino 12.0.1 Certificate management

We will cover all details including the latest features and there will be no questions unanswered.
This includes the setup, Let's Encrypt, adding external DNS providers, integrations and many more details.
And it is going to be all hands-on on an own Linux machine with production style DNS setup.

But we also cover certificates in general.

I am looking forward to the workshop on Tuesday.

PS:
This is a commercial workshop in German for DNUG.

But we could repeat it in future in English...

-- Daniel


Important Domino 12.0.1 IF1 for customers using DAOS

Daniel Nashed  7 January 2022 21:25:12

This issue has been already in 12.0, but was discovered to late to be included into 12.0.1.
HCL worked hard to get IF1 out ASAP. There was a hotfix already available end of the year.
But IF1 take a bit longer than distributing a hofix -- there is more testing is involved.


If you are running on 12.x, and you are using DAOS, you should install IF1.
If you are on 12.0, I would recommend moving to 12.0.1 with IF1.
But if you have to stay with 12.0 there is a hotfix available from HCL support.

The problem occurs when databases are fixuped and many NLOs are involved.
It turned out that this also affects compact, which is using a fixup internally for most of the compact operations.

So you really should get IF1 installed if running DAOS.

Here is the official technote and info about IF1.

I just updated the Domino Community image and made 12.0.1 IF1 the new default.

-- Daniel

Domino 12.0 Fixup for databases with a large number of NLOs can lead to Domino Server performance degradation

https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0095401


Interim Fixes for 12.0.1x versions of HCL Notes/Domino

https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0095939




One Touch Setup meets automated lab setup

Daniel Nashed  2 January 2022 19:06:19

Domino One-Touch is the base for all the automation.
Once you started automation, it's only limited to your imagination.

Probably this will officially be available after our DNUG CertMgr and certificate hands-on workshop, were we will use the auto deployment of course.
Stay tuned for more functionality.. Looks like ideas are floating faster then  I write them.
But it's just the 2nd day of the year..

-- Daniel


Image:One Touch Setup and meets automated lab setup

Note: I had to short cut the fields for the configuration with a X_ instead of SERVERSETUP_ because I hit the limit for field len with some variables.


Image:One Touch Setup and meets automated lab setup


As some of you know I have my own lab registration database automating Hetzner server deployment including DNS leveraging their REST APIs.
I just added an agent, generating JSON on the fly based on the IP address of them machine.
And I have added an auto deployment and download routine to the "setup" of my start script.

In combination with JSON templating, I can download and customize JSON on-the-fly in any way.
I added a JSON based customizable menu, which can be also used to deploy other software.

The auto JSON generation is a Lotus Script agent, which dynamically replaced place holders in JSON files as shown above.
Probably I should make the agent available to show how simple this

For my lab environment setup database I also introduced a new well known URL to auto deploy configurations.
So for any host in an internet domain (like www.acme.com) would look like this --> https://acme.com/.well-known/domino.cfg
Now that JSON configuration with templating makes deployment via JSON easier than editing a ENV file, JSON setup is the new default!

And there are many options I will document over time.
One example would be   " domino setup https://acme.com/.well-known/domino.cfg  "
The short cut  " domino setup auto acme.com " would provide the same functionality.
And if your host is part of the acme.com domain, you could even use  " domino setup auto " to hit the default configuration in https://acme.com/.well-known/domino.cfg.

There is a lot new stuff coming. It's all prepared. But it's a lot of work to write up the documentation.

I just moved the Domino start script documentation in mark down. And this will be the new base to write up easier to read documentation.
The One-Touch functionality is also moved into a separate file, to keep rc_domino_script small and the functionality separated.
The updated scripts are in the develop branch of the Domino Docker Community image, but not added to the start script tar for now.


Agent Code

Surprisingly this isn't much code and sort of elegant.
It has some tricky parts. The replacement function needs exactly the right number of elements.
Having empty elements will cause the resulting text to be empty.. Took me a while to find - specially the Redim needs to be for n-1 if the index is zero based.


Sub Initialize
       
        Dim session As New NotesSession
        Dim db As NotesDatabase
        Dim WebDoc As NotesDocument
        Dim TemplateDoc As NotesDocument
        Dim doc As NotesDocument
        Dim TemplateItem As NotesItem
        Dim FormulaStr As String
        Dim item As NotesItem
        Dim x As Long
        Dim count As Long
        Dim OneTouchConfig As String
        Dim ret As Variant
       
        Print "Content-type: application/json"
       
        On Error GoTo error_handler
       
        Set db = session.Currentdatabase
        Set WebDoc = session.DocumentContext

        Set Doc = GetDocByFormula ( {(Form = "Server") & IP = "} + WebDoc.remote_addr(0) + {"} )

        ' If remote IP not found, get default document for testing
        If (Doc Is Nothing) Then
                Set Doc = GetDocByFormula ( {(Form = "Server") & (IP = "0.0.0.0")} )
        End if

        If (Doc Is Nothing) Then
                LogError "OneTouchSetup - No counfiguration for " + WebDoc.remote_addr(0)
                Exit Sub
        End If

        OneTouchConfig = doc.OneTouchConfig(0)
       
        If ("" = OneTouchConfig) then
                OneTouchConfig = "Default"
        End If

        Set TemplateDoc = GetDocByFormula ( { (Form = "OneTouchSetup") & (TemplateName = "} + OneTouchConfig + {") })
       
        If (TemplateDoc Is Nothing) Then
                LogError "No Template Doc found"
                Exit Sub
        End If
       
        Set TemplateItem = TemplateDoc.Getfirstitem("Body")
       
        If (TemplateItem Is Nothing) Then
                LogError "No Template Item found"
                Exit Sub
        End If


        FormulaStr = TemplateDoc.Formula(0)
       
        If ( "" <> FormulaStr) Then
                ret = Evaluate (FormulaStr, doc)
        End If
       
        count = 0
        ForAll i In doc.Items
                x = InStr (1, i.name, "X_", 1)
                If (1 = x) And ("" <> i.text ) Then
                        count = count + 1
                End If
        End ForAll

        If (0 = count) Then
                LogError "No Fields found"
                Exit Sub
        End If

        ReDim ReplaceFromArray (count-1) As String
        ReDim ReplaceToArray (count-1) As String

        count = 0
        ForAll i In doc.Items
                x = InStr (1, i.name, "X_", 1)
                If (1 = x) And ("" <> i.text ) Then
                        ReplaceFromArray(count) = "{{ SERVERSETUP_" + StrRight (UCase (i.name), "X_") + " }}"
                        ReplaceToArray(count) = i.text
                        count = count + 1
                End If
        End ForAll

        Print Replace (TemplateItem.text, ReplaceFromArray, ReplaceToArray, 1, 1000)

        Exit Sub
       
error_handler:

        LogError "OneTouchSetup - Error: " + Error()
       
        Exit Sub

Critical Exchange on Prem issue: Check your servers ASAP -- Malware agent fails to load in 2022 -- FIP-FS-"Microsoft" Scan Engine Failed to Load

Daniel Nashed  1 January 2022 11:56:20
Sadly not a good start into 2022 for some Exchange on Prem admins.
You should check your servers ASAP to avoid surprises Monday morning.
Depending on the configuration a failure of the "Microsoft Filtering Management Service" might stop your mail flow!

I have not seen anything on heise yet. But I got this tweed --> https://twitter.com/miketheitguy/status/1477097527593734144
And there is a forum entry --> https://docs.microsoft.com/en-us/answers/questions/680488/microsoft-exchange-fip-fs-scan-engine-failed-to-lo.html
Plus a more detailed post --> https://borncity.com/win/2022/01/01/exchange-fip-fs-scan-engine-failed-to-load-cant-convert-2201010001-to-long-1-1-2022/

I am not speculating what could be wrong in detail with the date, since I am not an expert..

Sorry to hear and I hope this is is resolved soon!

Best of luck!

Daniel


Image:Critical Exchange on Prem issue: Check your servers ASAP -- Malware agent fails to load in 2022 -- FIP-FS-"Microsoft" Scan Engine Failed to Load


Image:Critical Exchange on Prem issue: Check your servers ASAP -- Malware agent fails to load in 2022 -- FIP-FS-"Microsoft" Scan Engine Failed to Load



Using Domino CertMgr with NGINX & Co

Daniel Nashed  31 December 2021 16:03:16

Domino CertMgr is easy to use and shows all the certificates in a moder UI.  Most other ACME solutions are quite cryptic and mainly command line oriented.
Also you might want to operate CertMgr with ACME HTTP-01 challenges behind a load balancer, reverse proxy etc.

I took a look this morning and came up with some simple redirect rules first:

Redirect HTTP to HTTPS on NGINX or other load-balancers

The following config redirects all standard traffic from HTTP to HTTS.
And the ACME HTTP-01 challenge is redirected to your CertMgr server.
The server can be on the same or any other machine. And the target can be HTTPS with any type of certificate -- ACME validation does not check existing certs.
Only the challenge is validated -- as long the connection can be established.


You can add this to existing HTTPS configurations to allow ACME-01 challenges and also ensure users are conveniently redirected to HTTPS if HTTP is requested, without opening HTTP (port 80) on any Domino server.


  # Port 80 is redirected to 443. Only ACME challenges are redirected to CertMgr server.

    server {
        listen 80 default_server;
        listen [::]:80 default_server;
        server_name _;

        location /.well-known/acme-challenge/ {
            return 301 https://certmgr.acme.com$request_uri;
        }

        location / {
            return 301 https://$host$request_uri;
        }
    }

TLS configuration with CertMgr certs

Now that we took care of redirecting challenges and HTTP traffic, what about using certificates created on CertMgr on your external host as well?
It could be a certificate from Let's Encrypt requested by the flow we just established -- redirecting ACME HTTP-01 challenges to another server.

Or it could be even a wildcard cert confirmed by ACME DNS-01 challenges.


Here is the documentation I came up with. If you have questions, feedback or ideas, let me know.
https://github.com/HCL-TECH-SOFTWARE/domino-cert-manager/blob/main/docs/external_cfg.md

It contains links to a full TLS NGINX example configuation:
https://github.com/HCL-TECH-SOFTWARE/domino-cert-manager/blob/main/examples/nginx/nginx.conf

And also to an update script with the logic described in the referenced document.
https://github.com/HCL-TECH-SOFTWARE/domino-cert-manager/blob/main/examples/nginx/cert_upd_nginx.sh

This integration allows you to update certificates automatically once you have deployed an exportable key from CertMgr.

I blogged about similar flows before. But this is now a complete example with the widely used NGINX.

-- Daniel


Introducing Domino One-Touch JSON templating - Without manual JSON editing :-)

Daniel Nashed  30 December 2021 12:42:19

Domino One-Touch setup with JSON format is really great stuff -- I love it since day one.
But it might be a bit difficult to edit for many admins -- Even if you use an prepared template, you have to edit the JSON file in an editor to specify server name, etc.

Using variables ala Helm or Ansible makes a lot of sense and if you leverage existing JSON config templates, you might get away with not editing JSON at all.
Both using the {{ Variable }} syntax. But I am more used to the shell variable syntax: ${Variable}. So I implemented both.

I already uploaed the script and updated JSON configuration files to the develop branch of our GitHub repository as part of the start script.

Example:
https://github.com/IBM/domino-docker/blob/develop/start_script/OneTouchSetup/first_server.json

The script itself can be also used for any kind of variable replacement. It checks template variables and prompts for a value -- see example below.

If a variable is already set in the environment, the value is used as default prompt.
On purpose all place-holders match the One-Touch environment variable names.
If you source in an existing configuration, those variables are automatically used.
And sticking with the existing standard variables makes it more consistent.


Example config extract with both syntax options:

{
 "serverSetup": {
   "server": {
     "type": "first",
     "name": "
{{ SERVERSETUP_SERVER_NAME }}",
     "domainName": "
{{ SERVERSETUP_SERVER_DOMAINNAME }}",
     "title": "
$(SERVERSETUP_SERVER_TITLE)",
     "serverTasks": "replica,router,update,amgr,adminp,http,certmgr"
   },
...



Running the start script config command now automatically uses the new functionality when specifying JSON. The result is a ready to use JSON file.
This is just a simple way to replace template variables. In future it would be a good idea to have a configuration database to build ready to use special tailored configurations.
But I think this is already really helpful to have. Not only for workshops and lab environments..

The script itself is surprisingly short including all checks --> https://github.com/IBM/domino-docker/blob/develop/start_script/extra/domCfgJSON.sh

-- Daniel


Example setup:


domino setup json 1
Using Domino config File [/etc/sysconfig/rc_domino_config]


SERVER_NAME: notes.nashcom.de

SERVER_DOMAINNAME: NashCom

SERVER_TITLE: Demo Server One Touch

NETWORK_HOSTNAME: notes.nashcom.de

ORG_ORGNAME: NashCom

ORG_CERTIFIERPASSWORD: xxx

ADMIN_FIRSTNAME: Daniel

ADMIN_LASTNAME: Nashed

ADMIN_PASSWORD: xxx

ADMIN_IDFILEPATH: admin.id

--------------------------------------------------------------------------------
One-Touch Domino Validation
--------------------------------------------------------------------------------

[3909618:000002-00007F687C6B60C0] Success - /local/notesdata/DominoAutoConfig.json is valid with respect to schema dominoOneTouchSetup.schema.json
--------------------------------------------------------------------------------


Domino 12.0.1 One-Touch setup supports MicroCA and import existing certs

Daniel Nashed  29 December 2021 16:35:50

Did you notice already that the One-Touch setup supports importing TLS Credentials for a first server setup?

You can pass a *.kyr file, a PKCS#12 (*.p12, *.pfx) or *.pem file.
The files can even have a password and you can mark the resulting TLS Credentials file for export with a new password!

So the full import functionality added in Domino 12.0.1 CertMgr UI is exposed in One-Touch setup for ENV variable and JSON formatted setup!

Below you find some easy examples. Refer to the documentation for a full list of parameters --> https://help.hcltechsw.com/domino/12.0.0/admin/inst_onetouch.html

To create a new MicroCA for your first server setup, only one parameter is required.
All other options have reasonable defaults. For example CA name is derived from you organization name.

Create a new MicroCA

SERVERSETUP_SECURITY_TLSSETUP_METHOD=dominoMicroCA

The shortest configuration for importing a PEM file instead are the follwing two settings.

Import an existing TLS certificate

SERVERSETUP_SECURITY_TLSSETUP_METHOD=import
SERVERSETUP_SECURITY_TLSSETUP_IMPORTFILEPATH=harbor.pem

That's a pretty slick way to configure a TLS Credentials entry for your first server.
The first server automatically creates the Domain wide certstore.nsf and assigns the first server as the CertMgr server.

For additional server the CertMgr can be used to create TLS Credentials.

Enabling the new TLS Cache on an additional server just requires loading the certmgr task to automatically pull a certstore.nsf replica.
Once the certstore.nsf database is present all internet processes will automatically use the new TLS Cache.


The One-Touch Certfificate Store integration was the missing logical link for automated setup.

-- Daniel


JSON configuration example

The same functionality is also available via Environment variables


   "security": {
    "ACL": {
      "prohibitAnonymousAccess": true,
      "addLocalDomainAdmins": true
    },
    "TLSSetup": {
      "method": "import",
      "retainImportFile": true,
      "importFilePath": "wildcard_nashcom_org.pem",
      "exportPassword": "Super42Secret007Password4KeyFile"
    }
  }

----------------------

    "security": {
    "ACL": {
      "prohibitAnonymousAccess": true,
      "addLocalDomainAdmins": true
    },
    "TLSSetup": {
      "method": "dominoMicroCA",
      "CADisplayName": "Demo CA",
      "CAOrgName": "NotesLab",
      "CAKeyType": "ECDSA",
      "CAExpirationDays": 1096,
      "orgName": "NotesLab",
      "TLSKeyType": "RSA2048",
      "certExpirationDays": 120
    }
  }

Introducing a Lab CA for testing

Daniel Nashed  29 December 2021 15:13:22

Image:Introducing a Lab CA for testing


Domino 12.0.1 CertMgr provides a MicroCA for testing. You can create any type of TLS web server certificate for any name.
The only restriction is that the private key cannot be exported and is recreated every time you renew the certificate.
It's designed as a very easy to use, simple small CA. But this is already pretty cool for internal test environments. You can even deploy the trusted root into your browsers.

A while ago I wrote a small CA as part of my nshcertool. It comes with a TLS enabled listener which can verify client certs.
I can run the CA as a free service on one of my servers just for test purposes. This would be helpful to play with the manual certificate request flow in CertMgr.

For the planned CertMgr & certificates workshop, I just wrote a small pre-delivery agent as an e-mail responder building an e-mail interface to the CA.
Sending a mail to a certain e-mail address with a certain subject and a CSR in the body will just reply with a certificate and intermediate CA cert.


This CA currently intended for lab use. So there is no verification for the requested certificate -- even I already query IP addresses, DNS names and client certs.
But it can be very helpful to understand certificate operations with CertMgr and provide exportable TLS certificates.

Would it make sense to provide this as a free service for the community for testing purposes?
This is even easier to handle than a HashiCrop CA ..

If I implemented it, would be an e-mail requester be sufficient?
Or would a REST based service be more helpful?

-- Daniel

Links

    Archives


    • [IBM Lotus Domino]
    • [Domino on Linux]
    • [Nash!Com]
    • [Daniel Nashed]