alt3rn1ty Posted July 1, 2015 Share Posted July 1, 2015 Arthmoor dont know if you are interested but something nice is coming in September https://letsencrypt.org/ Apparently the process is very simple once its set in motion. Free site encryption .. No strings. Let’s Encrypt is a free, automated, and open certificate authority brought to you by the Internet Security Research Group (ISRG). https://letsencrypt.org/howitworks/ Anyone who has gone through the trouble of setting up a secure website knows what a hassle getting a certificate can be. Let’s Encrypt automates away all this pain and lets site operators turn on HTTPS with a single click or shell command. When Let’s Encrypt launches in September 2015, enabling HTTPS for your site will be as easy as installing a small piece of certificate management software on the server: $ sudo apt-get install lets-encrypt $ lets-encrypt example.com That’s all there is to it! https://example.comis immediately live. The Let’s Encrypt management software will: Automatically prove to the Let’s Encrypt CA that you control the website Obtain a browser-trusted certificate and set it up on your web server Keep track of when your certificate is going to expire, and automatically renew it Help you revoke the certificate if that ever becomes necessary. No validation emails, no complicated configuration editing, no expired certificates breaking your website. And of course, because Let’s Encrypt provides certificates for free, no need to arrange payment. Link to comment Share on other sites More sharing options...
Arthmoor Posted July 1, 2015 Share Posted July 1, 2015 Painless SSL? Are we living in a dream now? Looks like a cool idea. Will have to remember to check it out when they go live. Link to comment Share on other sites More sharing options...
alt3rn1ty Posted January 12, 2016 Author Share Posted January 12, 2016 Its live But I think its public beta All the same it has had over 250,000 sites adopting it already. https://twitter.com/letsencrypt/status/684221075966705664 Link to comment Share on other sites More sharing options...
alt3rn1ty Posted March 10, 2016 Author Share Posted March 10, 2016 Now at 1 million sites certified using it .. But there's a change coming - The client is going to be renamed ( not known at this time ), and will be hosted by EFF site in future : https://letsencrypt.org/2016/03/09/le-client-new-home.html https://www.eff.org/deeplinks/2016/03/new-name-and-roadmap-lets-encrypt-client Link to comment Share on other sites More sharing options...
VaultDuke Posted August 13, 2016 Share Posted August 13, 2016 Giving this a bump. Of all the login data stored in my vault, AFK mods is one of the last non fully https encrypted sites i visit, with the others either going full encryption (Neverwintervault and hopefully the nexus, too after its redesign) or closing down this summer (bethsoft). Link to comment Share on other sites More sharing options...
Arthmoor Posted September 5, 2016 Share Posted September 5, 2016 Not ignoring you btw. Just don't have a lot of time to mess around with something like that right now. It doesn't seem to be something considered overly important by any of the forums I visit regularly whether they're modding forums or otherwise so I'm not sure it would end up being worth the hassle. We'd need to set up a clone of the site to test it and make sure nothing was going to break etc. This isn't something you just turn on blindly and hope for the best. Link to comment Share on other sites More sharing options...
alt3rn1ty Posted March 6, 2019 Author Share Posted March 6, 2019 Glad you implemented this eventually, especially with Google and Chrome steering the internet towards SSL everywhere. I only recommended it after seeing Steve Gibsons investigation into LetsEncrypt on Security Now. Here's what he had to say before it took off - Security Now #483 : https://twit.tv/shows/security-now/episodes/483?autostart=false ( Go to - Time 1:14:00 ) Was it as painless / trouble free as they claim ? Steve: They put - yes. And I've now read the entire specification front to back, 36-page RFC, and they've nailed it. They absolutely got it right. But it is crucial to understand what it is that you get for free. It is absolutely the case that you get for free what many certificate authorities are now charging for. So in that sense it is absolutely true competition for what all certificate authorities are currently making some money selling. It is not at all competitive with what all certificate authorities should be charging money for, meaning that it is - okay. And so what that is: Remember that there are broadly three categories of certificate. There's the so-called domain validation certificate, a DV, which its only assertion is that the certificate is bound to this domain, that is, the certificate is just a certificate for the domain. It doesn't assert anything about the ownership of the domain. So the certificate will make a claim about the ownership. So even a domain validation certificate, it'll have a common name and an organization associated with it. It's important to understand that this doesn't validate that, that is, a domain validation cert is really, it's just saying - it's like the minimum required to establish an SSL/TLS connection to a remote website. The next level up fixes, sort of at the weakest level, the fact that the domain validation isn't really making an assertion about the organization. That type of certificate is called an OV, an organization validation. The problem is that there's no visible indication of which is which. And so one of the things that I do wish we had, and I don't know how we could get it in practical terms, is three levels of indication in the web browser where we currently only have two. We currently have either EV, which is the Cadillac, the Extended Validation certificate, or not EV. And in the grouping of not EV is both DV and OV. That is, essentially nothing but the validation of the domain name and really not the organization, or the organization validation, which would be nice to somehow be able to assert because that requires - that's not what this system does. The whole Let's Encrypt thing is automated, and it is free specifically because it can be, because you're able to cryptographically validate the domain control with full automation. You cannot validate organization, that there's a corporate entity, without involving people. And so that won't and can't be free. That's what you need the CA for. Or, going further, if you want Extended Validation and an indication in the URL, the green coloration or glow or whatever it is, depending upon what browser you're using, then that takes extra work. Okay. So we need to understand that all this is is that weakest form of validation. And CAs are probably going to lose that business to the degree and as this takes hold. And, frankly, that's a big business because Extended Validation certs are still the minority. But this is sort of inevitable because they actually weren't doing much to get any money for just doing a domain validation. I mean, so little, in fact, that it could be completely automated with the so-called ACME protocol, A-C-M-E... Leo: That's it. That's the name I was looking - that's the funny name. Steve: Yes, Automated Certificate something. Oh, Certificate Management Environment. So you could tell that the acronym came first, and they had to reverse-engineer... Leo: They call those retronyms, yeah, yeah. Steve: Retronyms, yeah. It's like, okay. We know what you meant. So, okay. So how does this work? There is an agent, some software which will be written by some pro Let's Encrypt people for the various platforms. I'm sure that Linux will have the first one. And the example on the EFF site and their video is of a Linux install where basically two command lines act to get something, to get the package from the repository, and then install. And this thing runs. The idea is that it contains the knowledge of how to configure the server if it had a certificate. It has the knowledge of how to ask the OpenSSL crypto library to generate a certificate. You have to ask, there's an interactive session where you tell it a few things, like what domain name you want and your organization name and the other things that certs typically have, you know, like geographic location and so forth. Then it has the ability to query the Let's Encrypt CA. So part of this service is a new certificate authority that will only be issuing, probably, domain validation certs through this automated protocol. Oh, and it has to be preconfigured with the URL of the CA. So that would be bound into this package. And of course the domain name of whatever it is wouldn't be changing often. So that's not a problem. So it generates a Certificate Signing Request, a CSR, which is the normal process we all go through when we're creating a certificate. And that certificate signing request involves the generation of a public key pair. The server holds onto the private key. That's its crown jewels. It never lets that go. But the public key is part of the certificate signing request, which it then is, when appropriate, it sends it to the Let's Encrypt CA. But first what happens is it needs to prove that it has valid control of the domain that it wants to get the certificate which it has just created that it needs to get signed. That is, we don't want some random person generating a certificate for GRC.com and submitting it through this automated protocol to have it signed because then they would have a cert for GRC.com. I don't want them to have that. They would still have to jump through some hoops to use it because GRC's IP is in DNS, and so people looking for GRC.com come to my IP, not this bogus entity's IP. So more needs to be done, but still we know we don't want them to get a cert for that. So the protocol has three main purposes. One is to validate that you have control of the domain you are wanting activity for. And that activity would be issuing certificates and revoking certificates and renewing certificates, you know, fundamental certificate operations. So there are two ways that you can prove, through this automated protocol, through the ACME protocol, that you prove you have control of the domain. The first is that you place content which the CA provides on your web server, which is then made publicly available, and the CA obtains it. So there's a well-defined, simple, JSON-based, you know, JavaScript Object Notation, JSON-based protocol where the user, the client of this ACME protocol says I want to work with a new domain name. I want you, CA, to ultimately issue me a certificate for this domain name. So let's do that. So the protocol, the ACME protocol at the client side generates another completely separate public key pair and, again, holds onto the private key and sends the public key to the certificate authority over the ACME protocol, along with a domain name that it wants to associate, essentially. So the CA has a public key and a domain name that the client says it has a right to have certificates issued for. The certificate authority challenges it then with a session ID and a cryptographic nonce, so that none of this can be repeated, and a list of challenges, a list of ways it can prove control of the domain. Currently there are two. But the protocol is meant to be open and extensible. And in fact it can technically be used for other things than just managing a domain name, though that's all it's defined for currently. So this challenge comes back to the client running the ACME protocol. And the client can choose which of the things it wants to do. One of the things it could want to do is to accept the challenge to put some content, which is just a bunch of Base64, so ASCII-encoded random gibberish, on a certain path in terms of the directory path of the website on the server. The path always begins with ./well-known/acme-challenge/ and then a path which the CA has provided. And again, that's a hex-encoded bunch of random stuff. Hex so that it is valid for a path name. And so the CA says, essentially is saying in this challenge, here's a blob that I want you to place at this blob location. Let me know when it's there and ready. So in accepting the challenge, this client establishes, takes the data from the certificate authority, arranges to have it appear in public on that path at .well-known/acme-challenge/ and then a gibberish path, and then says, okay, I accept the challenge. I'm ready to go. The CA then makes a public query at the domain name that they're negotiating over at that well- known/acme-challenge/gibberish page and then obtains what's there, which should be the random gibberish that it gave the client. And so in completing that loop, involving looking up the domain name, getting the IP address, making a query, essentially what that tells it is, with provable security, that the entity that the CA is in communication with is able to affect and influence web pages at that domain. So it has control of the domain. And so in my example of some bad guy trying to get a certificate issued for GRC.com, they'd have no way of influencing my server, of arranging to get a page to appear on a whim on a certain location down my own public server space. So what the successful accomplishment does is to bind the public key, which was generated just for this, to the domain name at the CA. So that, once done, establishes that the entity has control of the domain. Subsequently, things like issuing certificates for that domain require that they be signed by the matching private key, which never leaves the client. And all subsequent operations are signed with the private key that matches the public key which has been bound to this domain name forevermore. One of the cool things that the system does at that point, once there is an association that's been made at the CA, is it ups the ante for all future attempts to make a binding to that domain name, which is, when I read that in the spec, it's like, oh, nicely done. Because that's what you want. The idea is the first person to use this Let's Encrypt system to issue a certificate establishes this relationship. And in doing so, nobody else can establish a relationship for that domain name without being able to prove they're the same entity that originally did it. So that's another application for the matching private key. But then there's also something known as a recovery code, which the CA sends back as part of this initial binding protocol, which should be, can be stored separately. The idea is to - and it's actually very much like SQRL's rescue code. It's offline, and it's a "get out of jail free" card if you screw something up, if your hard drive crashes, if you lose all of your cryptographic stuff. If the worst happens, how can you - and because we've upped the ante on making these associations, how do you say no, no, no, it's really me? Please, I need you to issue me a replacement certificate because I've lost mine, but it really is me. Well, this recovery code is, again, long and random. And only the person who originally made that association would be able to do it. And what's cool is all the recovery code does is forgive the binding. That is, essentially it says, okay, you still are going to have to reprove again that you still have control over the domain the way you originally proved it, but we're going to let you do that. So very nice aspect of the protocol. And one other very neat thing that I saw there was when you vet - so the next aspect is you then issue a certificate. So the client takes the certificate signing request that it made. And it negotiates a transaction with the CA saying, okay, I've got a CSR, Certificate Signing Request. I need you to sign it. And it signs that request with its private key, which it uses for proving that it is the rightful requester for activities in this domain, sends that to the CA. The CA looks through the various fields in the certificate to make sure that they're all valid. For example, it would be possible for you to request things that you shouldn't request, like the right to sign other certificates. It's like, oh, no, no, no, can't do that. So it'll strip out things that you're not able to do. And then, when everything looks right, it will sign that and return the certificate to the client as part of this negotiated transaction. One of the other things it returns, which is what I was going to say I thought was another really nice aspect of this, is a URL of a simple GET query which the server, the client running in the user's server, can use to get a renewed certificate any time it wants. The idea would be it would still have to fit within whatever time horizon constraints the overall certificate has. But, for example, you could use this to issue short-life certificates. If you wanted to experiment, for example, with a protocol that we've discussed before, where instead of a long-life certificate with the need to revoke, you instead arrange to issue short-life certificates and don't worry about revoking them because they're going to expire in a couple days. So the system is a platform for experimenting with that. And they've already incorporated one of the components you would need into the protocol, which is a way for the server, daily, to simply say give me a certificate, a refresh of my existing certificate. You can't change any of the parameters. You can't change the keys or features or anything. But you could say give me a certificate that's good for four days. And that's done with a simple GET request. And the reply to that GET request is another signed certificate good for some length of time. And this makes that very simple. So clearly, if the world is going to be switching to short-lived certificates, we need a clean, simple, fast way to reliably get them periodically. And this is already built in. The way I explained of putting content on a page is one of the two currently defined means of proving you have control of the domain. The other one is a use of SNIs, Server Name Indication. That's the technology where a single server that supports SNI is able to, at a single IP, support different hostnames. And SNI is used to disambiguate which certificate should be returned to the client who is requesting an SSL connection. The idea there is that you could use this system for non-web-based applications. Clearly the first application is a web-based application because you need to put a web page up at somewhere publicly available at a random gibberish page name in order to obtain the content and verify ownership. But you can use SSL and TLS for non-web things. And so using server name indication, the client chooses that as a means of proof in the protocol and creates a self-signed certificate where a random gibberish domain name is appearing in the certificate, along with the domain that they're asking for control over. And so they respond to the challenge that way. And then, again, the CA makes a request at this random gibberish machine name dot domain name dot whatever, and verifies that it's able to establish a server name indication enhanced TLS connection that way, and there again proving that the client has control of the domain. And at that point then the association is established that allows certificates to be issued and revoked and so forth. So anyway, it's truly elegant. It's simple, won't be difficult to implement. None of this is hard. The spec is all open. The plan is to bring up a CA that operates this protocol in second quarter of 2015, so in the late spring, early summertime this should happen. And I forgot to mention that once the client obtains the signed certificate, since it is then - it contains sort of the little mini expert system that knows how to configure the various web servers on the server platform. It does that. It puts the certificate where it's supposed to go, and the configuration files to bring up HTTPS on the server, and you're done. So what the user sees is they run this, or install this. Oh, and I should also mention that clearly it won't be long before this is built in. Why wouldn't Apache build this into the server, so you don't even have to add an add-on module? It's like, yeah, once the system exists, just have it there. So you'd have to be able to get it for installations that wanted to add it. But the idea is that the operator of the domain either starts this process or loads it and starts it, answers some simple questions about the domain name they want to secure, their organization and where they're located and so forth, the standard things that go into the certificate. They press a button, and then hum a short tune, and then up pops a dialogue saying, okay, you're now operating a secure server on that domain. Everything else is done for them. And it can be made transparent because the lowest level of authentication, just asserting that I have control of this domain, that's all automated. And I just think this thing is 100% cool. I'll be very surprised if it doesn't take off. I think it's clearly going to. Is it as trouble free in practice as they claim ? Link to comment Share on other sites More sharing options...
Arthmoor Posted March 6, 2019 Share Posted March 6, 2019 No, it's a pain in the ass actually. Especially if you need to make changes to the domains like I just did. Or when they make undocumented changes to the behavior of certbot and it silently fails your renewals and you don't realize it until 2 days before the cert expires. Or any number of other things that seem routine in the linux world. I'd hate to see how much more of a pain this is with actual paid certs. Link to comment Share on other sites More sharing options...
alt3rn1ty Posted March 6, 2019 Author Share Posted March 6, 2019 Ah, from what I understand they could be a lot more of a PITA, and the site owner paid for the privilege. Sado masochists. Link to comment Share on other sites More sharing options...
DayDreamer Posted March 10, 2019 Share Posted March 10, 2019 Tell me what could be less of a PITA. Folks that I know started this effort, and are still on the board. We'll be at the same conference next week. I'm paying $50,000 out of my budget annually. They just sent me a complimentary hoodie! Link to comment Share on other sites More sharing options...
AndalayBay Posted April 17, 2019 Share Posted April 17, 2019 On 3/6/2019 at 1:37 PM, Arthmoor said: No, it's a pain in the ass actually. Especially if you need to make changes to the domains like I just did. Or when they make undocumented changes to the behavior of certbot and it silently fails your renewals and you don't realize it until 2 days before the cert expires. Or any number of other things that seem routine in the linux world. I'd hate to see how much more of a pain this is with actual paid certs. They switched to using IPv6 for the renewals if you have them configured in your domain. Fortunately I got a server generated email telling me that my renewals had failed with 19 days to go. IPv6 is not working with Linode. Even my primary domain, which Linode gives you an explicit IP, doesn't work. I've opened a ticket with Linode, but I suspect I'm just going to have to remove the IPv6 addresses from the domain. My ISP doesn't support IPv6 yet, so I can't test it. Once I remove the v6 addresses, the renewal should go through. One more thing, if you're using the old challenge method, you might want to switch to the new DNS plugin method. There is a plugin available for Linode. I haven't finished switching yet, but plan to do so. Link to comment Share on other sites More sharing options...
Arthmoor Posted April 18, 2019 Share Posted April 18, 2019 I've got IPv6 configured for my stuff and it works perfectly fine. I've seen posts here on the forum using it, and I see active user agents using it on the bug tracker, and on the old MUD forum I still run. I'm on Linode too so I don't think this is a universal issue. I'm even using their DNS manager to handle it. I tried getting the DNS plugin for certbot to work but couldn't get it to cooperate, so I guess I'm still using the "old" challenge method. So unless I get forced into it at some point I'm not gonna inflict that hell on myself again :P Link to comment Share on other sites More sharing options...
alt3rn1ty Posted March 3, 2020 Author Share Posted March 3, 2020 @Arthmoor You may have heard of this already if you received an email from Lets Encrypt, I just saw a BBC tech news report on Lets Encrypt site Certificates needing renewal due to some kind of bug .. https://www.bbc.co.uk/news/technology-51719588 In a notification email to its clients, the organisation said: "We recently discovered a bug in the Let's Encrypt certificate authority code. "Unfortunately, this means we need to revoke the certificates that were affected by this bug, which includes one or more of your certificates. To avoid disruption, you'll need to renew and replace your affected certificate(s) by Wednesday, March 4, 2020. We sincerely apologise for the issue." So I guess if your site certificate is not revoked, yours is not one affected .. If not sure renew it before 4th March Link to comment Share on other sites More sharing options...
Arthmoor Posted March 3, 2020 Share Posted March 3, 2020 I got the email. I don't care who the company is or what the underlying reason for it is, but giving site operators less than 12 hours notice on certificate revocation is unacceptable. What's worse is the command the email said to use doesn't work. You have to go digging through their support posts to find people in the comments who found the actual command you need to use. And even worse than that, they've known about this issue for months and said nothing the whole time. I managed to get my certs renewed despite the roadblocks, but there's people in the comments on their forum post about it who aren't able to do anything about it right now because they're away from the office on vacation and such. Link to comment Share on other sites More sharing options...
alt3rn1ty Posted March 3, 2020 Author Share Posted March 3, 2020 Its telling that the BBC are not allowing comments for the news article too (even for members, I just logged in to check), they usually do that when they know an article is more than likely to be sensitive and comments will turn into a slagging match. Understandable in this case. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now