Hi,
Our end user of our plugin is running into this exception -
Java.security.cert.certificateException: Server certificate
chain is not trusted and thumbprint doesn't match
I was wondering if I could get some insight into this issue; (@laurentsd, I read some of your community posting about similar issues and it appears that we have our plugin thumbprint format right and it looks like our setup is clean and according to the guidelines. Also, we are not able to reproduce the end user's issue in house which makes it difficult for me to explain the issue with any greater clarity)
My question is when does the virgo web client container enforce this security measure and how could a plugin (both the plugin download from an extension server part and subsequent end point api calls to an extension server) run into this exception. From our service layer, all api calls that we make to our server goes through https but via a "trust all certificates" and hence we do not generate this exception. But clearly calls that originate from the Objects view => Data adaptor => Our service end point calls clearly throw this exception in our end user's site. We have a self signed certificate.
Further characterization of the issue
1. This issue happens only in setups that have Linked mode VC. User has 2 VC's in Linked mode each with its own web client service running and with 2 of our VC-extension servers serving the same (our) plugin (we ensured that the thumbprint from both of our servers is the same so that no matter which extension server ends up serving the plugin).
2. The plugin is working for the end user from one of the web clients (i.e. https://webclientservice1:9443 works and shows our plugin and https://webclientservice2:9443 does not show our plugin). What is even more disconcerting is that logout and login to webclientservice1 breaks https://webclientservice1:9443 too. Restarting the services makes one of the web clients work fine but ends up breaking the other. (Which one works depends on which web client was started first). One important thing is it always shows our plugin extension in both the web clients which suggests that the download of the plugin was not the issue but subsequent api calls were the problem.
Any pointers on what thumbprint the container is comparing with and where it stores it would be helpful. Is there any directory we can clean to force it to reestablish the thumbprint and allow service calls to go through would be a useful pointer.
Any help or insight into this exception is appreciated.