Domino Administration - Back to Basics (Part 1) - Certificates

Domino is different, a lot of its concepts predate the internet and quite often inspired the standards. This is not an step-by-step instruction, but an introduction into concepts. The "step by step" approach is another story for another time.

In the beginning was the Certificate

Notes and Domino run using ID files. This are not merly files that can arbitrarily reconstructed, but cryptographically created Public Private key pairs. To avoid naming collisions the key names are hierarchical (Since R2), so anyone can call their server Server1 without confusion (sort of). This hierarchy is achieved using X400 naming conventions, an early competitor to DNS naming. A X400 name can consist out of multiple parts, these are the ones Domino is using:

So the minimum is a common name and an Org. The starting point of each Domino journey is the creation of the OrgID. All other parts depend on it. Note: there isn't a country ID, even if country mentioned after the Org. When you create your OrgID (while setting up the very first server), you can specify the country and it becomes part of the OrgID.

In practise however I haven't seen many OrgIDs that would carry a country code in them. So you can skip that part.

Signing Ids

Using the OrgID as signing certificat, one can go and create server and user certificates. E.g using the OrgID /O=Acme one can create /CN=Coyotee/O=Acme. For convenience the qualifiers are usually omitted, their meaning results from the position (and the fact that country is 2 letter if present and Orgs have 3 or more). So instead of /CN=Coyotee/O=Acme one can write Coyotee/Acme.

In practise however more enlightened organisation use their OrgCert as cautiously as root certificates in the X509 world and only register/sign Organizational Unit (/OU=) Ids which then can be used to sign server and user certificates.

Trust between certificate is hierarchical, similar to Internet certificates, so IDs having the same root (/O) certifier recognizse each other. The hierachy can be used in Access Control (another story for another time) to grant access to all IDs at a given level e.g. /OU=Management/O=Acme

Types of ID files

As mentioned there are 3 types of Ids:

• Certifiers (on /O and /OU level)
• Server Id
• Person Id

The distinction becomes relevant in access control where access can be granted to users or servers only. Person and Server IDs can occur on any level. Typically we see servers either on the org level or in their own OU.

Selecting OU levels is not an easy decisions. We see models of organisations like /OU=Sales, /OU=Board but also geography like /OU=Gernay and /OU=Singapore. This can be very deliberate. Someone moving (department or location) would get the userid recertified with the new OU. What needs careful planning: what document access is won/lost with such a move (That's a business decision, Domino can handle all scenarios when planned properly).

Cross Certification

To include certificates with a different root one uses Cross Certificates which are captured in the directory (and/or local addressbook, the user's personal directory). When one creates a cross-certification for an /O id, all the decendants (/OU/OU/O) are recognized too.

Insights

In no specific order:

• In Notes/Domino the terms ID and certificate are loosely used interchangable
• The concepts are similar to Internet certificates. Main difference: the parts are named and limited how long the chain can be (6 parts max). In practise you rarely see 6 level deep internet domains or Notes Names
• The 4th level of /OU doesn't need a certifier. It is mainly recommended to distinguish multiple "John Doe"
• Notes names are separated by /, Internet names separate the common name with @ and the domain parts with .
• Internet names have a central naming registry run by IANA, while Domino's central registy Notes.net never took off. So you can create as many /O=Acme certifiers as you like (technically you can do that with your own CA too)
• Creating Certificates with the same name does NOT create the same public/private key pair. All trust relations will not work. IDs signed with the old certifier will throw a trust error for the new one. Also all cross-certificates break
• Cleaning up Name conflicts is a huge mess. So don't do that
• Notes IDs can hold X509 certificates for signing internet messages
• A personal Notes address book or the Domino directory can hold external X509 public keys to validate signatures or encrypt outgoing messages
• To minimize the hassle for handling certificates Domino provides a Certificate Authority and an ID-Vault. Set them up. Saves headaches!
• ID Files, both on the server and the client are used to encrypt databases. Loose the ID, loose access! A well managed IDVault is your life insurance
• Back things up. Make sure they are save! One organisation I encountered printed hex dumps of all cert and server ids and locked them in their corporate vault. Smart move. I wonder if they repeated that, as they should, at key rollover time
• Certificates don't live forever. They need to roll over keys. Plan that well and use an IDVault - and back up everything before you start
• Pro Tip: If you are shure your server's future DNS name won't change, you can name the CN part after the full qualified DNS name. E.g CN=lion.exoticpets.org/OU=Servers/O=Pets4Us. It will help as you will learn in Part 2
• Really: use an IDVault
• Did I mention: use an IDVault

What are your insights or concepts you like to know?