Facebook
Twitter
-
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
SSL Support
- Thread starter danallen1
- Start date
-
- Tags
- ssl ssl replacement
Hi Dan,
I'm sorry to hear that you've had such a bad experience with buying SSL certificates. We know about the issues with our Marketplace, and we are already working on changing the workflow for buying domain names and SSL Certificates - it should be very clear and understandable for all customers, and problems like yours should never arise.
Please let me know your Order ID and contact e-mail, so that we can contact you and reissue your cert. You can PM me directly if you don't feel like sharing this information publicly. Thanks.
I'm sorry to hear that you've had such a bad experience with buying SSL certificates. We know about the issues with our Marketplace, and we are already working on changing the workflow for buying domain names and SSL Certificates - it should be very clear and understandable for all customers, and problems like yours should never arise.
Please let me know your Order ID and contact e-mail, so that we can contact you and reissue your cert. You can PM me directly if you don't feel like sharing this information publicly. Thanks.
danallen1
Basic Pleskian
Thank you, Custer, that is awesome. I'll send the info in a minute.
I don't know if you can address a question about the SSL process. I am wondering whether there is any reason why the process of receiving and installing a certificate cannot be automated. Installing these things is biggest pain.. part of that is due to not understanding some basics, and I am going to address that for myself. I am thinking that once I understand the basics, it should be possible to automate the process from start to finish.
When I say automate, this is what I mean.
You guys should do this and send me $2 for every cert installed this way, unless you already had this figured out.
Can that be done? I am thinking, of course it can be done. So, why isn't it? Why does it cost $30 to have the CA's computer send email to authenticate a cert request? That is pretty expensive email. The only value they add is to authenticate the request for a cert. They do it with an email. Somebody is making a lot of money on this. I can provide the same authentication, certs of equal quality, and deal with the CA audit requirements for $20/email and make a fortune, especially if the cert can be installed automatically, who would want it any other way? Got to buy my way to having my root cert built into browsers, that is the hurdle. I am few $million short on the cash that would take. You guys can jump that and you should.
Am I nuts?
I don't know if you can address a question about the SSL process. I am wondering whether there is any reason why the process of receiving and installing a certificate cannot be automated. Installing these things is biggest pain.. part of that is due to not understanding some basics, and I am going to address that for myself. I am thinking that once I understand the basics, it should be possible to automate the process from start to finish.
When I say automate, this is what I mean.
- Click to buy. hint: who needs a choice of CAs? What is needed is a good price. If the CA's root cert is in carried by the usually named browsers, FireFox, Chrome, IE, Safari,and Opera, that is all that matters. Pick one CA. Sell that one. Make sure the price is near the bottom of the heap. You do not need to maintain multiple relationships with CAs. What you do need is a simple process for getting these not just bought but installed, and you might need a CA to work with you on that.
- Email sent to domain owner or authorized person to authenticate the cert request
- Recipient of email clicks the link
- Cert is installed.
You guys should do this and send me $2 for every cert installed this way, unless you already had this figured out.
Can that be done? I am thinking, of course it can be done. So, why isn't it? Why does it cost $30 to have the CA's computer send email to authenticate a cert request? That is pretty expensive email. The only value they add is to authenticate the request for a cert. They do it with an email. Somebody is making a lot of money on this. I can provide the same authentication, certs of equal quality, and deal with the CA audit requirements for $20/email and make a fortune, especially if the cert can be installed automatically, who would want it any other way? Got to buy my way to having my root cert built into browsers, that is the hurdle. I am few $million short on the cash that would take. You guys can jump that and you should.
Am I nuts?
Last edited:
@danallen1
You literally asked:
The answer is NO, in the sense that obtaining and installing a certificate could be easier.
Should it be easier? NO.
First of all, an automated installation is just the opposite of increasing security.
Second, certificate authentication by mail validation is not that safe: a smart hacker hacks the server first and would authenticate by mail, without you ever knowing it.
Third and final, why automate something that actually does AND should require attention from the sysadmin?
In short, there is never an easy way, when it concerns security.
Certificates are no exception.
By the way, I am (on the one hand) not surprised by your reaction, given the reactions of all parties involved and (on the other hand) rather surprised by all the fuss.
Really, there is no reason to ever use the buttons in Plesk to buy external products.
To be honest, all buttons are leading you to a too expensive product and/or service.
A small tip before buying anything: compare prices, offers and features and be aware that it is never "cheap" (or smart) to buy at Enom or Godaddy (some of the Odin partners).
Regards.....
You literally asked:
The answer is NO, in the sense that obtaining and installing a certificate could be easier.
Should it be easier? NO.
First of all, an automated installation is just the opposite of increasing security.
Second, certificate authentication by mail validation is not that safe: a smart hacker hacks the server first and would authenticate by mail, without you ever knowing it.
Third and final, why automate something that actually does AND should require attention from the sysadmin?
In short, there is never an easy way, when it concerns security.
Certificates are no exception.
By the way, I am (on the one hand) not surprised by your reaction, given the reactions of all parties involved and (on the other hand) rather surprised by all the fuss.
Really, there is no reason to ever use the buttons in Plesk to buy external products.
To be honest, all buttons are leading you to a too expensive product and/or service.
A small tip before buying anything: compare prices, offers and features and be aware that it is never "cheap" (or smart) to buy at Enom or Godaddy (some of the Odin partners).
Regards.....
Dan,
Have you heard about Let's Encrypt (https://letsencrypt.org/)? It's a new SSL CA that will be offering properly signed SSL certificates. We are now testing a Plesk extension that allows users to create proper CA-signed SSL certificates issues by Let's Encrypt for their domains via one click:
Something tells me this should address the usability problems that you have, what do you think?
Have you heard about Let's Encrypt (https://letsencrypt.org/)? It's a new SSL CA that will be offering properly signed SSL certificates. We are now testing a Plesk extension that allows users to create proper CA-signed SSL certificates issues by Let's Encrypt for their domains via one click:
Something tells me this should address the usability problems that you have, what do you think?
Attachments
@custer
Thanks, for bringing that up, I was already aware of the efforts of E. Kazakov and the intention to create the extension.
However, can you elaborate on that? Where to find, where to find the documentation, where to find the beta version of the extension etc.
Some questions of a whole different order:
a) you are using the "API Client" approach with the extension, if I am not mistaken. At least, the code of E. Kazakov does.
This kind of approach has been available for some time, the Plesk API can be used to install certificates and automation of this process is possible.
However, I am not quite sure about using API calls in this case, I have my doubts.
Can you answer the question whether the extension is using API calls? If so, what is the specific reason for that and/or what are the considerations behind this approach?
b) Letsencrypt is, more or less, in an alpha/beta phase and contains the letsencrypt binary.
It seems to be the logical step to use the binary on the server-side, without any API calls: hence, the question in point a.
It also seems to be the case that letsencrypt has some automatic configuration options, i.e. automatic configuration of Apache and Nginx (experimental).
Are you going to implement these automatic configuration options in the extension?
c) in general, I am in favour of the letsencrypt binary, certainly given the fact that letsencrypt has the (default) option of the automatic renewal of certificates.
In essence, the letsencrypt binary seems to be a candidate to be part of the core packages of Plesk.
I assume that the current extension is intended to test letsencrypt in the Plesk environment, followed by an inclusion in the core packages of Plesk.
Is that assumption correct? Are you planning to include letsencrypt in the core packages in the long run?
Hope that you can answer the various questions above...
Regards....
Thanks, for bringing that up, I was already aware of the efforts of E. Kazakov and the intention to create the extension.
However, can you elaborate on that? Where to find, where to find the documentation, where to find the beta version of the extension etc.
Some questions of a whole different order:
a) you are using the "API Client" approach with the extension, if I am not mistaken. At least, the code of E. Kazakov does.
This kind of approach has been available for some time, the Plesk API can be used to install certificates and automation of this process is possible.
However, I am not quite sure about using API calls in this case, I have my doubts.
Can you answer the question whether the extension is using API calls? If so, what is the specific reason for that and/or what are the considerations behind this approach?
b) Letsencrypt is, more or less, in an alpha/beta phase and contains the letsencrypt binary.
It seems to be the logical step to use the binary on the server-side, without any API calls: hence, the question in point a.
It also seems to be the case that letsencrypt has some automatic configuration options, i.e. automatic configuration of Apache and Nginx (experimental).
Are you going to implement these automatic configuration options in the extension?
c) in general, I am in favour of the letsencrypt binary, certainly given the fact that letsencrypt has the (default) option of the automatic renewal of certificates.
In essence, the letsencrypt binary seems to be a candidate to be part of the core packages of Plesk.
I assume that the current extension is intended to test letsencrypt in the Plesk environment, followed by an inclusion in the core packages of Plesk.
Is that assumption correct? Are you planning to include letsencrypt in the core packages in the long run?
Hope that you can answer the various questions above...
Regards....
Hey!
First of all you should understand that letsencrypt upstream utility won't work on the server with Plesk out of the box: it writes apache/nginx configuration files, the same Plesk does - only the one master is required
The idea of the letsencrypt-plesk plugin is fully delegate to Plesk a dealing with web servers. In this role Plesk is much more stable - it does it for years, there is no experimental but complete support of both apache and nginx.
From that point of view we have fixed the behavior of the utility preserving its UX. There is no issues with architecture here, isn't it?
Now we have a 3d-party utility that does amazing things and we want UI integration in panel. The proper solution is implementing PHP client for LE CA - but it is about a month of work and its further API maintenance. On the other hand the functionality has already been available in the official utility.
So that is the logical solution could give us quick results - we can release with LE general availability and support already released Plesk version, or do you prefer to wait at least for a year for next Plesk version?
What if I tell you there won't be any features in Plesk core anymore? Only extensions will have a valuable feature-set. Will you believe me? It is a joke, but I'd expect such evolution.
According to the automatic renewal - it is just a crontab job, we create it easily, don't worry.
Sum up, I do not regret API usage here. I cannot imagine any other reason we develop it and preserve backward compatibilities in versions.
First of all you should understand that letsencrypt upstream utility won't work on the server with Plesk out of the box: it writes apache/nginx configuration files, the same Plesk does - only the one master is required
The idea of the letsencrypt-plesk plugin is fully delegate to Plesk a dealing with web servers. In this role Plesk is much more stable - it does it for years, there is no experimental but complete support of both apache and nginx.
From that point of view we have fixed the behavior of the utility preserving its UX. There is no issues with architecture here, isn't it?
Now we have a 3d-party utility that does amazing things and we want UI integration in panel. The proper solution is implementing PHP client for LE CA - but it is about a month of work and its further API maintenance. On the other hand the functionality has already been available in the official utility.
So that is the logical solution could give us quick results - we can release with LE general availability and support already released Plesk version, or do you prefer to wait at least for a year for next Plesk version?
What if I tell you there won't be any features in Plesk core anymore? Only extensions will have a valuable feature-set. Will you believe me? It is a joke, but I'd expect such evolution.
According to the automatic renewal - it is just a crontab job, we create it easily, don't worry.
Sum up, I do not regret API usage here. I cannot imagine any other reason we develop it and preserve backward compatibilities in versions.
@EugeneKazakov
I can imagine that the API approach has many advantages and I certainly see the value of the backward compatibility.
By that, I mean: I fully understand the approach and I am aware of the fact that there even is a necessity to work-around the potential issues, arising from conflicts between (on the one hand) the Plesk Nginx and Apache templates and (on the other hand) the adjustment of config files, made by letsencrypt.
However, there is a strange irony in having the API open, in order to allow for uploads/activation of letsencrypt certificates: opening the API will make the whole Plesk ecosystem rather vulnerable, certainly when taking into to account that outsiders can upload their own certificates and mimick "certificate security".
In your python scripts, you have some code that essentially can be viewed as an "API Client wrapper".
I really wonder whether it is not faster to create (python) code that simply gets the letsencrypt certificate and stores the certificate on disk: the letsencrypt certificate can be easily set to be the active certificate, with Plesk related command line tools and/or with simple "move" commands and/or with "symbolic links".
It would certainly result in "clean code", since most of the lines of code can be discarded, in specific the code related to the API Client.
Sure, I must admit that I do not actually know the code behind the "letsencrypt Plesk extension", but I can safely assume that it is based upon your python scripts.
If the above is a correct assumption, then my humble opinion would be that the python scripts and the certificate process are overly complicated.
Naturally, all the above is intended to be positive feedback, in the sense that it can be some food for thought.
Regards....
PS I suggest to start a personal conversation, if we want to discuss the extension and/or potential directions of development in more specific detail.
I can imagine that the API approach has many advantages and I certainly see the value of the backward compatibility.
By that, I mean: I fully understand the approach and I am aware of the fact that there even is a necessity to work-around the potential issues, arising from conflicts between (on the one hand) the Plesk Nginx and Apache templates and (on the other hand) the adjustment of config files, made by letsencrypt.
However, there is a strange irony in having the API open, in order to allow for uploads/activation of letsencrypt certificates: opening the API will make the whole Plesk ecosystem rather vulnerable, certainly when taking into to account that outsiders can upload their own certificates and mimick "certificate security".
In your python scripts, you have some code that essentially can be viewed as an "API Client wrapper".
I really wonder whether it is not faster to create (python) code that simply gets the letsencrypt certificate and stores the certificate on disk: the letsencrypt certificate can be easily set to be the active certificate, with Plesk related command line tools and/or with simple "move" commands and/or with "symbolic links".
It would certainly result in "clean code", since most of the lines of code can be discarded, in specific the code related to the API Client.
Sure, I must admit that I do not actually know the code behind the "letsencrypt Plesk extension", but I can safely assume that it is based upon your python scripts.
If the above is a correct assumption, then my humble opinion would be that the python scripts and the certificate process are overly complicated.
Naturally, all the above is intended to be positive feedback, in the sense that it can be some food for thought.
Regards....
PS I suggest to start a personal conversation, if we want to discuss the extension and/or potential directions of development in more specific detail.
