HCL Domino V12 Key Security Features Overview

Copyright © 2021 HCL Technologies Limited | www.hcltech.com
Domino 12
New Security Features Overview

About Us
Hemant Naik
Speaker / Product Support Lead
Vinayak Tavargeri
Organizer / Senior Manager
Rajendran Jayavel
Panelist / Senior Technical Architect
Shrikant Jamkhandi
Panelist / Group Technical Specialist
Rajib Manna
Panelist / ND,Sametime, SCN Consultant
Chaitanya Yalavarthy
Speaker / Technical Lead
Meet the Team
Rahul Kumar
Panelist / Senior Technical Architect

Copyright © 2021 HCL Technologies Limited | www.hcltechsw.com
Agenda
• HCL Domino 12 Security Overview
• System Requirements
• Brief introduction for TLS
• Enforce internet password lockout based on IP address
• Two new curves supported for TLS 1.2 ciphers that use ECDHE for forward secrecy
• 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 Web server login form
• Time-based one-time password authentication Overview
• TLS 1.0 is disabled by default, Support for PEM-formatted TLS host keys and certificates
• New template signing ID uses 2048-bit keys
• New Query Vault command options. Upload IDs to the vault manually
• Support for SameSite cookie
• Web server GET /names.nsf?Login requests prevented by default
• References
• Q&A

HCL Domino 12 Security Overview
4
Key security features and enhancements introduced with V12 which are expected and requested from our customers.
• Automating certificate management (request for Let’s encrypt certificates from with in Domino)
• Internet lockout based on IP address and validation of IPs in X-Forwarded-For header.
• Domino administrators can specify PEM files directly in Server document or Web Site document.
• Two new curves(X25519, X448) which are mandatory for key exchange protocol in TLS 1.3 are supported for TLS1.2
Ciphers that use ECDHE for forward security.
• Enabled Forward security using X25519 for NRPC protocol.
• Two-factor authentication can be enabled for web users.

HCL Domino 12 System Requirements
5
Supported Operating System:
The Docker-compatible Red Hat Universal Base Image (UBI) provided with Domino 12 is supported running in the RHEL/CentOS 7.5 UBI
or the RHEL 8.0 UBI on Linux versions supporting Docker (RHEL/Centos OS 7.5 or equivalent Linux OS).
Reference : https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0086047

Improved TLS Certificate Management
6
New server task (CertMgr) is introduced to work with a new Certificate Store (certstore.nsf) database. This feature
helps to save customer’s time and money for the creation of TLS certificates
• CertMgr and certstore.nsf are to completely automate requesting, configuring, and renewing free, from the Let's
Encrypt® certificate authority (CA).
• Components of certificate management.
Certificate Manager (CertMgr) server task.
Certificate Store database (certstore.nsf)
CertMgr DSAPI
• Domino continues to support using OpenSSL and KYRTool to generate certificates in a keyring file, the method
available prior to Domino 12.
• Certificate Manager is a much easier process and is recommended.
Please Note that certificates generated through Certificate Manager are securely stored directly in TLS Credentials documents in
certstore.nsf rather than in keyring files on disk.

Copyright © 2021 HCL Technologies Limited | www.hcltechsw.com 7
 Certificate Manager(CertMgr) Server task
• CertMgr task runs on one master server in a Domino Domain to perform certificate management requests.
• Add CertMgr to servertasks parameter on notes.ini to start task.
ServerTasks=Replica,Router,Update,AMgr,Adminp,Sched,CalConn,RnRMgr,HTTP,CertMgr
• The first time CertMgr task runs on Domino server, it creates the Certificate Store database(certstore.nsf).
• CertMgr can be run on Domino V12 Windows 64bit and Linux 64bit platforms, including containerization platforms
such as Docker.
- AIX and OS400 can still leverage certstore.nsf by creating manual replicas.
• Starting the certmgr task on any additional server in the domain creates a replica copy of certstore.nsf from master
server.
- Each additional server act like a “CertMgr client” and will just replicate certstore database every 2 minutes

 Certificate Store database (certstore.nsf).
• This database provides the interface to request,
store, and distribute certificates in a secure way.
• The database contains predefined Let's Encrypt®
ACME account documents that include the trusted roots
needed for certificates issued from the Let’ s Encrypt
certificate authority.
• The database can be replicated to any Domino
server that runs Domino V12.

Enforce Internet Password Lockout based on IP Address
9
One of high weightage enhancement feature by HCL Domino customers to enforce lockout based on IP addresses to
stop attacks.
 Enforce internet password lockout based on IP is to lock users who are not in Domino directory.
 IP based Internet lockout feature is to detect & prevent Denial of Service (DoS) attacks.
 If custom DSAPI filters are in use, you may not be able to leverage the functionality of IP based lockout. If
doesn’t work in your env, disable DSAPI and retry.
 For Single Sign-On, Domino server on which the Internet password lockout feature is enabled must also be the
server that issues the single sign-on key.

10
Configuration of Internet password lockout based on IP address
 Enable “Count user name failures also as IP address
failures” to count as IP login failures if login failed
with user name in NAB.
 In Server Configuration Document -> Security tab ->
Internet Lockout section -> Also enforce lockout
based on IP address
 “Locked Out Users” view is updated with new name
“Locked Out Users/IP Addresses.
 Title Changed from “UserName” to “User Name/IP Address”.
UI changes in inetlockout.nsf database:

 Enable “Also enforce lockout based on IP address” only to add failed login attempts count against users in NAB.
Note: Failed logins attempts of user in NAB will not be counted against IP Address.
NAB user failed to authenticate with Domino HTTP server:
Only User Name failed attempt count is added.
External user failed to authenticate with Domino HTTP server:
Only IP address attempt failed attempt count is added.

 Enable “Count user name failures also as IP address failures” also to add failed attempts of users in NAB against
respective IP.
Note: it may be necessary for the administrator to look multiple places when the lockout is due to the User Name and/or the IP Address.
NAB user failed to authenticate with Domino HTTP server:
Both User Name and IP Addresses are added/increased in failed attempts.
External user failed to authenticate with Domino HTTP server:
Only IP address failed attempt count is increased

X-Forwarded-For header validation with trusted Proxy IP list
13
 When Internet lockout based on IP feature is enabled, you can also configure to validate
the proxy IPs in X-forwarded-For header and IP of TCP connection to Domino with trusted
Proxy IPs in your environment
 In the Domino directory, open the Server document for a server on which to enable the setting.
 Select the Internet Protocols > HTTP tab.
 In the Trusted Proxies section, select “Enable trusted proxies”.
 Click Edit List and specify a comma-separated list of IP addresses to allow.
 Include IP addresses for incoming TCP connections to Domino server and the IP addresses in X-Forwarded-For headers.

The HTTP server will use the following rules to determine the IP address of the client for X-Forwarded-For
header validation
1. The server will first check for the existence of the http X-FORWARDED-FOR header. That header has
the following format.
X-FORWADED-FOR: <client IP> <proxy1 IP> <proxy2 IP> ……….
(Note: the last proxy address the request goes to Domino HTTP is not part of the header and is not included)
If the header is present, it will use the first address in the header which is the client IP address as the
address of the client machine.
Sample Header with 2 Proxies and X-Forwarded-For header enabled.
HTRequest::ProcessXForwardForHeader> X-FORWARDED-FOR Header value is [192.168.164.1, 192.168.164.44]
2. If the X-FORWADED-FOR: header is not available, the client IP address will be the client address of the
TCP connection to the http server accepted from the network.
Sample Header with 2 Proxies and X-Forwarded-For header not enabled on Proxy1:
HTRequest::ProcessXForwardForHeader> X-FORWARDED-FOR Header value is [192.168.164.44]

Important Note:
Every proxy IP address specified in the X-FORWARDED-FOR header must be in the trusted proxy list for
the request to be accepted by the server, else web users request fails with below error.
Http Status Code: 400
Reason: Request cannot be processed, request contains an invalid HTTP header
Limitations:
 This feature cannot be used in Mixed environments, it works only on V12 and Later Domino
server’s environment.
 The Internet Lock feature is shared with (IMAP, SMTP, POP3, LDAP, DIIOP) protocols.
 Authentication failures from non-HTTP protocol through a firewall/proxy to Domino may lead to lockout
of respective firewall/Proxy IP, For this reason the Internet Lock feature should not be used with any non-
HTTP protocols running behind a firewall/proxy.

NRPC port encryption support of forward secrecy using X25519
16
Additional forward security feature introduced to improve security of a long-term secret key when NRPC port encryption
is enabled.
 Forward secrecy using X25519 is enabled by default on Domino 12 server when NRPC port encryption is enabled.
NRPC client version
Algorithms used
when connecting to Domino 12
Clients prior to V 9.0.1 FP7 RC4
•V 9.0.1 FP7 and later FPs
•V 10
•V 11
128 bit AES-GCM for network encryption
and integrity protection and 128 bit AES
tickets
V 12 256 bit AES-GCM for network encryption
and integrity protection, X25519 for
forward secrecy, and 128 bit AES tickets.
 NRPC encryption algorithms used by client
versions.
 If you currently use the PORT_ENC_ADV setting and want to enable X25519 for forward secrecy, add 32 to your current
value for that setting.
Reference : https://help.hcltechsw.com/domino/12.0.0/admin/conf_port_enc_adv_r.html
 Enable LOG_AUTHENTICATION=1 to see which algorithms are
being used to authenticate and encrypt NRPC traffic.
NRPC connection from V11.0.1 client:
Authenticate {1A70006}: CN=Notes Admin/O=Acme
[0954:0040-0AC0] T:AES:128 E:1: P:t:e S:AES-GCM:128 A:2:1 L:N:N:N FS:
NRPC connection from V12 client:
Authenticate {1A70001}: CN=Notes Admin/O=Acme
[0954:003F-1314] T:AES:128 E:1: P:t:e S:AES-GCM:256 A:2:1 L:N:N:N FS:X25519

Two new curves supported for TLS 1.2 ciphers that use ECDHE for forward secrecy
17
 Fastest and reliable curves to avoid many potential implementation pitfalls, also being used in TLS 1.3 for key exchange
protocols
 TLS 1.2 ciphers that uses Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) for forward secrecy now support two new
curves for forward secrecy: X25519 and X448.
 Add SSL_LOG_SUCCESS=1 parameter on server notes.ini to see the cipher and curve used for TLS handshake.
[0958:000B-11B8] 05/07/2021 09:04:35.19 AM TLS1.2 connected 192.168.164.1 (49876) -> 192.168.164.36 (443) - ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xC030) with Curve25519
 The elliptic curve used for forward secrecy is negotiated dynamically as part of the TLS handshake.

 Domino’s New vs Old ordered preference for ECDHE:
`
 Each of these curves can be disabled with a
corresponding server notes.ini:
New order Old Order
1. X25519 1. NIST P-256
2. NIST P-256 2. NIST P-384
3. X448 3. NIST P-521
4. NIST P-384
5. NIST P-521
SSL_DISABLE_CURVE_X25519=1
SSL_DISABLE_CURVE_P256=1
SSL_DISABLE_CURVE_X448=1
Sample log after adding “SSL_DISABLE_CURVE_X25519=1” on notes.ini
05/07/2021 09:23:00 AM TLS1.2 connected 192.168.164.1 (54014) -> 192.168.164.36 (443) - ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xC030) with NIST P-256

Suppress key rollover alerts during ID vault synchronization
19
In the previous versions of domino installs, key rollover alert messages continuously logged on ddm.nsf throughout the day.
This had caused some admins to treat these as an issue with user ID synchronization.
These are informational messages which needs to be ignored by administrator.
 Key rollover alert is shown routinely when a Notes ID is synchronized with the ID vault.
Alert :Unable to read rollover values from view. Vault ‘CN=test1/O=Acme'. User ‘/IDVault’
 The Domino server checks if the user is in the middle of key rollover and looks for below items on the user Vault entry
during vault sync.
"ActiveKeyWidth", "ActiveKeyCreated", "PublicKeyHash", "KeyGenState", "LastCertReq", "AliasHash".
 To suppress the alert message, add IDV_SUPPRESS_ROLLOVER_LOG=1 on Vault server notes.ini.
 Enhancement request to supress alert message : https://domino-ideas.hcltechsw.com/ideas/DOMINO-I-1410

Import internet certificates that contain unsupported critical extensions
20
This feature is introduced to support importing of certificates designated as critical. This inability is reported to HCL
Software via SPR # DLIMBSMS4E and addressed in V12.
On Notes/Domino V11.0.1 and earlier versions, internet (X.509) certificates extensions flagged as critical cannot be
imported into user ID files/person documents in NAB.
An error message is prompted when try to import critical marked extensions.
Error : Unable to parse certificate
To import Critical extension internet certificates in Notes/Domino
V12.0, add below notes.ini on server/Notes client.
ALLOW_PARSE_OF_UNSUPPORTED_CRITICAL_EXTENSIONS=1

New Web Server Login Form
21
The $$LoginUserFormMFA is an improved modern-looking web login form.
The login form is required if you configure time-based one-time
password (TOTP) authentication.
This can be used even if you don't use TOTP.

New Web Server Login Form
22
How to create New Web Server login form ?
1. Create the database from the DOMCFG5.NTF template provided with Domino 12 or later.
Name of the database must be DOMCFG.NSF
2. Open the Domino Web Server Configuration database.
3. Open the Sign In Form Mappings view.
4. Click Add Mapping.
5. Under Site Information, choose one:
All Web Sites/Entire Server -- to use the custom log-in form for all Web Sites on the server, or for the entire Web server.
Specific Web Sites/Virtual Servers - to map the custom log-in form to specific Web Site documents or Virtual Servers.
6. Under Form Mapping, for Target Database specify DOMCFG.NSF
for Target Form, specify $$LoginUserFormMFA.

Time-based one-time password authentication
23
 This addresses an high-weightage enhancement request from our customers to have 2FA for Domino web
server to improve security.
 Time-based one-time password (TOTP) authentication provides an extra layer of security when users authenticate to
a Domino Web server.
 When users log on to a Domino Web server, users need to provide time-based one-time passwords in addition to
their user names and passwords.
 TOTP applications that comply with RFC 6238 are supported, including Google Authenticator, Authy, and Duo Mobile.
Prerequisites :
a. Make sure your ID vault server runs Domino 12
b. The ID vault database is upgraded to the Domino 12 idvault.ntf template design.

Docker considerations for TOTP authentication
24
Requirements and recommendations for enabling TOTP on a Domino server on Docker are as follows.
1. Create or replicate an ID vault on the Domino on Docker server.
All TOTP-specific configuration is saved in users' ID vault documents.
2. Make sure that the web sites or virtual servers that run within the Docker container are accessible from outside the container.
3. Recommend running the Domino HTTP server with a default Internet site, TLS enabled, and Server Name Indication (SNI) enabled to
connect to a web site or host name.
For more information on SNI, refer Domino Web server support for Server Name Indication (SNI) in the Domino documentation.
https://help.hcltechsw.com/domino/12.0.0/admin/conf_enabling_sni.html

TLS 1.0 is disabled by default
25
Deprecation of TLS 1.0 is intended to assist developers as additional justification to no longer support older TLS versions
and to migrate to a minimum of TLS1.2.
Domino 12 disables Domino's support for TLS 1.0 by default
TLS 1.2 as the currently supported TLS protocol version.
The TLS 1.0 protocol dates back to 1999 and offers very poor levels of security against the attacks that are prevalent in
today's environment.
Most modern web browsers and cloud service providers dropped support for the TLS 1.0 and TLS 1.1 protocols earlier
this year and the IETF TLS WG has submitted a "die-die-die" internet draft for TLS 1.0 and TLS 1.1 to the IESG for
publication as an RFC.
Refer  https://tools.ietf.org/html/draft-ietf-tls-oldversions-deprecate-06
Environments that still require TLS 1.0 for backwards compatibility can re-enable TLS 1.0 support by below setting in the
notes.ini file. SSL_ENABLE_TLS_10=1

Support for PEM-formatted TLS host keys and certificates
26
This feature simplifies the process of enabling secure domino functionality by the Domino Administrator.
When configuring a Server document or Web Site document with a path to a keyring file, administrators can now specify text
files containing PEM-formatted keys and certificates instead of ".kyr" files in the proprietary format.
These PEM-formatted files must have names that end in a ".pem" extension.
Contain a PEM-formatted RSA or ECDSA private key and
the set of PEM-formatted certificates forming the certificate
chain for that private key, ordered with the leaf certificate first.

New Template Signing ID uses 2048-bit Keys
27
A new template signing ID, CN=Domino Template Development/O=Domino, provides stronger encryption using 2048-bit
keys.
Templates that are new or modified in Notes and Domino 12 are signed with the new ID.
The following templates have been signed with the new ID:
 pubnames.ntf
 certstore.ntf
 pernames.ntf
 discussion12.ntf
 teamrm12.ntf
 websecuritystore.ntf
 domadmin.ntf
 dct.ntf
 idvault.ntf
 dominoblog.ntf
 resrc12.ntf

Notes V12 clients provisioned with default ECL settings include the new ID in the ECL so don't show ECL alerts when
opening databases signed with the new ID.
 Pre-12 Notes clients with ECLs set by administrators see ECL alerts
when opening databases and templates signed by CN=Domino
Template Development/O=Domino.
 To avoid the alerts, Domino administrators can update
administrator ECL's in the Domino directory to include the new
signing ID with proper permissions.
Referhttps://help.hcltechsw.com/domino/12.0.0/admin/conf_editingadministrationecl
s_t.html#conf_editingadministrationecls_t
Note  If the “Allow users to modify” setting is not enabled in the
administration ECL, to prevent alerts for Notes 12 clients, edit and save the
administration ECL.
New Template Signing ID uses 2048-bit Keys

New Query Vault Command Options
29
Query Vault was introduced in Domino V10.0.1
Use qvault to archive user vault documents manually to restart ID synchronization and to manage archived user vault
documents.
Use the Query Vault (qvault) console command or the Domino Admin Client to update Person documents with the last
successful ID synchronization time.
To enable this, need to add server notes.ini parameter IDV_Enable_Vault_Scan=1
In V12, New options are introduced to inactivate and reactivate user's ID vault documents.
To inactivate:
Syntax  load qvault -x <vaultname> -u <username> -i
To reactivate:
Syntax  load qvault -x <vaultname> -u <username> -v

New Query Vault Command Options
30
IDV_Enable_Vault_Scan=1 is mandatory in Server notes.ini for the qvault commands to work.
In absence of this ini, you will encounter error “QVR - The local security feature is not supported for the database or server” after
running any qvault command.
Example : load qvault -x O=ID_vault_Acme -u "CN=Test User1/O=Acme“ -i
Example : load qvault -x O=ID_vault_Acme -u "CN=Test User1/O=Acme“ –v

Uploading User IDs to a Vault Manually
31
Vault administrators can manually upload a single user ID file or multiple user ID files referenced in a CSV file. Users can also upload their own ID files to an ID
vault.
 Upload a single user ID file. (Action by Administrator)
Prerequisites :
1. Users must be registered with Notes IDs and be assigned to a vault
through a Security Settings policy.
2. To upload a user ID for somebody else, you must be a vault administrator.
Procedure :
1. Open the People view of the Domino directory.
2. Select Person document
3. Click ‘Action, menu  select ‘Upload ID files to ID Vault’
4. Select Single file. In the ID file name field, browse for and select the ID file.
5. In the User name field, the user's Notes name display. For example, Test User1/Acme
In the Password field, enter the password. Click OK.

Uploading Multiple User IDs to a Vault Manually
32
Vault administrators can manually upload a single user ID file or multiple user ID files referenced in a CSV file.
 Upload multiple user ID files referenced in a CSV file. (Action by Administrator)
Prerequisites :
1. Users must be registered with Notes IDs and be assigned to a vault through a Security Settings policy.
2. To upload a user ID for somebody else, you must be a vault administrator. Sample csv file :
3. The CSV file must have two, comma-separated columns.
a. In the first column, specify the complete path to each ID file.
b. In the second column, provide the password for each ID file.
c. Use the UTF-8-character set and do not include a header row.
Procedure :
2. Select Person document
4. Select ‘CSV Import. Browse CSV file
5. Click OK.

Uploading User IDs to a Vault Manually
33
Users can also upload their own ID files to an ID vault. Please note user can upload single User ID file.
 Upload a single user ID file by end user.
Prerequisites :
1. Users must be registered with Notes IDs and be assigned to
a vault through a Security Settings policy.
2. User must have atleast Reader access on Domino Directory.
Procedure :
ID file name with path and the ID file name field will be available
as per Notes ID authentication. Its non editable.
3. User can enter only password in the Password field.
Enter the password.
4. Click OK.

Support for SameSite Cookie
34
Use of the SameSite cookie attribute reduces the risk of cross-site request forgery (CSRF).
Configure the SameSite cookie attribute to enable a Domino web server to assert that browsers can only send cookies that
originate from the Domino server web site.
 Configure the SameSite cookie in these documents in the Domino directory
• Server document
• Web Site document (single server)
• Web SSO Configuration document (multiple servers)
 Configure the attribute through a notes.ini server setting.
 For SameSite cookie attribute, select one of the following options:
Strict : Cookies are sent only when browsers directly access the web site of the Domino server from which the cookies originate.
Lax : Cookies are sent when browsers directly or indirectly access the web site of the Domino server from which the cookies originate.
None : Cookies are sent regardless of the web site from which the cookies originate. Requires that HTTPS be enabled.
For information on SameSite cookie Attribute  https://en.wikipedia.org/wiki/HTTP_cookie#Same-site_cookie

Configuring the SameSite Cookie Attribute through the Domino Directory
35
 If you are using Server document, Setting available Internet Protocols > Domino Web Engine tab > HTTP Sessions section
 If you are using Website document, Setting available
Domino Web Engine tab > HTTP Sessions section
 If you are using Web SSO configuration document, Setting available
Basics tab, Token Configuration section

Configuring the SameSite Cookie Attribute through the Domino Directory
36
 Use one of the following notes.ini settings to configure the SameSite cookie attribute on a web server.
If the web server configure through a Server document or a single-server Web Site document, use
 DOMINO_SAMESITE_SINGLESERVER=value
If the web server configure through a Web SSO Configuration document, use
 DOMINO_SAMESITE_MULTISERVERSSO=value
 Make sure that the SameSite cookie attribute field in the web server document is set to Use browser default or INI
setting.
Following values representing the desired SameSite attribute:

Web server GET /names.nsf?Login Requests Prevented by Default
37
 For improved security, Domino 12 Web servers do not allow GET /names.nsf?Login requests by default.
When you upgrade to Domino 12, the following error is logged to the server console:
 Prior Domino V12, used /names.nsf?login to generate a login page, the best practice is to instead issue GET on a
resource to force the server to generate the login page.
For example, GET /names.nsf works in most cases.
 While not recommended, the notes.ini setting is available to revert to the pre-12 behavior and allow GET
/names.nsf?Login requests  DOMINO_REJECT_GET_LOGIN=0

What’s new in Domino v12
Domino V12 System Requirement
Improved management of TLS certificates
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
New template signing ID uses 2048-bit keys
.
References

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
Upload IDs to the vault manually
Support for SameSite cookie
Web server GET /names.nsf?Login requests prevented by default
New Web server login form
References

KEYWORD KEYWORD
Thank You!
Questions, Answers & Feedback

$10 BILLION | 159,000+ IDEAPRENEURS | 50 COUNTRIES

HCL Domino V12 Key Security Features Overview

More Related Content

What's hot (20)

Similar to HCL Domino V12 Key Security Features Overview (20)

Recently uploaded (20)

HCL Domino V12 Key Security Features Overview