Problem #1: You keep changing vocabulary, using abbreviations, and shortening terms so what the heck you’re talking about is lost. I see terms like “cert”, “RSA”, “Ca” , “public key”, “private key” etc. but no effort to actually define or explain any of them. I understand that because you are familiar with the process, all this is simple to you, but to other people, it’s confusing. I even tried ZeroSSL, and while it did a bunch of stuff. I was left with about a half a dozen pages of text with absolutely no clue what I was supposed to do with them.
Like I said, I’m a web programmer. I’ve reverse engineered complicated web installations that other programmers have abandoned, so I’m not a web newbie. I even rewrote a customers entire site, using a programming language I learned as I worked. It’s like you guys go out of your way to make this confusing.
That’s the key “anyone using TLS” So you’re saying those terms are familiar to people familiar with using those terms.
I don’t have shell access. My hosting provider is HostGater, who will gladly charge $10 to install the free “certs” which may or may not expire in 90 days… And no, I’m not changing hosts. They may be jerks but I’ve got over 60 domains there, including several I’m hosting for other people. Google (also a bunch of jerks) is now classifying any site that takes passwords, but doesn’t have https, the same a malware sites. So I have to figure out a way for people to access their personal settings on sites that contain very little actual personal information, without having to pay tons of money for several dozen “SSL Certs”.
Let’s start with the term “cert”. So far I’ve seen as many as 4 different cryptic files, not one of which I’m sure is a “cert” because they all contain words that could easily be shortened to “cert”. The files also seem to be randomly referred to by any of a half dozen other terms, none of which have very much clarity about what specifically they are referring to. I have yet to s an ssl glossary anywhere that does assume you already know most of the terms they vaguely describe.
Programming is intuitive. Commands, for the most part, give clues to what and how they function, and once you get the feel for how the person who created that language thinks, the rest falls into place. All this ssl stuff is anything but intuitive. It looks as if it was invented by someone who wanted it to be as confusing as possible, so they could feel like there were part of an exclusive club.
Seriously, Wikipedia? Guess you didn’t hear what happened to Burger King when they made the mistake of depending on the veracity of Wikipedia. Anyway, A Wikipedia admin, yes an admin, once wrote to me in an email that anyone depending on Wikipedia for medical device, deserves to die.
These entries read, to someone unfamiliar with SSL terminology like this, “The qwerwer, also known as the lwrjehtr helps prove the ownership of the skadhgfskjdh and includes information about the oiuwerth, the lksajdhfjk and the hjkflksjdfhlkjg.”
That’s a nice story. It’s almost as if you didn’t want to learn anything new. Your passive-aggressive stance to not knowing something explains why you had to start the thread with “I’m a web developer and did $randomstuff”.
I’m afraid no one can help you if you don’t want help. So far I haven’t seen a single specific question or problem, just general ranting and hyperbole.
You can use Google to get more info if you don't know the basics - someone already posted links to some good resources. There are also good books which explain in detail how X.509 works. If you can't follow the provided instructions you can ask here for more help. If you still can't install the certificates, you might consider some paid service to get the job done for you if you are not up to the task.
(And that hostile attitude won't be helping you, btw.)
The existing web PKI is quite complex and I'm not sure that there's a way to eliminate or even significantly reduce that complexity. We think we're on a good path toward getting integrations that will hide it from a lot of people; for example, the Caddy web server automatically gets and uses certificates from Let's Encrypt to enable HTTPS for every site it serves, with no configuration or user interaction, and a large number of hosting providers have also made it automatic or convenient for their users with provider-side integration.
We're hoping this will continue to become the norm everywhere. Providers like HostGator are making this more difficult than necessary. I have said in several other threads that HostGator customers in particular will not benefit financially from using Let's Encrypt certs. This is because our certs have a validity period of 90 days so they must be replaced at least that often; since HostGator charges $10 each time, customers using Let's Encrypt certs will have to pay at least $40 in certificate fees per year, which is more than they might pay if they got a paid certificate from another certificate authority and paid the fee only once every 1 or 2 years. There is nothing that we can do about this except to highlight that other hosting providers (even some which don't directly integrate Let's Encrypt!) are doing a better job with HTTPS integration.
HostGator's lack of integration is also an inconvenience in another regard: a big part of the Let's Encrypt vision is automation of certificate requests and deployment, which several clients and tools that interoperate with Let's Encrypt do. So we have millions of sites that automatically renew their certs every 2-3 months with no human intervention at all. Of course, our shorter renewal period is more annoying in environments where this automation isn't applicable, and HostGator, by requiring manual intervention to deploy certs, means this automation won't happen for their customers. For both of these reasons, Let's Encrypt might not be a good choice for you since you're committed to staying with them.
Of course, we do have people using Let's Encrypt successfully with HostGator and you're very welcome to do so if you decide to. I think the information in the Wikipedia pages @TCM linked to is very helpful and I think it's plausible to say that many of these technologies are becoming an important part of the web platform and that some degree of familiarity with them is an important part of web developers' skill set today. Notably, more than half of all web requests are now made over HTTPS, and, as you may be aware, some browser features are now only available on HTTPS origins. Reading other people's overviews of these topics can be a great way to learn, and in my experience, Wikipedia's coverage of this kind of topic tends to be excellent.
In terms of some of the specific concepts you might encounter:
Making a secure connection requires cryptographic keys, which are used for many purposes and come in many varieties. Many of these are ephemeral and used internally by software in the course of a connection, but some of them are long-lived and are created and used explicitly by administrators in the course of setting up sites and services.
Environments like the web where people interacting don't have a prior relationship normally use public-key cryptography, a set of technologies which allow entities with no direct prior communications or interaction to create a secure communication channel. In public-key cryptography, keys exist in pairs called public keys and private keys. The public keys are not secret and are used by other parties as part of the process of contacting you; the private keys should be kept secret and never posted publicly.
The most common algorithm used in public-key cryptography today is called RSA. When using RSA, you will have a key pair consisting of an RSA public key and RSA private key. These may exist in the form of text files, commonly using a format called PEM.
The process of ensuring that people can confirm the validity of keys they encounter, in order to establish secure connections with the parties they intended to, requires some kind of system for this purpose. On the web we use a system called the web public key infrastructure, or web PKI. This infrastructure is established through agreements between different kinds of entities, including browsers and certificate authorities. The certificate authorities are organizations that follow procedures to publicly confirm the match between a particular public key and some kind of "identity" (whether a legal identity or just something like a domain name or e-mail address), so that they can state publicly that a particular public key "belongs to" a particular identity.
Such statements are expressed in digital documents called digital certificates (which can also be represented as text files in PEM format). The digital certificates are statements by certificate authorities about other entities' identities and public keys. These certificates can, among other things, be verified by web browsers when connecting to a web site. This lets them confirm that they have established a secure communication channel with an entity that is the actual owner of the web site.
The web protocol HTTP can be used in conjunction with a security protocol called TLS (which was previously known as SSL) in order to make cryptographically secured connections that otherwise work much like ordinary HTTP connections. The secure connections are called HTTPS connections, and involve HTTP-over-TLS, usually using TCP port 443 on the web server instead of port 80. In an HTTPS connection, the browser performs a TLS session negotiation with the web server before sending an HTTP request.
Part of the TLS session negotiation, and hence part of the HTTPS process, is verifying certificates from the server. This is normally totally transparent to the browser user, but the web server administrator may have to do something to get and install the certificates.
The server serves a set of certificates called a certificate chain. This chain confirms not only the identity of the server itself, but also the identities of certificate authorities that were involved in the certification process. The chain consists of a single end-entity certificate, also called a leaf certificate, which is the certificate belonging to and describing the server itself, and one or more intermediate certificates (sometimes informally called "chain certificates" or "CA certificates"), describing delegations or grants of authority by certificate authorities to other certificate authorities.
The ultimate authority to issue browser-trusted certificates is held by root certificate authorities, which are trusted as a result of negotiations between the browser industry and the CA industry, and as a result of audits of the business practices and policies of the CAs. The root certificate authorities issue the intermediate certificates that form part of a certificate chain. The certificates describing these root authorities do not need to be made part of chains, because they are already known to the browsers (and, if they weren't, the browsers wouldn't believe them simply because of their presence in a chain).
In Let's Encrypt's case, the root certificate authority from which our authority to issue trusted certificates derives is caled IdenTrust, and it is identified as "DST Root CA X3". Let's Encrypt operates an intermediate certificate authority called "Let's Encrypt Authority X3"; there is an intermediate certificate showing that Let's Encrypt has been authorized by IdenTrust to issue certificates, and this intermediate certificate should be sent as part of the chain.
Every certificate authority performs some kind of verification of entities that request certificates in order to confirm their identity, or as much of their identity as is asserted in the certificate. Certificate authorities like Let's Encrypt perform a kind of verification called domain verification (or "DV"), which does not try to confirm the real-world or legal identity of the subject of a certificate. Instead, it just tries to confirm that the entity requesting the certificate also exercises control over the Internet domain name(s) that will be mentioned as the subject of the certificate.
Let's Encrypt performs DV in what can be a fully automated way, machine-to-machine, using a protocol called ACME, which has also been described as a certificate issuance API. Using ACME, a machine requests authorization for a certificate from Let's Encrypt and Let's Encrypt responds with challenges, which are tasks that can be completed in order to confirm that the requester really has control of the appropriate domain name(s). This would, for example, stop you from getting a certificate for someone else's web site which you don't actually operate. When the challenges are completed, Let's Encrypt confirms this and is willing to issue the certificate.
Some Let's Encrypt client applications, of which there are a few dozen, can perform this whole process with no human intervention, depending on the nature of the web server environment.
Other applications require some degree of human involvement or intervention.
To deploy a certificate, a web server needs the full certificate chain (which consists of the end-entity certificate, often just called "the certificate", and one or more intermediate certificates) and the private key which corresponds to the public key mentioned by the certificate. The public key itself is state in full by the certificate and so it does not need to be stored or given in a separate file. The Certbot client, which my organization, EFF, has written as part of the Let's Encrypt project, creates and refers to four different PEM files whenever you obtain a certificate from Let's Encrypt, namely
privkey.pem, the private key
cert.pem, the end-entity certificate
chain.pem, the intermediate certificates that should be served as part of the chain (currently consisting of just one intermediate certificate)
fullchain.pem, a combination of cert.pem and chain.pem into a single file
Depending on the server software or server environment, these PEM files can be provided or configured in different combinations. These filenames themselves are not industry standards but are conventions from Certbot, and might or might not be used by other client software.
If you can suggest particular parts of our documentation where you think this background information, or other information, would fit, we're always looking for opportunities to improve things.
That's how things usually are in IT as soon as you get beyond trivial entry-level stuff, which is why I find it funny that you felt it necessary to emphasize that you "debugged complex programming environments". Yet you can't manage to read into a topic just enough to understand what's going on, especially when public key crypto is such a universal topic in IT that every serious professional at least has to know the basics.
Being baffled by "cert" really debunks the person, not the documentation. But what do I know, right?
Thank you schoen. You didn’t answer everything, but you made a good attempt, without being dismissive.
It seems the move to make ssl free is growing and I’ve already had to instruct several clients to demand refunds from their hosts who charged them for SSL when they already had it free via cPanel’s AutoSSL. Unfortunately HostGator is still trying to force people to pay for what is now widely free.
One of the drawbacks of LetsEncrypt SSl is that it needs to be renewed every 90 days, but according to this article, cPanel is remedying that. (Good for them).
I think the core of the problem is that the purpose of SSL is to simply exist, whereas programming languages exist to function, therefore whoever decided the terminology and process of SSL didn’t need (or think they needed) to make it understandable, predictable or intuitive. Even the online helpers like ZeroSSL fall short of being useful due to the overly cryptic mindset of the developers of SSL.
@schoen has a good point there - if you feel that something might be improved in a certain way, just suggest it, preferably describing which parts need improvements - the team behind Let’s Encrypt is pretty open and chances are that will help.
As for the confusion - taken software development as an example, you can probably imagine that teaching a new language or even just explaining a new framework or IDE to someone practically not familiar with programming might not be too trivial. But then again - some people might want to understand how things work and some might just want to use programs someone already wrote for them.
Same here - if someone wants a better understanding as to how all things SSL work, they can study the documentation and that indeed will require some effort, just as any learning. If someone wants to just use SSL though, they might find that there are such tools as certbot, which will do most of the work for them without any specific knowledge.
To simplify things a bit - you can either hail a cab (use certbot) or drive. But the latter will require getting a driving licence obtained through some learning, practice and passing a test.
P.S. If you have any suggestions regarding as to how one would make ZeroSSL simpler than it is, I’m open to ideas. For example there might be a section added later this/next week pointing to the guides or videos people made after using the service - hopefully that might be helpful enough.
You may also be interested in https://www.eff.org/encrypt-the-web, which tries to introduce both HTTPS and the arguments in favor of using it in a very beginner-friendly way. If, reading that article, or watching the video, you find terms that are not defined or explained, please point them out so we can improve the article.
I understand what you are saying however documentation for LetsEncrypt and Certbot is currently written in a way that makes sense to security people and developers who configure ssl for web servers.
Think of it as re-orientation documentation rather than a beginner course. What I mean by that is we teach network monitoring at our job. We run two versions of the course. Version 1 - 1 day for people who have used other solutions and just need to know how to use our one. The documentation you are referring is akin to that kind of approach. The second course we teach is a 3 day course where we explain the basics of things like SNMP and then explain the implementation of it in our software product. This is probably what you are after however it is not how the documentation is structured.
What you are describing is a well understood problem form my point of view. Most people that post issues on here are not able to articulate the difference between the challenge types and why they are actually doing what they think they are doing.
Have a review of this post: Certbot Fast-Guide! if you think this is the kind of things you would like to see then post positive feedback and people will try to make it clearer
This is not quite accurate. One of our goals is in fact to expand the set of people who can get a certificate beyond those who are already comfortable with TLS. So, to the extent we can, we'd like to make the documentation helpful to those people.
I think one area we probably tend to fall short is that we try to explain things in a "just follow these steps and it will work" manner, but don't do as much deep background, which makes things hard to understand when they stop working.