Re: But why is it so complicated?
Alright mister "I can pinch my grandkid's cheeks while simultaneously playing guitar on vacation in the Alps", have at you. Welcome to Certs 101—or How I Learned to Stop Worrying and Love OpenSSH
Certificates are cryptographically secure chains (terminology: the chain of trust) that are able to verify eachother through a web of cryptographic keys and signatures. Just like you don't need to know polynomials to know algebra exists and works, you don't need to know the ins and outs of cryptography to use certificates, and it really is quite straightforward.
Firstly, it is necessary to mention that there are usually 3 separate parts to a valid certificate:
1. The private key;
2. The public key;
3. The signature.
There are other varyingly relevant data points (including expiry date) but this is all you need to know to fathom the idea of certificates. What people call a "certificate" or "cert" is usually a file containing the public key and the signature, as well as various related (and cryptographically secure) metadata. On Windows, they appear as *.crt files, and you might have seen them as .pem on *nix. The private key is kept separate, for reasons outlined below.
A cert's signature is generated using a second cert's private key. The private key should never be shared, ensuring the person that originally created the second cert can sign the first. The public key is used to verify signatures created with its sister private key, but cannot be used to sign new signatures. This process makes it easy to verify the validity and trust of a signature, while making it highly improbable to fake one.
Since we need a private key to sign a certificate in the first place, we can create self-signed certs, also known as root certificates. These root certs can be used to sign other certs down the line, creating the chain of trust. But if the certs in the chain all come back to this root certificate, how can we trust the root, thus giving credulence to the chain?
A CA, or Certificate Authority, is an entity that is responsible for widely-trusted root certs. They create root certs and provide tools to have other people's certs signed by them. We choose to trust CAs and their root certs because they put their reputation as a company and policies behind the certs they provide. If you look through a certificate viewer eg. in your web browser, you'll see all certificates on your computer trickle back up to root certs provided by Microsoft, Google, Verisign, GoDaddy, Symantec, etc. Every operating system and/or web browser has its own list of root certs that it trusts, and these certs are usually provided along with the software.
That's it, really. Not too complicated right? Now we can get to more practical uses of certificates.
The reason why your browser is giving errors when you try to connect over HTTPS to your control panel is likely because of any of these reasons:
1. The certificate is expired;
2. The certificate is self-signed, and your computer/web browser does not have the cert in its list of trusted root certs;
3. There's no certificate at all.
A solution that would work fine for you is to:
1. Create your own cert;
2. Install it in the server;
2. Install it in your browser/OS's trusted cert store.
You can easily accomplish this with many methods, and I will provide one for OpenSSH (works on any platform). Contrary to popular belief you do not need to pay a CA to get a certificate and can easily self-sign your own. A self-signed cert of your own making is not any less safe than a CA-signed cert, and depending on your viewpoint may be more safe since you probably trust yourself more than some faceless company :)
For the creation of certificates, aside from the private key, there is also the certificate signing request which is a simple file outlining some of the extra metadata that is used to generate an X.509 cert, which is the standardized format for the web. Ever see the company name next to the green padlock in your web browser? That's some of the metadata in the cert that the CSR is used to generate.
You can easily create a private key, CSR, and certificate in order using the following oneliner:
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 1096
key.pem is the private key that was used to sign the cert. cert.pem is the public key, signature, and metadata, in one file. You will be prompted for various pieces of information to fill out the CSR after running the command. The CSR is consumed in the process here; it's optional to save it since you likely won't need it in this instance.
The only thing you need to worry about in the CSR is the Common Name, which should be the address you are accessing the web service through. The Common Name is how your web browser knows it's using the right cert for the right site. If you access it via IP, since you are only using it locally, it is safe (though not recommended) to use local IPs for the CN, eg. 192.168.50.1.
As for installing the cert in the system/OS's trusted store, if you visit the site with the new cert installed in the web server, on a modern browser it should ask you if you want to allow the cert, and if you want to store the changes permanently. This method should work on all major operating systems and browsers and should be all you need to do. Alternatively, if you don't want to have to repeat this process for all the browsers you may use, while mildly outdated here's the easiest way to install a certificate into Windows' trusted store: https://blogs.technet.microsoft.com/sbs/2008/05/08/installing-a-self-signed-certificate-as-a-trusted-root-ca-in-windows-vista/
I don't know how your software works so I won't comment on how to get the cert in there.
(Most of this came from memory so I apologize if I was wrong or misleading somewhere.)
Finally, yes, it doesn't really matter if you have a valid cert on your local network or not, but denying the information just because it might not be immediately relevant is not a very good practice to keep. Even if you don't go through with setting things up properly, let this at least be a lesson into certs and how really not confusing they are. Things can get crazy with OCSP stapling and other additive technologies, but those are outside of your use-case and you likely will never need to care. The basics, however, are still important. Even knowing the basics can give a lot of insight into what might otherwise be considered ungrokable geekspeak, and with how widespread HTTPS is, that makes it even more inportant to know.
Certs 201 is next week and I expect to see you there young man.