• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Resolved Why Plesk try to force users to use Symantec SSL certificates

virtubox

Regular Pleskian
Plesk Guru
Hello,

I really love the integration of Let's Encrypt in Plesk, and I also love the extension security advisor to make easier the migration from http to https on wordpress websites.
But if I was already thinking if the third panel of Security advisor was really useful or not for normal users (because http/2 should be enabled by default and the plesk interface should be automatically protected with a SSL certificate) , other informations like KernelCare or Patchman were already very commercial.

So, I do not understand why Plesk enable by default the Symantec SSL certificates buttons , and require to use the panel.ini editor extension to disable it.
At first because , it 's already hard enough to explain to our customers the fact than let's encrypt provide the same level of security than any paid certificates, but also because Symantec is not really a good choice. They are selling their SSL certificates business to Digicert due to several security issues with their Certificate Authority in the past :

Timeline: Symantec certificate authority improprieties

If I do not have anything against the Symantec extension in Plesk, I do not think it should be enabled by default or promoted in Plesk.
 
@virtubox

Your statement

If I do not have anything against the Symantec extension in Plesk, I do not think it should be enabled by default or promoted in Plesk.

is completely correct, I fully agree.

Even though it is quite common that Plesk endusers require specific types of certificates (EV, DV and so on) and/or that Plesk Inc. wants to offer a simple service......

........it is still is not right that Plesk Panel becomes a sort of advertising channel for Symantec.

For that reason, I will assign a like to your post.

Regards.......
 
Hi.

We fully share your love of Let's Encrypt and plan to actively continue the development of our Let's Encrypt extension. In fact, we have released a new version of Let's Encrypt yesterday ( Change Log for Plesk ).

However, we are also aware that some customers need things that cannot be provided by Let's Encrypt - for example, OV and EV certificates. Symantec SSL extension is currently the only extension in our catalog that can address these needs in automated way, so we've integrated it with our Security Advisor to help those customers who have these needs.

We're aware of the past issues with Symantec CA and we'd like to note that Symantec SSL extension offers certificates by GeoTrust, Thawte and so on. If you don't trust Symantec, you can purchase certificates issued by the authorities you trust, including Let's Encrypt - we're definitely not forcing anyone to buy Symantec certificates.

If you don't want to see the "Secure" buttons, you can modify your server/VPS deployment scripts and tell Security Advisor do not suggest Symantec certificates.
 
@Ruslan Kosolapov

I would like to opportunity to respond to some of your statements.

We fully share your love of Let's Encrypt and plan to actively continue the development of our Let's Encrypt extension. In fact, we have released a new version of Let's Encrypt yesterday ( Change Log for Plesk ).

The new release is brilliant!

I would really recommend to be more specific on this forum about the new features!


However, we are also aware that some customers need things that cannot be provided by Let's Encrypt - for example, OV and EV certificates.

True...........and it is good that this would be more explicitly mentioned on this Plesk forum, because not everybody seems to be aware of "normal" certificates.

For instance, any webshop should not simply implement LE certificates, it is often better (and sometimes required!) to implement an EV or other type of certificate.

If you don't want to see the "Secure" buttons, you can modify your server/VPS deployment scripts and tell Security Advisor do not suggest Symantec certificates.

The suggested solution, as such a work-around, is not a good solution: it is likely that an upgrade or patch will undo any changes, this besides the fact that it is often a very bad idea to mess with the nature of the default scripts, as shipped with Plesk or it's extensions.

Nevertheless, a work-around is a work-around and if it helps, it helps.

But why not implement a feature that allows to check one checkbox that disables or enables specific certificate suggestions?

Symantec SSL extension is currently the only extension in our catalog that can address these needs in automated way, so we've integrated it with our Security Advisor to help those customers who have these needs.

Are you implying that other SSL issuers will also be allowed if there is some way of implementing a solution in a Plesk Extension?

I really am interested in the honest answer to the above question.

Kind regards.......
 
Hi.

We fully share your love of Let's Encrypt and plan to actively continue the development of our Let's Encrypt extension. In fact, we have released a new version of Let's Encrypt yesterday ( Change Log for Plesk ).

However, we are also aware that some customers need things that cannot be provided by Let's Encrypt - for example, OV and EV certificates. Symantec SSL extension is currently the only extension in our catalog that can address these needs in automated way, so we've integrated it with our Security Advisor to help those customers who have these needs.

We're aware of the past issues with Symantec CA and we'd like to note that Symantec SSL extension offers certificates by GeoTrust, Thawte and so on. If you don't trust Symantec, you can purchase certificates issued by the authorities you trust, including Let's Encrypt - we're definitely not forcing anyone to buy Symantec certificates.

If you don't want to see the "Secure" buttons, you can modify your server/VPS deployment scripts and tell Security Advisor do not suggest Symantec certificates.

The issue (in my opinion) isn't to provide an extension to purchase SSL Certificates from Symantec (I understand some customers want EV certificates for their business), but to enable it by default in Security Advisor with the text "Free Let’s Encrypt SSL/TLS certificates provide a baseline level of protection" .

I have to install panel.ini extension on every Plesk initial configuration and to add the lines :
Code:
[ext-security-advisor] 
promoteSymantec = false 

[ext-catalog] 
contextAds = off

@Ruslan Kosolapov

For instance, any webshop should not simply implement LE certificates, it is often better (and sometimes required!) to implement an EV or other type of certificate.

I do not agree on this point. An EV certificate will never be required (and should never be required) because it doesn't provide a better security or a higher level of encryption than a Let's Encrypt certificate.

Some (trusted) people are fighting enough against EV Certificates and all their issues :
Are EV certificates worth the paper they're written on?
 
@virtubox,

With respect to

I do not agree on this point. An EV certificate will never be required (and should never be required) because it doesn't provide a better security or a higher level of encryption than a Let's Encrypt certificate.

note that there are countries where it is required by law and/or required (for participating in "trusted webshop" programs, for instance) to have a EV (or better) certificate.

Moreover, what you (and most people) seem to forget is that a certificate is not only a "thingy with ciphers and numbers".

A certificate issuer offers a whole range of services .......... and one of them is assurance ("people, it is trusted and verified!")

and the most forgotten one is insurance.

Paying a specific amount to an insurance company or some small amount to a cerificate issuing company is not the same: a certificate with insurance is a better choice.

The problem is that these types of advantages are not valued by anybody, until the worst case scenario is happening.

Well, before you say "that worst case scenario often does not occur"........... it often does, but the other fact is that people do not know it: a good hack is virtually unnoticeable.

Actually, the second worst scenario is already happening: the huge degree of adaption and/or huge number of implementations of LE certificates.

It is just asking for trouble: reliance on LE makes one security loophole the gateway to a security breach in millions of sites using LE certificates.

In short, the attack vector is huge...........any hacker can just focus on LE in order to sniff traffic at millions and millions of sites.

And a good sysadmin therefore knows that he should not rely on a LE certificate for company critical applications.

Regards........

Not that a good sysadmin would host company critical applications with Plesk Panel .... it happens, but they really should not. ;)

 
Some (trusted) people are fighting enough against EV Certificates and all their issues :
Are EV certificates worth the paper they're written on?

This is another issue.

None of the certificates are worth the paper they are written on.

Security does not only entail certificates........security should be emphasizing all that creates a tiny moment of access to critical data, applications or servers.

The author you are referring simply states the same, but chooses to do so in a context of EV evaluation.

But really, he is not thé expert on the issue............ actually, the real experts are the ones designing the processes behind certification.

One should see it like this: a certificate is the key..........and that is barely relevant, it is all about the lock that is intended to keep people out.

A lock on a door in a wall in a home without a window open..........well, burglars are not focussing on the lock or the key, they just enter the open window. ;)

The real experts are the cryptographic geniuses.

And that is so old skool, in the sense that most certificates we are using right now are based upon cryptographic work in the 1970s.

If you are interested, try to read up on the work of Diffie Hellmann, on elliptic curve cryptography and on perfect forward secrecy.

So, you are right to say.......

"people are fighting enough against EV Certificates and all their issues"

but that really should be applying to the actual root cause of the problem: the considerable challenge to create almost perfectly secure certificates.

Now we can return to Let's Encrypt, both to the LE certificates and the organisation behind it.

The organisation behind LE is founded by some cryptographic geniuses, as a non-profit initiative for the better of (the security of) the internet.

The LE certificates are (almost) the best available in the business.

Nevertheless, LE certificates are failing in one area: anybody can claim a LE certificate ...........and that is bad.

It is better if companies and their owners are verified
.

AND that is the added value of what certificate issuers can do, since it is chosen policy of Let's Encrypt's organization to not do so.

As long as Let's Encrypt's organization will not opt for "personal or company verification", there is added value to all certificates other than those of LE.

To start a discussion about prices and/or about a comparison between LE and other certificate issuers......

....... well, that is not meaningful at all: the pure fact is that Let's Encrypt's organization will never choose to offer "personal/company verification", hence also allowing a lot of space for other companies to offer this type of service at the price they think is appropriate.

Regards.......
 
@virtubox,

One thing I have to mention, in relation to my previous post.

Let's Encrypt's organization seems to grasp the reality of the internet and some weaknesses.

As a result of that, they have chosen the right path in the form of a policy that does not entail "company/person verification".

One of the major weaknesses in the internet is that everybody is (directly or indirectly) able to register a domain under the name of somebody else.

That is a weakness in the area of the DNS registry of the internet.

The major consequence is that one can ask for a certificate that seems to suggest that somebody is another person, a trusted person.

Let's Encrypts organization does not really want to cater for this: their primary objective is to make traffic more secure.

Other certificate issuers have a mixed objective: they want to secure traffic with cheap and simple certificates and also reduce the probability of impersonification with the EV and various other types of (very) expensive certificates.

Banks are not allowed to have a simple certificate, the European law requires them to prevent any type of impersonification or misleading (even if the misleading is the result of actions by others that have malicious intents).

Banks are also liable for any mishaps...........so they are happy to pay a huge price for extended certificates, in order to reduce liability costs.

This is only one example of one type of party that really want to buy an extended type of certificate....... and many other examples can be given.


However, in the end it is always a matter of opinion and choice by the person or organization obtaining the certificate.

AND THAT allows us to return to the topic in this thread.


It is just a matter of choice............and we should have the freedom of choice.

It should not be suggested at all that we can only have one (paid-for) alternative for the (free) LE certificates.

For that reason, I am inclined to say that the Symantec links should be completely absent by default in Plesk Panel.
 
@virtubox

It should not be suggested at all that we can only have one (paid-for) alternative for the (free) LE certificates.

For that reason, I am inclined to say that the Symantec links should be completely absent by default in Plesk Panel.

This is the main point of this thread. Any website with a login form (including wordpress backend access) should be secure with a SSL certificate nowadays.
And letsencrypt make this process easier . Then if a company want to use an EV certificate , it's a choice.
 
@virtubox

This is the main point of this thread. Any website with a login form (including wordpress backend access) should be secure with a SSL certificate nowadays.And letsencrypt make this process easier . Then if a company want to use an EV certificate , it's a choice.

Correct.

But an even more startling point in this topic thread seems to be absent: Plesk offers Plesk Panel to hosting providers, enabling them in their business and/or supporting a very efficient and viable business model, whilst also taking away customers by offering to purchase good with Plesk or Plesk partners, instead of the hosting provider itself.

And that is a bit odd.........it is like saying: you pay us for Plesk Panel, which for an advertising channel for sales that you do not benefit by.
 
Indeed.. Anyone can claim an LE certificate and one could argue that LE is undermining the concept as a whole.

If DNS of a domain is compromised it's fairly easy to maintain a system that will semi-permanently have a fake LE-certificate without the owner even noticing.

All paid certificates lost some of its worth upon the acceptance of LE, although I still like that it happened.
 
Indeed.. Anyone can claim an LE certificate and one could argue that LE is undermining the concept as a whole.

If DNS of a domain is compromised it's fairly easy to maintain a system that will semi-permanently have a fake LE-certificate without the owner even noticing.

All paid certificates lost some of its worth upon the acceptance of LE, although I still like that it happened.

I agree, If DNS of a domain is compromised, it's possible too generate a fake LE-certificate. But that's the same with a paid certificate.
The main difference is in case of hack, LE certificates can be used during less than 90 days, when paid DV certificates can be used during up to 3 years.
It's also possible to automate the revocation with LE, when it's pretty hard with paid certificates.
 
Don't expect too much of revocation.
I have revoked a certificate almost a year ago and in Chrome you can still access that site without getting a warning as Chrome is not checking for that at all...
Yes, Firefox detects the revocation, but Chrome decided not to use it.

Indeed a shorter period for your certificates makes things better protected, but as long as your domain is not pinned to a certificate you can create a certificate everywhere.

A compromised DNS is not enough for the better paid certificates.
 
Don't expect too much of revocation.
I have revoked a certificate almost a year ago and in Chrome you can still access that site without getting a warning as Chrome is not checking for that at all...
Yes, Firefox detects the revocation, but Chrome decided not to use it.

Indeed a shorter period for your certificates makes things better protected, but as long as your domain is not pinned to a certificate you can create a certificate everywhere.

A compromised DNS is not enough for the better paid certificates.

About revocation, the OCSP Stapling is currently the best solution available.
For paid certificates, I was talking only about DV certificates, not OV and EV. But it's the same problem if the certificate and the private key are compromised.
 
Does anyone know how to remove it? I cant find any help Googling for it. I dont like having unused, unnecessary software on servers, I disabled or remove everything not used, its better for security and updates and performance, and of course ease of using the admin when there are less options.
Thanks
 
I have a different issue, I am new to this:

Hi

I am so frustrated

I had to update all my domains to the new Symantec SSL in Plesk months ago.
I was able to do that but it was hard to activate the BASIC SSL.

If I choose Canada as a country, it asks for a proper 'state code'
Canada does not have states, it has provinces, and it has postal codes, not zip codes. I find this all over on american sites, like we dont exist.

anyway, I just added a new domain today
and I cannot activate the Symantec SSL using the DIGI CERT SSL link in website hosting settings for that domain.
I tried everything
I always get the error in the 'state' field

I copied my 'who is info' on the site owner.

I wonder if this service from Symnantec is still working?

or can it be that my domain has not propogated fully yet?

I have the latest Plesk

any ideas?
thanks
 
Hi @Dennis Oppelt

DigiCert Extension (former Symantec Extension) has been developed by Symantec. I agree that the form validation is too strong, but, I guess, it's required by CA validation policy.

I'm also not so experienced with DigiCert CA, so, I'd suggest contacting DigiCert support about that.
Your description of the problem is clear enough, I hope DigiCert support can help.

PS: little spoiler - we have plans how to make such things clearer.
 
I resolved the activation issue. In the filed that says: "state"
I was supposed to use "AB" for alberta

but it is confusing, if you choose canada, it should change other fields to 'province' or postal code'

or more clear instructions
 
Back
Top