Identifying certificates, their purpose and expiration dates? 1

[AvayaGuy72]

I work for a managed service company as an Avaya Engineer and was put in charge of documenting all the certificates and when they will expire. The obvious certs that I would ID would be Avaya certs but since some customers have CPODs using VM I would think there are Microsoft certs as well as others that need identified too.

I don't know much at all about certs and I'm looking for the best way to find this information and how best to document them. Any suggestions where to start in this huge, unknown space? What Avaya servers/services have certificates that stand out to you that I should know about?

Thanks in advance!

Oscar

 

[kyle555]

In a perfect world, if SMGR was the CA for everything, you'd be able to see that between the Certificate Authority section of System Manager as well as the Inventory page.

For elements that enroll with System Manager via trust management, they appear in the inventory and you can click one, and 'other actions' and 'manage identity certificates' and for a SM for example, you'll see 5 - one for the SIP interface, one for the PPM, one for database replication to System Manager, etc

You'd be best to ensure your alarming is configured to SAL and possibly your NMS but also to System Manager itself. That way, at least in System Manager's alarm table you'd be able to see when any SM or other Avaya app would send an alarm saying it's cert will expire in 120/90/30 days.

There's ways to check manually. If you like, just crack open firefox and go to

https://yourSM100:5061

It'll never load, but it will try a TLS handshake and you can see the certificate in there. You can do that for any IPort/service like AES's secure DMCC or TSAPI interfaces too.

If you feel like doing it in bash...

https://www.shellhacks.com/openssl-check-ssl-certificate-expiration-date/

$ echo | openssl s_client -servername shellhacks.com -connect shellhacks.com:443 2>/dev/null | openssl x509 -noout -dates

 

[AvayaGuy72]

Thanks Kyle! That's territory I haven't explored. I haven't found the perfect word yet so I'll get started on the areas you identified.

 

[kyle555]

At the very least, you can validate alarming. In Home / Services / Configurations / Settings / SMGR / TrapListener, you can see where SMGR listens for traps it'll display in it's events/alarms viewer.

In Inventory/Serviceability Agents if you add a SNMP Target Profile of SMGR's IP/port 10162/v2 community and then go into your Serviceability Agents and add Assign that Profile to them, you can tell your elements to send their alarms to SMGR. Or to SAL. Or to some other NMS.

And if you're later than 6.3.8ish you also have Notification Filter Profiles where you can say "for SMs, in this whole list of traps a SM can possibly send, build filter AvayaGuy72CertSafetyNet and tick the boxes for traps just related to certificates. Then you can add a SNMP Target to "The Company's NMS that opens tickets" and tell your SMs to send only alarms of type AvayaGuy72CertSafetyNet to Company NMS

You can build those filter profiles for whatever elements SMGR supports as a serviceability agent to configure their alarming.
At the very least, you can get it in your own SMGR dashboard, and in a more perfect world, you can send those alarms to central systems so you wouldn't need to worry about managing a calendar.