Domino CertMgr Meets Knot DNS, DNSSEC, ACME DNS-01 with Open Standards

I have been working on a new DNS integration for HCL Domino CertMgr, combining a number of established Internet standards with a modern authoritative DNS server.
The result is a lightweight solution that supports automated certificate issuance and renewal without depending on a proprietary DNS provider API.

Each of the components can be looked at separately. They are based on standards. My setup is an end to end integration based on those components demonstrate how this can work end to end.


Building on Domino CertMgr's Extensibility

One of the goals of CertMgr in Domino 12.0 was to support different integration methods: REST APIs, Domino agents, and operating-system commands.
I implemented several DNS integrations early on. Today I came up with a command line integration leveraging standard technology.


Knot DNS, INWX, and Open Standards

The new integration uses Knot DNS as a hidden primary DNS server, with INWX providing the publicly authoritative secondary nameservers.

The solution combines several modern standards:

• ACME (RFC 8555) for automated certificate management, including DNS-01 domain validation.
• Dynamic DNS Update (RFC 2136) for creating and removing DNS challenge records.
• TSIG (RFC 8945) for authenticating DNS update requests.
• DNS NOTIFY (RFC 1996) to inform secondary DNS servers about zone changes.
• DNS zone transfers (AXFR/IXFR, RFC 5936 / RFC 1995) to synchronize the authoritative DNS servers.
• DNSSEC (RFC 4033–4035) to provide authenticated DNS data.

Knot DNS automatically signs the updated zone and propagates the changes to the INWX secondaries.






No Fixed DNS Propagation Delay

One particularly nice aspect of the implementation is that it doesn't rely on a fixed waiting period.
A small Bash script submits the authenticated DNS update and then checks all configured authoritative nameservers.
Only when the expected TXT record is visible everywhere does the script report success to Domino CertMgr.
The same mechanism verifies removal of the challenge record after validation.

This allows us to configure the DNS provider delay to zero. The integration itself determines when DNS propagation has completed.

Simple, Flexible, and Secure

The integration requires only a small Bash script and the standard nsupdate and dig utilities.

TSIG permissions can be restricted on the DNS server to specific record types and permitted DNS names, limiting what the integration credential can modify.
The script supports credentials stored in a protected key file or supplied through environment variables, allowing administrators to choose the approach that fits their environment.
No additional REST service, database, or permanently running integration process is required.

A Nice Example of Extensible Architecture

What I particularly like about this solution is that all components communicate using established standards.
Domino CertMgr doesn't need to know anything about Knot DNS, INWX, or the underlying DNS architecture.

It simply invokes an external command and evaluates the result.

A small integration, built on open standards, demonstrating why extensibility matters

And a nice reminder that architectural decisions made for Domino 12.0 are still paying off today.


Additional Notes: Why This DNS Architecture?

The Domino CertMgr integration was actually the last mile of this project.
My original goal was to find a way to update DNS records using secure, modern Internet standards. At the same time, I wanted to take a closer look at DNSSEC and DNS providers supporting it.

I chose INWX, which provides comprehensive DNSSEC support. One feature I was missing was the ability to manage DS records for delegated subdomains.
DS records are an essential part of the DNSSEC chain of trust between a parent zone and a delegated child zone. Other providers, such as Cloudflare, support managing these records.
Instead of treating this as a limitation, I took the opportunity to run my own authoritative DNS server.

I chose Knot DNS, which handles dynamic DNS updates, DNSSEC signing, and zone transfers. INWX continues to provide the publicly authoritative nameservers.

The resulting architecture is straightforward:

DNS update and publication


Domino CertMgr
    |
    | Command-line integration
    v
Bash script + nsupdate
    |
    | RFC 2136 + TSIG
    v
Knot DNS (hidden primary)
    |
    | DNSSEC signing
    | DNS NOTIFY + AXFR/IXFR
    v
INWX authoritative secondaries
    |
    v
Public DNS

----

The Bash script also queries the INWX authoritative nameservers directly to verify that the DNS challenge record has propagated before returning success to CertMgr.
This gives me full control over DNSSEC signing and dynamic DNS updates while continuing to use the provider's public DNS infrastructure.
The result is a combination of RFC 2136, TSIG, DNSSEC, DNS NOTIFY, AXFR/IXFR, and ACME, with each component doing exactly what it was designed to do.

• Comments [0]

Knot DNS: A Lightweight Authoritative DNS Server for ACME and Dynamic DNS

Running your own authoritative DNS server for a sub-domain can be useful even if your main DNS domains are hosted by an external provider.

For my setup, I wanted to cover two use cases:

• ACME DNS-01 validation using CNAME delegation, without modifying the DNS records of the primary domain.
• Dynamic DNS (DDNS) for devices with changing public IP addresses, without depending on a third-party DDNS service.

Both can be implemented with Knot DNS (https://www.knot-dns.cz/), an open-source authoritative DNS server that supports DNS UPDATE (RFC 2136), TSIG authentication, and fine-grained access control.

Delegating DNS Subdomains

The main domain remains hosted by the existing DNS provider. Only two dedicated subdomains are delegated to the Knot DNS server.

For example:

• validation.example.com — ACME DNS-01 validation
• dyn.example.com — Dynamic DNS records

The DNS provider only needs to configure the appropriate NS delegation records pointing to our authoritative Knot DNS server.

This allows us to manage both zones independently without moving the primary domain or changing its existing DNS infrastructure.

1. ACME DNS-01 Validation with CNAME Delegation

ACME DNS-01 challenges require a TXT record under _acme-challenge to prove control of a domain.

Instead of granting an ACME client permission to modify the primary DNS zone, we can use a CNAME record to redirect validation to our dedicated zone.

For example, in the primary DNS zone:

_acme-challenge.mail.example.com. IN CNAME mail.validation.example.com.


The ACME client creates the corresponding TXT record in the delegated zone:


mail.validation.example.com. IN TXT "acme-validation-token"


The certificate authority follows the CNAME and checks the TXT record.
The main advantage is that the ACME client only requires update permissions for the dedicated validation zone.

This is particularly interesting for HCL Domino CertMgr, which supports DNS-01 validation through DNS providers and DNS UPDATE integrations.

Multiple domains, including domains hosted at different DNS providers, can use the same validation infrastructure through CNAME delegation.

Benefits

• No DNS API credentials for the primary DNS provider are required.
• ACME clients receive access only to a dedicated validation zone.
• DNS-01 validation works without exposing an HTTP service.
• Wildcard certificate validation is supported.
• The same DNS infrastructure can serve multiple domains and certificate management systems.

2. Running Our Own Dynamic DNS Service

The second use case is a private Dynamic DNS service.

Many routers and mobile devices have changing public IP addresses. A DDNS client can update a DNS record whenever the public address changes.

For example:

slate7.dyn.example.com. IN A 203.0.113.25


Instead of using a commercial Dynamic DNS provider, the device sends an authenticated DNS UPDATE request directly to Knot DNS.

The configuration uses a dedicated TSIG key for this purpose.

acl:
 - id: slate7-updates
   key: slate7-ddns
   action: update
   update-type: [A, AAAA]
   update-owner: name
   update-owner-name: slate7.dyn.example.com.

This restricts the client to updating only the A and AAAA records belonging to its own hostname.

Even with valid TSIG credentials, the client cannot update arbitrary records in the zone.

For devices with dynamic public addresses, restricting access by source IP would be impractical. TSIG authentication and record-level restrictions provide the necessary authorization.

The result is a simple, self-hosted DDNS service based on standard DNS protocols rather than a proprietary provider API.

3. Knot DNS Configuration

Both use cases can be configured on the same Knot DNS instance.

The following example shows the relevant configuration:

server:
 listen: 0.0.0.0@53

log:
 - target: stdout
   any: info

key:
 - id: acme-update
   algorithm: hmac-sha256
   secret: xxxx=

 - id: slate7-ddns
   algorithm: hmac-sha256
   secret: yyyy=

acl:
 - id: acme-updates
   address: [127.0.0.1, 10.100.0.0/16, 1.2.3.4/32]
   key: acme-update
   action: update
   update-type: TXT

 - id: slate7-updates
   key: slate7-ddns
   action: update
   update-type: [A, AAAA]
   update-owner: name
   update-owner-name: slate7.dyn.example.com.

zone:
 - domain: validation.example.com
   storage: /storage/zones
   file: validation.example.com.zone
   acl: acme-updates
   dnssec-signing: off

 - domain: dyn.example.com
   storage: /storage/zones
   file: dyn.example.com.zone
   acl: slate7-updates
   dnssec-signing: off


The configuration separates the two applications using different TSIG keys and ACLs.

ACME updates are restricted to TXT records and a list of trusted source networks.

Dynamic DNS updates are restricted to A and AAAA records for one specific hostname.

Both zones are authoritative and independently managed.

4. Why Knot DNS?

Knot DNS is designed as a high-performance authoritative DNS server. It is not a general-purpose recursive DNS resolver.

For this scenario, that is exactly what we need.

It provides:

• Standard DNS UPDATE support (RFC 2136)
• TSIG authentication
• Granular ACLs for update types and record ownership
• Independent authoritative DNS zones
• DNSSEC support when required
• A small footprint suitable for Linux servers and containers

There is no need to implement a custom HTTP-based Dynamic DNS API or integrate with a particular DNS provider.

Clients can use the standard `nsupdate` utility or any compatible RFC 2136 implementation.

Conclusion

Delegating a couple of dedicated DNS subdomains to a self-hosted Knot DNS server provides a flexible foundation for two useful services.

ACME DNS-01 validation becomes independent of the primary DNS provider, while Dynamic DNS can be handled directly through authenticated DNS UPDATE requests.
Both services use open standards, have separate credentials and permissions, and can run on the same lightweight authoritative DNS infrastructure.
This is particularly useful in environments where certificate automation, remote devices, and self-hosted infrastructure need to work together without relying on provider-specific APIs.

• Comments [0]

Two Open Source ACME Servers Tested with HCL Domino CertMgr

HCL Domino CertMgr supports the ACME protocol for automated certificate management. While most deployments use public certificate authorities such as Let's Encrypt, ACME can also be used with private certificate authorities.
I recently tested two interesting open-source ACME server projects with HCL Domino CertMgr. Both worked successfully, but they take very different approaches.


acme-ca-server – A Python-Based Private ACME CA

GitHub: https://github.com/knrdl/acme-ca-server

The first project, acme-ca-server, is a Python-based ACME server with an integrated Certificate Authority and PostgreSQL backend.
It provides a relatively straightforward way to set up a private ACME endpoint using Docker.
For my tests, I deployed the server with PostgreSQL 17 behind an NGINX reverse proxy. After configuring the database connection, CA keys and external URL correctly, HCL Domino CertMgr was able to request and obtain certificates.

The project currently supports HTTP-01 validation, but not DNS-01.

The implementation works, but I would not consider it production-ready without additional work.
In particular, CA private key protection deserves more attention. A CA signing key is one of the most sensitive components of a PKI, and protecting it requires more than simply storing it in a container or database.
There are also operational and security aspects that would need to be reviewed before using this implementation in a production environment.
Nevertheless, the project demonstrates that a relatively small, independent ACME CA can interoperate successfully with Domino CertMgr.

go-acme-server – A Flexible ACME Foundation Written in Go

GitHub: https://github.com/misiektoja/go-acme-server
Documentation: https://misiektoja.github.io/go-acme-server/

The second project is particularly interesting.
Unlike a traditional standalone ACME CA, go-acme-server is designed as an embeddable Go library implementing the ACME protocol.
It separates ACME protocol handling from the actual Certificate Authority implementation.
This is a very attractive architecture because it allows developers to build virtually any kind of CA integration on top of the ACME protocol.

The library provides functionality for:

• ACME account and order management
• HTTP-01, DNS-01 and TLS-ALPN-01 challenges
• Certificate issuance and revocation interfaces
• Custom CA implementations
• Custom storage backends
• Integration with external services and approval workflows
   

The project also includes a quickstart example with a small embedded CA.
I extended this example with configurable listening addresses, an external ACME BaseURL, support for operation behind NGINX, real DNS resolution and DNS-01 validation.
With these relatively small changes, HCL Domino CertMgr successfully worked with the Go implementation as well, including DNS-01 challenges.
The example CA is intentionally temporary and uses in-memory storage. It is a development starting point rather than a production CA.

Why Go Makes This Particularly Interesting

Go is a modern programming language that is particularly well suited for network services and security-sensitive infrastructure.
It offers several advantages:

• Memory safety through managed memory and bounds checking
• A strong standard library, including TLS and X.509 cryptography
• Native concurrency and efficient network handling
• Small, self-contained binaries
• Straightforward container deployment
• Good cross-platform support
• A relatively small operational footprint
   

Of course, secure implementation and proper key management remain essential regardless of programming language.
But Go provides a very solid foundation for building a modern ACME service.

Beyond a Standalone CA

The real potential of go-acme-server is its extensibility.
The ACME server does not need to implement all CA functionality itself. Instead, certificate issuance can be delegated to a custom backend.
For example, an implementation could integrate with:

• An existing enterprise PKI
• A hardware security module (HSM)
• A custom certificate signing service
• An approval workflow
• An internal certificate inventory
• HCL Domino applications and services

For Domino environments, this opens up interesting possibilities.

A Domino application could manage certificate requests, approval policies, auditing and certificate inventory, while the Go service handles the ACME protocol and delegates signing to an appropriate CA backend.
Alternatively, a lightweight CA could be implemented directly in Go using its standard cryptographic libraries.
This makes the project much more than another ACME server. It provides a reusable foundation for building custom certificate management solutions.


Conclusion

Both open-source projects successfully interoperated with HCL Domino CertMgr in my tests.
The Python-based acme-ca-server demonstrates that a small private ACME CA can work with Domino, although additional security and operational work would be necessary before considering production deployment.

The Go-based go-acme-server is the more interesting project from an architectural perspective.
Its modular design makes it possible to integrate the ACME protocol with almost any certificate authority or PKI workflow.

Combined with Go's modern development model, security-oriented standard libraries and lightweight deployment options, this provides an excellent starting point for building custom ACME infrastructure.
For me, this is the most interesting outcome of the tests: ACME can be used not only to connect Domino CertMgr to existing certificate providers, but also as a standardized interface for entirely new PKI integrations.
Both projects are worth exploring, particularly for anyone interested in private PKI and automated certificate management.

• Comments [0]

Running NGINX on OpenWRT

My Slate7 (https://www.gl-inet.com/en-us/products/gl-be3600) runs OpenWRT.
It comes with NGINX for it's admin interface. But the NGINX version is pretty old and limited.

The Domino NRPC Proxy container image would work out of the box (https://github.com/nashcom/domino-nrpc-proxy).
There is Docker available for OpenWRT. But the image is too big for a small router like the Slate7..
Therefore I wrote another build script to statically link NGINX on Alpine.
This allows to run binaries on any machine with the same processor architecture.

Most OpenWRT routers run on arm64. Here is the binary.

There is a build option:

build.sh -static

The binary also has the NRPC stream module statically linked...

file nginx

nginx: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), static-pie linked, BuildID[sha1]=41561b747f07f246a6cea3f802efbf13228ea243, stripped

---

du -h nginx

7.8M    nginx

---

root@arm:/local/github/domino-nrpc-proxy/dist/static/nginx/aarch64# nginx -V

nginx version: nginx/1.31.8
built by gcc 15.2.0 (Alpine 15.2.0)
built with OpenSSL 3.5.9 29 Sep 2026
TLS SNI support enabled
configure arguments: --with-ld-opt=-static --with-compat --with-stream --add-module=.. --with-stream_ssl_preread_module --with-stream_ssl_module --with-stream_realip_module --with-http_ssl_module --with-http_v2_module --with-http_v3_module --with-http_realip_module --with-http_auth_request_module --with-http_stub_status_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_sub_module --with-http_slice_module --with-http_secure_link_module --with-threads --prefix=/tmp/nginx --sbin-path=/usr/bin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=stderr --http-log-path=/dev/null --pid-path=/tmp/nginx/nginx.pid

• Comments [0]

Running multiple Domino Servers on the same IP and NRPC port

For our DNUG Academy lab we need a secondary server for Domino IQ.
The 2nd server perfectly fit on the first machine and just got it's own Docker container and data directory.

But what about the IP address? One way would be to map them to different IP address.
There is an easier way. You can use a NRPC proxy module which works very similar to TLS SNI.

The NRPC Stream module allows mapping by name.
Below you find the extracted config.

Here is the GitHub project: https://github.com/nashcom/domino-nrpc-proxy


-- Configuration --

load_module /ngx_stream_nrpc_preread_module.so;

worker_processes auto;
pid /run/nginx.pid;

events {
  worker_connections 768;
}

stream {

    map $nrpc_preread_server_name $domino_target {
        yoda.academy.dnug.eu     127.0.0.1:1353;
        luke.academy.dnug.eu     127.0.0.1:1354;
        default:                 127.0.0.1:1;
    }

    server {

        listen 1352;

        nrpc_preread on;
        nrpc_preread_replacedots $NGINX_REPLACE_DOTS;

        proxy_pass $domino_target;
        proxy_connect_timeout 5s;
        proxy_timeout 1h;
        proxy_socket_keepalive on;
    }
}

• Comments [1]

eMudhra CA Key Compromise – how to remove the affected certs

The certs might be in different trust stores. Not all of them are in Domino admin's responsibility.
And there are many more applications to look into.

Maybe someone wants to provide all the information for Java in a similar way?
I am not a big Java fan. But Java in Notes/Domino works exactly the same way than any other application, which contains Java.

If you have questions let me know. If you run into bigger problems, I can also help remotely if needed.

I am going to look into the Linux trust stores next. But I would assume the Linux community is good at patching root certificates.
On Linux an easy test would be using curl. Same for Windows if it uses the right trust store.


I hope this helps a bit.

-- Daniel



cacerts.pem

In Domino the CA cert is in the current cacerts.pem in notesdata.
The current Domino server does not use the cacerts.pem file by default, but checks the Domino directory.

It would be still a good idea to remove the affected certs.
The cacerts.pem file is just a simple file, which you can edit or on clients deploy a new version.
That might be tricky if you don't have Mavel client or other software.
You would need to trigger some Lotus Script code for example.

Java Trust Store

In case of Java applications you would need to also patch or replace the JVM trust store.
Meanwhile the trust store is in PKCS12 (.p12) format. Even it is still named cacert with no extension and looks like the old JVM key store.

Removing and adding certs has been documented in many places.

Domino Directory

The Domino directory could contain the root too. I have checked in my Domino Directory and I can't find it.
Since it is a quite new root, it might not be in Domino Directory.


Finding out which roots to remove

There are actually two root certs which need to be removed.

1. The Affected root cert
2. An older already retired CA from Comodo

• I found the Comodo root in my Domino Diectory.
• But it is not listed in my current cacerts.pem.
• You might find it in older files. I got one but I did not check which version it belongs to. It was still on disk
  

I am listing the roots below for your convenience.

How to test your client

I wrote a small test button to check the cert. In my case I hit exactly this mixed situation where in one cacerts.pem the Comodo AAA Root cert was listed.
Removing the root made it worse, because then the Comodo cross cert was used.

This is only testing the newer Lotus Script HTTP Request class

The client has other ways for HTTP requests like the embedded browser used to display images.
This would need a separate test.


Root certificates you should remove


1. The mainly affected cert


emSign ECC Root CA - G3
=======================
-----BEGIN CERTIFICATE-----
MIICTjCCAdOgAwIBAgIKPPYHqWhwDtqLhDAKBggqhkjOPQQDAzBrMQswCQYDVQQGEwJJTjETMBEG
A1UECxMKZW1TaWduIFBLSTElMCMGA1UEChMcZU11ZGhyYSBUZWNobm9sb2dpZXMgTGltaXRlZDEg
MB4GA1UEAxMXZW1TaWduIEVDQyBSb290IENBIC0gRzMwHhcNMTgwMjE4MTgzMDAwWhcNNDMwMjE4
MTgzMDAwWjBrMQswCQYDVQQGEwJJTjETMBEGA1UECxMKZW1TaWduIFBLSTElMCMGA1UEChMcZU11
ZGhyYSBUZWNobm9sb2dpZXMgTGltaXRlZDEgMB4GA1UEAxMXZW1TaWduIEVDQyBSb290IENBIC0g
RzMwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAAQjpQy4LRL1KPOxst3iAhKAnjlfSU2fySU0WXTsuwYc
58Byr+iuL+FBVIcUqEqy6HyC5ltqtdyzdc6LBtCGI79G1Y4PPwT01xySfvalY8L1X44uT6EYGQIr
MgqCZH0Wk9GjQjBAMB0GA1UdDgQWBBR8XQKEE9TMipuBzhccLikenEhjQjAOBgNVHQ8BAf8EBAMC
AQYwDwYDVR0TAQH/BAUwAwEB/zAKBggqhkjOPQQDAwNpADBmAjEAvvNhzwIQHWSVB7gYboiFBS+D
CBeQyh+KTOgNG3qxrdWBCUfvO6wIBHxcmbHtRwfSAjEAnbpV/KlK6O3t5nYBQnvI+GDZjVGLVTv7
jHvrZQnD+JbNR6iC8hZVdyR+EhCVBCyj
-----END CERTIFICATE-----

#0
Root       : /C=IN/OU=emSign PKI/O=eMudhra Technologies Limited/CN=emSign ECC Root CA - G3
Not Before : 2018.02.18 18:30:00
Not After  : 2043.02.18 18:30:00 (expires in 16.3 years)

Serial     : 3CF607A968700EDA8B84
Sign Alg   : ecdsa-with-SHA384
KeyUsage   : CrlSign
Extensions : BasicConstraints, CA, SelfSigned, KeyUsage
Key        : ECDSA NIST P-384
ASN1 OID   : secp384r1


SubjKeyId  : 7C:5D:02:84:13:D4:CC:8A:9B:81:CE:17:1C:2E:29:1E:9C:48:63:42
SKI-SHA1   : 7C:5D:02:84:13:D4:CC:8A:9B:81:CE:17:1C:2E:29:1E:9C:48:63:42
SKI-SHA256 : CF:8B:70:15:7D:F6:C6:25:1C:22:90:20:CD:9B:3D:87:6B:E0:A1:FA:73:11:CC:46:19:31:F9:1A:67:D1:C4:B8

MD5        : CE:0B:72:D1:9F:88:8E:D0:50:03:E8:E3:B8:8B:67:40
SHA1       : 30:43:FA:4F:F2:57:DC:A0:C3:80:EE:2E:58:EA:78:B2:3F:E6:BB:C1
SHA256     : 86:A1:EC:BA:08:9C:4A:8D:3B:BE:27:34:C6:12:BA:34:1D:81:3E:04:3C:F9:E8:A8:62:CD:5C:57:A3:6B:BE:6B




2. Cross sing CA

The root CA is used to cross sign the  "emSign ECC Root CA - G3"  CA for legacy clients.

From the status of the cert you can see that it isn't a big loss to delete the root document as well.
And you have to remove it to be on the safe side! This is not optional.



Comodo AAA Services root
========================
-----BEGIN CERTIFICATE-----
MIIEMjCCAxqgAwIBAgIBATANBgkqhkiG9w0BAQUFADB7MQswCQYDVQQGEwJHQjEbMBkGA1UECAwS
R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHDAdTYWxmb3JkMRowGAYDVQQKDBFDb21vZG8gQ0Eg
TGltaXRlZDEhMB8GA1UEAwwYQUFBIENlcnRpZmljYXRlIFNlcnZpY2VzMB4XDTA0MDEwMTAwMDAw
MFoXDTI4MTIzMTIzNTk1OVowezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hl
c3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNV
BAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAL5AnfRu4ep2hxxNRUSOvkbIgwadwSr+GB+O5AL686tdUIoWMQuaBtDFcCLNSS1UY8y2bmhG
C1Pqy0wkwLxyTurxFa70VJoSCsN6sjNg4tqJVfMiWPPe3M/vg4aijJRPn2jymJBGhCfHdr/jzDUs
i14HZGWCwEiwqJH5YZ92IFCokcdmtet4YgNW8IoaE+oxox6gmf049vYnMlhvB/VruPsUK6+3qszW
Y19zjNoFmag4qMsXeDZRrOme9Hg6jc8P2ULimAyrL58OAd7vn5lJ8S3frHRNG5i1R8XlKdH5kBjH
Ypy+g8cmez6KJcfA3Z3mNWgQIJ2P2N7Sw4ScDV7oL8kCAwEAAaOBwDCBvTAdBgNVHQ4EFgQUoBEK
Iz6W8Qfs4q8p74Klf9AwpLQwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wewYDVR0f
BHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNl
cy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2Vz
LmNybDANBgkqhkiG9w0BAQUFAAOCAQEACFb8AvCb6P+k+tZ7xkSAzk/ExfYAWMymtrwUSWgEdujm
7l3sAg9g1o1QGE8mTgHj5rCl7r+8dFRBv/38ErjHT1r0iWAFf2C3BUrz9vHCv8S5dIa2LX1rzNLz
Rt0vxuBqw8M0Ayx9lt1awg6nCpnBBYurDC/zXDrPbDdVCYfeU0BsWO/8tqtlbgT2G9w84FoVxp7Z
8VlIMCFlA2zs6SFz7JsDoeA3raAVGI/6ugLOpyypEBMs1OUIJqsil2D4kF501KKaU73yqWjgom7C
12yxow+ev+to51byrvLjKzg6CYG1a4XXvi3tPxq3smPi9WIsgtRqAEFQ8TmDn5XpNpaYbg==
-----END CERTIFICATE-----



#0
Root       : /C=GB/ST=Greater Manchester/L=Salford/O=Comodo CA Limited/CNªA Certificate Services
Not Before : 2004.01.01 00:00:00
Not After  : 2028.12.31 23:59:59 (expires in 2.2 years)

Serial     : 01
Sign Alg   : sha1WithRSAEncryption
KeyUsage   : CrlSign
Extensions : BasicConstraints, CA, SelfSigned, KeyUsage
Key        : RSA 2048 bit

CRL        : http://crl.comodoca.com/AAACertificateServices.crl, http://crl.comodo.net/AAACertificateServices.crl

SubjKeyId  : A0:11:0A:23:3E:96:F1:07:EC:E2:AF:29:EF:82:A5:7F:D0:30:A4:B4
SKI-SHA1   : A0:11:0A:23:3E:96:F1:07:EC:E2:AF:29:EF:82:A5:7F:D0:30:A4:B4
SKI-SHA256 : CA:34:12:34:2C:B2:FE:91:4A:E1:82:B3:2A:5C:49:4B:B9:82:E6:47:B5:69:C5:27:70:C4:84:51:5F:CC:5E:E2

MD5        : 49:79:04:B0:EB:87:19:AC:47:B0:BC:11:51:9B:74:D0
SHA1       : D1:EB:23:A4:6D:17:D6:8F:D9:25:64:C2:F1:F1:60:17:64:D8:E3:49
SHA256     : D7:A7:A0:FB:5D:7E:27:31:D7:71:E9:48:4E:BC:DE:F7:1D:5F:0C:3E:0A:29:48:78:2B:C8:3E:E0:EA:69:9E:F4




Domino Directory entry to delete




Example Lotus Script code


Sub Click(Source As Button)
     
      Dim session As New NotesSession
      Dim req As NotesHTTPRequest
      Dim url As String
      Dim response As Variant
     
      url = "https://dv-g3b-aaa-emudhra.we-have-a-problem.com/"
     
      On Error Goto RequestError
     
      Set req = session.CreateHTTPRequest()
      req.Timeoutsec = 15
      req.Maxredirects = 0
      req.Preferstrings = True
     
      LogMsg "Testing: " & url
     
      response = req.Get(url)
     
      LogMsg "TLS connection succeeded"
      LogMsg "HTTP status: " & Cstr(req.Responsecode) + " Data: " + response
      Exit Sub
     
RequestError:

      LogMsg "Request failed"
      LogMsg "Error: " & Cstr(Err)
      LogMsg "Description: " & Error$
     
      Exit Sub
     
End Sub

• Comments [3]

Domino Container - Relace Domino and JVM cacerts

The Domino container image had certificate management for a while already.
But it was intended to add certificates and not remove them.

Removing certificates could be tricky. There are commands to do it.
But you have to hit the right certs in an automated way.

The new option allows to provide your own curated certificate list which will be always set when you provide it.
The functionality to add certificates still remains. The file will be replaced first and then the optional addition to the trust stores is executed.

What I am not changing is the Linux trust store.
Usually customers should build their specific base image with their OS level changes which are usually company wide.
So I am staying away from it for now unless someone has a strong requirement for it.

Different distributions have their own way to manage certs.
I added a cert addition. So I could build the replacement.

The container Linux layer is usually not used for any directly for client connections.

You find the documentation here:

https://github.com/HCL-TECH-SOFTWARE/domino-container/tree/main/dockerfiles/install_dir_domino/custom


-- Daniel

• Comments [0]

eMudhra CA Key Compromise – Why This Is a Serious Security Issue

On October 17, 2026, a serious security issue involving eight eMudhra intermediate Certificate Authorities (CAs) was reported.
The private signing keys of these CAs were generated with extremely weak randomness and can be recovered from publicly available information.

This means anyone who knows these keys can issue certificates for virtually any domain, not just domains previously using eMudhra certificates.

An attacker able to intercept network traffic could present a forged certificate for a legitimate website or API endpoint.
A vulnerable TLS client might accept that certificate as trusted, allowing the attacker to impersonate the server and potentially read or modify encrypted traffic.


Why Revoking Existing Certificates Is Not Enough

The compromised intermediate CA certificates have been revoked. However, revocation only protects clients that actually check and enforce it.
Many TLS implementations do not check certificate revocation by default. They validate the certificate chain against trusted root certificates but may never discover that an intermediate CA has been revoked.

As long as a client continues to trust the affected certificate chains without effective revocation checks, newly forged certificates can still be accepted.


What Administrators Should Do

There are two important actions:

1. Update trust stores and remove trust in the affected CA chains. This includes operating systems, applications, runtimes and containers. Removing an entire root CA may be necessary where more targeted distrust mechanisms are unavailable.
2. Verify certificate revocation handling. Ensure applications enforce revocation or another reliable mechanism for rejecting compromised CA certificates. Do not assume that certificate chain validation alone is sufficient.

Where to Check

• Browsers: Chrome, Firefox, Edge and Safari have already deployed protections.
• Operating systems: Windows, Linux and macOS trust stores need to be considered.
• Mobile devices: Android and iOS have received protections, but application-specific TLS implementations may behave differently.
• Applications: Java, OpenSSL, Go, Python and other runtimes may use independent certificate stores or verification mechanisms.
• Containers: Updating the host does not automatically update certificate bundles inside container images.

What About HCL Domino?

Domino administrators need to consider multiple certificate stores:

• cacerts.pem in notesdata directory: Contains affected trust anchors and needs to be reviewed and updated.
• Java cacerts: The bundled JVM uses a separate certificate trust store. Its contents and revocation behavior need to be verified for the specific Domino release.
• Domino Directory: The standard Domino Directory does not contain these public CA roots by default.
• Operating system: Linux and Windows certificate stores may be used by other applications and components running alongside Domino.
• certstore.nsf: Only contains Let's Encrypt roots by default and would only need to be checked if you added those roots

Updating one trust store does not necessarily protect applications using another.

How Can You Test Your Systems?

Dennis Jackson has published an excellent resource explaining the incident, providing cryptographic proof of the compromised keys and offering live tests for TLS clients.

https://emudhra.we-have-a-problem.com/


The tests can help determine whether a particular TLS client still accepts certificates issued through the compromised CA chains.
A successful test with your browser or curl does not automatically mean that other applications on the same machine are protected.

The most important lesson: Trusting a root CA without reliable revocation handling means trusting every certificate that can be issued through its subordinate CAs — including certificates signed with compromised keys.

Maybe we should start looking into the CA bundles we trust more closely. That's probably something to look at after this is resolved.
A while ago I looked into the list of root certs in trust stores. Usually vendors use the trust stores of the security stack they use (libcurl, JVM, etc).

• Comments [2]

Running Nomad Web on Ubuntu Touch Phone in a Container

This is the next level working with an Ubuntu Touch phone.
I have crafted an Ubuntu X Window Docker container and added RDP support.
Now I can RDP into my Ubuntu phone and start Nomad web in Firefox.

All the components are running on the same phone and there is still room for mow applications.

What I have tested first are the most challenging parts.
Normal Docker containers will be much easier to deploy.

I have an Yubikey working inside a container. And there are many other ARM applications in a Docker container which will work out of the box.
The Desktop container was built on another ARM machine and pulled down to the phone.

• Comments [0]

Ubuntu Phone - Checking CPU state and power consumtion

It is getting more interesting. The phone has 8 CPU cores.

- 4 Efficiency cores
- 4 Performance cores with a prime core with a bit more power

You can turn off individual cores. But that does not change idle power consumption.

ChatGPT wrote a nice script for me to include also battery and USB status.
That's pretty cool for performance / efficiency spelunking.

In my case I hooked up the phone with a power bank:

Turning off CPUs does not make a big difference. It looks like the kernel is pretty effective.

I might later tune maximum CPU frequency.
And I might add scripts to a GitHub project later.

What I found so far is pretty interesting.
I have a second script which shows the CPU/power information per interval.

• Comments [0]