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

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:ffdhe3072
Shared groups: X25519MLKEM768
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
SSL-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

• Comments [0]

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

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"

• Comments [6]

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

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
   

• Comments [14]

Converting a binary file to Base64 in Lotus Script

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

• Comments [13]

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

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

• Comments [6]

CertMgrUtils Usecase

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
   

• Comments [238]

Picking the right cloud server hardware

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

• Comments [4]

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

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.

• Comments [14]

Are you running Domino on Kubernetes?

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?

• Comments [219]

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

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.








 


 

• Comments [6]