<div dir="ltr">Hey folks,<div><br></div><div>Long story short, does anyone know how CVP OAMP monitors for changes to the security.properties file?  Is there a way to fool the system into thinking it hasn't changed?</div><div><br></div><div>We were trying to add CA signed certificates to CVP OAMP in our non-production environment and things got a bit out of hand... Somehow the security.properties file got modified with no backup taken.  I've since learned that CVP somehow monitors this file and rewrites the hash every time it detects that it has been changed, then updates the keystore password to match.  It does NOT update the Tomcat startup options stored in the registry, so this breaks all web services.</div><div><br></div><div>I can fix it by changing the security.properties file and keystore to match the registry hash, but whatever anti-tampering mechanism that is in place detects the change and rewrites the hash after the next service start.  If I restart the service after that, it breaks again.  I've also tried changing the registry and server.xml files for each Tomcat service to match the new security.properties hash, but Tomcat always fails with an improperly padded key error.  I also tried changing the Created/Modified dates on the keystore and security.properties file to match the initial server install, but the anti-tampering detection seems to key off something else.</div><div><br></div><div>Are we hosed?  Is there a way to fix this permanently without reinstalling the OAMP server?</div></div>