Cisco devices must regenerate self-signed certificates before 2020

So the user must still connect the self-signed certificate when connecting to the device (over ssh for example).

So in this case the user generates the certificate and also accepts it.

By the way, most ssh clients will tell you if a certificate changed. So the moment your self-signed certificate is compromised you will know.

Ugh.

We built a DB to track them; nothing special, it sends email reminders. Been meaning to just publish calendar reminders, but haven't gotten to it.

We also check expiry dates on the live certificates via one of our monitoring systems (Zabbix, but this isn't a built-in check) that will start yelling, I think, 2 weeks before expiry.

you can also build scanner yourself on top of nmap and store discovered certs in one DB and link it with your configuration management db

If you have any sort of monitoring system in place, it should also be able to check for certificate expiration (or "validity" in general). Even the old antiquated nagios has had this ability since the dawn of time.

As a sort of last resort and/or where no other solution is in place, you can do what I did on a customer's network a few years ago. Fortunately, there wasn't much "security" in place (internally, at least).

nmap can easily 1) detect/identify TLS and 2) produce "grepable" output.

I simply gathered a list of all IP subnets that were in use and scanned all of it. Afterwards, it was fairly simple to go through the results and figure out which hosts were running services using TLS on which ports.

There are existing tools that can connect to services using TLS and gather the information from the presented certificate. If you can't find one that does what you need, that's no big deal, it really doesn't take much to write your own tool just for this purpose.

(In fact, something like this -- running on a host that has access to connect to all of your TLS services -- might be nice to have even if you have a "proper" solution in place. If (when?) something falls through the cracks, you'd have this as a sort of "fallback" or "backup" to alert you to anything your proper solution might have missed.)

[0] https://spiffe.io/

It's very likely just somebody harcoded a date "in the distant future" in some OpenSSL config file or script that generates the self-signed cert.

I'm having trouble trying to come up with any link between the two.

---

In my opinion, with the exception of perhaps very small networks, no one who's "doing it right" should really be affected by this issue.

I can kinda maybe understand folks using self-signed certificates for VPNs but, really, if you're doing much at all with certificates you should either be running your own internal PKI and/or getting certificates by somewhere else.

My previous employer had literally hundreds of devices using their own self-signed certificates (for device management) on them. Many of them were the "default" certificates that shipped on the devices, so it was the same certificate shared across hundreds of devices. As someone who gives a shit about security, that drove me absolutely nuts but no one else gave a damn. (Even worse, since nearly all of these devices used the same credentials, you'd only need to MITM one of them in order to "pwn" damn near everything on the entire network!)

For stuff like web tools that might happen by least effort, but for SSH it's a bunch of extra effort, 90% of the effort of doing it properly, yet with almost none of the security benefits. Anybody who cares will use their own CA and be unaffected, anybody who doesn't care never enabled certs for SSH on the Cisco boxes.