SSL Cert Renewed in Certmgr but no one could see it

Certmgr is the greatest thing in Domino these days if you are an admin.

Autorenewing SSL saves so many problems, delays, and potential loss of revenue for customers that it is, in my opinion, one of the best things HCL has added to Domino.

Much of the credit for it goes to HCL Lifetime Ambassador Daniel Nashed. 

When you see him at Engage or DNUG, buy him a beer.

Daniel was on hand to help me with my problem tonight, and he was correct with his original assessment, Certmgr should just work. 

I agreed, and it was working, or so it showed in the view when verifying it using "tell certmgr show certs" at the server console, but we could not see the validated certificates for 2 domains.

Since I had manually renewed them today, we should have seen a date of expiration for March 18. Instead, we saw December 17th for the one that expired yesterday, and the other showed January 21.

The TLS cache should be auto-refreshing when it gets the new certificates, but appeared to not be doing the task.

We reviewed the basic configuration and tried some test requests, which should have triggered a cache refresh and resolved the issue. But that didn't help us see the correct certificates in our browsers.

While Daniel asked me about different parameters, I learned something about the updated certmgr, we don't need to put the .kyr name in the Security tab, TLS options field. 

Instead, we should be using the DNS name. I totally missed this. The .kyr name in the field is there for the legacy people who have yet to move to V12 or V14. See page 36 of the slide deck mentioned below.

You can read Daniel's slides from his OpenNTF session, which is full of deep technical information. https://blog.nashcom.de/presentations/openntf2021_domino_certmgr.pdf

The other part, which I did know, but had yet to remove from the customer server is the Internet Sites Basics tab, DSAPI Filters field no longer requires ncertmgrdsapi.

After doing these bits of cleanup, and restarting HTTP a few times, we were still left with the issue of incorrectly reported SSL certificate dates.

We turned on debugging for the cache using set config CERTSTORE_CACHELOG=1. 

Page 47 in the above slide deck.

And we got nothing.

Which surprised both of us.

And then we went to look at the notes.ini to see if anything was pointing to the wrong place.

And this is where we found the problem.

Now, there is a parameter that should not have been there at all, and there was only one Google reference for it that we found. Evidently, that reference should not have been public, but it was, and someone at the customer site had added it sometime in the last 60 days or so because Certmgr had been running fine for over a year already.

For the sake of some poor admin out there troubleshooting this, I will say that if you experience the same problem as I did, look in your Domino notes.ini for a line that starts with "SSL_DISABLE_TLS".

I will not put the rest of the command here because, as Daniel said, no one should be using it.

If you find something like this, just remove the line outright from your notes.ini.

You can use "set config ssl_disable_tls(rest of the name)=" to remove it from your active server.

There is no 0 or 1 to put to remove it.

Then, at your server console, type "restart task HTTP," which is the better way to restart HTTP.

And poof, like magic, it all worked again.

That command blocks the newer TLS Cache refresh implementation from running. Thus even though Certmgr could get the updated certificates, it could not run the refresh because this line was telling it not to run.

Customers are so cute when they tell you they didn't change anything.