TLS X.509 Client Certificates
How to secure Internet Servers with X.509 Client Certificates? How to deploy X.509 Client Certificates ? How does a Certificate Signing Request (CSR) work ? In this hands-on video we will run a little nodejs Server that requests Authentication with an X.509 Client Certificate, we will Sandbox a CSR with XCA and we will have a look at OpenXPKI which is a great Software to automate processes around TLS and Certificate Generation, Key Management and the like. Last but not least I show a Blueprint on how to securely link a hosted MQTT into your home automation Software.
The nodejs Server Example is on my github
The XCA Tool can be obtained here
More Info on my Cheat Sheet Repo on Github
Watch the video on YouTube
Click to view the entire transcript
(the use case)
Let me show you how I open the door to my
house or to my garage at home with my mobile
I open this app where I can type in a pin,
click on this button and then the door opens.
That app is in fact just a web page running
on a web server in the cloud.
Now I hear you say – “Marc, are you mad
– do you really allow everyone to open the
door to your house at night?” - of course
not – the site is protected with a client
That means that my phone is the only device
on this planet that can browse to that web
Here is how I did it.
We had talked about certificates and about
this nice GUI here called XCA in the last
I showed you how to generate a Certificate
Authority, a CA, and how to generate server
Now the great thing with X.509 certificates
is, that we can also use them for client authentication.
That means that a web server would only answer
requests coming from a device that has the
All others will be rejected.
Imagine how you could secure for example your
Nextcloud instance, your personal photo collection
or – like I do – simple apps to interface
with your IOT at home in a way that only you
can use them from your tablet or phone.
(Demo server from my Github)
If you browse to my github repository, then
you can find an example for nodejs that does
exactly what I showed here – it shows a
web page with the two input lines for a pin
and two buttons.
In order to use it, you will need a host with
Windows, MacOS or Linux – it doesn’t matter.
Just copy the files to a subdirectory and
start node testserver.js.
The server now answers requests on port 8443.
So if you now browse to let’s say https://testserver:8443/form
then you will most probably get a certificate
In the ca subdirectory you can find a self-signed
certificate authority (CA) that you can import
into your browser.
In Chrome and Firefox this is done under the
Alternatively - if you want to run this on
a server with valid Let's encrypt certificates
or the like, just replace the files server.crt
and server.key with the certificate and private
key of your "real" server.
Don't replace the ca.crt file as it's used
for client authentication!
The files server.crt and server.key in the
ca subdirectory have been signed with the
ca.crt for testing purposes.
If you want to test without certificate warning,
then you could just make an entry into your
host file and point testserver to any host,
for example your localhost by adding the following
into your /etc/hosts file (on Linux) or your
If you now browse to the URL again, then your
browser should tell you that you have been
rejected as you don't have the right client
That's the purpose of this exercise ;-) - In
order to gain access, you need to import the
file testuser.p12 from the xca.db sub directory
into your browser.
Let me do this.
I’ll go again into the security settings
of my browser, then import the certificate.
The password for this is hello.
Let me open the page again – and now the
My browser tells me that the server is requesting
It asks me which certificate I should provide.
If I now select the testuser certificate,
then the page opens.
I can use it as desired.
Without having to type any username or password,
without using a VPN.
Just plain TLS certificates.
On my phone, it would just use the certificate
(How to generate client certificates)
So – how can we generate our own client
Just like in the last episode, we will use
XCA for this (you could do this on the command
line as well with OpenSSL of course).
Launch XCA and open the xca.db file from my
github – this already contains some sample
As you can see, there is a CA, a server certificate
and also a client certificate.
How did I generate the client certificate?
Well, pretty much like the server certificate
in the last episode.
I clicked on “New Certificate”, just this
time I chose and applied the TLS_client template.
As a common name this time I just entered
the name “testuser” And of course this
one also needs a key.
So I generated a new one.
In order to be able to use this with my web
browser or phone, I exported it as PKCS#12
file, because that file format contains both
the key and the certificate and also I know
that my iPhone can read that type of certificate
As there is a private key inside, I now needed
to protect it with a password.
The password for all the sample data on my
github is just “hello”.
(how secure is this)
You might have doubts on the security of this.
And you are right to challenge that.
We should not take security lightly.
In a nutshell, the certificate is just another
An authentication factor can be something
you know – such as a user name and password
– it can be something that you are – so
biometric data, or it can be something you
have – like a key, a token or a certificate.
So if you wanted to let’s say make the admin
frontend of your nextcloud or photo sharing
app or anything else super secure, then I
would not ask you to remove or replace the
password authentication, but rather add the
client certificate requirement on top of it.
That would reduce the surface that you potentially
expose to hackers by a huge percentage – I’d
say above 99% really.
If you have services running in the web – be
it a password protected web site or an ssh
server or whatever – then you will see hundreds
if not thousands of log entries from people
or bots attempting to connect to it.
Every single day.
They get to the login prompt and now they
can start guessing passwords or using cross
site scripts or injection attacks to your
If you had that site locked down with a client
certificate, then all these attempts would
not even get to that page on the application
layer because they would be rejected by TLS
a layer below.
On the presentation layer, between the TCP
protocol and the application.
Still, there are remaining attack vectors.
If someone gained control over the server,
then they could of course do whatever they
You still need to secure the server.
If someone had gained control over your client,
then they could potentially steal the client
certificate and use it.
If someone is able to get into the middle
between you and the server, then they can
potentially intercept data as well and exploit
weaknesses of the protocol.
Last but not least, if someone had a day 0
exploit to TLS, or if you used an old version
of TLS that has known vulnerabilities, then
they could use that as well.
But still – the security level is not worse
with certificates than it was without certificates.
All these attack vectors can be exploited
with or without certificates.
(how to deploy client certificates)
The main challenge with this concept however
is the distribution of the client certificates.
Not a big thing if you need to put it into
one single web browser.
But how would you distribute these let’s
say to 10 or 100 clients?
And how would you distribute them to let’s
say an iPhone?
In an enterprise environment those devices
would be managed by a central Mobile Device
Management platform such as intune or altiris
or the like.
In the home environment this is a challenge
Let me first quickly show you how it should
NOT be done.
I’ll attach the PKCS#12 file (which includes
the certificate _and_ the private key) to
an email and send that email to my mobile
Now this is great in the sense that I can
now easily open and install the certificate.
But even though the PKCS#12 format is password
protected, this is a weak protection.
Especially if you chose a super weak password
like 12345 or hello.
This would actually open an additional attack
vector – the interception of the certificate.
(Certificate Signing Requests, CSR)
So how to deal with this?
In a real life secure scenario, the private
keys should never ever leave the system where
they have been generated on.
Now – I do not have an app that allows me
to generate keys on my iphone, so let me show
you this with two instances of XCA.
One instance would be the client who wants
to have a client certificate signed by the
CA, let’s call him Marc – that’s me,
and the other instance would be the site that
has the private key for the CA, let’s call
So first, I would download the ca certificate
The public part.
Without the private key.
Then I would generate a private key which
I would want to use with that certificate.
Now – rather than creating a certificate
(which I could not sign anyhow because I don’t
have onemarcfifty.com’s private key), I
would now generate a Certificate Signing request,
That CSR contains the public key that complements
my private key.
And I would then submit that CSR to onemarcfifty.com.
So let me export this on Marc’s side and
then import it on onemarcfifty.com’s side.
On the Onemarcfifty.com side, this CSR can
now be signed with their CA.
That generates a certificate below the CA
Now Onemarcfifty would export that ready made
certificate which now contains the public
keys of Marc and of the onemarcfifty.com CA.
But still no private key has been transferred.
Onemarcfifty.com send me that certificate
and I’ll import it.
Because I do have my own private key plus
the public key of the CA, the certificate
will now be properly linked to the CA and
I can use it.
You could in theory do that workflow over
e-mail – I would really not recommend it,
but you could.
No secret information was transmitted at any
point in time.
Just - a thoroughly forged man-in-the-middle
attack could still be possible.
A malicious attacker who has access to your
e-Mail could replace your request with their
own and hence get granted access to onemarcfifty.com.
Also – some information that you transfer
with the CSR could be used to lower the effort
for brute forcing the encryption.
Please remember that most successful attacks
do not attack the encryption.
They rather try to circumvent it.
And many popular attacks in the past aimed
at the authentication process.
That means the part of the process where you
prove that you are authorized to obtain a
If you send the CSR via e-mail then the only
authentication is your e-mail address.
The CA can’t verify your key.
There is actually free and open source software
available for that type of workflow.
Have a look at openxpki for example.
You can self host this software.
For testing purposes, there is a demo site
where we can actually log in with demo accounts
and submit CSRs and they’ll sign it for
So I create a CSR
- export it
- Generate a Request on the openxpki platform
Now – here I am at the same time the officer
who approves this request – normally that
would be a 3rd person.
- And now I can download the signed certificate
So – if I made the access to that site quite
secure with let’s say an additional 2nd
factor such as a one time password or a temporary
code sent via text message, or the site would
only be available in the intranet for example,
then I could make that quite secure – by
home or small business standards.
If I go back to the initial application that
I have shown in the beginning, then we could
even take this blue print further.
Many home automation products can use MQTT
as a protocol.
Let’s say you have your MQTT Server running
here at home in a container or on your router.
And here on the other end we are in the internet,
so outside of the LAN.
In order to open the door at home we need
to publish a command to MQTT.
Now here we could have a VPS, a cloud server
for a dollar or a free oracle instance or
the like that has Letsencrypt Server certificates.
If we add a self-signed CA here then we can
do the following.
Our MQTT at home could communicate over TLS
with an MQTT instance here on the VPS.
Our phone could securely connect to a little
nodejs server here using client certificates
and issue the command to the local MQTT which
would in turn relay the command to the MQTT
at home which would then instruct the home
automation to open the door.
No passwords, no VPN, no hole in the firewall,
no port forwarding.
Just the right certificates at the right places.
Guys, we’re running out of time.
Let me know if you liked this episode.
Leave me a comment if you want follow-ups.
All links and the example code are in the
description and on my github server.
In any case – thank you so much for watching.
Stay safe, stay healthy, bye for now.