How to create a valid self signed SSL Certificate?

today i want to address a topic that has given me a headache for a long time since i started running my home lab because when you set up any self-hosted services like a proxmox server an xcloud server or any other web application and you open it your browser always warns you that your connection isn't private and i know what most people will do now just click on advanced and proceed and hey awesome everything works right we could just move on and don't care about it anymore right not really if you want to do it right and secure your web interfaces and applications in the network correctly you should get your ssl certificates right that's why in this video i want to explain what self-signed certificates are why it's so important to configure them properly and how you can very easily do this in your internal network without let's encrypt without any additional software and without the need for a public dns name [Music] before we can do this and start generating self-signed certificates let's also talk about ssl certificates in general and why we need them i will try to make it short because we have a lot of stuff to cover today so it might become a longer video but some high level understanding of ssl and tls is absolutely necessary to know in it and it is a perfect practice to learn it by the way if you would like to learn more about topics like this i might also do more videos in the future about network protocols and security so why not subscribe to the channel and like the video that would really help me out okay back to ssl certificates an ssl certificate is part of the tls protocol and it has two main goals so first is encrypting the connection and second validating trust between the client and the server both are vital for the secure web as we know it today so without ssl certificates there wouldn't be https and you couldn't really secure browse any website today nearly all websites operate on the https protocol and are protected with ssl certificates that's a good thing you can see it in your browser when you open a website so there you might have noticed a small lock icon in front of your address bar which tells you that the connection is secure this also shows that the website is using an encryption with https and you can trust the issuer of the ssl certificate to understand how this works we need to first look inside an ssl certificate and find out what it contains so ssl certificates are written in the so called x 509 standards this is a format for defining public key certificates all ssl certificates have a public key that the client can use to send encrypted messages to this server if you have worked with public key cryptography before for example in ssh you might also know that this is called an asymmetric encryption and there are always two parts to make this work so the first the public key to encrypt messages and a corresponding private key to decrypt the messages to be honest i was never really good at cryptography so that's not my favorite topic and we don't dive too deep into this but what happens when a client opens a website is the client will send a request to the server and the server will send its ssl certificate back to the client which contains the public key and then the client starts the tls handshake process and sends the data encrypted with the server's public key and because the server has a corresponding private key that belongs to this certificate it can read the client's messages but only the web server can decrypt the messages and once the tls handshake process is done the client and the server agree on specific standards they generate session keys and then finally can exchange the data i know this is highly oversimplified so technically the tls handshake process is a bit more complex and there are some additional steps involved maybe i'll do a video about this at some point if you're interested in but the main thing you need to remember from this tutorial is that the ssl certificate always contains a public key which is shared with anyone who is connecting to the server any corresponding private key that remains on the server to decrypt the client's messages so this is the first important part of an ssl certificate the public key the second is the web server's identity and this is important to validate the trust between the client in the server because we as a client we want to make sure that we are talking to the correct server if we would validate the web server's identity someone in between could just hook into the connection and impersonate the web server by sending his own ssl certificate then our data is still encrypted but an attacker could read everything this is also called a man-in-the-middle attack in cyber security and that's why we include the server's identity in the ssl certificate because then the client can validate this information and decide if it trusts the server and ensure we're talking to the correct server and not somebody else like an attacker this is very important for security but why does a client trust a public web server but not our internal web servers and what exactly do we need to include in the web server's identity to tell the browser it should trust our certificates now let's look at how the client validates a website's certificate and there are a few parameters important for this validation and if one of them is suspicious the client notices oh there's something going wrong and presents you with a certificate warning and we just go over some of the most important parameters you need to consider when creating self-signed certificates just to keep it easy the first important parameter is a target address and this is described in the subject alternative names of the certificates so when you inspect it you can see it in the details for example on my website you can see three subject alternative names one for the main domain thedigitallive.com one wildcard for this domain which tells you that the certificate is valid for all sub-domains as well and the sni cloudflare.com domain which tells you this as a cloudflare certificate and the browser always compares what url you are accessing and it checks if it matches at least with one of these subject alternative names the next is the expiry date because all certificates are just valid for a specific time period so this is mainly for security reasons that a certificate isn't valid forever and it is defined in a valid from and a valid to date the third is a certificate chain and this is also very important because the browser always checks if the ssl certificate is issued by a ca that's included in the root store of the device so don't worry we'll go over this in some detail you can inspect the certificate chain when you open the certification path and this shows us that the certificate was issued by a so-called certificate authority also just called ca and the certificate authorities assigned the underlying certificates to validate their ownership so there are different types of c8s existing there are root case usually at the top and intermediate cas in between so the root ca issues the intermediate ca and the intermediate ca issues the ssl certificate so that's why it is called a chain and the browser always tries to validate this certificate chain by following the path back to the root ca to decide if it trusts it and that should be the case for all public websites because if you are visiting a website the certificate of 40 or also called just ca that signs this certificate is usually a public one so a public ca and there are many of these public cas existing globally some of them are digicert globalsign godaddy and let's encrypt and they sign and issue most of the ssl certificates on public websites today so public cas can sign certificates for you that are trusted by any client but again the question is still why does the client trust these public cas and the answer is pretty simple it's because all these public cas are stored on every device in every browser by default for example on windows you can inspect that in the trusted root ca store of the device so here you can see all these trusted public cas and they issue and sign all of the intermediate cas which then issue the ssl certificate that all public websites are using today okay so you might now ask why the hell do we do all this stuff here so why even bother with self-signed certificates if we could just get an ssl certificate from let's encrypt entirely for free and yeah i usually don't use self-signed certificates on a public website or servers and i've already made some tutorials and videos about reverse proxies and how to get trusted ssl certificates from let's encrypt but let me explain where the problem is in an internal network because in an internal network you might not want this or it is even not possible because when you want to get a certificate from a public ca there are some restrictions and requirements you have because again these ssl certs are automatically trusted in every browser just imagine anyone could just get an ssl certificate for every domain in every ip address that would be a big security problem so that's why these public cas always verify the ownership of the domain you can only issue ssl certificates for a domain that is yours so for example if you buy a public domain like the digital life.com you validate the ownership then you can get an ssl certificate from let's encrypt for example but this is then only valid for three months and it is only valid for the digitallive.com now let's assume you're running a bunch of self-hosted applications or services for example i'm running a proxmox server in my home lab which runs my virtual machines and it also has an administrative web ui protected with https and my proxmox server is listening on an internal ip address like 10.10.04 if i would now want to get rid of the certificate warning and obtain a trusted ssl certificate from let's encrypt i would need a dns name that points to this internal ip address and it needs to have my public domain something like server.digitallive.com and when a client in my internal network wants to open a connection to the server by using this domain name i would need to somehow route this traffic to the internal ip address of my server which might be tricky but still possible the bigger problem comes now because i would also need to upload this ssl certificate onto the proxmox web ui so that means whenever the certificate becomes invalid i would need to get a new one and i would need to re-upload it on the web ui to be fair there are many services and programs that support automatic certificate renewables by the implementation of the acme protocol which can obtain and refresh these certificates from let's encrypt every three months proxmox also has this built in but this is just one example and it might work for proxmox but of course i would need to do this for all of my internal services like my firewall my storage server everything that has an https protected web interface and it might not be supported by all the devices so you can see it can get pretty complex and a lot of administrative work to do this so let's now take a look at how that would work instead with self-signed certificates where we don't need all of this stuff because with self-signed certificates you can just pick any internal domain name for example i'm using steelcreative.home in my home network and i'm also using private ip addresses and the client can then directly connect to these addresses by just using the internal dns name or the ip address that's much simpler and to create a valid certificate chain i'm using a private ca that signs this certificate and then i just need to upload this a certificate on all of my servers once the only thing that you would need to do now is because the client also needs to trust the self-signed certificate is you would need to upload the private ca into the trusted root ca store of all of your clients that need to access the web server's web ui and i really mean on every client so every pc every laptop every smartphone whatever wants to connect to our server the ca that signs our certificate needs to be included in the trusted root ca store of that device but in smaller networks like a home lab it isn't so much work and you just need to generate this certificate once tell all your clients hey please trust this certificate authority and then you're good if you still want to access your servers from outside you can of course use reverse proxies and certificates from lads and crypt or you can also use access proxies with two-factor authentication and i quickly want to say a few words about teleport the sponsor of this video so with teleport you can protect your remote resources like ssh linux servers kubernetes databases or web applications with two-factor authentication and in audit logging it is entirely open source and free to use in the community edition and suppose you want to use it in your company environment and secure your development or operations teams in that case teleport also offers an enterprise version with additional 24 7 support and single sign-on it's really a great application so just download and try it out of course you will find a link to their website in the description down below i hope you are still with me don't worry we are close now so i hope it's clear why self-signed certificates make much sense for an internal network and how they generally work now let's create our own self-signed certificates that will be valid for all the clients in our internal network and this is actually much easier than you probably think to do this we will use the tool open ssl which is an open source implementation of the ssl and gls protocols you can by the way do much more with this tool but we will now use it to generate inspect and validate ssl certificates usually this tool is installed on nearly all linux distributions but if it isn't there you should be able to install this fairly easy through your package managers and for the windows guys just like me you can also do this entirely in powershell by the way it doesn't really matter where you're using it but this is a very simple command line tool that you will need for many many other things as well but it is no additional service that's running somewhere or some external service you need to rely on by the way you also don't need to write down any commands so i've documented this all on my cheat sheets repository on github because i can't remember all of this myself so when i need to generate self-signed certificates that's probably just a few times in a year and then i can just go to my documentation pages and just copy and paste these comments but still let's go over them step by step because you should understand what you're doing here and not just blindly copy something from a tutorial that's that's never a good idea okay so as you should know from the first part of this video we need a certificate of 40 to issue our self-signed certificates let's start with this so first we generate a new rsa key so this is a private key of the ca cert that you should never share with anyone because whoever has control over this private key can generate new certificates assigned with this ca so that's why when we generate this key we encrypt it with aes and use a passphrase because this is such a sensitive key so make sure you're storing this passphrase later in a safe place because we always needed to generate and sign new certs so a password manager might be a great idea and we output this private key file to this file here the ca key.pam and i also generate my rsa certificates with 4096 bits because they are more robust than the default encryption and so when you execute this command you also need to enter this passphrase so let's do this and the private key for the ca is now generated and so we can now generate a corresponding ca certificate for this private key and this command here will generate a new x 509 certificate which is valid for a specific time which we define in days so usually i pick a time that is longer than 15 years or so because if the certificate expires we would need to update it on every client that wants to connect to all servers so so just pick a long time so we also need to input the ca's private key here so so that we've just generated and output this ca certificate into a file which is called ca.pam so let's do this so when you generate this search you also need to enter the passphrase and then you need to fill in some information about this certificate so it's not really important what you enter here because this is mainly just for identifying the ca certificate later in the browser so i will just put in some generic information and that's it certificate r40 is created so now you can check the information in your certificate if this is correct by using the open ssl tool so we can use the x 509 module and input this ca.pam file that we have generated and use the text parameter to view this in human readable format so um this is a content of the file here so everything between these lines and when you scroll up this is the format converted into human readable so when you scroll up you can see the details of this certificate you can see the issuer that this is our ca certificate and you can also see that this is a ca certificate when you inspect the x 509 v3 extension so there is a specific parameter which is called ca column true this is only there if the certificate is a certificate for a ca okay great so now that we have our ca we can issue certificates for our servers with it and for what server you create a certain all that depends on what you want to do with it so you can use this ca to generate a certificate for a specific dns name that results to an ip address something like proxmox dot co proxmox.clcreative.com whatever and that's what i want to do now but wildcard certificates or ip addresses are also possible so you can issue one certificate with wildcard one that is valid for different subdomains and then you just need to issue this certificate once and you can use it on all the different servers when you're using sub domains in your dns system the important thing here is to generate certificates for the correct target address that you're entering in your browser for example when i'm using this for this address i would need to enter the ip address or this entire network but there are many different scenarios possible here it just depends on your network and setup the main important thing is that it shouldn't change later because when you change it you might need to regenerate your certificates and re-upload them on your clients so let's create our self-signed certificate by using this ca so first we will start with generating an rsa key a private key for our certificate just like we did for the ca the exception is that we don't need to protect this with a passphrase so we don't encrypt it with aes because we later need to upload this private key in the corresponding certificate on our server and if you protect this securely then it isn't a problem to generate this private key without a passphrase i usually never do this and let's output this into a different filename which is called cert-key.pam and also use for 4096 bits so let's generate it and the next command here will generate a certificate assign request so we are not directly generating the ssl certificate here because it needs to be signed by our ca first but at this point we already need to set the certificate parameters correctly like the hash and the target address because otherwise the certificate won't be valid so in the past this subject name here was important to validate the certificate but now it isn't important anymore so you can just put anything in here your server name or whatever you like so for example i will just put in the creative here and that's totally fine and we will also use the private key of our certificate that we've just generated and output this into a cert.csr file so this is a file for all certificate signed request let's hit enter so the important part of entering the correct dns name or ip addresses comes now because before we create this final certificate let's create a config file to set this correctly the parameter we need to set here is the subject alternative names just we have inspected in the certificates and you can do this by entering specific dns names that resolves to the ip addresses in your internal network or you can also use ip addresses for example i want to generate this certificate which is valid for this ip address but i would also like to enter a dns name if i want to change that later for example let's input a wildcard for cl creative.com which can resolve to my proxmox server but i want also to include this ip address here uh let's check oh no it was the four and we put this content basically in a file which is called xfile.cnf and uh when we inspect it you can see it's just the content in the file here okay so now let's generate this certificate from the certificate signed request and we just use the x 509 module of the open ssl tool and issue a new certificate with this hash that is valid for a specific time so now we can also put a longer time in here for example let's add a zero and we input our certificate sign request here so third.csr that we've just generated and we also need to include the certificate of 40s third here so the c8.pam and the ca key as well and output this into our search.pam files so this will be the file for the ssl certificate we also need to include the xd file so the xfile.cnf where we have defined the subject alternative names and at the parameter ca create serial so this is important when you're issuing more than one certificate to add a serial number that is increasing so let's hit enter and now we need to enter the passphrase for the certificate authorities private key and that's it our ssl certificate is generated so now we have a few different files in this project folder so we have the ca key the private key of the certificate of 40 the certificate of short keys certificate oh man i just get confused here and the certificate private key the signed request we don't need anymore and the certificate but we are not finished yet remember when we talked about the certificate chain and how the client validates the certificate so we need to combine both of these certificate files the c8.pam and the cert.pam into one single full chain certificate file and it might sound like another complicated thing but it's just actually put both files together in one so you can just use the cut command to put the output of the cert.pam file into a new file which is called full chain dot pen and then just cut the output of the ca3.pam file and add it to this file so it's actually just both files combined to one and on my proxmox servers web interface there's also a menu for importing our ssl certificates so when we go to certificates here we can upload a custom certificate and now we just need to put the private key in here so we just need to copy the output of the search key.pam so just copy it and the output of our certificate chain so put it here and upload it and when we reload the page you can also inspect the certificate this is our generated ssl certificate but you can see the connection is still not trusted because our windows client or the browser does not trust our ca that we've generated and this is because we haven't imported it in the trusted root certification of 40 store and this is also very simple so on my cheat repository i've documented how to do this on the different clients you can do this on linux you can also do this on windows or on your smartphones like android and ios for example so on windows it's actually pretty simple you just need to execute this command here in the powershell so let's just do this and import it oh i probably need to do this with administrator privileges and now it is important you can also inspect the root ca store so let's check if this is really there so when we go in here you can also see here is our ca that we've just imported okay so sometimes you need to close the browser and reload it again but now you can see the connection is trusted and when we click on this icon you can see the connection is secure and their certificate is valid because when we go to the certification path the client now trusts our cac at creative which we have just generated and imported into the trusted root ca store okay so i know that was a lot and you might take some time to rewatch this video and follow some of the steps by looking into my cheat sheets repository on github but that's totally fine i think getting those ca certs into the trusted root c8 store is probably the most annoying task because you need to do this on every single client in your network and i've already thought about automating this process so for example i've written a short powershell script that will do this entirely on my windows clients or you could also think about integrating this cas cert into any vm images or using tools like terraform or ansible for mobile devices i haven't really found a great solution here unfortunately so you probably need to do that on every phone that you're using manually but if you generate a certificate authority that is valid for a very long time you only need to do that once and then you can still issue new certificates for different services later the client still will trust these new certificates because they were issued by the same ca that you already imported before so i hope this helps you in your home lab and in your internal network to get rid of any certificate warning and you could also learn something useful and as always thanks to everybody for watching i will catch you in the next video take care bye bye

Channel: Christian Lempa

Views: 183,697

Keywords: certificate authority, create self signed certificate openssl, digital certificate, root authority, secure socket layer, self signed ca certificate, self signed certificate, self signed certificate erstellen, self signed certificate explained, self signed certificate lunar client, self signed ssl zertifikat erstellen, ssl certificate

Id: VH4gXcvkmOY

Length: 25min 1sec (1501 seconds)

Published: Mon Feb 28 2022