Daniel Nashed’s Blog

Performance Challenges on modern Intel Hybrid CPUs with Notes and other applications

Daniel Nashed — Thu, 16 Apr 2026 10:13:46 +0200

After moving to a new notebook, my Notes client got very slow when I was in a Sametime meeting or ran other a bit more CPU intensive tasks.
It turns out that Windows is giving the Notes client the slower E-Core CPU cores, which results in a very slow UI responsiveness.

HCL is aware of this and we had a call last week.
If you are running a modern Intel CPU on your workstation/notebook you should read this link for detailed information and a tool

https://github.com/nashcom/nshcpuset

I wrote up all the technical details and a small troubleshooting and work-around tool.

My take away from this is that we have to watch more for the CPU P-Cores then the total number of cores a modern CPU has.

The notebook I got has 2 physical P-Cores with Hyper-Threading + 8 E-Cores.
This doesn't hit Notes alone! We had interesting experiences with VMware workstation before they looked into it.

Darren blogged about the VMware issues he ran into https://blog.darrenduke.net/darren/ddbz.nsf/dx/type-2-hypervisors-and-the-evils-of-e-cores.htm

I am not a fan of Processor Lasso and looked into the APIs on my own to get a clear picture.
Processor Lasso is a too big tool with a lot of options.
You can also use it, but the easier path is to use my small program.

-- Daniel

Domino on Proxmox deployment models

Daniel Nashed — Wed, 15 Apr 2026 16:17:10 +0200

With the current cost increases for VMware licenses and also hardware some of my customers start to look very seriously for alternate solutions.
One deployment method would be Proxmox with local ZFS disks.

ZFS is a very interesting file-system and volume manager combined. It offers a lot of flexibility and choices.
Compression, de-duplication, optimized record size, snapshots, encryption and more benefits.

I am a big fan for a while and I did blog about Domino on Proxmox before.
Last weekend I looked into different deployment methods for Domino on Proxmox for a customer.

A VM with Linux + Docker + Domino might be additional overhead which could be optimized.

LXC containers use native ZFS volumes and are very efficient:

Lightweight Linux instance with shared kernel like Docker
Leverage ZFS host subvolumes for a true end to end storage management and less overhead
Standardized OS images

What is missing is the automated installation we know from Docker.
I am looking into that right now and if you are interested in Domino on Proxmox, I want to hear from you.

At Engage I will show case Domino on Proxmox. I will bring a Proxmox server running on my notebook with an automated Domino installation including management scripts with me.
I would like to hear from you what type of deployments you are looking into.

We are working on multiple deployment options optimized for Proxmox in combination with Domino clustering to optimize the deployment footprint.
This includes DAOS storage deduplication cross servers and backup.

-- Daniel

My Notebook deployment on VMware workstation with Proxmox 4 CPU cores + 8 RAM as a test/demo installation for on the road.
For LXCs it does not even need the hardware support.

Join Us at Engage 2026: Domino on Linux, Installfest and CertMgr

Daniel Nashed — Tue, 14 Apr 2026 19:22:49 +0200

Engage Conference 2026 is just around the corner.

A quick look at the agenda reveals several Linux-focused sessions—and that’s no coincidence.
Linux continues to play a key role in sovereign and future-proof solutions. As in previous years, Bill is hosting the popular Domino on Linux round table.

In addition, the conference will feature a Linux desktop session along with a series of Domino on Linux Installfest sessions. These sessions can be attended independently, but they are also designed to complement each other and build progressively.

Bill, Martijn and I have teamed up to present a full range of sessions—from beginner through to expert level. This includes hands-on labs using on-demand virtual machines at Hetzner, along with forward and reverse DNS within our domino-lab.net environment.

Even if you can’t attend the Installfest sessions, the Linux round table is highly recommended. It’s a great opportunity to ask questions, share feedback, and connect with others—especially if you’re already running Domino on Linux or planning to explore it. For example on Proxmox.

We’ll also share updates on what has been developed over the past year, along with a new initiative aimed at making Domino on Linux more accessible for administrators.

As part of this effort, a new repository has been launched as a central entry point into the Domino on Linux ecosystem:
https://nashcom.github.io/nsh-domino-linux/

Beyond the Linux sessions, I will present another session on Domino CertMgr. If certificate management and automation are topics of interest, this session should definitely be on your list.

You can explore the full agenda here:
https://engage.ug/pages/session2026

We are looking forward to seeing you at Engage 2026.

Bill | Martijn | Daniel

Certificate Lifetimes Are Shrinking — Is Your Domino Infrastructure Ready?

Daniel Nashed — Mon, 30 Mar 2026 23:24:07 +0200

Certificate maximum lifetimes dropped to 200 days in March 2026 and will reach 47 days by 2029.
At that frequency, manual renewal becomes operationally impossible. HCL Domino CertMgr automates issuance and renewal end-to-end.
This includes certificate rollover and also key rollover -- which is as important as rolling over certificates and often overlooked in current discussions.

For everything outside Domino — NGINX, load balancers, and other services — there is a need for automated certificate management.
Rotating the private key on every renewal cycle is the part most deployments have not solved yet.

Here is a longer document I wrote up for one of the projects with additional details:

https://github.com/nashcom/srvguard/blob/main/docs/certificate-lifetime-reduction.md

This initiative started last week. The timing is not a coincident. It's in time for my Engage presentation and the latest changes for certificate lifetime.

When HCL introduced CertMgr in Domino 12.0 most of the feature we have today have been already present.
Domino 12.0.1 introduced export / import which might be helpful for automation.

CertMgr and certstore.nsf are built on open standards and importing certificates/keys and handling CSRs for an automated flow are straightforward to implement on Domino CertMgr side.
The challenge is most time the CA side. My previous post shows a straightforward HashiCorp configuration using ACME as the protocol.
But there are also other easy to use ways to integrate with modern CAs.

There is more to come. But I want to keep also some news for my conference session.
If you are curious what is coming you can take a look at the referenced projects.

-- Daniel

HashiCorp ACME with Domino CertMgr – a Beautiful Combination

Daniel Nashed — Mon, 30 Mar 2026 22:59:58 +0200

For my upcoming session at HCL Engage next month, I’ve been looking into additional integrations for Domino CertMgr. The guiding principle is simple: use standards wherever possible.
One of the most important standards in this space is ACME. It has become the default protocol for automated certificate lifecycle management and is supported by virtually every modern toolchain.

Vault as an enterprise ACME CA

HashiCorp Vault is a modern, API-first PKI solution widely used in corporate environments. With built-in ACME support, Vault can act as a fully functional ACME certificate authority.
That makes integration straightforward:

Vault provides the CA
ACME provides the interface
CertMgr consumes certificates

No custom code, no special handling—just standard protocol.

Why this combination works so well

Domino CertMgr was designed for automation. Pairing it with Vault via ACME creates a clean and robust setup:

enterprise-grade CA
fully automated issuance and renewal
standard-based integration

Current work

I’m currently building a streamlined Vault setup to make testing and demos easier, including ACME-enabled configurations out of the box.
This allows quick validation of:

Domino integrations
short-lived certificates
policy-driven issuance

Some of this will be shown at Engage conference.

Explaining the Domino CScan token

Daniel Nashed — Wed, 25 Mar 2026 00:43:39 +0200

Now that ClamAV integration shipped in 14.5.1 hopefully more admins look into CScan.
CScan for mail flow scan is very straightforward to configure. The configuration database document now defaults to ClamAV with the default parameters.

There some details about the implementation which are not well known but eventually good to know.
There is a Scan Token added when the document is scanned. This token avoids rescan the document on the next hup as long the virus scan signature does not change.

Technically the token is a JWT which you can decode and read. Each server creates a key stored in it's CScan server document.
The key is encrypted for the server and there is a public key to validate the token.

The token contains the information about the server and time when the document was scanned, a hash, a thumb print of the signing key to find the right signing key.
It contains also the scan version and pattern and the configuration.
There is also a hash built based on the attachments in some way to avoid re-scanning and to check if attachments changed.

Here is an example token which could be useful to know:
Field Name: $$CScanToken Data Type: Text Data Length: 644 bytes Seq Num: 1 Dup Item ID: 0 Field Flags: SUMMARY
"eyJ0eXAiOiAiSldUIiwgImFsZyI6ICJFZERTQSJ9.eyJ2ZXJzaW9uIjoxLCJpc3N1ZXIiOiJEb21pbm8gQ29udGVudCBTY2FuIiwiY3JlYXRlZCI6IjIwMjYwMzIxVDE5NDE1OSwxMyswMCIsInNlcnZlciI6IkNOPXJheS5sYWIuZG51Zy5ldS9PPWRudWctbGFiIiwic2NhblZlcnNpb24iOiJDbGFtQVYgMS41LjEvMjc5NDciLCJjb25maWdEYiI6IjAwMjU4ODUyMTA3RUQ1NTIiLCJjb25maWdJRCI6IkIyODdDRTBDOUM1N0NCMkUwMDI1OEFCMTAwNTQxNjg1IiwiY29uZmlnTmFtZSI6ImNsYW1hdi1sYWIiLCJ2ZXJpZmljYXRpb25IYXNoIjoiRjJDM0IwOTA1RTAxMjQ0Qzk3Qjg5MDJDNzI3MjVEOUQ4RENDMERGMSIsImtleVRodW1icHJpbnQiOiJzMTFsSUxDeWVfbUk3NEpGZmlkYm5wbWsxY1EiLCJoYXNoQWxnb3JpdGhtIjoiU0hBMSJ9.Pe8ntQ0WaiDH8xksK2gK_8034uRul4qkFWD5GYp1iZKBET1_D-vqsiFs35X0DqUgNCHACWD0wINJ3ErE5OqbAw"
---

{ "version": 1, "issuer": "Domino Content Scan", "created": "20260321T194159,13+00", "server": "CN=ray.lab.dnug.eu/O=dnug-lab", "scanVersion": "ClamAV 1.5.1/27947", "configDb": "00258852107ED552", "configID": "B287CE0C9C57CB2E00258AB100541685", "configName": "clamav-lab", "verificationHash": "F2C3B0905E01244C97B8902C72725D9D8DCC0DF1", "keyThumbprint": "s11lILCye_mI74JFfidbnpmk1cQ", "hashAlgorithm": "SHA1" }

Revisiting Domino ClamAV for databases on rest

Daniel Nashed — Tue, 24 Mar 2026 16:32:46 +0200

Domino 14.5.1 ships native ClamAV mail flow scan in addition to ICAP.
The configuration is pretty straightforward as blogged earlier.

What is still missing is an periodic/on demand scan of NSF files.
I am revisiting my ClamAV integration on request of two customers.
One doesn't have on rest scan yet. The other one is using a solution which is discontinued soon.
Because I spent all that work already and now Domino also uses ClamAV, it's a good idea to look into it again.

Tag or quarantine messages?

The work I did was almost complete for a first round. What is still open is if we really want to remove attachments and what about quarantining messages.
For now I am just tagging mails and optionally move them to a Virus folder.
Moving out attachments would be a pretty big step for a new feature.
For the mail flow it looks a bit different, because the mail was never delivered to a user.

I think for the first step moving to a Virus folder and central reporting would be good?

Logging

Now that Domino comes with a nice cscanlog.nsf, I am just reusing what is already available.
I looked at all the fields and provide the same admin experience for the ClamAV on rest scan implementation.
It would be a separate database. Maybe even a separate per scan.

Looking for the next steps

The solution already supports incremental scans and scans for separate directories.
There is no exclude or wild-card search. But that would be easy to add. Probably better with wildcard support then using lists?
I think the first step could be wild-card support. using Unix standard regex.

But eventually I want to also support Domino pattern matching?
What do you think? I could offer both. Bot Unix pattern matching is the more standard approach.

Domino 14.5.1 AutoUpdate and container update

Daniel Nashed — Fri, 20 Mar 2026 21:48:51 +0200

For Linux my clear preference is a container deployment wherever possible.
A container only adds a very thin layer on a server and makes updates and consistent installations possible.
The container image has a lot of customization options.

I have a couple of customers who are really happy with their container deployment. OK they have me around to add any new option they might need on the fly -- which goes to the open source project as a feature immediately.
Haha I am my best customer for the container deployment. I add new functionality mostly for me. And some features go hand in hand with functionality in the Domino start script.
But you don't always want or can use containers.

Domino Autoupdate is pretty cool. I just ran it again for 14.5.1 to update all my Windows servers and a coupe of Linux servers.
In my case the Linux servers are mainly native to test autoupdate.

But AutoUpdate itself has also some helpful information. AutoUpdate provides more detailed information about your servers in one single spot.
It also knows about if the servers run in a container and which container platform is used.
And It also knows for example the account the server runs on.

On Linux it also provides the glibc version for example.
None of this information is there by co-incident. I added all those details because they play an important role in the deployment process.

Another small difference is that Domino servers report their version using a push. Each server is responsible for their own AutoUpdate server document on the central replica.

-- Daniel

Domino/Traveler 14.5.1 shipped today - the container image is updated - ClamAV is added to Domino

Daniel Nashed — Thu, 19 Mar 2026 22:36:51 +0200

Domino & Traveler 14.5.1 are now the default for the container build. But the menu behind "D" can be still used to switch the major version.

All the changes always run thru an automation test. But you never know what might break.
In this case it was a Traveler tar with a different name. Because it is compressed it needs the tar.gz extension.

Took me a moment to find it today. But I wrote a work-around and the file name will be updated soon.
Updating Domino servers to 14.5.1 is just a container build away -- if you run containers.
I have updated my production servers and a couple of lab servers.

But an update isn't as complicated as it was in earlier days also on other platforms.
There is no big version change from 14.5 to 14.5.1 for Java versions and Libs.
Everything would be expected to work unchanged and there are enhancements I am waiting for.

ClamAV

One addition in Domino 14.5.1 is the mail flow scan with ClamAV instead of ICAP.
This brings free anti-virus to any Domino environment and is something you might want to look into for server to server scans.
The scan is intelligent and works with a trusted JWT among servers which contain the scanner type and pattern along with an attachment hash. Actually hash of hashes, which avoids re-scan of the whole message inside a domain.

Notes / Domino 14.5.1 – Testing TLS 1.3 and Post-Quantum Cryptography with HttpGetRequest

Daniel Nashed — Sun, 8 Mar 2026 22:06:24 +0200

Recently I received the first questions about protecting against attacks based on quantum computing, often referred to as Post-Quantum Cryptography (PQC).

It’s interesting to see this topic appearing in real customer discussions. Thinking ahead about cryptography is certainly important. However, the ecosystem is still evolving and very little software currently supports the new algorithms.
With Notes/Domino 14.5.1 EA2, there is now early groundwork for PQC support.

But what does this actually mean? And how can we test it?

What Domino 14.5.1 introduces

From the What's New in Notes/Domino 14.5.1 EA2 – Security section:

The OpenSSL library has been updated to version 3.5.4 in Domino 14.5.1 EAP2. This is a Long Term Support (LTS) version of the library that has been submitted to the CMVP for FIPS 140-3 verification.
The cryptographic layer underlying Notes and Domino now leverages OpenSSL 3.5 to support multiple algorithms relevant to protect against attacks based on quantum computing, such as ML-DSA, ML-KEM, SHAKE-128, and SHAKE-256.
As this field is rapidly evolving and the IETF standards are still being written, there is no end-user PQC functionality currently available for use in 14.5.1.

What this actually means

Notes/Domino 14.5.1 ships with OpenSSL 3.5.4.

OpenSSL 3.5 is the first mainstream OpenSSL version that includes initial support for PQC algorithms, including:

ML-DSA (signature algorithm)
ML-KEM (key encapsulation)
SHAKE-128
SHAKE-256

Both OpenSSL and libcurl (it uses OpenSSL) are statically linked into Notes/Domino, which means Domino can use these algorithms wherever the OpenSSL backend is used.

One example is the LotusScript HttpGetRequest class.
Other components inside Notes/Domino still rely on the classical SSL/NTI stack, which currently does not support TLS 1.3.
Where libcurl is used, TLS 1.3 and PQC-related algorithms become available.

The ecosystem challenge

Most Linux distributions ship much older OpenSSL versions.

OpenSSL 3.5.x is still very new, so both ends of the connection must support it.

Requirements for PQC testing:

Component	Requirement
Server	OpenSSL ≥ 3.5
Client	OpenSSL ≥ 3.5
Go applications	Go ≥ 1.26 (Go does not use OpenSSL)

Testing PQC support

To experiment with PQC without upgrading an existing server environment, OpenSSL provides a very useful tool:

openssl s_server

This command allows running a simple TLS test server.

When used with the -www option, it returns a basic HTML page showing TLS handshake information.

Running a test server

The example below restricts the server to the PQC hybrid group X25519MLKEM768.

If a client supports PQC hybrid TLS, the connection will succeed.

Using a container for a modern OpenSSL version

A simple way to obtain a recent OpenSSL build is using a Kali Linux container, which ships with very recent packages.

openssl_s_server.sh
apt update
apt install -y openssl

HOSTNAME=$(hostname)

echo
echo HostName: "$HOSTNAME"
echo

if [ ! -e /local/server.key ] || [ ! -e /local/server.crt ]; then
openssl req -x509 -new -newkey ec \
-pkeyopt ec_paramgen_curve:P-256 \
-pkeyopt ec_param_enc:named_curve \
-nodes \
-keyout /local/server.key \
-out /local/server.crt \
-days 365 \
-subj "/CN=$HOSTNAME" \
-addext "subjectAltName=DNS:$HOSTNAME,DNS:localhost,IP:127.0.0.1"
fi

openssl s_server \
-accept 8443 \
-cert /local/server.crt \
-key /local/server.key \
-groups X25519MLKEM768 \
-www \
-state

run.sh
HOSTNAME=$(hostname -f)

docker run --rm -it \
--name openssl \
--hostname "$HOSTNAME" \
-p 443:8443 \
-v .:/local \
kalilinux/kali-rolling \
bash -c /local/openssl_s_server.sh

Test results

A Notes 14.5 FP1 client cannot connect to this server.

However, the same request using Notes 14.5.1 EA2 works.

The TLS negotiation output includes:

Supported groups: X25519MLKEM768:x25519:secp256r1:x448:secp384r1
Shared groups: X25519MLKEM768

Meaning the connection successfully negotiated the PQC hybrid group.

The TLS session shows but the imported part is the group/CurveID

Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384

Java comparison

Java currently does not support PQC in TLS.

Even Java 21 does not implement:

ML-DSA
ML-KEM
PQ hybrid TLS groups

Java applications usually rely on HTTPS reverse proxies, which can provide TLS features in front of the application.

Conclusion

Notes&Domino 14.5.1 ships with a very current OpenSSL version, helping the platform stay ahead of the cryptographic curve — quite literally.

However:

Domino HTTP still requires a reverse proxy for TLS 1.3 and PQC support
Most production environments already use reverse proxies or load balancers

For Java environments, a reverse proxy approach is usually required as well.
At the moment, few environments have an immediate need for PQC-safe operations, but it is useful to start experimenting with the technology.

Testing external servers

To test a server you can use:
openssl s_client -connect www.example.com:443

Make sure you are running OpenSSL 3.5 or newer, otherwise PQC groups will not be available.

Logs from OpenSSL s_server s_server -accept 8443 -cert /local/server.crt -key /local/server.key -cert_chain /local/chain.pem -groups X25519MLKEM768 -www -state This TLS version forbids renegotiation. Ciphers supported in s_server binary TLSv1.3 :TLS_AES_256_GCM_SHA384 TLSv1.3 :TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 :TLS_AES_128_GCM_SHA256 TLSv1.2 :ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 :ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 :DHE-DSS-AES256-GCM-SHA384 TLSv1.2 :DHE-RSA-AES256-GCM-SHA384 TLSv1.2 :ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 :ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 :DHE-RSA-CHACHA20-POLY1305 TLSv1.2 :ECDHE-ECDSA-AES256-CCM TLSv1.2 :DHE-RSA-AES256-CCM TLSv1.2 :ECDHE-ECDSA-ARIA256-GCM-SHA384 TLSv1.2 :ECDHE-ARIA256-GCM-SHA384 TLSv1.2 :DHE-DSS-ARIA256-GCM-SHA384 TLSv1.2 :DHE-RSA-ARIA256-GCM-SHA384 TLSv1.2 :ADH-AES256-GCM-SHA384 TLSv1.2 :ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 :ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 :DHE-DSS-AES128-GCM-SHA256 TLSv1.2 :DHE-RSA-AES128-GCM-SHA256 TLSv1.2 :ECDHE-ECDSA-AES128-CCM TLSv1.2 :DHE-RSA-AES128-CCM TLSv1.2 :ECDHE-ECDSA-ARIA128-GCM-SHA256 TLSv1.2 :ECDHE-ARIA128-GCM-SHA256 TLSv1.2 :DHE-DSS-ARIA128-GCM-SHA256 TLSv1.2 :DHE-RSA-ARIA128-GCM-SHA256 TLSv1.2 :ADH-AES128-GCM-SHA256 TLSv1.2 :ECDHE-ECDSA-AES256-CCM8 TLSv1.2 :ECDHE-ECDSA-AES128-CCM8 TLSv1.2 :DHE-RSA-AES256-CCM8 TLSv1.2 :DHE-RSA-AES128-CCM8 TLSv1.2 :ECDHE-ECDSA-AES256-SHA384 TLSv1.2 :ECDHE-RSA-AES256-SHA384 TLSv1.2 :DHE-RSA-AES256-SHA256 TLSv1.2 :DHE-DSS-AES256-SHA256 TLSv1.2 :ECDHE-ECDSA-CAMELLIA256-SHA384 TLSv1.2 :ECDHE-RSA-CAMELLIA256-SHA384 TLSv1.2 :DHE-RSA-CAMELLIA256-SHA256 TLSv1.2 :DHE-DSS-CAMELLIA256-SHA256 TLSv1.2 :ADH-AES256-SHA256 TLSv1.2 :ADH-CAMELLIA256-SHA256 TLSv1.2 :ECDHE-ECDSA-AES128-SHA256 TLSv1.2 :ECDHE-RSA-AES128-SHA256 TLSv1.2 :DHE-RSA-AES128-SHA256 TLSv1.2 :DHE-DSS-AES128-SHA256 TLSv1.2 :ECDHE-ECDSA-CAMELLIA128-SHA256 TLSv1.2 :ECDHE-RSA-CAMELLIA128-SHA256 TLSv1.2 :DHE-RSA-CAMELLIA128-SHA256 TLSv1.2 :DHE-DSS-CAMELLIA128-SHA256 TLSv1.2 :ADH-AES128-SHA256 TLSv1.2 :ADH-CAMELLIA128-SHA256 TLSv1.0 :ECDHE-ECDSA-AES256-SHA TLSv1.0 :ECDHE-RSA-AES256-SHA SSLv3 :DHE-RSA-AES256-SHA SSLv3 :DHE-DSS-AES256-SHA SSLv3 :DHE-RSA-CAMELLIA256-SHA SSLv3 :DHE-DSS-CAMELLIA256-SHA TLSv1.0 :AECDH-AES256-SHA SSLv3 :ADH-AES256-SHA SSLv3 :ADH-CAMELLIA256-SHA TLSv1.0 :ECDHE-ECDSA-AES128-SHA TLSv1.0 :ECDHE-RSA-AES128-SHA SSLv3 :DHE-RSA-AES128-SHA SSLv3 :DHE-DSS-AES128-SHA SSLv3 :DHE-RSA-SEED-SHA SSLv3 :DHE-DSS-SEED-SHA SSLv3 :DHE-RSA-CAMELLIA128-SHA SSLv3 :DHE-DSS-CAMELLIA128-SHA TLSv1.0 :AECDH-AES128-SHA SSLv3 :ADH-AES128-SHA SSLv3 :ADH-SEED-SHA SSLv3 :ADH-CAMELLIA128-SHA TLSv1.2 :RSA-PSK-AES256-GCM-SHA384 TLSv1.2 :DHE-PSK-AES256-GCM-SHA384 TLSv1.2 :RSA-PSK-CHACHA20-POLY1305 TLSv1.2 :DHE-PSK-CHACHA20-POLY1305 TLSv1.2 :ECDHE-PSK-CHACHA20-POLY1305 TLSv1.2 :DHE-PSK-AES256-CCM TLSv1.2 :RSA-PSK-ARIA256-GCM-SHA384 TLSv1.2 :DHE-PSK-ARIA256-GCM-SHA384 TLSv1.2 :AES256-GCM-SHA384 TLSv1.2 :AES256-CCM TLSv1.2 :ARIA256-GCM-SHA384 TLSv1.2 :PSK-AES256-GCM-SHA384 TLSv1.2 :PSK-CHACHA20-POLY1305 TLSv1.2 :PSK-AES256-CCM TLSv1.2 :PSK-ARIA256-GCM-SHA384 TLSv1.2 :RSA-PSK-AES128-GCM-SHA256 TLSv1.2 :DHE-PSK-AES128-GCM-SHA256 TLSv1.2 :DHE-PSK-AES128-CCM TLSv1.2 :RSA-PSK-ARIA128-GCM-SHA256 TLSv1.2 :DHE-PSK-ARIA128-GCM-SHA256 TLSv1.2 :AES128-GCM-SHA256 TLSv1.2 :AES128-CCM TLSv1.2 :ARIA128-GCM-SHA256 TLSv1.2 :PSK-AES128-GCM-SHA256 TLSv1.2 :PSK-AES128-CCM TLSv1.2 :PSK-ARIA128-GCM-SHA256 TLSv1.2 :DHE-PSK-AES256-CCM8 TLSv1.2 :DHE-PSK-AES128-CCM8 TLSv1.2 :AES256-CCM8 TLSv1.2 :AES128-CCM8 TLSv1.2 :PSK-AES256-CCM8 TLSv1.2 :PSK-AES128-CCM8 TLSv1.2 :AES256-SHA256 TLSv1.2 :CAMELLIA256-SHA256 TLSv1.2 :AES128-SHA256 TLSv1.2 :CAMELLIA128-SHA256 TLSv1.0 :ECDHE-PSK-AES256-CBC-SHA384 TLSv1.0 :ECDHE-PSK-AES256-CBC-SHA SSLv3 :SRP-DSS-AES-256-CBC-SHA SSLv3 :SRP-RSA-AES-256-CBC-SHA SSLv3 :SRP-AES-256-CBC-SHA TLSv1.0 :RSA-PSK-AES256-CBC-SHA384 TLSv1.0 :DHE-PSK-AES256-CBC-SHA384 SSLv3 :RSA-PSK-AES256-CBC-SHA SSLv3 :DHE-PSK-AES256-CBC-SHA TLSv1.0 :ECDHE-PSK-CAMELLIA256-SHA384 TLSv1.0 :RSA-PSK-CAMELLIA256-SHA384 TLSv1.0 :DHE-PSK-CAMELLIA256-SHA384 SSLv3 :AES256-SHA SSLv3 :CAMELLIA256-SHA TLSv1.0 :PSK-AES256-CBC-SHA384 SSLv3 :PSK-AES256-CBC-SHA TLSv1.0 :PSK-CAMELLIA256-SHA384 TLSv1.0 :ECDHE-PSK-AES128-CBC-SHA256 TLSv1.0 :ECDHE-PSK-AES128-CBC-SHA SSLv3 :SRP-DSS-AES-128-CBC-SHA SSLv3 :SRP-RSA-AES-128-CBC-SHA SSLv3 :SRP-AES-128-CBC-SHA TLSv1.0 :RSA-PSK-AES128-CBC-SHA256 TLSv1.0 :DHE-PSK-AES128-CBC-SHA256 SSLv3 :RSA-PSK-AES128-CBC-SHA SSLv3 :DHE-PSK-AES128-CBC-SHA TLSv1.0 :ECDHE-PSK-CAMELLIA128-SHA256 TLSv1.0 :RSA-PSK-CAMELLIA128-SHA256 TLSv1.0 :DHE-PSK-CAMELLIA128-SHA256 SSLv3 :AES128-SHA SSLv3 :SEED-SHA SSLv3 :CAMELLIA128-SHA TLSv1.0 :PSK-AES128-CBC-SHA256 SSLv3 :PSK-AES128-CBC-SHA TLSv1.0 :PSK-CAMELLIA128-SHA256 --- Ciphers common between both SSL end points: TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-RSA-CHACHA20-POLY1305 DHE-RSA-CHACHA20-POLY1305 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES256-SHA384 ECDHE-RSA-AES256-SHA384 DHE-RSA-AES256-SHA256 ECDHE-ECDSA-AES128-SHA256 ECDHE-RSA-AES128-SHA256 DHE-RSA-AES128-SHA256 ECDHE-ECDSA-AES256-SHA ECDHE-RSA-AES256-SHA DHE-RSA-AES256-SHA ECDHE-ECDSA-AES128-SHA ECDHE-RSA-AES128-SHA DHE-RSA-AES128-SHA AES256-GCM-SHA384 AES128-GCM-SHA256 AES256-SHA256 AES128-SHA256 AES256-SHA AES128-SHA Signature Algorithms: id-ml-dsa-65:id-ml-dsa-87:id-ml-dsa-44:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:ed25519:ed448:ecdsa_brainpoolP256r1_sha256:ecdsa_brainpoolP384r1_sha384:ecdsa_brainpoolP512r1_sha512:rsa_pss_pss_sha256:rsa_pss_pss_sha384:rsa_pss_pss_sha512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224:DSA+SHA224:DSA+SHA256:DSA+SHA384:DSA+SHA512 Shared Signature Algorithms: id-ml-dsa-65:id-ml-dsa-87:id-ml-dsa-44:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:ed25519:ed448:ecdsa_brainpoolP256r1_sha256:ecdsa_brainpoolP384r1_sha384:ecdsa_brainpoolP512r1_sha512:rsa_pss_pss_sha256:rsa_pss_pss_sha384:rsa_pss_pss_sha512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224 Supported groups: X25519MLKEM768:x25519:secp256r1:x448:secp384r1:secp521r1:ffdhe2048:ffdhe3072Shared groups: X25519MLKEM768--- New,TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384SSL-Session: Protocol : TLSv1.3 Cipher : TLS_AES_256_GCM_SHA384 Session-ID: AA0FD5EF7D084515DB148EB6AEF8061905A90BAD3E87DE157B5859212135E283 Session-ID-ctx: 01000000 Resumption PSK: 75BAD9484C7D6F0CF176130FC6CEE498A8CF3F12C154080D1547F9B4ED12C4A72596345B3AC6D82EA2C2233C3C929558 PSK identity: None PSK identity hint: None SRP username: None Start Time: 1772999818 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no Max Early Data: 0 --- 0 items in the session cache 0 client connects (SSL_connect()) 0 client renegotiates (SSL_connect()) 0 client connects that finished 29 server accepts (SSL_accept()) 0 server renegotiates (SSL_accept()) 20 server accepts that finished 2 session cache hits 0 session cache misses 0 session cache timeouts 0 callback cache hits 0 cache full overflows (128 allowed) --- no client certificate available

How to run a program on Linux multiple times in parallel for testing

Daniel Nashed — Thu, 5 Mar 2026 21:57:26 +0200

This is really cool. I did't know about those options for xargs. And I never used seq.
It can be used for a lot of things.

Here is an example to create test mails
seq 1 50 | xargs -P50 -I{} nshmailx -to test@example.com -subject "TestMail {}" -server 127.0.0.1 -port 25

Here is a more simple example which demonstrates what it does.

seq 1 10 | xargs -P50 -I{} echo '"Test{}"'

seq counts from 1 to 10 and prints the result to stdout.
It could be also used to start at a different value and you can add an optional increment.

There are two interesting options for xargs.

-P50

run the specified program with 50 instances in parallel

-I{}

specify a place holder which will be replaced by the text from stdin -- in this case the number.

What is also cool is that it works in single and double quotes.

seq 1 10 | xargs -P50 -I{} echo '"Test{}"'
"Test1"
"Test2"
"Test3"
"Test4"
"Test5"
"Test6"
"Test7"
"Test8"
"Test9"
"Test10"

Domino Start Script - Changing the default command for showing log files to "less"

Daniel Nashed — Sat, 28 Feb 2026 12:03:26 +0200

In preparation for the Engage Domino on Linux workshops I looked again into the editor used by default.
Currently the default editor for the start script is vi. All scripts respect the EDITOR environment variable which you could set in your environment.

But for showing logs probably the "less" command would be more helpful for anyone who is not a "vi" expert.

The start script had an environment variable for a while. If you want to go back to the previous mode or if you want a different editor you can override the default configuration:
SHOW_LOG_COMMAND=vi

I would also like to understand which type of editor you are using on Linux.
The following list should show the most popular ones.

vi/vim
nano seams to be very popular if you are not a vi fan
mcdedit from Midnight Commander
micro is another simple to use editor

Converting a binary file to Base64 in Lotus Script

Daniel Nashed — Sat, 28 Feb 2026 03:33:30 +0200

This took me a while. The devil is in the detail.
But finally I came up with something quite straightforward.

I had similar code in my blog which I finally took to build this helper function.
The Base64 encoding is needed for data source images which I will add in-line into Markdown.

-- Daniel

Function EncodeFileBase64 (FileName As String) As String Dim session As New NotesSession Dim stream As NotesStream Dim db As NotesDatabase Dim doc As NotesDocument Dim body As NotesMIMEEntity Set stream = session.CreateStream Call stream.Open(FileName, "Binary") Set db = session.CurrentDatabase Set doc = db.CreateDocument Set body = doc.CreateMIMEEntity Call body.SetContentFromBytes(stream, "application/octet-stream", ENC_IDENTITY_BINARY) Call body.EncodeContent(ENC_BASE64) EncodeFileBase64 = Replace(Replace(body.ContentAsText, Chr(13), ""), Chr(10), "") Call stream.Close Set doc = Nothing End Function

Engage 2026 Agenda is live -- My CertMgr session got accepted

Daniel Nashed — Fri, 27 Feb 2026 19:33:36 +0200

Just before the weekend the agenda got published --> https://engage.ug/pages/session2026

Bill, Martijn and myself are going to have a couple of sessions about Domino on Linux (Installfest & Roundtable sessions).

And there is also a Linux desktop session from Bill. We might have surprises for admins & developers who want to run Linux on their notebook as you might guess from earlier Linux on USB stick posts.
But beside the shared Linux sessions I am also very happy that my Domino CertMgr session got approved.
The session will go way beyond the standard use cases and I am working on some integration options which I will go thru and publish before or at Engage.

Domino CertMgr

If you have specific use cases that go beyond the standard use cases, I want to hear from you.
I have plenty of ideas and ready extensions. But I want to make this to make a practical experience.
You can ping me either directly or thru the HCL Domino CertMgr GitHub repository by opening an issue --> https://github.com/HCL-TECH-SOFTWARE/domino-cert-manager
There is already a lot of extra material in the repository and there is also OTS integration for CertMgr.

But the session will go far beyond that, explains technical background and how components work hand in hand together.
There are also some new CertMgr features in Domino 14.5.1 we will go thru.

I am looking forward to Engage conference!

-- Daniel

CertMgrUtils Usecase

Daniel Nashed — Fri, 27 Feb 2026 02:51:54 +0200

Here is the use case I had in mind first when building the helper script lib.
A flow where my CertMgrUtils class is used.

Earlier the MicroCA was added as a trusted root.
From there the Script Lib copies the trusted root from CertStore to to names.nsf to make sure the Lotus Script NotesHTTPRequest can connect to the K8s service.

Flow

Create a key outside Domino using OpenSSL with a password
Add it via OTS to a setup document in an application including the password
A setup agent uses the Lib to import the key directly from the document to certstore.nsf
Request a MicroCA document by filling in the right fields
Create a K8s pod which has the private key assigned to a secret
The pod runs a Go process using the key and gets the matching certificate from CertMgr via HTTP before starting the listener
At run-time CertMgr is queried over HTTP with SNI for a matching new certificate matching the private key
The certificate and key is updated on the fly and the HTTP listener reloads on the fly

Picking the right cloud server hardware

Daniel Nashed — Fri, 27 Feb 2026 02:26:23 +0200

When choosing cloud server hardware, the devil is in the detail.

CPU performance

Cost effective hardware usually uses older CPU models which don't have hardware support for hash and crypto operations.
In modern application communication requires TLS. Also ZFS and other components require hardware support for SHA operations and crypto.

A simple test shows the difference.

openssl speed -seconds 3 -bytes 16384 sha256 2>/dev/null | awk '/^sha256/ {printf "%.2f MB/s\n", $2/1000}'

My older VM cost efficient server at Hetzner doesn't have hardware support for thos operations:

332.13 MB/s

A more modern machine shows dramatically better performance:

1762.05 MB/s

My local Proxmox host on new Intel hardware even has better performance.

2347.82 MB/s

For larger servers with higher load the new modern CPU makes a lot of sense and is good invested money.

Disk performance

Specially for Domino I/O response time is very important for NSF.
Domino uses many small random I/Os and is more read than write bound.

I/O writes are usually very well cached. Reading data can also be well cached if you have sufficient RAM.

But fast SSDs still make a difference as you can see in an earlier test.

Latency is most important for Domino I/O.
Backup operations require high I/O transfer rates.

Cloud providers often provide different levels of disk performance.

Different storage classes with different disk types
Sometimes performance is limited by to certain number of IOPS and thruput unless you pay extra

When choosing hardware you really need to balance performance vs. price.

--- NVMe internal disk on an older notebook ---Disk Random 16.0 Read 321.10 MB/s Disk Sequential 64.0 Read 433.78 MB/s Disk Sequential 64.0 Write 97.33 MB/s Average Read Time with Sequential Writes 0.620 ms Latency: 95th Percentile 1.839 ms Latency: Maximum 14.415 ms Average Read Time with Random Writes 0.591 ms Total Run Time 00:00:40.08 --- NVMe internal disk on my new notebook ---Dramatic increase in read and write performance. Another 10 times better latency as well! Disk Random 16.0 Read 1508.35 MB/s Disk Sequential 64.0 Read 4414.35 MB/s Disk Sequential 64.0 Write 1138.50 MB/s Average Read Time with Sequential Writes 0.081 ms Latency: 95th Percentile 0.152 ms Latency: Maximum 1.208 ms Average Read Time with Random Writes 0.084 ms Total Run Time 00:00:07.33

NotesClass CertMgrUtils - Export / Import / Copy trusted roots into Domino Directory

Daniel Nashed — Wed, 25 Feb 2026 00:30:43 +0200

As part of an application I am working on, I wrote a Notes Class to manage TLS Credentials.
What was of special interest is to copy trusted roots from CertStore into Domino Directory because it is needed for the NotesHTTPRequest in Lotus Script since 14.5 by default on servers.

There isn't any automation to import Trusted roots. But there is a simple way to import Trusted Roots into certstore.nsf by generating a request.
The resulting document can be copied into the Domino directory -- But the document needs to be mangled a bit.
Function CopyTrustedRootToDominoDirectory (doc As NotesDocument, DominoDirectoryDb As NotesDatabase) As Integer

In addition to Trusted Root functionality I also added the export and import functionality as easy to use functions.
There is a C-API call designed explicitly for use via LS2CAPI used in a ScriptLib

All functionality requires an existing document in certstore.nsf
I might add more functionality over time.

Function CertStoreCreateExportableKey (doc As NotesDocument, ExportPassword As String) As String Function CertStoreImport (doc As NotesDocument, ImportFilePath As String, CurrentPassword As String, ExportPassword As String) As String Function CertStoreExport (doc As NotesDocument, ExportFilePath As String, CurrentPassword As String, ExportPassword As String) As String

For now it is mainly intended for my application. But if you need this type of functionality, I am happy to share the ScriptLib which contains the CertMgrUtils class.

Are you running Domino on Kubernetes?

Daniel Nashed — Mon, 23 Feb 2026 00:02:26 +0200

With the current new challenges for virtualization platforms to find an alternate solution for VMware work-loads Kubernetes (K8s) might get more attraction.
Some virtualization platforms are even built on K8s. In those cases running a container vs. running a VM could become more interesting.
Running on K8s brings new challenges. A container also on K8s runs a Linux instance with a very thin Linux based virtualization layer.

A container scales to the limits of the underlying Linux platform.
I wrote up a document with some details how to run in production -> https://opensource.hcltechsw.com/domino-container/concept_run-production/

The main challenge is the storage because Domino NSF files require a very stable and connection with low latency and many smaller I/Os.
A standard cloud based K8s environment usually isn't a good fit for larger Domino servers.
You really need special I/O tuned infrastructure. Like an enterprise SAN CSI connection.

If you are running on K8s I would like to understand what type of infrastructure you are running in which scale and how you manage it.
I am currently working on automated container and K8s deployments.

What is of special interest is the storage back-end and backup.
I am looking into different type of scenarios either using NFS based file targets or snapshot flows levering CSI driver snapshots.
Is anyone using Rancher as management interface?

Run workloads on the same IP using NGINX Stream and HTTP configurations in parallel

Daniel Nashed — Fri, 20 Feb 2026 20:53:53 +0200

Today I am working on a K8s lab environment where I only have one external IP.
That means I can only have one NGINX instance listening to the public IP on 443.

But what if I have different type of work-loads.

Some need TLS termination like the Rancher admin interface
Others would work well to send the traffic dispatched on TCP level like Domino requesting it's own certificates via CertMgr

Both are possible at the same time when thinking outside the box.

Every HTTPS request will first hit NGINX on the "stream" configuration
The stream configuration gets the SNI name using a SNI NGINX stream configuration

In case it matches a host that needs TLS termination the request is dispatched to a local port 8443 on the same NGINX instance
The NGINX instance on 8443 terminates the traffic and sends the request to the backend
The backend is still HTTPS but with a private certificate

Using this type of setup you can use a single NGINX DaemonSet to dispatch all your traffic.

The same kind of configuration would also work on Docker. But in my case this is sitting behind a K8s MetalLB to receive all the K8s cluster lab traffic.

Domino 14.5 is not supported on Windows Core Server

Daniel Nashed — Thu, 19 Feb 2026 15:54:24 +0200

Microsoft offers two different installation modes for Windows Servers for the two different editions (Standard & Datacenter).

"Windows Core server" an installation mode without full graphically UI
The full server installation with a full administration GUI

Windows Core Server Standard Edition is meanwhile the default when you run the installer.
But even the Domino System Requirements does not explicitly exclude Windows Core server it is not a supported configuration yet.
There is an AHA idea to vote for, which only has 7 votes today.

https://domino-ideas.hcltechsw.com/ideas/DOMINO-I-2524

I am not sure if nobody has the requirement or nobody knows it is not supported yet.

Windows Core Server needs less resources and is the recommended installation mode by German BSI because also from security point of view.
Specially for smaller servers since Windows 2025 it is important to reduce the footprint of the Windows server, because it tends to use more memory out of the box.
It comes with a simple configuration menu for the most important tasks and works well with Domino.
The installer, the classical configuration wizard and also the Jconsole GUI just works unchanged.

Only the service.exe doesn't launch. But to start and stop services you can either use sc command line or use the services part of taskmgr.
RDP works as well. But Windows 2025 also comes with OpenSSH installed and you can just enable for administration via a SSH session -- But that's maybe something for another post.

This post is to raise awareness and to see if someone is currently using it or plans to use it.

If you have a requirement to install it, please vote for my AHA idea.