(about certificates)
We all know this nasty warning here when we open web pages in our own intranet. We don’t have a certificate. Today I want to show you three alternative
ways to get rid of that. How can we do that? First option – self signed certificates. We will use this great free and open source
software called XCA to generate our own Certification Authority or CA and our own certificates. No fiddling around with command line OpenSSL
or the like. Nice software. I love it. Second option – We can use Let’s Encrypt
Server certificates in our LAN – and the third option that I want to show you are Wildcard
certificates with a dedicated sub-domain. Let’s go step by step (self signed certificates)
In the first episode I have already shown you this very cool software called XCA by
Christian Hohnstädt. It’s awesome and it’s free open source. As a reminder – if you browse to https://hohnstaedt.de/xca,
then you can download it for various platforms such as Linux, MacOS or Windows plus there
is a portable version. After you start the software, you first need
to generate a database where we will store all the certificates. So you click on File – New Database, then
you give the database file a name and after you have created the file, XCA asks you to
assign a password to that database. Make sure you use a password you can remember
– there is no way to recover it if ever you forget it. (create CA)
So now, we can create our own CA – just like we did in the first episode. Click on “New Certificate”, select and
apply the default CA template down here at the bottom, then move over to the “Subject”
tab and fill out at least the fields Internal Name, countryName, organizationName and commonName. Last but not least, generate a new key for
the CA and confirm everything. (create Server certificate)
Here we go, we have our own CA. Now let’s generate a Server certificate
that we sign with this CA. Again, I click on “New Certificate”, this
time I select the existing CA for signing and I apply the default TLS_Server template. As an internal and commonName, I now type
in the name of the server that I want to create the certificate for. Again – fill out the country and organizationName
fields and generate or use a key. If you want this certificate to be valid for
multiple names – for example short names and fully qualified domain names or IP addresses,
then you can add these here under Extensions as Subject Alternative names. You could as well generate a wild card certificate,
if you wanted to use one single certificate for a whole domain for example *.onemarcfifty.com. (export components)
Cool – now we just have to export the various components in the right formats and then distribute
them to the right places. The web server which we create the certificate
for needs the server certificate and the server key. Our browser just needs the CA certificate
(again without the private key). So let’s export everything. There are various export formats. Some of them contain the certificate and the
private key, others do only contain the certificate or the key in separate files. Let’s start with the CA. Click on export – the most common format
without the key here is PEM – that’s basically a base64 encoded or packed version of the
text certificate or chain. The file extension .crt just makes it easier
for some software to recognize it as a certificate. So let’s call this one ca.crt. Next we need the server certificate. So this is the same game really, click on
export, select PEM as the format, let’s call this one server.crt. Last but not least, we need the key on the
server. So move over to private keys, make sure you
select the right key, Export in pem format. Just this time let’s call it server.key. The file extensions and names are not really
standardized anywhere. The PEM format itself is a standard but the
naming of the files is entirely up to you or to the software that you are using. I just like .crt and .key because it clearly
shows what it is. (distribute components)
I want to use this certificate with an OpenWrt router. If I browse to the router’s address then
you can see that I get that ugly security warning. Here’s the detail of the current certificate. I will now replace the original certificate
with my own. I just need to copy the two server files to
/etc on the router and name them uhttpd.key and uhttpd.crt. Before I can use them, I need to quickly restart
the uhttpd daemon on the router. If I now open the page, then I get the same
warning. Just this time the certificate is my own. In order to trust it, I need to import the
CA to my web browser. I go to settings then security and down here
I can manage the certificates and also import the CA. Let me do that. If I now refresh the page, then it shows up
secure and without a warning. Mission accomplished. Let me quickly view and check the certificate
– here you can see all the details like the issuer, the subject and also all the alternate
names that it is valid for. Where exactly you have to put these certificates
on your server and how you have to name them really depends on the server software. Check my cheat sheet repository on Github. I will try and make a short overview of the
most common products and the place where they expect the certificates to be. So far for self-signed certificates. The advantage of this mechanism is, that you
can generate any certificate really. The disadvantage is that you really need to
import the CA certificate to any client and to all clients that want to browse to that
server. Now for another method – Let’s encrypt
certificates. (Let’s encrypt server certificates)
Here is how you would typically use Let’s Encrypt certificates. You have a web server running in the internet
and on this server you run the certbot software. That software periodically connects to Let’s
Encrypt and requests a new certificate using the ACME protocol. Let’s Encrypt would then do a DNS lookup
of your server and check if this is the server that made the request. If yes, then they would either say – “no
need to renew, your certificate is still valid” or they would give you a new one. So how could we use this in our LAN then – in
our local network? Let’s first have a look how we can use server
certificates and then look at wildcard certificates. (How to use Let’s Encrypt in the LAN)
If you own a domain – like I do with onemarcfifty.com – then you could do the following. You define your internal domain name, so the
DNS domain that you use inside your lan, to be the same domain like the one that you use
in the internet. I could therefore use the domain onemarcfifty.com
inside my LAN. Why not? I have control over the DNS inside my LAN
because that’s running on my router. So my proxmox server for example would then
be called pve.onemarcfifty.com. It’s not reachable from the outside, it’s
just a name I give it internally. So how would I give this server a public certificate
then? Well, I would just make an entry for the server
in my public DNS as well and let that entry point to the same server that has the certbot
agent for let’s say www.mydomain.com. That entry could be an A record pointing to
the server’s IP address or it could be an Alias or CNAME pointing to the name of that
server. The certbot on that server can now request
certificates for that name. If I browse to that server name from inside
my LAN, then I would not be redirected to that www server, but rather the machine that
I have running inside my LAN. So all I’d have to do is copy those certificates
along with the server’s private key from the WAN machine to the server in my LAN and
that server would then have a valid public certificate. Those certificates are located under /etc/letsencrypt
on the public server. This solution has a couple of challenges though. Of course, the certificate would only work
if I called the server page by it’s fully qualified domain name. Because the certificate had been issued to
pve.onemarcfifty.com but not just to pve. So I would still get a certificate warning
if I used the short name. Also – I would potentially need to make
a lot of entries in my public DNS if I wanted to use this for multiple servers. Plus – I either need a cloud server or I
have to open ports on my firewall so that the certbot can be checked by Let’s encrypt. Here’s another solution: Wildcard certificates. (Let’s Encrypt wild card certificates)
Wild card certificates from Let’s Encrypt work like this: your certbot requests a wildcard
certificate let’s say for *.onemarcfifty.com – now, rather than connecting back to a
specific host, Let’s Encrypt now give you a challenge: They tell you to put a txt record
named something like _acme_challenge into your dns. They give you an arbitrary value to put into
that record. If they can successfully query that txt record
and if it does contain the value that they have requested you to put in there, then they
know that you are the owner of that domain. They issue the wild card certificate. Yo do NOT need to open any ports. You do NOT need a server in the cloud for
this. This method of course does have challenges
as well. If you want to automate it, then you would
need an API for your DNS provider. But there’s a lot of howtos on the net for
digitalocean, cloudflare and many others. I am using a German Web space provider who
do not offer an api. In this case I can use a manual authentication
hook script that basically logs into their web ui and makes the entry as requested. So now I have a certificate that is valid
for any host inside onemarcfifty.com and also for any domain under onemarcfifty.com – I
could therefore use a subdomain inside my lan – such as local.onemarcfifty.com. And I do not have to create any public DNS
entries for my hosts inside my lan. Any host in that sub domain would show as
valid in the browser if I provided a copy of the wildcard certificate to it. I am using this in my network on a reverse
proxy server running nginx. Whenever I cross network or rather VLAN boundaries,
then the traffic is redirected over this proxy server in order to ask for a second factor
of authentication. That reverse proxy has a wildcard certificate
for my domain. That means that all SSL or TLS traffic that
I have running via that nginx would automatically be shown as secured and OK. Just to round this subject up: If you are
using the Let’s Encrypt Certificate method, you should be aware that due to Certificate
Transparency (CT) or rather Audit requirements the CA Authorities keep publicly available
logs of every single certificate that they issued. That means that everyone on this planet may
know that I have a server called pve.onemarcfifty.com and also everyone may get a copy of that certificate. Of course without the private key. But still I am exposing the naming scheme
of my servers. May or may not be an issue for you. Perfect – I hope I could give you a couple
of ideas on how to use Server certificates in your LAN. Let me know if you want to have a follow up
on anything – leave me a comment here on YouTube or start a discussion on my discord
server. In the next episode I want to show you how
you can secure access to web servers by using x.509 client certificates. This does not seem to be used so frequently. However it can shrink the attack surface of
your servers exposed to the internet considerably. This is going to be a very interesting episode. Don’t miss out on it. Until then – thank you so much for watching,
liking and leaving comments. Stay safe. Stay healthy, bye for now.
