We came across an issue with some Java code that uses the Apache HTTP client to access another resource on the same Domino server. It's basically an agent that collects stuff from other NSFs using an HTTP request. This works perfectly as long as your server works with a custom wild card SSL certificate from a "common" certificate authority. However, when you are using the Let's Encrypt certificate that you get using Domino's CertMgr, your code may stop working as the HTTP request will fail with an error like this:

If you are running Sametime V11 or earlier and want to upgrade to Sametime 12, you have two options. They start from scratch with a clean install (sometimes it’s worth it) or migrate existing Sametime to the new Sametime 12. I have prepared a short guide on how to migrate the contact list (vpuserinfo.nsf) of your users and I have also added the option to convert from native Domino Directory to LDAP, which is a condition for migration to Sametime 12.

In my last post, I talked about how I implemented a partial Jakarta NoSQL driver using the AppDev Pack as a back end instead of the Notes.jar classes used by the primary implementation. Though the limitations in the ADP mean that it lacks a number of useful features compared to the primary one, it was still an interesting experiment and has the nice side effect of working with essentially any Java app server and Java version 8 or above. Beyond the Proton API calls, the driver brought up the interesting topic of handling authentication. Proton has three ways of working in this regard: Anonymous, which is what you might expect based on how that works elsewhere in Domino. This is easy but not particularly useful except in specific circumstances. Client certificate authentication, where you create a TLS keychain for a given user and associate it with a Directory user (e.g. CN=My Proton App/O=MyOrg), and then your app performs all operations as that user. This is basically like if you ran a remote app with NRPC using a client Notes ID. Act-as-User, which builds on the above authentication by configuring an OAuth broker service that can hand out OIDC tokens on behalf of named users. This is sort of like server-to-server communication with the "Trusted Servers" config field in the server doc, but different in key ways.

No IT solution is delivered using code written solely by the solution provider. There is always dependent code written by a third party. Dependency management tooling has proliferated in every technology sector to support this. And every solution includes an implicit assumption that the dependent code will continue to work as it does and provide whatever the consumer requires. And the brutal truth for consumers is that the authors of your dependencies did not write their code knowing your requirements up front. Whether or not it fits your implementation falls in the realm of “caveat emptor”. If it doesn’t, if you need an enhancement or you find a bug, your priorities may or may not align with the priorities of the owners of that dependency. With a product, you’re just one paying customer. With open source, you’re just one consumer - not even a customer.

Four weeks on from the last code drop HCL today released 12.0.2 EAP Drop 5Headline items for me: Domino Restyler is available out of box in the Notes client as opposed to the last drop in Nomad. (Note: a very informative getting started video with Domino Restyle from the Cross Canada Collaboration User Group is here ) We get a new version of the Admin/Designer 64 bit client. (that’s not to say we don’t get versions of all other client, we do) The Notes client on Mac runs on 12.6 Monterey (though won’t perfectly until GA)

If you are using DOTS in Domino 12.x, you might have seen some NullPointer Exceptions after you have updated a DOTS plugin. Recommendation was to delete the complete workspace-dots folder prior to starting DOTS after the upgrade. This issue has been addressed in SPR# SJAAC3BNWV: DOTS – Workspace need to be deleted on every change and add of new plugin. With this fix it is no longer necessary to delete the workspace-dots folder. Not sure, when the fix was provided. There is no information about it in the fix list database. But this is only true for Domino on WINDOWS. If you are using DOTS with Domino on LINUX, you will see an error on the Domino server console ( “An error occurred while processing the command”) or even worse, the NullPointer Exceptions. The problem is that the underlying API in Domino does not delete files starting with a dot. (hidden files on UNIX systems).

One Touch setup (OTS) is quite powerful tool. But sometimes you need to know exactly what happens and combine functionality to make best use of it. With Domino 12.0.2 OTS creates certstore.nsf automatically and you can let it create a MicroCA for you. But what if you want to use a Let's Encrypt certificate instead? There is a quite simple way to just find and update the existing document with a appConfiguration. And if you specify notes.ini CertMgr_ACCEPT_TOU=1 the ACME account license agreement will be automatically accepted (already part of 12.0.0).

You should pay special attention to the infrastructure that keeps the entire IT system running. Especially, at the beginning of your journey to HCL Nomad Web. That’s important, because it must meet all security standards to ensure the smooth operation of HCL Nomad Web. We will therefore take a look at what we actually need for the infrastructure for HCL Nomad Web.

Though the bulk of the work I've been doing for the XPages Jakarta EE project is to bring JEE technologies to Domino, the NoSQL driver has been designed to lead a double life: it works in an XPages context, but it's written to not have any XPages dependencies. One reason for this is that I want it to be usable if you use, for example, the Open Liberty runtime project to side-car apps on a Domino server but still use Notes.jar for data access. Another reason for its organization, though, is that I intended for the driver to be portable across implementations. The driver itself is split into a main bundle and a ".lsxbe" implementation bundle. My original thought was to make that ready for a JNX or Domino JNA implementation, but it's pretty flexible.

Usually OpenSSL is the tool of choice for all type of certificate operations. But what if no OpenSSL command line is available? Like in a Domino container where you can't install software? After some research, I came up with the keytool, which is part of the JVM Domino ships.