A few weeks ago I had to update the certificates used by Sametime for a customer. Since they use LetsEncrypt certificate, I had set the renewal to be automatic, but it did not happen. I started looking at the issue with the invaluable help of my friend and Sametime guru Carsten Gericke and after digging in a bit we found the solution.
First of all, there are two things to take note of:
1) When using LetsEncrypt, Sametime does not use the certificates in the /sametime/sametime-config/web/keys but those in the /sametime/sametime-config /web/acme-certs/server.domain.com directory, for example /sametime/sametime-config/web/acme-certs/st.eld.it
2) Now LetsEncrypt creates by default certificates with ECDSA keys rather than RSA keys.
In 12.0.3, in the /web/acme.sh directory there are two directories st.eld.it and st.eld.it_ecc, those directories are where the certificates requested to LetsEncrypt are stored The first one contains the RSA certificates the second one the ECDSA certificates
The problem with upgrading the certificates in 12.0.3 is that if Sametime, specifically the nginx container, that uses certbot, finds that the st.eld.it directory exist, it tries to install the certificates from there to the /sametime/sametime-config/web/acme-certs/st.eld.it. But now the new certificates are in the ../st.eld.it_ecc directory and the ../st.eld.it directory contains still the old files.
This problem does not happen in a new installation of ST 12.0.3 because the directory used to store the RSA certificates does not exist anymore, it happens when you upgrade from a previous version to 12.0.3.
The solution to this problem is to delete the /sametime/sametime-config/web/acme.sh/st.eld.it directory. Doing so will make certbot look only for the directory with the ECDSA certificates, ../st.eld.it_ecc. The certificate from that directory will be installed in the ../web/acme-certs/st.eld.it directory and everything will work.
Looking at the nginx container log you should see this
[Tue May 19 14:17:02 EDT 2026] Your cert is in: /config/acme.sh/st.eld.it_ecc/st.eld.it.cer [Tue May 19 14:17:02 EDT 2026] Your cert key is in: /config/acme.sh/st.eld.it_ecc/st.eld.it.key [Tue May 19 14:17:02 EDT 2026] The intermediate CA cert is in: /config/acme.sh/st.eld.it_ecc/ca.cer [Tue May 19 14:17:02 EDT 2026] And the full chain certs is there: /config/acme.sh/st.eld.it_ecc/fullchain.cer [Tue May 19 14:17:02 EDT 2026] Run post hook:’if [[ -d /run/service/nginx ]]; then s6-svc -u /run/service/nginx; fi’ [Tue May 19 14:17:02 EDT 2026] The domain ‘st.eld.it’ seems to have a ECC cert already, lets use ecc cert. [Tue May 19 14:17:02 EDT 2026] Installing key to: /config/acme-certs/st.eld.it/key.pem [Tue May 19 14:17:02 EDT 2026] Installing full chain to: /config/acme-certs/st.eld.it/fullchain.pem
Once again the community has got together for the annual Engage event.
This was the second managed by Kris and Tom and it’s clearly visible that they are improving and following Theo’s path, which is not easy at all.
The venue was, as usual, not conventional. The stadium of the KAA Gent football team. When you attended the session on the third floor you were looking right at the field, impressive!
Attendance was up from the previous year, which is a very good sign, not only there were the usual suspects, is nice to meet again friends from other countries, but also several first-timers and students.
Not surprisingly there were several sessions where AI was the topic, I feared that this trend would restrict the sessions to be interesting only for developers, but it turned out I was wrong, there were sessions where the speaker showed how to use AI in order to make Domino administration easier, a very good thing in my opinion.
It was good to see that AI has moved from being just the trending buzzword to a technology that can be used to achieve good results also in our space.
I helped Keith Brooks in setting up the room for his remote session, and we found some issues in connecting the monitor to the laptop. We solved it using one of the most advanced techniques available. Power off the monitor and power it on again. Guess what ? It worked.
Our session was on a very specific topic, so when I saw about a dozen people attending I was very happy, especially considering that in the room there were some of the most experienced people in the community that work with Sametime.
As OpenNTF, we officially launched our last project, the LotusScript Class Map, which was received very well by the developers attending the event. More details on our website https://www.openntf.org
One of the best moments overall was when at the “Ask HCL” session, Tom showed up on stage. It was really great to see him in person again. We all wished him well for his recovery after surgery and I am sure he will do again a great job with Kris next year.
If you want to have SSO between Domino and Sametime 12.0.1 FP1 or above you need to create the Web SSO document in Domino using “LTPA Token 2” as token format, instead of “LTPA Token and LTPA Token2” as was common in previous versions of Sametime. This because HCL, starting with Sametime 12.0.2 FP1 disabled LTPA V1 token support by default – in favor of LTPA V2 which is more secure.
On the Sametime server open the file custom.env and make you see this at the end ENABLE_LTPA=true LTPA_KEYS=C:\Sametime\ltpa.keys <- replace with the location of your LTPA key file LTPA_KEYS_PASSWORD=XXXXXX <- replace with your key password
Open the sametime.ini file and change the line
ST_AUTH_TOKEN=Jwt (this is the default) to ST_AUTH_TOKEN=Fork:Jwt,Ltpa
A customer of mine ran into an issue when using his Sametime server for meetings with external companies. The participants could not see any video neither hear audio.
Since internally everything works perfectly and he is using a TURN server, we started looking into its configuration and logs. We didn’t find anything wrong and the logs reported no errors. Then, after finding that until circa one month ago everything was working fine, he remembered that since then, he changed the coturn certificate from a single LetsEncrypt certificate to a wildcard one he gets from a CA for his company.
So he switched back to the LetsEncypt certificate, and everything started working again. Upon looking in the coturn GitHub repository he found this https://github.com/coturn/coturn/issues/352 Turns out that coturn does not support wildcard certificates, and looking at the thread on GitHub is likely it will not do it in a foreseeable future.
I have suggested HCL to improve their documentation, mentioning this; even if I understand this is not a HCL issue, adding a warning not to use wildcard certs could be useful.
As I wrote in a previous post I will speak at Engage 2026.
But I am not the only one from OpenNTF that will have a session there, my colleagues in the Board will have sessions there too. This pictures shows the content that we are delivering at Engage, as you can see there’s something for both developers and admins.
Hope to see many of you there, and if you have any questions about the OpenNTF activities, or any request, or you want to help, just grab one of us and let’s talk!
I had the honor and the privilege of having a session accepted at Engage 2026.
I will speak, together with my usual partner-in-crime, Marianna Tomasatti, about the difference in configurations of Sametime Chat Server on Docker and on Windows.
Sametime Chat on Windows Tue, Apr 21- 16:05–16:30 – Room A Sametime chat on Windows offers the same features as Sametime on Docker/Kubernetes; however, configuration and customization are performed differently, and the files you need to edit are not the same.In this session, we will explain how to configure LTPA, SSO, and other tips and tricks.
While working for a customer, who has Sametime Chat on Windows and uses only web access to mail, I found a bug in Sametime. I opened a case and HCL could reproduce it; they created a Technote, KB0127919, for it. Hopefully will be fixed soon.
The time-to-live (TTL) setting defines how long the chat history is stored in the database. The default value is 90 days.
The instructions on how to change it in the official documentation unfortunately refer only to Docker and Kubernetes deployments and do not cover the Windows-based chat-only server.
On a Windows Server, you don’t have to edit the file custom.env, as you would in Docker or Kubernetes; instead, you need to edit the file chatlogging.ini. Add at the end of the file this value: CL_MONGO_HISTORY_TTL=30 where 30 is the number of days you want to keep the chat history.
Then follow the instructions in the documentation to delete and recreate the Mongodb indexes. Open a mongo shell and type the following commands use chatlogging db.EVENTS.getIndexes() [here the default value should be 7776000] db.EVENTS.dropIndex(“TimeStamp_1”) db.USERS.dropIndex(“date_1”)
Restart the Sametime server and check again the value of the EVENTS index for TimeStamp_1, should be 2592000 in my case of 30 days.
