NTOPNG and Let's Encrypt Certificates
-
I'm using a lets encrypt certificate with Pfsense. Whenever I change the default webconfigurator cert to the let's encrypt certificate ntop becomes inaccessible. As soon as I revert back to the default it's available again.
Anyone know of a workaround?
-
How do you have ntopng set? It should work for that. It did the last time I tried it.
-
Looks to be the default configuration - included in the attachment. When accessing I get ERR_SSL_VERSION_OR_CIPHER_MISMATCH
If I change the Advanced - admin access from the acme (lets encrypt) issued certificate back to the webconfiguration default certificate ntop is accessible again. My acme issued cert is EC384, but not sure that makes a difference.
-
That could be why. I haven't tried it with an EC cert, it worked fine for me with a regular cert.
-
Replying to this because it may be related to the issue I just ran across.
I just added a new Let's Encrypt Cert via manual import in the Certificates page, and after switching to it in Advanced settings, the Ntop GUI (myfirewall:3000) was still using the old cert.
I had to go to Ntop NG pfsense config, and click 'Save' on the ntop settings. This "activated" the new cert for the :3000 ntop web interface.
So the issue appears to be that adding a new cert does not automatically activate it for the ntop web app on port :3000. Having to "resave" ntop settings each time a new cert is added is maybe a bug?
-
How would ntopng know you made that cert change? It has no way to know, resaving its settings makes it re-read the certificate and pull in the new settings.
You have to remember that ntopng is a package and is not going to have its settings automatically updated by changes in the base system.
-
Thanks for the followup. Ntop wouldn't know, but the Pfsense UI knows (assuming I made the cert change using PfSense UI, which I did). Was hoping/assuming pfsense would notify the ntop package to refresh its cert/settings in this scenario. That's not how it works, fair enough.
Previously I used the acme package to set up the Let's Encrypt cert - maybe the acme package DOES trigger ntop to re-read its cert? Not sure, I may be remembering wrong.
Additional motivation to go back to using paid SSL certs rather than the frequently expiring Let's Encrypt ones which cause additional manual work, or additional dev effort to put in place automation to deal with all these scenarios.
Also - we're running a number of firewalls. If it was just one firewall, with a cert that expires every 2 years, it would not be an issue to document somewhere the need to click the save button on ntop settings every 2 years when the cert is renewed.
-
The correct path forward in that case is to add an action to the ACME package cert entry to restart the ntopng service.
The rc script doesn't appear to rewrite the cert, though, so you'd need to do something a little more drastic, like have ACME run /etc/rc.start_packages in the renew actions.
-
Thank you for those ideas! I'll also look into whether there's a way to trigger Ntop to "Save Settings" using a script.
-
I have the same issue. Also using ACME 2.0 for an EC384 certificate. People are reporting that old school Letsencrypt certs work fine. May try that this weekend.
Edit: No dice on the standard RSA cert. Same issue. Doesn't seem EC384 related after all.
-
Has anyone else found an answer? I have tried adding my cert to the package but am still failing.
-
I was having an issue with Lets Encrypt certs as well. They worked fine for PFSense GUI, they just were not working for ntopng. As other's have indicated, when using the LE certs, the browser was giving a "ERR_SSL_VERSION_OR_CIPHER_MISMATCH" and the process core dumps when restarting. When using other SSL/TLS testing tools (like testssl.sh), the port was open by no TLS handshake was happening, no cipher was being offered.
Originally I was using a 384bit ECDSA LE certificate.
What seems to have allowed me to work around the issue was switching to a 2048 bit RSA certificate. Earlier in the thread @spambait mentioned that didn't help him, so not sure why it's working for me. I did manually cat the key and fullchain into the ntopng/httpdocs/ssl/ntopng-cert.pem file.
Switching certificate types in the existing certificate did not seem to actually change the type of certificate being generated. I had to create an entirely new certificate (Services -> Acme Certificates -> Certificates -> + Add).
