SSL error after reboot on Linux Plastic proxy server

[Johan Ung]

Hi, got a strange error that I cannot get my head around.

Have a Plastic Proxy server installed under Ubuntu Server 16.04 and it works great, until I reboot the system.

After reboot I get errors in the proxy server log file:

2017-09-04 17:49:56,014   ERROR PlasticPipe - Error happened trying to SSL to ssl://xxx:8088. The authentication or decryption has failed.
2017-09-04 17:49:56,014   ERROR PlasticPipe - Failed to negotiate remoting SSL with ssl://xxx:8088. Will try starting a TCP connection then switching to SSL
2017-09-04 17:49:56,094   ERROR PlasticPipe - Error happened trying to SSL to ssl://xxx:8088. The authentication or decryption has failed.
2017-09-04 17:49:56,094   ERROR CacheHandler - An error occurred trying to retrieve the license type of server [ssl://xxx:8088] : Server ssl://xxx:8088 does not support SSL

If I manually restart the plasticcachesd service it works again.

I tried disabling the service from starting at boot and running a delayed script that starts plasticcachesd after 30 sec, but still the same error. If I manually login to the server and start it, it works.

Any ideas?

[calbzam]

Hi,

I guess you are restarting only the Proxy Server machine but the Plastic server is in a different machine right? If I properly uderstand, after rebooting the proxy serve, it is not starting and you need to manually run the script. It's strange because the same script should be run during the reboot.

Are you using the default installation so you haven't customized any script, right?  I will run some test in my Ubuntu machine.

Regards,

Carlos.

[Johan Ung]

Yes that is correct. It's a standard installation and yes, proxy server only on this machine. It a COMODO certificate (PositiveSSL).

[Johan Ung]

I eventually used /opt/plasticscm5/mono/bin/certmgr to add my certificate(s) to trusted certs, now it works. Would be interesting to know the reason for the original issue  though.

[manu]

On 9/4/2017 at 6:00 PM, Johan Ung said:

If I manually restart the plasticcachesd service it works again.

How did you do that? Using another system user?

All that comes into my mind is that the system is starting the daemon with a user not having the certificate installed (or an invalid one) and you are running the daemon using a user already having the certificate accepted.

[Johan Ung]

I logged on and ran:

sudo /etc/init.d/plasticsd restart

This starts the plasticd with the same parameters and user as the system does att boot up, in both showing up (ps command) as:

plastic+  1337  1.3 35.6 3733632 2540924 ?     Sl   Aug24 362:36 plasticd /opt/plasticscm5/server/plasticd.exe --daemon

Strange indeed.

[manu]

 Really strange... in theory both process are executed by the "plastic" user...

Well, is anyone faces this problem you pointed out how to solve it... Just manually install the certificate using the "/opt/plasticscm5/mono/bin/certmgr" tool.