One of the best kept secrets starting with Domino 9 is how to handle TLS/SSL connections to untrusted 3rd party Certification Authorities.
I’m not going into detail what TLS/SSL means. There are thousands of websites explaining it already. The important point for this blog post is that the requesting system needs to trust the Certification Authority (CA) which issued the SSL certificate of the target system. If it doesn’t trust (aka “knows”) the CA it normally will throw an error or refuse the connection.
When you’re accessing public websites or APIs that use an “acknowledged” CA like VeriSign, GoDaddy etc. you normally won’t run into problems. Most systems like browsers or servers know most of those CA’s. They are part of the product. But what will be if your system doesn’t know the CA? A common use case, especially in company/enterprise environments, is to use one or multiple internal CA’s (see here why NOT to use self-signed certificates). In that case you have to publish the internal CA’s to your requesting systems before you can establish secure connection.
As developing with Domino means nowadays normally Java I’m only explaining that bit here. You had two options (see first answer here) in the past:
- Importing the needed CA’s into the servers Java truststore (aka cacerts)
- Programmatically “deactivate” the trust check – which also means disabling the security
Option 1 is a pain. The cacerts file may get updated (== replaced) with any JVM update. So if you update your Domino server and the Domino JVM gets updated you’ll also have to re-import the CA’s. Every time. If you forget to check and re-import it…bang.
Option 2 is a no-go. You’re basically disabling security.
Starting with Domino 9 IBM has made some significant changes to the underlying handling of this. Instead of relying on the standard Java cacerts solely Domino will also check Internet Cross Certificates in the server’s Domino Directory. That means you can import the CA’s using the Domino Administrator into your Domino Directory using your well-known mechanism and they won’t be affected/replaced by any JVM update. Isn’t that kick-ass? We’ve added that in a some customer environments last year and it worked like a charm. It’s my fault of not blogging earlier.