MidServer takes a long time to fully start after upgrading to San Diego when running as non-admin user

[Rodrigo Renie]

After upgrading our instances from Quebec to San Diego, MidServer takes a long time to fully start when running as a non-admin user. I've followed all the procedures to run as non-admin user specifically for the San Diego release and this problem persists. After it starts, the service works as expected, it just takes quite some time to start.

When running as non-admin (see log agent0.log.as_non_admin.0.txt attached), you can see in the logs that it takes over 20 minutes between theses two lines:

05/17/22 16:36:40 (965) MIDServer JVM default socket factory: class com.service_now.mid.security.policy.PolicyBasedSSLSocketFactory
05/17/22 16:59:01 (474) MIDServer Integration crypto failure protocol=HTTPS javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated: peer not authenticated

But simply by removing the non-admin user from it's service configuration, ie running as Local System user (see agent0.log.as_admin_local_system.0.txt attached), the same log entries occurs within seconds:

05/17/22 16:31:49 (191) MIDServer JVM default socket factory: class com.service_now.mid.security.policy.PolicyBasedSSLSocketFactory
05/17/22 16:31:53 (724) MIDServer OCSPCheck adding BouncyCastle provider at -1

[Sagar Pagar]

Hi,

Please check the old thread and supportive docs. hope it will help you.

MID Server takes extremely long time to return results

MID Server cannot connect to ServiceNow instance, error in agent log: org.apache.commons.httpclient...

Thanks!

Sagar Pagar

[Rodrigo Renie · Accepted solution]

Service Now support has helped solved the issue. The probleam was caused by our company's SSL Inspection, which causes the CA Root Certificates from our instance to be replaced by the firewall's internal one and, because of that, the MidServer is unable to verify it.

Here a link explaining the situation: https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0863673#mcetoc_1fqntl21fkj

In order to solve this issue, I had to apply the workaround described in this KB:

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0864766