Secure Domino
Have you ever been asked about about using SSL with Domino? If you're anything like me, you've been asked a few times and always said that it's possible but you need to buy a certificate. Well, I've been asked again and this time I want to go beyond the theory and try it out. Surely it's not the case that you have to buy an SSL key?
My Domino server shows the scars of a past failed attempt to try SSL. There's a document in certsrv.nsf and a rogue .kyr file somewhere that prevents me creating any more. While I try and get this sorted is there somebody out there that can shed some light? What's the difference between a key that Domino generates for you and one that costs loads of money from a company like Verisign? Would you buy a key if you wanted to show customers of your e-commerce site that you're trustworthy? Whereas, with a simple site on an extranet, you can make your own? I'm confused. Once I've got it all sorted I'll share what I learn.
Skip to the 
You can subscribe to an individual
Jake,
The selfcert process is for use on your dev and test servers to save having to splash out for certificates which you do not actually need. You will definitely need one for a production app as when you visit a site with a self certified certificate the browser will give a warning saying that there are problems with the certificate.
What you are paying for from Verisign (or whoever) is the fact that they are assuring the user that you are who you say you are. They do this with their own set of keys, the public end of which are embedded into the browser.
The selfcert process is very simple, just follow the steps in the admin help database very closely and then drop the kyr file into your server and change the server document to redirect port 80 to 443.
Jake -
Another take on the SSL cert issue: you don't *need* a Verisign certificate to do SSL. Users will be able to establish the SSL connection with no problem with a self-cert... PROVIDED that they are willing and able to accept your certificate. What Verisign buys you is AUTOMATIC acceptance of the certificate by the browser - the user is not presented with a frightening dialog box saying that the browser doesn't know whether it can trust the server that wants to establish an SSL connection. Most browsers trust Verisign certificates by default.
In an intranet/extranet type situation, you can probably use a self-cert without any issues. On the wild, wild Internet, I would spring for the Verisign cert.
Hope this helps.
Sean
Hi
It is actually the same.
Versign is a Certificate Authority and in Domino you can create your own CA and create your own server certificates.
So the quetion is of course why don't everybody do this?
As Matt mentions above Versign is a 3' party garanting that Jake is who he's claming to be.
The most important part in all this is actually a different matter. It is about which trusted certificate roots there default in browsers. If a trusted CA root certificate is in a users browser the user will automaticlly sillently accept the server certificate. If not the browser pops up a window and the user has to accept the certificate.
This raises uncertainty at user .. what is this? is it okay to accept it? what happens if i don't?....
This is NOT you want if you have a site like Amazon :-).
regards
Jesper Kiaer
Check out {Link} You can get certificates starting at $49 that support 99% of all browsers.
Jake,
To avoid the user getting a nasty prompt you need a certificate that matches one already in their (probably IE) browser that is "trusted". But unless you are a bank you do not really need to part with a lot of money - there are other companies apart from Verisign who can provide that and are already on the trust list.
You can pay 895us for a Verisign 128bit cert but GeoCert charge 229us, Thawte charge 199us and DigiCert charge 99us.
They all do the same thing, but it might be argued that Verisign and Thawte have a reputation for more rigorous vetting of their clients than some other companies.
Ian
Using Domino to provide certificates is not a technical problem.
As said earlier, what companies like Verisign provide is :
- a trustworthy third party anyone can rely on saying you are who you pretend to be
- agreements with browser editors (IE mainly) to include their root certificate public key - making it easy to accept server certificate, and install client certificate while a complex several steps dialog is needed if you use domino server to provide certificates.
Anyway,depending on what you need SSL to, providing yourself the third party authority might be ok. It all depends on who will be your users.
Trust yourself! (a bit outdated but still very interesting : {Link}
Good luck to you.
Thanks guys. It's all starting to make sense now.
So, if a client wants SSL on their "extranet", for use solely by their employess, can they creat their own Domino CA and then get an auto update to add this to the root certificates in IE?
That's right Jake, we had a similar situation, we just added a "how to accept the certificate" into the instructions we send out to the users.
In the end we shelled out the ■500 (project was in profit by now) for a certificate because it was easy, and I guess we were lazy :)
Our hosting company has a certificate that comes from Verisign and they are happy to let their customers use it. Maybe if your client is in the same situation (i.e. using dedicated hosting) the same could apply...
Another low-cost alternative is RegisterFly.com. They have 128 Bit SSL Certs for $24.99. I am using one of theirs in a production environment and it works beautifully.
Agree with all the above after doing this myself about 5 months back. Yes, you pay thru nose for Verisign and Thawte AND it can take ages to get the cert issued AND you have to be a registered company, etc, etc, and sending stuff off to these people was a bit daunting. First I went the self-signed route and it all worked out okay after nervously following instructions. Then went with a COMMODO cert (www.instantssl.com) and got a 'proper' cert. About 80 quid for a 128bit cert for a year and got it sorted within hours. Didmn't have to send paperwork/faxes, etc, once they checked out my Companies House registration. Tricky part (for me at any rate) was sorting out the domain, they are only issed to a single domain for your money, but since you normally have control over this wen you use SSL its ok, but forget virtual hosts! Also, the whole idea of certs is giving users confidence, so sharing someone elses loses your identity and defeats the purpose in my eyes!
Chrz & good luck +Tim+
Oh, and another thing, under v6.01 Domino, athough it supports 128 certs, you do get lots of nasty SSL errors showing on your console/log saying its too strong for export - or failed handshaking errors - but the Notes/Domino Knowledgebase says this is okay, it is still working okay. (They blame IE for not working properley - as if!)
+Tim+
You really should consider comodo. Comparing the price to Versign it is more economical. I am using it on my SSL server and it works like a charm. Here is the URL for their site:
{Link}{Link}
It only took me a few hours from sending the informatino and receiving the final product (the SSL certificate).
P C
{Link}
Tim,
The company I work for are investigating the use of SSL for a number of websites they host - one virtual domain with about 10+ virtual hosts. We host these sites on one server that sits behind a public (shared) firewall machine.
You said if you had virtual hosts, forget it ... The company we approached for buying SSL said each domain must have a separate ip-address ... but it is not possible because of the public firewall machine.
Can you us what would be a solution to this?
tks,
Richard.
FWIW, we issue our own certificates and roll out pre-built copies of Internet Explorer and Mozilla which contain our root certificate. That way no user is confronted with the "do you want to trust...?" dialog box. It is quite simple to do. MS supplies an "IE administration kit" with which you can build your own distro.
@Richard: individual certificates are needed for virtual hosts (each on their own IP!!!) because the web server cannot determine which host the client is trying to reach before it has decoded the encrypted request, and it cannot do that, because it doesn't know which certificate that request belongs to, because it can't decrypt... You get the drift?
Multiple hosts = multiple certificates.
Richard, no, sorry, I can't really offer a solution as I don't know much about this really. All I know is that your URL root domain must match the one coded in the SSL cert - I don't think this has anything to do with IP directly. If you have 10 virtual hosts, then you need a SSL cert for each one - not impossible, but costly and ore effort to config/maintain. Alternatively, for any SSL operation (ie: placing an order) you redirect to one host only and just use that for SSL, eg: secure.yourdomain.com/... This will work (I think) and usually you have enough control of the URL processing to complete the SSL operation as this is usually necessary to complete the order. You can always then redirect where you like afterwards without SSL.
If I recall correctly, you must specify exactly the URL you require, eg: www.yourdomain.com or yourdoamin.com, if you want both, its two certs! If not, you will get an SSL failure (of some description).
Hope this helps +Tim+
Jan-Piet, are you sure about multiple-hosts = multiple-certs = multiple-IP?
I cannot say for sure - although what you say makes sense, this could be a big restriction in the real world!!
Oh, and another thing...
If you ask Verisign or thawte to issue a cert and give them the wrong data (eg: the host/domain) I gather it is tough! To fix it you payup again for another very expensive cert. With Commodo, you get 30 days to sort out any problems! Just thought this might be worth mentioning.
Chrz +Tim+
@Tim: quite sure, unless you are able to get a wildcarded certificate (*.domain.com), but I understand the big Certification Authorities will not usually do that, or at least not w/o a hefty fee.
Doing it youself is quite easy, although I don't know whether the Domino CA can do that for you. OpenSSL can.
I agree with Tim's suggestion. I've used a single "generically-secure-sounding" domain name for all SSL traffic, and redirected to there from several different domains hosted on the same Domino server. It saves money and reduces domain and certificate registration/renewal hassles. Just remember to tell your users (on the previous page) that they will be redirected to your secure site.
Guys I suggest you look at a openssl. It is an open source SSL certificate generation toolkit. It allows you to become your own CA or mulitple CA's and create SSL certs for all applications not just Domino. We use it here in IIS, and for all sorts of other applications like BEA Tuxedo. With it you can do it all with regards to SSL Certs.
Check it out at {Link}
Does anyone know if it matters what server you are on when generating the certificate to be sent to the CAs? We are going to purchase a Thawte cert. The box that will face the internet is not in our possession yet. Can we generate the key on a different Domino server? I guess my question is, does the key generation rely on the machine/server itself?
Mark. I think it does matter what server software you're running on. A key for Apache would be different to the key for Domino on the same machine. Don't think the actual machine matters though. Could be wrong on both counts though.
We have always used self certed certs, having the Domino admin server as a CA for all other servers in the domain.
Now we've bought certs from GlobalSign, relatively cheap, and trusted of course.
It is supplied for *.ourdomain.nl
Somehow I'm hoping to get our own CA to provide trusted certs (with the GlobalSign private cert *.ourdomain.nl embedded) for the other servers. Does anyone have an idea?
Otherwise we have to order for all Domino servers (about 18) their own cert. :S
We purchased certs for our external web servers, but we chose to self-certify our own X.509 email certificates in Domino. Free! Lotus Notes users can Sign/Encrypt their Internet Email to customers. Yeah, those customers must "trust" our certificate the first time they get a Signed email message. It's not really an issue. I only see power-users with X.509 certificates.
Jake -
Not sure if you're still monitoring this thread, but I just read about a great SSL deal from GoDaddy:
{Link}
Eric Thauvin mentioned it, and it's tons cheaper than Verisign or Thawte. I just mentioned it in my blog (see there for slightly more details on today's post), and we're going to try it out at the office and see how it works. Could save a lot of money...
- Julian
Just a couple of late thoughts on this...
1. Machine/sw specifics: I think the certs are issued in a non-machine or software specific format, nor are the ca-requests that you send them to certify are specific. Its just the process you go thru to issue the req and accept the cert that is machine specific (But as usual, could be wrong on this!). As long as you copy/paste the cert bits between the header/footer as per the intructions you should be okay. (As an aside, I believe all you are getting for your money is a few prime random numbers!)
2. Keep a copy of any CA request you issue and any certs you receive. These are plain text and should be stored safely away somewhere! Keep your 'built' keyring file too!
3. Practice with a couple of self-cert runs on your domino server - this gives you a bit of experience, before you attempt to befriend the junk-yard-dog in the real world - and its free to experiment!
4. Don't underestimate the value of branding! Verisign and Thawte are well recognized and consumers will inherently trust them! COMMODO is well recognized, but less so, but godaddy? hmmm, perhaps not at the moment. Certs come with optional branding logos. With Commodo, you get a realtime registration check when you hover over their 'site-seal' which is nice, but adds page-loading overhead. Warning Some site-seal/cert logos may be incompatible with your page designs! (eg: Not available with a transparent background) and you can't easily change this!
5. If you are using Frames (urgh!) then you will not get the PADLOCK on your browser-bar nor the HTTPS: in the address(URL) bar for a secure page! This is a pain! You have work harder to educate the user that you are really secure by telling to check page-properties and the connection to type to show that you really are secure!
6. Remember: SSL is overhead! https performance is about 30-60% slower than raw HTTP.
7. You have to work harder with Callbacks, redirects and images so that the users don't get dreaded 'this page contains secure and non-secure items! Proceed?' messages - these problems are not always solvable!
8. Ticking the DB properties box, 'Use SSL for this database' doesn't mean you have to tick this box. You can easily use SSL in a 'mixed-mode' sense by specifically issuing your own protocol selection, eg: set your links to use HTTPS: or HTTP as needed. If you use IE, then the page-source will be hidden while in SSL mode - Nice when in production, but a pain when developing! If you clear the 'db-property 'Use SSL...' it sometimes doesn't take effect - possibly due to caching! Can waste a lot of time.
9. Don't forget the CGI/Environment variables! There is one that will tell you you are using SSL when a page loads - it is possible that you don't manage to handshake SSL when the page loads and you have to take avoiding action (hide-whens) to protect confidentiality - even IF the browser has warned the user about the handshake failure!
10. If you are encrypting stuff for transmission, you should also be doing all the other stuff to protect confidentiality! Like db-encryption to protect storage, ACL's and even (in the UK) registereing with the Data Protection Registrar.
Bottom line? Keep SSL page design simple, be patient and give yourself plenty of time to achieve your goals! Just getting the cert is only (as usual) only half the story - It is unlikley you just buy a cert, stick it on your server and bingo thats it! You have been warned!
Chrz +Tim+
Why do I get an error in outlook express that the cert is not trusted??