- My View
We have a requirement to relate Certificate data discovered on our servers with CI records. In our view, certificates aren't Assets or CIs as their management is covered by a separate Process (not Config or Asset Mgmt) and their attributes to be recorded are different enough to warrant their one records. I'm aware of the sys_certificate table and we do have data on there that relates to the ServiceNow instance itself. My question is, from a Platform Architecture perspective, is there any thoughts against using this to store Certificate data discovered on servers and relating it to those server CIs? Should this table be left purely for internal use? Thanks in advance for your input.
We have a very strong policy against using system tables to store enterprise data: generally speaking, the people involved in managing certificates are very different from the people who manage the ServiceNow instance. I would recommend very strongly against using an internal configuration table for this type of data.
We have actually created a table under cmdb_ci to store Certificate data and added the attributes there (Common name, Hash algorithm, Bit length, Cert manufacturer, etc.). That way we can leverage the CI to CI relationship types to relate the Cert CI to servers or Business Applications that they secure. We do consider Certificates CIs in our environment.
Thanks for the feedback, Dave. I'll mull this over. I understand the reluctance to utilise sys* tables, so will consider another existing table, the creation of a similar one or enforcing governance to restrict access to the certificate records used by the platform itself. A separate table seem the sensible option.
Each Organisation has a view of what constitutes a CI. As a primary purpose of Config Mgmt is to manage the relationship between Services and the components necessary to deliver them, it seems like that's a valid place to store the records. As Certificates have a lifecycle and (often) a cost, as discreet items of data they seem to align more closely with Asset Mgmt. As you highlight, the value comes from being able to relate them to infrastructure, Applications (and ultimately Services), so as long as the records can be related I guess it's an individual decision in which table they reside.
That does give me good insight into your decision and the reason why, so thank you for sharing your experience.
I am assuming that you are referring to SSL Certificates? in Asset you could be discussing the Data Eradication / Destruction Certificates issued per drive removed for replacement or at system decommission time.
If you are discussing SSL Certificates - I would recommend that they do follow standard ITIL Processes (Request, Deploy, Remove) as they do expire - and require a process to monitor and update if necessary.
So - I have implemented these for several clients as CMDB Records with 'Installed On::Has Installed' relationship to the system that it is is placed on. (M2M for certain certificates also).
If you simply want to do a 'Certificate dump' - you could look to utilization of the Managed Documents feature - and add a M2M relationship table between the document and cmdb so you can maintain the relationship accordingly. This will allow you to track versions - alternatively - you could simply utilize the 'attachment' option on a CI Record.
I can provide additional guidance and assist if needed.
Success is not a place at which one arrives, nor is it a definition. Success is the process you engage which sets the direction that your journey will take you.
Thank you for the detail.
We are also facing this challenge in our organization and would prefer using CMDB class to store Certificate data and manage it through Asset process.
Currently ServiceNow do not have certificate class which we can utilize. Could you please elaborate more on this part?