wissel.net

Usability - Productivity - Business - The web - Singapore & Twins

Who has access to your certifier?


Domains and Certifiers are the most commonly confused items in Notes and Domino. By habit (I wouldn't call it a best practise, it really is just a habit) they bear the same name, but they don't have to. You can have multiple totally distinct certifiers in one Domain and you can use one certifier across multiple domains - or mix both. Interestingly the same is true for Internet certifiers (mostly seen in https): You surf to the Domain amazon.com but the certifier has been created by Verisign. Now when you go and try to borrow steal get access to the root certificate, containing the private key of Verisign's certificates you are up against some Fort Knox style security. Rightfully so. With access to the root certificate you can compromise the whole chain of security. The same is true for the cert.id that is used to create servers, users and organisational units for use in Domino Domain(s). When reviewing how secure these are kept I regularly find ignorance in holy union with incompetence. Quite often hired hands have boxes with floppies (less in these days) or memory sticks with all ids and certifiers on it and an open list of passwords. Contractors never change, contractors never have their own motives, contractors are always honest, never underpaid (the actually guy/girl, not the outsourcing fees) and from outmost integrity. Also they never make mistakes. And then you wake up. The whole pyramid of digital certificates, non-repudiation and authenticity crumbles without your PKI insufficiently protected. A security expert once stated it very clearly: " If you can not with 100% confidence confirm who ever had access to your root certifier (and might have kept a copy) since its creation, your PKI must be considered compromised". I would say, that is probably true for a lot of Notes shops. Happy recertification then!
So how does a proper and due process for certifier management look like? There are several steps involved Speak out loud every step and make sure all participants are briefed about the process and understand it:
  1. Setup a new machine with only internal network connection to your admin server and a working Notes Admin client. Make sure it is maleware free. Have a printer attached to it and install a Hex-Viewer
  2. Setup or make sure it is setup properly: the Domino Certificate Authority (Yes it is there since R6)
  3. Hook up a projector, so all participants can see what is going on
  4. Invite four to six signers (board members is a good choice) and some witnesses. Ideally have the corporate notary present
  5. Prepare envelopes and sheets of paper suitable for long term save storage (ask your notary for the right material)
  6. Create a new certifier ID in the admin client. Let one of the signers type the password, that is NOT shared with anybody
  7. Edit the certifier and configure it to hold four to six passwords (depending on the number of signers you invited), require at least 3 passwords to unlock it
  8. Let every signer add a password that should be really complex -- and long. Let them write it down first before they type it in
  9. Hand one envelope with the password to each witness and let them verify that the password actually works. Make sure they don't see any other password. If that fails back to step 6
  10. Now connect to the network and upload the new certifier to the Domino CA you configured/verified in step 2
  11. Let the envelopes be sealed and handed to the corporate notary to be stored in the designated corporate vault
  12. Open the ID in the Hex Viewer and print the hex dump. Put that in an envelope together with a pluggable storage (SD Card, USB Stick etc.) that contains a copy of the ID. If that media isn't readable anymore you can restore it from the HexDump print
  13. Let everybody sign a document that outlined what happened just now and hand that over to the notary for filing
  14. Last not least: wipe the cert file from the machine (not just delete, properly wipe) also wipe the temp files (the printer spooler stuff)
Now you have a proper cert, now it is time to create your IDVault and create your organisational certifiers. The organisational certifiers warrant the same attention and I would recommend to use them everywhere. What I'm curious about: " How do you secure your PKI?"

Posted by on 07 March 2011 | Comments (1) | categories: Show-N-Tell Thursday

Comments

  1. posted by Serdar Basegmez on Tuesday 08 March 2011 AD:
    Excellent post!

    You clearly defined the most ideal case :)

    Unfortunately many admins are really ignorant about certifier id's. On my security audits, I find certifier id on a public network share (not only help desk but also ordinary users can see it) and try passwords like 'LOTUSNOTES', '12345678', 'passw0rd' etc. These are the classical ones being told in step-by-step guides. 50% success (!) is guaranteed!

    I also suggest my clients to utilize Certification Authority, if they want some mid-level admins to create users but don't let them to know cert.id passwords.