rXg's Certificate Management is AWESOME
The rXg's Certificate Management feature is one of my favorite things about it. as someone who has managed ssl/tls certificates on many different platforms at many different times, including manually, I absolutely love the convenience of this feature. It pairs AMAZINGLY with the previously discussed http virtual hosts feature, and in my post about how I set up this blog.
Certificates
Authentication
Certificates are an important layer of security that make the web trustworthy and valuable. Without them, it would be very difficult to know whether the page you are visiting actually originated with the entity that owns the domain you are visiting or if any of the dozens of intermediate hops are impersonating it.
Certificates are essentially signed public keys. What is signing and signed by whom, you may ask. Signing is a way for an entity to affirm that it approves a particular piece of data. Unlike real world pen and ink signatures, electronic signatures use a cryptographic process.
Every modern device, be it a phone/tablet/laptop/desktop or whatever, ships with
a number of trusted root certificates. In Ubuntu Linux, these are found in
/etc/ssl/certs. These are determined by the distribution maintainer and can be
updated periodically through system updates.
Every time you navigate to a website that supports SSL/TLS (TLS is the newer terminology), your browser downloads one ore more certificates from that site, and the site proves that it has the private key correlated with the site's certificate by sending a small amount of data signed with that private key, which the browser is able to decrypt with the public key in the certificate. These certificates form a chain of signatures eventually going back to a root certificate that is trusted by a certificate on your machine.
Every decent browser can allow you inspect a site's certificate. When I inspect the certificate for 802.11.henryhaller.com I find that it goes back to an ISRG root certificate installed locally.
Feel free to verify this on any site you visit!
⚠️ Note: One common failure mode of very old and very out-of-date devices is that they sometimes will not recognize newer certificates as valid because they do not have the appropriate root certificate, since it may have been generated after the last system update.
Encryption
It may interest you to note that most of the encryption of data between your browser and the websites you visit does not use the site's certificate private key directly. Instead, your browser and the site negotiate symmetric session encryption key material within the privacy of the a-symmetric encryption provided by the certificate. This symmetric encryption is far more efficient CPU-wise, and the symmetric encryption keys can be rotated much more frequently because they are only used on a per-session basis within one browser.
Getting a Certificate
By default, most systems use a self-signed certificate out of the box. These produce those certificate warning errors that we all know and love. This does not mean the connection is unencrypted, it just means that the ownership of the domain that the site is operating on has not been validated. In order to get a working certificate, you must validate the ownership of your site to such an authority. The most common way to do this is Domain Validation.
Domain Validation
Domain Validation is the relatively simple process of proving that you are the rightful owner of a domain. Fortunately this has been automated and scales up fairly well to a point where you can easily have hundreds of domains served from a single IP address and get certificates for all of them for free. Domain validation generally applies to non-wildcard domains, ie a single specific domain like 802.11.henryhaller.com, not *.henryhaller.com.
Domain validation rests on the assumption that the rightful owner of a domain will be able to control what IP address the domain resolves to (or "points to" in more casual speak). The rightful owner can then validate the fact that they own this domain by having the IP address that this domain resolves to serve a specific file, this process is known as the HTTP-01 challenge by letsencrypt but the same thing applies for zeroSSL as well. When the challenge succeeds, the CA (Certificate Authority, an entity that signs certificates) accepts that the certificate signing request is valid and signs it.
Domain Validation and rXg
On the rXg this process is very simple. All you have to do is navigate to System::Certificates and create new. Mine is already filled out, but a new one will only have the private key. For sign mode, simply choose "Generate CSR for [letsencrypt|zerossl] to sign". Then just fill out the rest of the fields with what seems best to you.
Note that the "active" checkbox at the top should be checked ONLY for the certificate that you want the rXg's web UI itself to use.
⚠️ Note: THE EMAIL THAT YOU PUT WILL BE PUBLIC. Also it will be validated, so it must look real.
Once the certificate record has been created, just give it a minute or two to automatically "renew" or click on the renew button yourself.
⚠️ Note: This rXg MUST have a public IP address, it CAN NOT be NATed.
zeroSSL
Zero SSL is another CA, just like letsencrypt. It works about 99% the same. The main difference is that you must have zeroSSL credential, which is free and easy to obtain and you must put that credential into the rXg into a Certbot Credential record at the bottom of System::Certificates.
What You Can Do With This
Let's say you happen to be running a system that is difficult, tedious, or just doesn't support TLS. Let's say you simply don't want to learn confusing in's and out's of certificate management of multiple different types of systems. If you happen to have systems like this running in your LAN environment, you can simply put them behind an HTTP Virtual Host and associate that HTTP virtual host with a certificate that is managed by the rXg! That is what I am doing with this blog, with my virtual Smart Zone and with my ESXi host.
Thanks for reading and I hope this gives you ideas!