ACME: Accounts and Validations

good morning everybody and welcome back to next door netadmin today is part two in our three-part Acme Deep dive and today we're going to be talking all about the Acme protocol we're going to be talking a little bit about what kinds of validations you might have on a certificate we're going to go into a good bit of depth on the Acme protocol so that you have an idea of what's Happening behind the scenes and can more effectively troubleshoot it if something goes wrong and we're going to talk about the specific kinds of validations that you can encounter under the Acme protocol so there's a lot to cover today let's just hunker down and Dive Right In shall we I mentioned last week that before a certificate Authority signs your Certificate request it will do some validations that are dependent on the ca it's not just dependent on the ca it's usually also dependent on what you have purchased if you're purchasing a commercial certificate the three basic types are domain validation or DV there's organization validation or OV and then there's extended validation which is EV as you go up in these levels of validation there's a lot more steps that need to be performed for verification and that means a lot more manual human work involved if you're doing organization validation you're going to be looking up details on the business you're going to be Consulting business records you might be Consulting a Dun and Brad street number who knows in extended validation there's even more validation to be confirmed like can you actually communicate with a person phone calls EMA mails possibly even Hardware security modules or smart cards involved depending on what the certificate is going to be used for the simplest method is domain validation where the only thing that's being validated is just the domain name on the certificate and everything else is not being validated or being signed to by the certificate Authority they'll only put their signature on this is the domain name for this certificate that's all there is to it this is why Acme certificates are only domain validation Acme itself stands for automated certificate management environment the key part to that being automated you need to have this set up in such a way that it can automatically renew and validate the certificate without human intervention so that precludes the use of organization validation or extended validation certificates because those require manual human verification effort so domain validation only cool that's pretty much all there is about the certificate of Authority part of that and so the rest of this video is going to be specifically about the Acme protocol itself there are a few certificate authorities that Implement Acme the best known and the one that started the process of actually codifying Acme and developing it into an internet standard would be the nonprofit organization isrg the Internet Security research group their public certificate Authority is the very well-known let's encrypt it was set up specifically to make the process of acquiring certificates easy and cheap as in free free is a good price we like free and as a big part of this it had to be automated from the get-go because if you're verifying and issuing thousands upon thousands of certificates to make them ubiquitous so that everything is secured and encrypted then it has to be automated there's no way that you can hire all the people in order to do all of this if the certificate is free and if the certificate's not free then you're not encouraging adoption so Acme as a protocol is often associated with let's encrypt and in the examples that I go through I am going to be using let encrypt because that's this just the ca I use but it is important to note that the protocol we're discussing can be used with different Casa there are other Casa that implement it there's zero SSL is one that I know of um I think bu SSL is another I don't have a full list at hand because I usually just use let's encrypt but it's not a requirement you can use Z me with other certificate authorities and so the protocol we're going over should be useful for you no matter which certificate Authority you eventually go with an Acme registration flow starts with registering an account and this is something that is often times a little invisible and I've had people come up to me even in my own company and say what what do you mean an account there's no such thing there's never been any such thing and all I can go is clearly you haven't read the actual specification an Acme certificate is tied to an account you must have an account in order to register a certificate why well this is mainly a function of being able to manage the certificate effectively and I'll explain what I mean by that because it's not Management in the traditional sense when you register and AC me account you register a contact email address it's not public the email address is only there if the certificate Authority needs to get a hold of you for some reason for example let's encrypt has used this on a few different occasions to tell people hey we discovered some flaw in our validation process and we're reissuing a whole pile of certificates that's an important thing to know um I've also gotten notices hey your certificate is 19 days away from expiring and it hasn't been renewed yet it's 5 days away from expiring it hasn't been renewed yet that's also kind of useful to know so registering an email address so that the ca can contact you the admin if there's a potential issue with the certificate is very important there's nothing else you receive from it nothing it's not used for marketing it's not used for you know trying to upsell you on stuff it's just to let you know of technical issues that need and admins attention or at least verification that everything is going the way that it actually should be but with that being said a contact email address is optional you don't have to provide that when you have an Acme certificate issued you can revoke it if the certificate has been compromised or if you have lost control of the private key you can revoke it there are two ways of revoking a certificate you can revoke it with the private key of the certificate itself if you have control of the private key you should be able to tell everybody do not trust this anymore either the owner has reason to remove it from circulation or if it's been compromised and an attacker wants to revoke it so that nobody trusts it anymore okay if it's been compromised and you've lost control of the private key anybody with that key should be able to revoke it there's absolutely no security downsides to this there might be a usability downside but that's a separate concern but what if you don't have control of the private key anymore let's say somebody broke into your server and you're trying to recover access to it but while you're going through the support line for your server administrator um you need to make sure that people stop trusting that certificate as soon as possible because it's compromised but you don't have access to that private key anymore in that case the private key for the Acme account can be used to revoke the certificate so that even if you've lost control of the certificate itself if you have access to the original account used to register the certificate you can still perform a revocation in an emergency so there's a reason for there being an account now the certificate itself when you go through the process of registering the certificate you'll typically be providing at least one you need at least one domain name that you're certifying uh and a list of others different Casa will have different limitations let's encrypt has a limitation of100 domain names per certificate which honestly seems pretty generous if I need a certificate with more than a 100 what am I doing and I can probably afford something that isn't free be that as it may you're going to have a list of domain names each one of those domain names needs to undergo validation to verify that it can be included on a certificate so how do you validate the domain name well let's think about what are we actually validating are we just validating that it exists well google.com exists should I be allowed to register a certificate that claims that I am google.com no I really shouldn't so clearly you have to do more than just verify that the domain name exists so what are we actually validating here we're validating or intending to validate that the entity which is registering the certificate is the entity that users will reach if they type that domain name into their connection whether that's a browser or whether it's email client or whatever if you're trying to reach google.com the the certificate that you are presented with should only be issued if it is actually residing at google.com not on my server in my you know back office so there's a few different ways of validating this the first one is given the method name HTTP 01 or HTTP validation all this does is hey if I try if if the certificate Authority tries to reach this domain name does it reach the server that is can does it reach a server which can present the correct validation tokens so when you say hi I want a certificate for www.om domain.com the ca will respond and say okay here's a a special validation token put this at the correct location in the web server okay if you're doing HTTP validation that validation token goes into a set location in the web server and then when you say okay I'm ready for you to validate this the ca goes from several different places not just from one because you want to make sure that this is reachable globally not just from one specific data center that might be in the path of an attacker controlled Network fine we're gonna go from multiple places we're going to try and hit the server and we're going to look up and see if this validation token is in the given spot and there is an actual spot where this is placed it's a it's a known URL that you're looking for so if you get the validation token what does that tell you well that tells you that whoever made the request has control over the web server it does not tell you that the valid that the Certificate request came from that web server all it tells you is that whoever made the request has control over the web server okay that is sufficient to validate that if I'm going to issue a certificate for somd domain.com I know giving it to somebody who actually is in control of somd domain.com's web server that is acceptable another way of doing this validation is through uh DNS 01 lookups a DNS validation is much the same thing except you take that validation token that the ca gave you and you put it into a DNS record a DNS text record specifically what does that tell you that tells you whoever's requesting this certificate for sumd domain.com has control over the DNS records for sumd domain.com which means that they can point it at any server they wish so you're still validating that whoever is getting this certificate has control over the server that it eventually points to you're just validating it a step higher up in the chain as it were this is more important because if you're trying to validate a wild card certificate something like star. domain.com whether it's www or SMTP or mail or sip or whatever if you're trying to to validate a wild card certificate you can't do that with HTTP you cannot check every single possible subdomain because some may not exist some may go to other places it's impractical but you can validate it with DNS because in DNS you can add whatever subdomain records you want so if you want to validate a wild card certificate that can validate anything on that domain you must do it through DNS verification Dems the rules HTTP and DNS are the two most common ways of doing certificate validation there are there is another way where you can do TLS alpn or uh there was another tls-based validation method that I think has since been deprecated it's not use anymore fine but HTTP and DNS are the biggies they're the ones that you will see most often if you're using HTTP validation this can often be built into a web server these days whatever server you have running your website set it up to request a certificate if you're using something like cpanel they have this built in now at and they call it Autos SSL okay cool uh if you're just running your own virtual private server or your own web server there are other tools that you can install to do this and I'm going to show some of them to you next week if you're wanting to do DNS verification that gets a little trickier because you need to have a DNS provider that can handle automated requests automated programmatic requests because we don't want to have a human in the loop that kind of is an issue with the goal here which is automated certificate management there's ways of having a human in the loop anyway but the general idea here is that you want a DNS provider that can handle automated requests and you'll need this in what's called an API or an application programming interface there are lots of DNS providers out there there are lots that support an API GoDaddy support supports API easy DNS supports API uh Route 53 from Amazon supports API there's a whole pile of them and you can get various DNS providers to support this again that's all in the details of implementation next week but it's still something to consider because it's going to in it's going to impact your choice of validation methods you're also going to need to consider how the validation is going to work you can have a web server cool but if it's not Port forwarded in from the internet then the certificate Authority is not going to be able to reach it to verify it if it's on a different port than Port 80 it's not going to be able to verify it there's some details in that it will start on Port 80 and if it encounters a redirect and the server tells it try again on a different you know uh on a different domain name or a different port number or whatever so long as it can reach it initially on Port 80 then it will follow a redirect and look for the verification token at wherever it's being redirected to but it has to initially reach it on Port 80 so if Port 80 is in use for something else or if for security reasons it's not Port forwarded at all then you can't use an HTTP verification you're going to have to use DNS verification instead which throws you into the whole API thing there's also possibilities of hey maybe you are using Port 80 to validate a certificate at a particular web server but maybe you want to do it on two different servers well if only one of them has Port 80 forwarded you you can't use HTTP for the other one and this becomes an issue if you're doing something like uh requesting a VPN certificate that's going to be installed on a router okay well if the router is forwarding Port 80 to a web server internally then it can't use port 80 for itself um or it might be able to depending on how it's set up regardless these are all implementation details but they are the kinds of things that you need to think about when you're planning a certificate deployment it's possible that you need to set up a certificate for a server that you have access to the server but you do not have access to DNS or it's on a DNS provider that doesn't support API access in that case if you want a man a an Acme certificate an automated certificate you're going to have to think about how do I actually get this to validate or do I go to a commercial certificate I don't anymore I will put in a lot of effort to work out an alternate way of doing it um wherever I can rather than going to a commercial certificate because if I can get it for free and have it renew in an automated fashion why would I not do that versus going and paying a commercial CA $80 for a certificate that will only last a year I should also mention Acme certificates because they're intended to be automated typically have very short lifetimes for let's encrypt the lifetime is 90 days which which means yes you're getting a new certificate every 3 months sooner usually usually I'm on the order of every two months because you don't want to wait until the very last minute to renew your certificate because what if you encounter a problem you don't want it to expire in the meantime while you're trying to fix the problem but because it's supposed to be automated this is not a problem and short key lifetimes also limit the potential for compromise if if somebody compromises the server well the certificate only had a short lifetime anyway it's not like it would have continued to be valid for a full year but that's a separate thing to some extent it's it's all part of the things that you have to keep in mind when you are a net admin a server admin a system admin these are the kinds of things that you deal with on a regular basis I think that's probably mostly it for now for now next week we're going to talk about implementation I have a few tools that I've been using for years uh and like quite a bit for their flexibility and for what they offer so that's something for you to look forward to and that's the one that'll be a little heavier in technical content I suppose the first the first of these episodes was pretty heavy on the math I realize um and this one has just been heavy on me talking a lot and next week will be pretty heavy on the technical details so hopefully that's something that you will enjoy or if not thank you for watching so far but that probably should be it for day so thank you very much for joining us I am your next door nadman and we'll see you next time

Channel: NextDoorNetAdmin

Views: 54

Keywords:

Id: jxgecyVvyhs

Length: 24min 37sec (1477 seconds)

Published: Mon Apr 15 2024