• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Resolved sw server and TLS

DieterWerner

Regular Pleskian
After each plesk update, the file:

/etc/sw-cp-server/conf.d/ssl.conf
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;

has been overwritten with:
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_protocols TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;

and that means:
sw-cp-server don't start and services like drweb can't work

I changed the permissions of ssl.conf to 444 but the file was overwritten anyway.
 
I don't see why the service should not start if TLSv1 is not part of the protocols??? What exactly is logged when trying to start the service?
 
Two different things. It might be that DrWeb cannot handle it, but sw-cp-server does not depend on it. As always, important question not answered: "What exactly is logged when trying to start the service?"
 
As always
As always the people don't know the specific command/s.
Would be extremely nice if you build them a bridge, with the help of the respective command. :p:D
eg:
fictive answer to another topic pfeif.gif
What is shown by systemctl list-unit-files | grep enabled && systemctl --user list-unit-files | grep enabled
ausserirdi.gif
or by
systemctl --state=failed
 
Last edited:
Two different things. It might be that DrWeb cannot handle it, but sw-cp-server does not depend on it. As always, important question not answered: "What exactly is logged when trying to start the service?"
The important question is:
why can the file /etc/sw-cp-server/conf.d/ssl.conf (permissions: 444) be overwritten.
 
Interesting question. I also wondered about the behavior you posted here and another which is much more strange in my opinion, due to the fact that /etc/nginx/conf.d/ssl.conf will be also overwritten by specific updates. Not the whole file, only the ciphers and protocols. Think, it happens exactly at the same time when /etc/sw-cp-server/conf.d/ssl.conf is changed. I didn't know about your problem, but it is so similar that it must arise at the same time.
In conclusion, I don't wonder anymore about it, because it seems to be the expected behavior.
 
....I didn't know about your problem, but it is so similar that it must arise at the same time. In conclusion, I don't wonder anymore about it, because it seems to be the expected behavior...
These changes can be made by Plesk in other locations as well as those that have already been mentioned. You would normally expect any customised cipher / protocol values to remain precedent over any default Plesk values, but... ;) Example: When renewing a Multi-Domain *Wildcard Plesk Host Domain SSL Certificate, but, manually and without using the Plesk Let's Encrypt Extention (as the present version of the extention doesn't support that specific type of Let's Encrypt Certificate renewal yet). You need to double check afterwards and where appropriate, overwrite any Plesk default cipher / protocol values (again!) with any of the previous modifications that had been made.

As you say @Servus it's only the cipher and protocol details, not other items. After the certificate renewal process example mentioned above (assuming, that customised cipher and protocol changes had previously been made) the the locations would be: Postfix: main.cf file Dovecot: 11-plesk-security-ssl.conf etc.

We're not sure that this is actually a bug @DieterWerner as it's just Plesk applying their own default security values regardless, to specific files they 'control'. It's a bit more like, a "...be aware" piece of information really, because if you are aware, then it's easy to check and amend after any Plesk (or Plesk controlled) updates.

Off topic for a moment @DieterWerner :) For security reasons, TLSv1.0 isn't actually supported by nearly everybody now and even TLSv1.1 is pretty antiquated. In a "best setup / perfect world scenario" you would be completely TLSv1.3 together with TLSv1.2 as a backstop / legacy support, but only the Plesk Onyx 17.9 Preview Release actually supports TLSv1.3 by default at present, so many people (us included) are using TLSv1.2 only whilst waiting.

We don't use it, but whoever is responsible at Plesk for configuring the DrWeb service to still require TLSv1.0 needs to have a word with themselves and very quickly, play catchup / issue a upgraded release for those that do use it. There's a lot of other things too, that are currently well out of date in Plesk :rolleyes: Fingers crossed, Plesk will "update" these soon for everyone's benefit and peace of mind.
 
Very good explanagen; Thanks!
But it doesn't answer the question:
"why can the file /etc/sw-cp-server/conf.d/ssl.conf (permissions: 444) be overwritten?"
 
...But it doesn't answer the question: "why can the file /etc/sw-cp-server/conf.d/ssl.conf (permissions: 444) be overwritten?"
:D:D Very true and to be honest, we don't know either.

Yes, theoretically, it shouldn't be possible...but maybe, it's intentional, because remember, it was originally a 644 permissions, Plesk created file, which has a notable amount of control over Plesk (admin) itself. Only Plesk can provide the correct answer to your question, but having said that, assuming that you do make pre-upgrade backups / run a diff on the old and new files after an upgrade or another comparison process etc then it's still easy enough to spot and correct now isn't it?
 
Back
Top