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.com.au
- extranet.mydomain.com.au
The possibilities are endless.
Last year, when we were on Domino 9.0.1, we generated the Certificate Signing Request (CSR) on Domino and set up domino first. Then we did our other sites.
This year, on Domino 12.0, we generated the CSR in Azure. We were able to use the resulting certificate on several platforms including WordPress and Drupal but it wouldn't load correctly in Domino.
Eventually we had to generate a CSR from Domino and get a new certificate. Luckily the newly generated certificate didn't muck up those existing sites.
Next year, we'll be starting the CSR process at Domino.
You need 12.0.1 or Higher
The second big issue we hit was that we couldn't stop the server from loading the old certificates, which were done Domino 9 style. We tried restarting the http task, tried rebooting the server and tried removing the .KYR files from the domino directory -- this last action prevented HTTPS from working at all.
In the end, we did an impromptu upgrade of our 12.0 servers to 12.0.1 (and added Fix Pack 11). HTTPS started working immediately.
Hopefully these tips will make your certificate renewal process a little smoother than our last effort.
Comments
This is implemented to ensure that when running the new more modern TLS Cache, the existing KYR files still work until you remove them manually from disk.
The new TLS Cache is always checked first. If no matching TLS Credentials document is found, it will still try to find a KYR file.
There are a couple of improvements in 12.0.1 to help you find out about the configuration used and also for importing. But this all worked the same in 12.0 already!
You can use "load certmgr -showcerts" to see all active TLS Credentials for a server.
It does not matter how you create the CSR nor how you import it.
You don't have to do it in Domino. But importing existing certificates has been improved in 12.0.1 with the import/export UI in certstore.nsf.
In 12.0. you had to import existing PEM based certs into certstore.nsf via "load certmgr -importpem ..".
This command did not enable the imported TLS Credentials automatically for the current server and you had to add your server to "Server with access" to get the private key encrypted for your server.id and to let the TLS Cache load it.
This command has been aligned with the new import functionality in 12.0.1 and automatically adds the own server -- that's the only change I an think of making a difference for you. So you might have missed to enable "Servers with access" for the TLS Credentials document.
Your blog post is based on assumptions and it is misleading for others!
Thanks
Daniel
Looks like, to me, you hit a config iussue more than a bug.