Potential pfSense feature/package: Monitor Cert expiry

[lohphat]

@johnpoz I wasn't talking about certs in the cert manager but certs passing through the gateway from client traffic in the org.

[jimp]

That wouldn't be anything done by the firewall, the firewall doesn't do DPI/IDS on its own.

There might be a way to make snort/suricata/zeek do that, but it would have to be something like that and not a function of the firewall.

[johnpoz]

@lohphat again - you can add a external cert in the manager that you use on some server in the network and you will get a warning.

But you could also just put in a cal item on your phone or whatever to remind you.

If you want something to actively monitor and check every day, etc.. I gave you 3 different free options.

Why do you want to recreate the wheel? There are plenty of ways to get this done.. If you want pfsense to monitor some site that you created a port forward for and not have to do anything else. That is asking a bit much if you ask me - so I forward 443 to server that serves up say 20 different domains based on the sni, How is pfsense to know to check the different certs.

If I port forward say 8443 to some server - should there be a check box on the port forward for pfsense to create some schedule to check if cert is going to expire?

If your managing your certs on your own outside of pfsense - then put in a cal reminder for yourself, or use one of the FREE tools out on the internet to check it.

Not sure why people think that pfsense is suppose to be all things to all users.. Its a firewall.. And its FREE as well.. But there are plenty of ways to skin this cat already - if you want pfsense to add this as feature - put in a feature request, or put out a bounty for the package - and maybe someone would create it.

[lohphat]

@johnpoz I still don't think you're following.

NetGate makes SMB grade non-consumber gateways.

It's a GATEWAY not just a firewall. Gateways have other functions, you know like DNS blocking (pfBlocker) and IPS/IDS (snort/suricata). Its not just moving/blocking raw packets. So are you saying pfSense should not remain competitive and stop innovating? If so, thanks for the warning.

In medium sized orgs there are potentially hundreds or thousands of certs which affect the business -- internal certs and external certs.

As on operations person, if a critical vendor we use becomes inaccessable because THEY forgot to renew a cert, it's my duty to the business to look out for failure modes. I have experience this sort of outage when our payroll processor forgot to renew and we couldn't safely connect to them to get checks to employees -- it was a frantic few hours dealing with a problem (which wasn't our responsibility) to get their IT team to acquire and update their web servers.

There are existing products which do just this -- capture and tabulate certs passing through the org and have the ability to alert based on parameters when to alert the org that certs in use (internal and external) are about to expire.

That's all I asked about.

So I'll take your answer under advisement that your product line isn't an appropriate solution for businesses which need a more functional gateway.

[lohphat]

@jimp Agreed.

That's why I asked the question to begin with. If someone had brought up the issue and what the current state was, and "it's probably apprpriate as a package" is a perfectly acceptable reply.

Thank you.

[johnpoz]

@lohphat said in Potential pfSense feature/package: Monitor Cert expiry:

capture and tabulate certs passing through the org and have the ability to alert based on parameters when to alert the org that certs in use (internal and external) are about to expire.

And what devices are these? Give one example please. You want your magic box to auto detect that hey internet is accessing this site on my network.. Oh by the way I peaked into the server hello and check that cert that was exchange and its going to expire in X days.. I should warn the admin of this box..

This monitoring service or feature would have to make its own connection to determine if the cert is going to expire - that short of info is not in the clear in modern tls/ssl handshake that ids/ips could see. TLS 1.3 pretty sure now encrypts the certificates - so how would this system even see the certificate to check the valid dates on it?

from the rfc 8446

• All handshake messages after the ServerHello are now encrypted.
  The newly introduced EncryptedExtensions message allows various
  extensions previously sent in the clear in the ServerHello to also
  enjoy confidentiality protection.

Lets say you you could get this info, who say the firewall admin would even care because he doesn't manage the certs on the at box - that is managed by the server team, etc.

As mentioned maybe you could get a IDS/IPS package to do something like that.. But with 1.3 I don't even see that working.. Without doing a mitm, and if your doing that - might as well host these certs in your reverse proxy and do ssl offload, which you could then get warnings of.

Or this magic box would have to see oh, some traffic from the internet was sent to box behind me, and via the sni (which will also be hidden with esni or its replacement ech) would have to make its own connection to get the cert so it could check if going to expire.

Ideas of doing xyz on the surface might seem simple - Oh if it could do that, that would be slick. But when you dig into how that something could work - its not so simple ;)

If you have lots of certs that are not part of pfsense and you want to monitor if they expire - that cat has already been skinned a dozen different ways.. Use of of those those tried and true skinning methods. Normally a enterprise that has lots of certs in their org, already have monitoring setup to make sure the site it up, that certs meet criteria, that they are valid, will they expire soon - and setup alerting to the interested/responsible parties, etc. I just don't see this a something pfsense should add.. But hey put in that feature request, or bounty..

[lohphat]

@johnpoz

Huh.

https://sematext.com/blog/ssl-certificate-monitoring/

[johnpoz]

@lohphat said in Potential pfSense feature/package: Monitor Cert expiry:

https://trackssl.com/

Yeah like I said - gave sim links.. That doesn't listen for traffic on your firewall and say oh let me check that cert - you have to tell it the fqdn to test, and it tests it on a schedule.

That is $9 a month - I gave 2 free services to do that, and a self hosted way also free.

[johnpoz]

@lohphat said in Potential pfSense feature/package: Monitor Cert expiry:

https://sematext.com/blog/ssl-certificate-monitoring/

None of those tools sit on the firewall and intercept what ssl traffic is passing and test if the cert is expiring..

@lohphat said in Potential pfSense feature/package: Monitor Cert expiry:

capture and tabulate certs passing through the org

You have to set them up, many of them not free.

Again that example script I gave could in theory be setup on pfsense to monitor stuff - but it would all have to be configured, it can not just capture and tablulate anything.

Again most orgs that have lots of certs should already have that monitoring setup.. Now a package that you could host say my example cron script actually on pfsense might something - put in a bounty.. But my guess is there is already a docker for such a tool out there that would just be easier to run for the org on something else in their network - and not on their firewall.

edit: here is a docker already to go
https://hub.docker.com/r/dariko/docker-ssl-cert-check

[lohphat]

@johnpoz

These products have been around for over a decade and as with most tech, it commoditizes -- just like pfSense has which before would be an expensive commercial option.

It is NOT unreasonable for this functionality to have been considered as extended functionality for the pfSense environment. Either natively or as a package.

I wanted to see where this topic was and if historically it has been discussed. It seems reasonable that enough time has passed for an OSS solution to emerge. Thus it's why I posted the question in the first place -- to see where things sat.

I apologize if asking questions is too distracting.

[johnpoz]

@lohphat your more then welcome to implement a package ;) if you feel something like this should run on your firewall..

If there was such driving want for such a thing on pfsense, and it was so easy to implement - curious why it already hasn't been done..

Maybe because its normally not worth it to open up a burger joint next to a wendys and burger king and McDonald.

Like I said this cat has already been skinned long time ago.. I don't see how adding such a feature would bring all the boys to the pfsense yard - but hey if you can make the best milkshake ;)