While no platform is immune to the possibility of hacking, the question I would pose is: Has your Domino infrastructure ever been hacked? Didn’t think so. It’s probably boring to say that the most straight forward answer is HCL Domino is rock solid on security. When set up correctly and optimised, HCL Domino is the most secure platform of its type. It’s true though. Reliable and secure is a good thing. A very good thing.
![]()
The HCL Domino v12 beta is out now. If you haven’t already tried it, it’s free for all existing licensed Domino customers. It’s waiting there in flexnet for you to download and try it out! It’s the first time a beta of this type is in existence and it has multiple interactions (we’re currently on beta 2; beta 3 is scheduled for the end of March. Register here to join us for the beta 3 webinar.
What I really love about it is the almost instantaneous feedback from the beta forum, from those in charge of development. Domino v12 is scheduled for full release in Q2 of this year. (June 2021 timeframe is given at the moment).
Read an overview of what’s coming here.
Here’s is a list of all the NEW NATIVE security features coming in Domino v12 and there’s a whole host of them:
- Automating certificate management
- Time-based one-time password (TOTP) authentication
- Enforce internet password lockout based on IP address
- TLS 1.0 is disabled by default
- Support for PEM-formatted TLS host keys and certificates
- Two new curves supported for TLS 1.2 ciphers that use ECDHE for forward secrecy
- New template signing ID uses 2048-bit keys
- NRPC port encryption supports forward secrecy using X25519
- Import internet certificates that contain unsupported critical extensions
- Suppress key rollover alerts during ID vault synchronization
- New Query Vault command options
- Support for SameSite cookie
Also note native support for DKIM is planned in the 12.0.x timeline. (Again natively, you can achieve DKIM with third party mail gateways).
We could argue about which are the best and more important ones here, but I’m going to concentrate on the 4 new security features in Domino v12 that you’re going to want to implement straight away:
- Automating certificate management
- Time-based one-time password (TOTP) authentication
- Two new curves supported for TLS 1.2 ciphers that use ECDHE for forward secrecy
- NRPC port encryption supports forward secrecy using X25519
Note: these are all based on current plans at beta 2, some of these will be subject to change (for the better) come beta 3 and GA.
What is it?
Automating certificate management?
What does it give you?
This topic could probably be four killer new features in one on its own, because it includes so much.
The short answer here is it takes something that was a headache to most admins and makes it completely seamless and automatic. It also includes support for ECDSA which is very progressive in terms of offering support for cutting edge security (some browsers don’t even support it yet).
In order to explain the context here, we probably need a short history lesson on cert management in Domino. Prior to SHA-2 being the supported, Domino managed certs via a Domino database. It did exactly what it said on the tin and was never really updated from the time of release. But it worked. There were only four steps listed in the database. Some customers did find it fiddly.
Then SHA-2 support for Domino came out and admins did not like how this was implemented. Again, it’s Domino, so it was secure, and it worked, but the process was a headache. I have to admit for 99 percent of our customers, I just did it for them to save them the hassle so I got used to it. But you did need a kyrtool, you’d need to install Openssl, you’d have to copy and paste various commands, copy parent and intermediate certs into text files. It was messy to implement.
Well that’s gone.
What’s in its place is the most straight-forward solution one could imagine.
![]()
Let’s Encrypt offers free third-party SSL certs. They’re currently the most widely used Certificate Authority in the world and work with all major browsers (they’re sponsored by some of them).
You can now get Let’s Encrypt Certs in Domino, by filling in a couple of fields in a form. In short saying, “I want a cert for my website. Give me one now.” And it will give you one straight away. In seconds, your web server will be running with that cert. A new task called CertMgr manages it all.
![]()
“It can’t be that easy,” I hear you say. Well, in most use cases, it is.
Wildcard certs are slightly different, but again it’s as easy as it can be. Other third-party certs are still 100 per cent supported, and easier than ever to implement with the Certificate Store.
Another point you might have missed around this is CertMgr supports Elliptic Curve Digital Signature Algorithm (ECDSA) using the NIST P-256 and NIST P-384 curves. Not all browsers support this yet (most do), but in short it has the potential to give quicker and more secure TLS connections and shows that HCL are ahead of the curve #badnerdpun.
How do you implement it?
There are a lot of options available here but I cannot over emphasise how straight forward this is to implement.
CertMgr runs as a task. The first time you load it builds a back-end Domino database. The database has intuitive forms but there’s documentation just in case. You create a free account with Let’s Encrypt with a couple of clicks within the database.
I don’t want to get too bogged down in the detail here, because you don’t actually need to know the back ground details, but there a couple of ways Let’s Encrypt will verify you’re the owner of the domain, either by HTTP response (the most straight forward I think, but requires that the server can initiate outbound HTTPS requests – even temporarily to Lets Encrypt) or via DNS Response.
The HTTP response in particular is VERY easy to setup.
Third party certs are managed via the database, so you won’t have to fiddle about with openssl and the kyrtool.
ECDSA is a more complex subject, but the steps to implement are relatively straight forward here, the main complicating factor here is managing browser support, there’ll be more of this in beta 3 (thanks to Daniel Nashed for answering some of my basic questions on this. Follow Daniel’s blog for more expanded detail on these subjects).
What is it?
Time-based one time password (TOTP) authentication
What does it give you?
Firstly, the obvious point here is you’ve been able to do TOTP in Domino for a long time, but it required third party software or appliances. Here we get TOTP natively within Domino.
What is TOTP? Well, it’s two factor authentication based on a time based password that changes. You put an app on your device that manages a six figure pin that changes every 60 seconds and it associated with a specific account.
Here you can deploy here with any number of apps (I’ve used Google Authenticator and OpenATP with Domino12 extensively for a couple of months and both have worked perfectly).
How do you implement it?
It’s easy.
You set up a trust relationship with your ID Vault and TOTP.
You enable it on the configuration settings document and then either web site, server or virtual server document.
You’ve to do a once off configure on the login form (but there’s a template for you to use, so it’s two minutes work for a non-developer).
Restart Domino and you’re ready to go.
Each user does a self-enrolment process the first time they connect which is intuitive, and takes no more than a couple of minutes.
![]()
There’s more functionality coming on this with Directory Assistance and managing multiple domains so watch this space.
What is it?
Two new curves supported for TLS 1.2 ciphers that use ECDHE for forward secrecy
What does it give you?
Better performance on Perfect Forward Secrecy.
Perfect Forward Secrecy has been available since Domino 9.0.1 FP3 IF2. It gives assurances session keys will not be compromised.
This new set of two new elliptical curves (once forward secrecy is set up) can offer better performance. The two new curves are X25519 and X448.
How do you implement it?
You do nothing. If you don’t want it you need to actively turn it off with a notes.ini setting. Domino 12 will attempt to use supporting curves in the following order
- X25519
- NIST P-256
- X448
- NIST P-384
- NIST P-521
What is it?
NRPC port encryption supports forward secrecy using X25519
What does it give you?
This sounds very similar to the last one, but there’s a whole lot more to unpack here. These are for Domino to Domino connections over port 1352 or Notes client to Domino connections over port 1352.
So if you’ve ports with encryption turned on (which nowadays we are recommending to everyone), with Domino 12 the level of encryption increases from:
- 128 bit AES-GCM for network encryption and integrity protection and 128 bit AES tickets
To:
- 256 bit AES-GCM for network encryption and integrity protection, X25519 for forward secrecy, and 128 bit AES tickets.
Basically stronger, encryption, better protection for sessions with forward secrecy and a curve that gives the best performance.
How do you implement it?
This is one of those points of different between Domino and Notes clients and ANY other technology. (i.e. as opposed to the Office365 hacks, which are being put down to weakness in how Microsoft authenticates out of box). Certs are baked in. Basically if you have port encryption turned on, this will turn on by default. If you don’t have them, turned on you can just enable encryption on the ports (for all inter server traffic), and via a policy for Notes clients.
In any other technology this would be so much more complex to do. You’d need multiple devices to manage the connections, you’d have to change the port numbers, probably have to allow that port in a firewall plus you’d need to manage certs with third parties. With NRPC, you’re already using certs to connect in so it’s just saying encrypt the port. The same port (1352) is in use whether encrypted or not encrypted, so no further changes are required on the network or firewalls etc.
![]()
Oh and that’s only NEW and NATIVE features in Domino 12. I just have to mention one more briefly that is no-charge to all entitled CCB customers. It’s HCL SafeLinx. It is already available and in the wild. It supports both HTTP and Notes port connections out of the box as a reverse proxy. If you already user HCL Nomad you’ll probably know about it. Later this in 2021, HCL Nomad Web will be out and you’ll look into this more then. (It can also be used for Sametime, Traveler and Verse – there’ a webinar on this coming up). It builds upon the layers of native Domino security and gives you flexibility to add extra layers of security, particularly for external connections. The main advantage is that it’s got baked in functionality for Domino so you don’t have to reinvent the wheel to do a basic set up.
I hope you enjoyed my first blog for HCL.
As always please provide feedback if you found anything interesting here.
Cormac McCarthy – Domino People Ltd
![]()