Real World Computing

Yesterday, I posted about attending a Domino Jam for the first time in six years and my feelings on how HCL has turned the product around. Today I want to touch on the security aspect discussed at the Jam and add my thoughts to the mix.  Secure by Design Immediately following the roadmap presentation, the jam looked at Domino's legacy and where it is today. One of the key takeaways from this was a discussion of the incredible security in Domino. We have seen this in our organization but it was nice to hear HCL and other organizations (via quotes and stories) saying the same thing. There are many good reasons for the high security score but two of the best are  Multi-layered security from the very beginning of the product. Domino being "on-prem" rather than web hosted.  There were a couple of interesting stories and observations, including one about a penetration test on one of the new tools (Volt) where the auditors talked about the many layers of security in the Domino ...

I'm not a big fan of HTTPS. Don't get me wrong, I agree with all of the security and comfort that it provides. I just hate the whole renewal process. Domino 12 introduces a new way to do HTTPS and it's apparently much easier going forward.  That's great news. Unfortunately, we hit a couple of snags on the way in, and I wanted to warn everyone about them - especially since the workarounds are so simple.  Domino Needs to Generate the CSR You're probably thinking that that this is pretty obvious but if so, you're not thinking about wildcard certificates. We use a wildcard certificate *.mydomain.com.au - This allows us to use it across multiple systems, including Domino, Azure, some WordPress websites and a Drupal Website. We also use it in conjunction with several hosted services. The wildcard certificate allows us to use the same certificate on different subdomains. For example: www.mydomain.com.au domino.mydomain.com.au azure.mydomain.com.au othersite.mydomain.co...