Explaining the Domino CScan token

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"
}

• Comments [0]

Revisiting Domino ClamAV for databases on rest

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.

• Comments [1]

Domino 14.5.1 AutoUpdate and container update

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

• Comments [0]

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

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.

• Comments [0]

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]