Troubleshooting ACC Plugin signing certificates - Support and Troubleshooting

Troubleshooting ACC Plugin signing certificates .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Table of Contents Certificate included with the installer Prior to ACC-F 4.3.1, the included certificate is now expired Since ACC-F v4.3.1 and v5.0, a newer certificate is included: How older Agents update the certificate How the SNCertificates.zip gets on the MID Web Server Custom signing certificates Example of Certificate Chain error for a Custom ACC Plugin Related Documentation All Agent Client Collector features and Applications have ACC Plugins (aka Sensu Assets) that contain the actual scripts that are run in the Agents.

These are signed, and out-of-box ACC Plugins from these features use the "ServiceNow Inc." code-signing certificate.

Certificate included with the installer Prior to ACC-F 4.3.1, the included certificate is now expired ACC Agent installs prior to ACC-F v4.3.1 included this certificate, which has now expired, since 23 August 2025. C:\ProgramData\ServiceNow\agent-client-collector\config\cert\SNCertificate_2025.cer

This is backed up by an intermediate and root certificate from Digicert.

And that DigiCert Root CA Certificate is usually included in Windows:

If the acc.log has an error like this: 2025-05-07T13:22:32.89 [ERROR] [asset-manager] [certificate validation failed: x509: certificate signed by unknown authority] Certificate validation failed for C:\ProgramData\ServiceNow\agent-client-collector\config\cert\servicenow\SNCertificate_2025.cer

Then that Digicert CA certificate is missing, and you should use: KB2119772 Agent Client Collector - Asset Certificate Validation Failed causing host data collection failure - DigiCert CA Certificate missing on agent host

Since ACC-F v4.3.1 and v5.0, a newer certificate is included: C:\ProgramData\ServiceNow\agent-client-collector\config\cert\SNCertificate_2028.cer

This expires 2nd April 2028. It uses the same certificate chain as before. It is identical in every way, except for the Valid to, and Thumbprint values.

The file format is Base64 X.509 (.cer), and includes the intermediate and root certificate as well.

If that has synched to the Agent correctly, you would expect to see it validated successfully too in acc.log. This is a Linux example, with Debug enabled:

2025-12-02T13:39:02.33 [DEBUG] [agent] [certificate] Validating the certificate [/etc/servicenow/agent-client-collector/cert/customer/SNCertificate_2028.cer] against the trust store 2025-12-02T13:39:02.33 [DEBUG] [agent] [certificate] Certificate 0: Subject=ServiceNow Inc., Issuer=DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1 2025-12-02T13:39:02.33 [DEBUG] [agent] [certificate] Certificate 1: Subject=DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1, Issuer=DigiCert Trusted Root G4 2025-12-02T13:39:02.33 [DEBUG] [agent] [certificate] Certificate 2: Subject=DigiCert Trusted Root G4, Issuer=DigiCert Trusted Root G4 How older Agents update the certificate This logging was confirmed using a ACC-F v3.5.3 Agent install, with an instance running the ACC-F v5.0.0 App.

After install, but before the Agent first connects to the MID Server, this is the only signing certificate present on disk: C:\ProgramData\ServiceNow\agent-client-collector\config\cert\SNCertificate_2025.cer

Once started, the data collection starts, and it needs to download assets for the check of that policy, starting with acc-visibility-modules:

[INFO] [https://10.190.132.7:8800/static/acc_plugin/windows/all/all/all/acc-visibility-modules.tar.gz] [asset-manager] [200 OK] finished fetching asset [INFO] [asset-manager] Successfully validated hash of file using sha512 on downloaded asset.

But then it fails on the certificate it had from the installer, which we know has now expired:

[ERROR] [agent] [x509: certificate has expired or is not yet valid: current time 2025-09-01T03:59:34-07:00 is after 2025-08-22T23:59:59Z] [certificate] certificate validation failed [INFO] [agent] [certificate] WARNING: This certificate has expired.... [C:\ProgramData\ServiceNow\agent-client-collector\config\cert\SNCertificate_2025.cer] [ERROR] [asset-manager] [certificate validation failed: x509: certificate has expired or is not yet valid: current time 2025-09-01T03:59:34-07:00 is after 2025-08-22T23:59:59Z] Certificate validation failed for C:\ProgramData\ServiceNow\agent-client-collector\config\cert\SNCertificate_2025.cer [ERROR] [asset-manager] Could not determine a valid CA signed certificate to verify signature, aborting Asset signature verification [ERROR] [asset-manager] [ Could not determine a valid CA signed certificate to verify signature, aborting Asset signature verification] Signature verification failed for asset with existing certificates

So it then automatically requests the newer ones from the MID Server:

[INFO] [asset-manager] FetchCertificates: Requesting certificates list from the MID Server [INFO] [https://10.190.132.7:8800/api/mid/mon/certs] [asset-manager] [200 OK] finished fetching asset [INFO] [asset-manager] FetchCertificates: Starting to download certificates from the MID Server [INFO] [https://10.190.132.7:8800/static/cert/servicenow/SNCertificates.zip] [asset-manager] [200 OK] finished fetching asset [INFO] [asset-manager] Successfully validated hash of file using sha512 on downloaded asset. [INFO] [asset-manager] FetchCertificates: Got no custom certificates from MID server [INFO] [asset-manager] Finished with downloading and installing certificates from the MID server

The cert\servicenow subfolder is created by that, and populates it with 2 certificates, the same old one, plus a new one expiring in 2028:

C:\ProgramData\ServiceNow\agent-client-collector\config\cert\servicenow\SNCertificate_2025.cer C:\ProgramData\ServiceNow\agent-client-collector\config\cert\servicenow\SNCertificate_2028.cer

It now tries to check the code signing again, using the original expired one again first:

[ERROR] [agent] [x509: certificate has expired or is not yet valid: current time 2025-09-01T03:59:34-07:00 is after 2025-08-22T23:59:59Z] [certificate] certificate validation failed [INFO] [agent] [certificate] WARNING: This certificate has expired.... [C:\ProgramData\ServiceNow\agent-client-collector\config\cert\SNCertificate_2025.cer] [ERROR] [asset-manager] [certificate validation failed: x509: certificate has expired or is not yet valid: current time 2025-09-01T03:59:34-07:00 is after 2025-08-22T23:59:59Z] Certificate validation failed for C:\ProgramData\ServiceNow\agent-client-collector\config\cert\SNCertificate_2025.cer [ERROR] [agent] [x509: certificate has expired or is not yet valid: current time 2025-09-01T03:59:34-07:00 is after 2025-08-22T23:59:59Z] [certificate] certificate validation failed [INFO] [agent] [certificate] WARNING: This certificate has expired.... [C:\ProgramData\ServiceNow\agent-client-collector\config\cert\servicenow\SNCertificate_2025.cer] [ERROR] [asset-manager] [certificate validation failed: x509: certificate has expired or is not yet valid: current time 2025-09-01T03:59:34-07:00 is after 2025-08-22T23:59:59Z] Certificate validation failed for C:\ProgramData\ServiceNow\agent-client-collector\config\cert\servicenow\SNCertificate_2025.cer

But now it uses the new ones it just downloaded from the MID Server too:

[INFO] [asset-manager] Certificate is valid, will use this certificate for verification : C:\ProgramData\ServiceNow\agent-client-collector\config\cert\servicenow\SNCertificate_2028.cer [INFO] [asset-manager] Successfully verified plugin with signature and public key [INFO] [asset-manager] Expanding asset to path: C:\ProgramData\ServiceNow\agent-client-collector\cache\acc-visibility-modules

It goes on to download and check the other assets successfully, and then Data Collection works.

The Agent does this because the Agent property 'fetch-certificates-from-mid' defaults to True even when it is not explicitly set in acc.yml. However if it set false it will not download from the MID Server.

How the SNCertificates.zip gets on the MID Web Server From the above, you can see the Agent gets the latest certificates from URL /static/cert/servicenow/SNCertificates.zip on the MID Server it is currently connected to.

ACC Plugins, and Configuration files are synched to the MID Server from records in the instance, but this is unusual in being downloaded directly from the install server.

The static folder in the URL equates to the agent\static of the MID Server install. e.g. https://10.190.132.7:8800/static/cert/servicenow/SNCertificates.zip C:\MID_SERVER\agent\static\cert\servicenow\SNCertificates.zip

As soon as the ACC Endpoint MID Server Extension is added to the MID server, and started, that ZIP file is downloaded from the Install server here: https://install.service-now.com/glide/distribution/builds/package/app-signed/agent-client-collector-framework/SNCertificates.zip

The documentation refers to the code in the ACC Endpoint extension that does this as "the monitor": Synchronization properties for validating Agent Client Collector plugins

As of November 2025, that's a 9,468 bytes file, containing:

25/03/2025 18:09 6,991 SNCertificate_2025.cer 09/04/2025 13:53 7,098 SNCertificate_2028.cer This is the same Install server that the MID Server gets its own upgrade zip files from, and that Agents download installers from when doing a self-upgrade. If the MID Server can auto-upgrade, then it should also be able to download this. It's IP address pair are documented here: https://www.servicenow.com/docs/csh?topicname=t_DownloadMIDServerFiles.html&version=latest (As of 1 November 2025: 149.96.5.98/149.96.6.98.)

That server uses the same Digicert SSL certificate as hosted instances:

An example of a MID failing to download SNCertificates.zip If the MID Server doesn't have the file, then the older Agents can't get it either.

Here is an example of a MID Server agent log, when the download to the MID Server failing due to certificate chain checks, indicating an inspection/interception firewall, that substituted a fake certificate, is being used on the customer's network:

INFO (Worker-Standard:MonitoringProbe-xxx) [ZipDownloader:74] Downloading file to C:\ServiceNow_MID\ServiceNow MID Server xxx\agent\static\cert\servicenow\SNCertificates.zip from https://install.service-now.com/glide/distribution/builds/package/app-signed/agent-client-collector-framework/SNCertificates.zip INFO (Worker-Standard:MonitoringProbe-xxx) [FipsLogger:69] Integration crypto failure protocol=HTTPS javax.net.ssl. SSLPeerUnverifiedException: peer not authenticated: peer not authenticated INFO (Worker-Standard:MonitoringProbe-xxx) [FipsLogger:69] Integration crypto failure protocol=HTTPS javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated: peer not authenticated INFO (Worker-Standard:MonitoringProbe-xxx) [FipsLogger:69] Integration crypto failure protocol=HTTPS javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated: peer not authenticated INFO (Worker-Standard:MonitoringProbe-xxx) [FipsLogger:69] Integration crypto failure protocol=HTTPS javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated: peer not authenticated WARN (Worker-Standard:MonitoringProbe-xxx) [HTTPClient:830] Socket error WARN (Worker-Standard:MonitoringProbe-xxx) [CertDownloadMonitor:35] There was an exception downloading the certificate from install server

Custom signing certificates Customer certificates for Custom ACC Plugins, could also expire and cause the same sort of errors as above. Checks using those would not run. The certificate would just need renewing in this situation, and that new certificate copying to the MID Server static folders again.

Docs page Manually refresh Agent Client Collector certificates states:

"Ensure that the self-signed certificate is placed in a .zip file on the MID Server in the following location: agent\static\cert" "Ensure that the certificate authority is part of the agent host's truststore, as the certificate chain is validated before the customer plugin signature." The docs don't mention sub-folders, and there is no requirement for the certificate to be in a subfolder, but customers often add custom certificates in a sub-folder named 'custom' to help identify their own.

"self-signed certificate" doesn't really mean that, as if it were truly a self-signed certificate with no certificate chain at all, we'd have no way of validating if the certifiacet was a valid one in the first place. It means a certificate generated by the customer, and should be a proper one backed up by a public or internal CA.

For Windows, "the agent host's truststore", would mean the Trusted Root Certificate Authorities, in the Certificates control panel applet.

Any .zip files in that static\cert folder, and also subfolders of that, should get synched to Agents connected to that MID Server.

If the certificate is not wrapped in a ZIP file, the MID Server's agent log will show warnings similar to the following, and those will not be synched to Agents. GZipped Tarballs are not ZIP files. For zip files that are fine, you won't see any logging in the mid server logs:

WARN (MidCertificateDownloadMonitor.86400) [MidCertificateManager:69] ignoring file 'customer/sign.crt'' due to missing .zip extension WARN (MidCertificateDownloadMonitor.86400) [MidCertificateManager:69] ignoring file 'customerXYZ.tar.gz'' due to missing .zip extension

You may also see that warning for folders, which is a product defect PRB1945995, and theses ones can be ignored:

WARN (MidCertificateDownloadMonitor.86400) [MidCertificateManager:69] ignoring file 'servicenow'' due to missing .zip extension WARN (MidCertificateDownloadMonitor.86400) [MidCertificateManager:69] ignoring file 'customer'' due to missing .zip extension WARN (MidCertificateDownloadMonitor.86400) [MidCertificateManager:69] ignoring file ''' due to missing .zip extension

The ".86400" on the thread name means this is a scheduled job that runs every 24 hours. That might mean that new files added by customers are not noticed by the ACC Endpoint extension for up to a day after being added, and so Agents might not get them synched for up to a day? - TBC

The file format of SNCertificate_2025.cer is Base64 X.509 (.cer), so using the same format and file extension will avoid format problems. SNCertificate_2025.cer includes the intermediate and root certificates in the same file. That makes it actually a .pem PEM Bundle file, but given a .cer extension so that Windows recognises it as a certificate.

It's not clear if intermediate and root certificates need to also be included in the file, or just need to be in the trust store of the host. - TBC

Example of Certificate Chain error for a Custom ACC Plugin Here we see the custom certificate fail because it can't find the custom certificate's issuer in the host's trust store. It then only has the ServiceNow certificate let to use, which will fail against the custom Asset.

[DEBUG] [asset-manager] Adding directory to garbage tracking: /tmp/sensu-asset42848733 .. [DEBUG] [agent] [certificate] Validating the certificate [/etc/servicenow/agent-client-collector/cert/customer/XXXX-acc-plugin-signing.crt] against the trust store [DEBUG] [agent] [certificate] Certificate 0: Subject=sn-XXXX-acc-plugin-signing, Issuer=XXXX XXXX [ERROR] [agent] [x509: certificate signed by unknown authority] [certificate] certificate validation failed [ERROR] [asset-manager] [certificate validation failed: x509: certificate signed by unknown authority] Certificate validation failed for /etc/servicenow/agent-client-collector/cert/customer/XXXX-acc-plugin-signing.crt ... [DEBUG] [asset-manager] Selecting certificates for signature validation .... [DEBUG] [asset-manager] selected cert [0] : [/etc/servicenow/agent-client-collector/cert/customer/SNCertificate_2028.cer] [DEBUG] [asset-manager] Completed selecting certificates for plugin signature validation.. [ERROR] [asset-manager] [error verifying plugin with public signature: plugin verification failed: crypto/rsa: verification error] Signature verification failed for asset with existing certificates

Related Documentation Secure a custom plugin with a certificate - Main page Create and edit Agent Client Collector plugins How to create a custom ACC Plugin (aka Asset) Enable OpenSSL secure signing for plugins - Explains how to sign a custom plugin Manually refresh Agent Client Collector certificates - Explains where to put your own signing certificates on the MID Server, and how to prompt Agents to then fetch them. Synchronization properties for validating Agent Client Collector plugins - Properties to control the behaviour in the MID Server and Agent