@molyfra I just checked the site and everything seems to be working on this end.
I can appreciate where you are coming from. Push back is expected and we are prepared to answer all of the hard questions. We do business regularly with Fortune 50 and Fortune 500 companies, governments, and some of the largest churches in the world. As the project sponsor we have approved resources for the development of this site and considered giving the service away free of charge. Market research tells us that more people are likely to use this service if they pay something for it. The most compelling argument for this is one that you touched on. People who pay for something have a reasonable expectation of service and the standing to demand something in return for what they paid. This is not the case if something is free of charge.
There are two service agreements on our site. The first is ours. That is the one that is being reviewed by a our legal representation and will be available in October. The other one is for Letâs Encrypt. Customers agree to both by using our service to manage Letâs Encrypt certificates.
We are already making updates for key retrieval steps to eliminate email from the process. The feedback here has mostly been very constructive and we look forward to anything that might help improve this service. It is worth repeating that this service in not targeted at Linux users. We see this as an opportunity to gain support from people who are otherwise paying for their certificates somewhere else. If this effort is successful then it serves this communities purposes well by extending itâs reach and financial support.
As an organization we are coming up on our five year anniversary. A lot of what we have done has been private consulting and training. It is clear to me, now, that our corporate website needs some attention, which has not been the case in the past. We have relatively few large clients, as opposed to many small to mid-sized clients, so marketing has not been a high priority. It appears as though this project will bring us a new level of visibility, so I will dedicate some resources to improving our website and social media. I sincerely appreciate your input.
I believe weâve already had a similar discussion on this forum about another service that generated private keys on usersâ behalf Â-- on the serviceâs machine. This is not a security best practice and I find it reasonable to criticize it because the key material is exposed to the service operator, to their infrastructure provider, and to anyone who can compromise either. Thereâs nothing in the design of TLS or the web PKI that should require all of these entities to be trusted with access to private key material.
There are other services that use Javascript to generate the private key inside the userâs browser. While this is still not as safe as generating it directly on the machine where itâs going to be used, I think this is the right path for services that are committed to having an in-browser UI for the entire key generation process without any external steps or commands. As people have pointed out at great length on other forums, we still have an integrity and transparency issue because itâs not straightforward to verify that the web app itself is genuine and uncorrupted for a particular user at a particular time, and not selectively replaced with a malicious version that leaks the keys somewhere or deliberately generates predictable or otherwise vulnerable keys (like by mis-seeding a CSPRNG). But for pure server-side key generation, there will never be any possible means of verifying any of these properties, or that the server didnât keep a copy of the private key, so weâre far worse off without a hope of remedying it.
@kclinger5, I think you could take a look into how other web-based clients have handled this part and see if you can shift where the private key generation happens through judicious use of Javascript. Thatâs ultimately the main thing that people have been worried about on this thread from a security point of view â not your motivation or goals or vision for the project.
The BRs outright forbid CAs from ever "archiving" (ie keeping copies of) private keys but don't go as far as to just outlaw generating them. However Mozilla's "Problematic Practices" document, which Let's Encrypt was asked to read and comment on (e.g. highlighting any practices it had which were identified as problematic) does include:
CAs must never generate the key pairs for [...] SSL certificates
"Certificate Automation" is not a CA, so at their strictest application that rule doesn't apply to them. But I think it makes sense for Let's Encrypt to at the very least make clear that it doesn't approve and maybe even look at adjusting the subscriber rules to spell out that setups like this are the Wrong Thing â˘
@schoen You have a valid concern. As I said before, this product is not aimed at this audience for use. We will do what we can to make it more secure and apply recommendations we can, but the people using this service are doing so for cost and convenience. They are not aware that there is a remote possibility that somebody is sniffing their traffic at the right time to intercept critical data like many in this forum are unaware of the operating system back doors that make this conversation moot. We encourage Linux users to use Letâs Encrypt command line tools.
We have had conversations with many people who see Javascript as a vulnerability. We cannot appease everybody, no matter how hard we try. We considered an âin browserâ solution and chose this path as a way of offering more features to end users.
We have almost completed our first system update which eliminates the files being transferred over email and provides a secure one-time link for curl commands and a secure download of the files within a login session.
We are doing everything we can to make this product secure for non-technical people. We are targeting an audience that would not use the command line Letâs Encrypt tools. We accept that there will always be critics of this service. That is to be expected with anything.
@tialaramex We considered this, also. Since the user initiates the creation of the key, and can have it deleted on the server, it is no different than if the user's key was in their email account. Did I mention that we don't want Linux people using this service? It is not meant for people who can run the Let's Encrypt commands. We have a common vision of making computing more secure.
I think it is great that there are so many people watching out for the security of others. We accept that this service is less secure than using the command line tools for Let's Encrypt. We are offering the choice of convenience and lower costs to people who want it. What we kept coming back to was this question: "Is is simple enough for my mom to use?"
We admit that the best practice is to use the Let's Encrypt command line tools. This is for people who will not use the command line tools.
With the popularity of cloud and outsourced hosting today, we're in kind of a chaotic situation for cryptographic security, because it's very hard for people to exercise direct control over their key material or the physical or administrative context where it's used or stored.
It's extremely common that computers not physically owned or controlled by a subscriber (and in some cases not even administered by the subscriber) are storing and using the subscriber's keys on their behalf.
Many of these computers may not even physically exist, but can just be VMs or containers running on actual physical computers. (We know that has its own further risks because of things like cache attacks that have been documented by security researchers in recent years: it's difficult for current architectures to achieve proper isolation between virtualized systems that hides cryptographic operations from other software on the same machine.)
Speaking for myself, what I don't like about tools like the current Certificate Automation design is that they introduce a new additional trusted party (and multiple trusted network transfers of key material) into the system, on top of all of the existing ones; that goes against the goal of trying to reduce the number of trusted entities in the system. But it's not clear that it introduces a qualitatively new vulnerability for users who are going to turn around and upload their private keys to someone else's computer. They're already saying that they're going to let someone else access their key material in order to help them provide a TLS service. (Maybe the "someone else" is usually a bigger company that has more resources to put into information security?)
I can try to find out whether Let's Encrypt wants to express itself somehow on this question.
Iâm still not quite sure what those âmany more featuresâ exactly are⌠Your site isnât advertising more than just the text âmanagement dashboard, email support, and installation instructionsâ (the other âââservicesâ"" already come with Letâs Encrypt by default).
Canât login again, HTTP 500 error, so I canât actually check it for myself⌠AgainâŚ
@schoen You make some valid points. The common concern seems to be that we need to reduce the number entities involved. I think it is fair to say that if somebody uses any third party CA or even services like Certificate Automation then they are making the conscious decision to add that person into the equation. We can criticize them for that decision, but ultimately it is their decision.
All of the features of Let's Encrypt are not available in any of the browser or graphical tools. Our next update will add a field that will allow users to pass Let's Encrypt arguments for the certificate creation. Of course we will take great caution to prevent any kind of injection or command expansion. We are experimenting with a drop-down feature right now. Also, our development server will be available starting this weekend for people to test our environment with the staging server to become familiar with the environment before they commit to using the service.
I prefer to focus on specific issues if you have them. Your last couple posts have lacked clarity somewhat. For example, I said that we wanted to offer "lower costs" and you rebutted with a free service rather than acknowledging that most of the service charge an unjustifiable amount for an SSL certificate. Again, no claim was made that we were the lowest cost option. Also, we were comparing "Certificate Automation" to "Certify," but then you started comparing "Certificate Automation" to "Let's Encrypt." I just want to make sure that we can have an efficient conversation. My plate is quite full at the moment, but responding to sincere colleagues is something I will always make time for.
*By the way, I noticed that "Certify" is also in "pre-release." I am interested to know they will remain a no-charge option. From their website: "Warning: This is pre-release software for testing and feedback and is not intended for general use."
At the end of your message you touched on something valid: The HTTP 500 error. I sent a message off to see if somebody can remedy the login issue. I am sure that the team will get that fixed quickly. If I don't hear back right away I will go check the logs, but it was not my intention to work on this project again until Monday. However, a simple announcement of a company project seems to have landed its entire defense and justification for existence into my daily routine. I am finishing up a project I have been working on this weekend, so I should be able to dedicate more time to addressing all of the recommendations, complaints, and insults next week.
The point I was trying to make was simple: I'm not seeing any clear advantage your (paid) service is offering besides the (free) ones which already exist. (I understand you have market research which said people were more inclined to use a paid service in stead of a free one..) And your site doesn't make that very clear to me. Perhaps some simple screen shots or video of how "Certification Automation" would work could help.
We are working on some screenshots and videos now. I completely agree that this is the fastest way to bring awareness about a product or service.
In all fairness, the example you provided is pre-release. Ours is also free until the 5th of November when we will start charging for our service. We may have been the first ones working on a graphical client for Let's Encrypt. Until about three months ago, there have not been any full-time resources committed to this project. We would chip away at it here and there, but then we finally just wanted to make it happen; so we did.
Our site does not just create certificates. It also enables users to manage all SSL certificates. It is a central management console for all of their SSL certificates that sends reminders about expiration and renewal (without having to setup a cron job separately).
Every year users will need at least four certificates to provide secure web services, so they can generate those certificates at their convenience without having to pay for each certificate. Users are paying for a year of service based on the number of certificates they have. That means that for $7.55, or less, they can make a certificate and renew it as many times as they need during their subscription. They are also able to renew and revoke their certificates whenever they want.
The domain verification feature alone makes our system a lot more convenient. We email a verification file and tell the user where to put it. Once they have done that they click on the "Verify" button and the process is complete.
Keep checking back to see the updates. I am confident that you will see our value additions, especially when you consider that this product is not made for anybody who would use the Let's Encrypt command line tools.
Your website indicates that your client will cost money after Nov. 5. An obvious way to improve your service is to keep it free forever for ordinary website certificates, as Let's Encrypt itself is free. Perhaps a desire for money (inappropriate in this context) blinds you to this obvious improvement. If you expect people to pay, you are going to have to include a list of benefits over all the other ACME clients that are free, in each announcement that you make.
Just my opinion.
Also, your home page misspells the common English word "protect". You don't run a spelling checker over your web pages? Weird.
Also, your home page and FAQ page omit the list of webservers that your client supports, and any other limitations.
@david7364 Certificate Automation was designed to work on all major browsers. As we encounter limitations we will eliminate them or list them for all to see.
Thank you for helping to improve our site. The typo was fixed as soon as you mentioned it previously. You have a keen eye, as you were the only user to find a typo so far.
For your opinion we are grateful. I have already stated several times in this thread that Linux users are NOT our target audience. When we generate certificates for the certificateautomation.com website, which runs on a distribution of GNU/Linux, we use the command line version. This browser client extends the Letâs Encrypt service to non-Linux users.
The idea of Free Software pre-dates the Linux kernel and is more about access than cost. Red Hat is an excellent example of a company that charges for training and support for a modified version (distribution) of GNU/Linux. Most of the Linux kernel developers are paid contributors. I invite you to read this to see how your opinion about selling this service being âinappropriateâ is not congruent with the philosophy of free software.
We are not selling certificates. We offer a value added service to help create, revoke, and manage certificates. You can pretend to know the intentions of the contributors to this project, but âdesire for moneyâ was not a motivation that was even discussed, even though this project represents a significant investment of time and money. Until very recently charging for this service was not even considered. We started entertaining the idea only because we have market research shows that more people will use it if we charge something. SSL upside down is 755, so we used this as the basis for our pricing, which actually goes down to just a few cents per certificate for Enterprise/Reseller subscriptions that produce hundreds of certificates using our service, but $7.55 at the most for one certificate. (Which is actually as many certificates as the user wants for a domain within an annual subscription, not just one certificate.)
In conclusion, if a non-technical person (like my mother) wanted a certificate we want to offer a service that is simple enough for such a person to use.
The significant question is which web servers are supported and which are not (for Windows alone, web servers include IIS, Apache, NGINX, and lots of tiny servers such as Mongoose). Only the OS and web server can execute privileged software such as an ACME server. The browser is not an issue; one would expect all 'modern' browsers to support any browser-based client.
This attitude is exactly why you need to provide a list of currently implemented servers and clients. No one wants to spend time learning about a product just to find out after download and experimentation that their OS or web server is incompatible with the product! IMO, you must provide a list of host OSs and web servers that are implemented so far, in your FAQ or home page. That is essential.
You haven't actually stated that you have implemented anything at all as yet. My advice is not to announce your service for real until it can handle most of your expected customers. This means most common versions of Linux running at least Apache (I may be wrong that this is the most common kind of OS and web server).
Choosing a price at random does not seem like good business to me. A price should be calculated to provide a desired profit, after all costs and overhead are considered, using estimates of numbers of customers. Such a calculated price can be expected to be more likely to keep you alive in your business and to be more stable over time than an invented price--customers expect to see such stability. And if you provide a free 'no-frills' version that works for most popular systems, then I would consider my objection to charging money to be moot. I would be interested to know the rationale behind your calculation that the market would be larger if you charge money; this seems counter-intuitive.
I wonder if your Windows implementations are native, or if they create the usual requirement to install Python or other unusual (for Windows) software, or even to use Microsoft's .NET system. Such dependencies can create problems if a new version proves to be inconsistent.
Most of your answers, given only to me here, need to be added to your FAQ, IMO. Thank you for allowing me to provide this feedback, and I apologize for any mistakes I have made. I wish you luck with your enterprise.
Users will need certificates for web or mail servers and they will find our solution, which has a low total cost of ownership and is simple to use. (At this point they may not have heard about the Letâs Encrypt project.)
Users then learn that by using Linux they can acquire the same certificates without any kind of a fee and learn enough Linux to use certbot, or some of the other free command line tools.
They will tell all of their friends and the Linux community will grow.
We see the advantage of a list of supported OS and web server software that will use these certificates. We only have a few items left before we advertise our service, and that is one of them. This post is the ONLY place that this project has been published, so far. We have created some social media pages, but have not promoted them at all until we feel completely confident that we have included everything first.
We welcome all constructive criticism of our project. Your input is valuable for gaining perspective from the outside in and I sincerely thank you for taking the time to share your thoughts.
