Threat Talks - Your Gateway to Cybersecurity Insights

How solid is your digital trust—or are you just hoping your PKI is secure?
Let’s be honest: too many companies run on borrowed trust and forgotten certificates. In this episode of Threat Talks, ON2IT’s Lieuwe Jan Koning and Rob Maas pull back the curtain on what really holds your digital world together—and what can tear it down overnight.
They break down PKI in plain language: the root of trust that must stay locked away, the intermediates that keep your systems running, and the automation that stops your team from clicking “ignore” on yet another warning.
You’ll see why rolling your own keys beats trusting anyone else, how to keep your devices speaking the same language of trust, and why short-lived certificates might just save you from the next big breach.
This isn’t theory—it’s how Zero Trust really starts: by proving that your organization can trust itself.

Additional Resources
• Threat Talks Episode on SSL Decryption – https://youtu.be/Xv_jVHVsD9w
• ON2IT Zero Trust: https://on2it.net/zero-trust/
• ACME protocol (RFC 8555): https://datatracker.ietf.org/doc/rfc8555/
• Let’s Encrypt / ACME protocol – https://letsencrypt.org
• DigiNotar case study background – https://en.wikipedia.org/wiki/DigiNotar
• Mozilla CA Program (trusted root store): https://wiki.mozilla.org/CA
• infographic about encryption  https://on2it.s3.us-east-1.amazonaws.com/20250304_Infographic_Encryption.pdf

Guest & Host Links:
Rob Maas (Field CTO, ON2IT): https://www.linkedin.com/in/robmaas83/ 
Lieuwe Jan Koning (Founding Partner, ON2IT): https://www.linkedin.com/in/lieuwejan/


Key Topics Covered
•  Why root certificates must never be online—and how intermediates provide a safe fallback.
•  Real-world PKI failure: DigiNotar compromise and lessons for CISOs.
•  How ON2IT built a secure, low-cost PKI with offline key bearers and ACME automation.
•  The hidden risks of training employees to ignore certificate warnings—and how Zero Trust demands the opposite.


🔔 Follow and Support our channel! 🔔
=== 
► YOUTUBE: https://youtube.com/@ThreatTalks
► SPOTIFY: https://open.spotify.com/show/1SXUyUEndOeKYREvlAeD7E
► APPLE: https://podcasts.apple.com/us/podcast/threat-talks-your-gateway-to-cybersecurity-insights/id1725776520

👕 Receive your Threat Talks T-shirt
https://threat-talks.com/

🗺️ Explore the Hack's Route in Detail 🗺️
https://threat-talks.com

🕵️ Threat Talks is a collaboration between @ON2IT and @AMS-IX

What is Threat Talks - Your Gateway to Cybersecurity Insights?

Threat Talks is your cybersecurity knowledge hub. Unpack the latest threats and explore industry trends with top experts as they break down the complexities of cyber threats.

We make complex cybersecurity topics accessible and engaging for everyone, from IT professionals to every day internet users by providing in-depth and first-hand experiences from leading cybersecurity professionals.

Join us for monthly deep dives into the dynamic world of cybersecurity, so you can stay informed, and stay secure!

00:00:00:03 - 00:00:02:03
You need a PKI infrastructure.

00:00:02:03 - 00:00:04:12
You may have one,
but did you build it properly?

00:00:04:12 - 00:00:06:08
And that's what we're going to talk about today.

00:00:06:08 - 00:00:08:07
Welcome to Threat Talks.
My name is Lieuwe Jan Koning.

00:00:08:07 - 00:00:11:18
And here from headquarters at ON2IT,
we bring you Threat Talks, a Deep Dive.

00:00:12:00 - 00:00:15:02
And the subject of today is the
private (public) key infrastructure;

00:00:15:10 - 00:00:16:15
how to set it up.

00:00:16:15 - 00:00:19:10
Let's get on to it.
Welcome to Threat Talks.

00:00:19:10 - 00:00:22:15
Let's delve deep into the dynamic world
of cybersecurity.

00:00:23:11 - 00:00:25:02
Let me briefly introduce
our guest of today.

00:00:25:02 - 00:00:27:10
It's Rob Maas. He's the
Field CTO of ON2IT.

00:00:27:10 - 00:00:32:10
And on a day to day basis thinking
about anything security.

00:00:32:10 - 00:00:36:01
And a couple of weeks ago, we promised you
when we were talking about SSL

00:00:36:02 - 00:00:39:12
decryption, that we would
organize a whole

00:00:39:12 - 00:00:42:18
episode on PKI infrastructure
because, we need

00:00:42:18 - 00:00:46:17
that kind of infrastructure, in order
to properly decrypt outbound traffic.

00:00:46:17 - 00:00:48:01
Isn't that right, Rob?

00:00:48:01 - 00:00:48:15
That is right.

00:00:48:15 - 00:00:52:16
For outbound traffic, we need to sign, or
generate a lot of certificates and sign them.

00:00:53:07 - 00:00:56:05
And therefore, you need a public key
infrastructure, at least that's

00:00:56:05 - 00:00:57:13
one of the reasons you need to have one.

00:00:57:13 - 00:01:01:13
Yeah. There's multiple, I mean,
you want to make sure every time

00:01:01:13 - 00:01:05:02
you sign a certificate and, don't use
self-signed certificate and all that.

00:01:05:02 - 00:01:07:10
So you need an easy way to create-

00:01:07:10 - 00:01:09:17
Another good example would be
management interfaces

00:01:09:17 - 00:01:12:18
as of, nowadays, almost every
management interface

00:01:12:18 - 00:01:15:18
is web based, often encrypted luckily.

00:01:15:22 - 00:01:19:22
And then, it comes with a self-signed,
but it's better to put in- Always replace it,

00:01:19:22 - 00:01:24:11
and how do you do this without going to
a vendor online and buy one?

00:01:24:11 - 00:01:25:15
Yeah. Okay.

00:01:25:15 - 00:01:29:10
And for SSL decryption, quickly
once more, what we talked about is,

00:01:30:05 - 00:01:34:16
if I want to decrypt my outbound traffic,
it means that my firewall or decryption

00:01:34:16 - 00:01:39:09
device needs to sign a certificate, sign my
session on behalf of this website I'm visiting.

00:01:40:09 - 00:01:41:12
More or less.

00:01:41:12 - 00:01:42:22
So the firewall is in between.

00:01:42:22 - 00:01:45:14
It acts as a man in the middle.

00:01:45:14 - 00:01:48:12
It will set up a proper connection
with where ever you going to.

00:01:48:12 - 00:01:49:18
For example, Facebook.

00:01:49:18 - 00:01:54:02
And then it will generate a certificate
that mimics the certificate of Facebook,

00:01:54:02 - 00:01:59:04
but then signed by a certificate
as being trusted by your clients,

00:01:59:17 - 00:02:02:04
so that if the client gets
the certificate, it refers to

00:02:02:04 - 00:02:06:08
the certificate of the firewall and then,
yeah, the connection can be set up

00:02:06:08 - 00:02:08:16
and the firewall can read along
because it’s in the middle.

00:02:08:16 - 00:02:08:21
Yeah.

00:02:08:21 - 00:02:12:23
We need some kind of infrastructure
that we call, private key infrastructure.

00:02:13:06 - 00:02:16:06
That somehow makes sure that
all those devices, laptops, phones

00:02:16:06 - 00:02:19:06
and all that trust this signed
certificate, that's what

00:02:19:07 - 00:02:21:05
this whole thing is about.
Okay. That's correct.

00:02:22:04 - 00:02:23:19
So what is it, PKI?

00:02:23:19 - 00:02:25:19
Is it then a server, what?

00:02:25:19 - 00:02:28:19
Yeah, it’s more or less
a framework or a set up.

00:02:29:01 - 00:02:31:23
Not sure what the right words
would be here, because you can do it

00:02:31:23 - 00:02:34:23
almost completely offline,
without servers.

00:02:35:00 - 00:02:37:03
So there are a few components
that require server,

00:02:37:03 - 00:02:39:12
but most of the things
you can do even offline.

00:02:39:12 - 00:02:42:10
But you can also go almost
a fully automatic way,

00:02:42:10 - 00:02:46:09
like Let's Encrypt and the ACME
Protocol, we will come to that.

00:02:46:09 - 00:02:47:13
And then everything in between.

00:02:47:13 - 00:02:51:05
I think most companies will end
up in kind of a hybrid setup.

00:02:51:16 - 00:02:54:00
Okay. Yeah. But we're going to talk,

00:02:54:00 - 00:02:56:11
we'll start with explaining a little bit
about the basics, and then later

00:02:56:11 - 00:02:59:11
we'll explain exactly how we did this,
because we have our own

00:02:59:16 - 00:03:04:12
PKI infrastructure. And we can
share exactly how we did this,

00:03:04:12 - 00:03:07:11
actually, there’s nothing secret about it.

00:03:07:11 - 00:03:11:21
Maybe the passwords and the location of the key.
[ ] a private key, but the rest we can share.

00:03:11:21 - 00:03:12:10
Yeah, exactly.

00:03:12:10 - 00:03:13:04
So we're going to do that.

00:03:13:04 - 00:03:18:06
But let's first, I mean, there is a notion
of a root certificate, a chain and,

00:03:19:09 - 00:03:24:08
intermediate, tell us a little bit,
please explain the lingo for us.

00:03:24:08 - 00:03:27:08
The whole idea about the
public key infrastructure is

00:03:27:08 - 00:03:29:11
we need certificates
that are being trusted.

00:03:29:11 - 00:03:32:18
And the way we do that is by creating
what they call a chain of trust.

00:03:33:02 - 00:03:36:00
And at the top of the chain,
there's always the root certificate.

00:03:36:00 - 00:03:38:00
So that's where it all starts.

00:03:38:00 - 00:03:41:11
And the root certificate is really
a simple certificate, more or less.

00:03:41:11 - 00:03:44:08
You create a certificate
and it will sign itself.

00:03:44:08 - 00:03:47:05
So the root certificate will
basically say, I trust myself.

00:03:47:05 - 00:03:48:12
That's where it starts.

00:03:48:12 - 00:03:51:12
So the only certificate you
can self sign, you're saying...

00:03:51:21 - 00:03:55:12
We do all the other certificates. The one thing
we can sign ourselves is the root certificate.

00:03:55:12 - 00:03:56:16
Yeah. It's signs itself.

00:03:56:16 - 00:03:58:22
You have to start somewhere. Okay.

00:03:58:22 - 00:04:01:04
That's also why, and we’ll come to that,

00:04:01:04 - 00:04:03:18
you should never lose that
private key that belongs

00:04:03:18 - 00:04:06:18
with the root certificate, because there's
no fallback mechanisms anymore.

00:04:07:04 - 00:04:11:16
This does happen, I recall, we are Dutch,
so that's mean that we have to

00:04:11:16 - 00:04:14:16
DigiNotar - DigiNotar is the
most famous one that lost

00:04:15:10 - 00:04:17:16
the root certificate private key.

00:04:17:16 - 00:04:22:18
And then, all the people, got a hold of it
and could mimic that they were trusted.

00:04:23:03 - 00:04:25:04
And they mimic that they
were Google, for example.

00:04:25:04 - 00:04:27:04
That's also how it came to light.

00:04:27:04 - 00:04:27:13
Yeah, yeah.

00:04:27:13 - 00:04:31:09
Because the public part of this key
was actually distributed

00:04:31:09 - 00:04:33:05
in all the operating system
and all the browsers.

00:04:33:05 - 00:04:33:12
Yeah.

00:04:33:12 - 00:04:38:03
The funny fact here is that,
and also not part..., we jump

00:04:38:04 - 00:04:42:09
ahead a bit here, is that in order to
trust your root certificate, you should

00:04:43:23 - 00:04:48:03
send it to all your clients, to the so-called
trusted certificate authority list.

00:04:48:03 - 00:04:51:12
And it can, in Windows,
that's a special folder.

00:04:52:04 - 00:04:55:15
It can also be, for example,
Mozilla has its own trusted root

00:04:55:15 - 00:04:56:13
certificate authority list.

00:04:56:13 - 00:04:59:14
So the browser needs to have it
and you send it everywhere.

00:04:59:22 - 00:05:04:19
And when DigiNotar was being
compromised, Microsoft put out an update

00:05:05:01 - 00:05:09:00
that retracted the DigiNotar
as a trusted certificate authority.

00:05:09:18 - 00:05:16:11
Except for the Dutch, we got 30 days extra
in order to replace all our certificates.

00:05:16:11 - 00:05:17:09
And we’ll get to that.

00:05:17:09 - 00:05:21:11
It is not nice if you lose your
signing certificate. No,

00:05:21:11 - 00:05:24:07
you really have a problem.
So it starts with the root.

00:05:24:07 - 00:05:25:13
It signs itself.

00:05:25:13 - 00:05:26:16
You should never lose that key.

00:05:26:16 - 00:05:28:17
It's really important, put it in a safe.

00:05:28:17 - 00:05:30:14
Then the next thing. Yeah.

00:05:30:14 - 00:05:32:18
One more question about this,
so the root. There are roots

00:05:32:18 - 00:05:36:08
that are commonly accepted in the world,
and that's why the internet works, correct?

00:05:36:15 - 00:05:41:00
That is what we call - [ ], Microsoft,
Google; the big ones, they all put it,

00:05:41:00 - 00:05:43:13
they have a have a group of -
Let’s Encrypt is

00:05:43:13 - 00:05:46:10
maybe now the most famous one.
Let’s Encrypt. Yeah.

00:05:46:10 - 00:05:50:01
And they all have an agreement
that they put that in the browsers.

00:05:50:01 - 00:05:51:13
They put it in all the operating system.

00:05:51:13 - 00:05:54:13
So operating systems then,
because they know the public key.

00:05:54:17 - 00:05:58:07
Everything that stems from that, they can validate.

00:05:58:07 - 00:05:58:12
Yeah.

00:05:58:12 - 00:06:03:09
So and then that’s what brings us
to the chain of trust, the

00:06:04:05 - 00:06:07:12
so you have the root, then you
create an intermediate certificate

00:06:07:17 - 00:06:09:11
because the root, you will bring offline,

00:06:09:11 - 00:06:12:18
so that's not very handy if you
need to sign another certificate.

00:06:13:02 - 00:06:16:08
So the root can then create an what
we call an intermediate certificate.

00:06:16:15 - 00:06:20:03
And that certificate is able
to sign in more or less

00:06:20:03 - 00:06:23:05
in name of the root,
the certificates that you asked.

00:06:23:21 - 00:06:27:05
And you can have multiple intermediates,
but typically you have one or two layers.

00:06:28:17 - 00:06:32:06
What happens then, if I go to a website
that has a signed certificate,

00:06:32:06 - 00:06:34:04
so I retrieve the public certificate,

00:06:34:04 - 00:06:36:06
it will also tell me
it's signed by this intermediate.

00:06:36:06 - 00:06:38:08
And then it will also
lead me to the root.

00:06:38:08 - 00:06:42:09
And it can chain, it can verify
all these certificates. In the

00:06:42:10 - 00:06:44:07
in the shownotes
we have a diagram of this.

00:06:44:07 - 00:06:46:01
That explains this. Yeah.

00:06:46:01 - 00:06:49:05
So the signing certificate, that
intermediate one in between,

00:06:49:06 - 00:06:51:19
so you have the actual server
certificate, that is the one

00:06:52:18 - 00:06:55:22
that is actually, that encrypts
the whole handshake.

00:06:55:22 - 00:06:58:01
Right? Yeah. And that is then
signed by the intermediate.

00:06:58:01 - 00:07:00:07
And that intermediate...
Is signed by the root.

00:07:00:07 - 00:07:02:08
Is signed by the root.

00:07:02:08 - 00:07:05:09
And you have to get them all, so
you can validate the whole chain.

00:07:05:09 - 00:07:08:16
That's the whole ... That's the whole idea
behind public key infrastructure.

00:07:08:16 - 00:07:09:05
Yeah.

00:07:09:05 - 00:07:14:00
Why doesn't the root
simply sign everything then?

00:07:14:00 - 00:07:16:11
Why do we need this intermediate thing?

00:07:16:11 - 00:07:20:00
The first thing is, it’s just
not practical, because

00:07:20:04 - 00:07:23:02
you want to really secure
your private key.

00:07:23:02 - 00:07:24:10
That’s one reason.

00:07:24:10 - 00:07:26:17
Because if that gets compromised,
there is no fallback,

00:07:26:17 - 00:07:29:16
you cannot say I will retract it
and create a new one.

00:07:29:16 - 00:07:32:02
And that brings me
also to the second part of this.

00:07:32:02 - 00:07:36:11
So first, you want to
securely store his key.

00:07:36:11 - 00:07:39:11
So signing is hard, because you
have to get that key online.

00:07:39:19 - 00:07:42:21
But the second thing is, if it is
compromised, like with DigiNotar.

00:07:43:20 - 00:07:46:17
You can... There is nothing left.
Your whole chain is gone.

00:07:46:17 - 00:07:50:21
And if you put an intermediate in between,
if the intermediate gets compromised,

00:07:51:08 - 00:07:54:12
then we can retract that, there are
challenges with that, we’ll come to that.

00:07:55:04 - 00:07:57:00
But the root can create
a new intermediate.

00:07:57:00 - 00:07:59:02
So we have kind of a fallback mechanism.

00:07:59:02 - 00:08:01:01
And then you can resign everything.

00:08:01:01 - 00:08:03:20
Yeah, we have to, but,
then at least we can do something.

00:08:03:20 - 00:08:06:15
Otherwise we have to
completely start over again.

00:08:06:15 - 00:08:08:21
Okay. How do you get a certificate
signed, by the way?

00:08:08:21 - 00:08:11:21
So if you don't have a PKI
and I want to sign my public website.

00:08:12:02 - 00:08:18:18
Yeah. So, there are two ways:
a proper way and a less proper way.

00:08:18:18 - 00:08:21:23
And you’re saying this with a smile, so

00:08:21:23 - 00:08:26:02
there must be like 90% of the certificates
requested are done in an improper way.

00:08:26:02 - 00:08:29:18
Right? Yeah, I think it's changing with,
with Let's Encrypt, but still a lot of,

00:08:29:23 - 00:08:35:16
companies go to an internet provider
or a certificate provider and say, okay,

00:08:35:16 - 00:08:37:05
I want a certificate.

00:08:37:05 - 00:08:41:13
This name, these are - Hostname.
Hostname, yeah, and these fields I want to fill in.

00:08:41:22 - 00:08:46:21
And then they are creating that certificate with
the private key and send it to the customer.

00:08:47:12 - 00:08:47:18
Oh, yeah.

00:08:47:18 - 00:08:50:01
So they generate a key pair, sign it,

00:08:50:01 - 00:08:52:09
and then you download everything
at the same time. Yeah. Correct.

00:08:52:09 - 00:08:56:11
Which means that they have your private
key. Exactly. And that's exactly the point,

00:08:56:16 - 00:09:02:02
why it's not the proper way.
It's because you put a lot of trust

00:09:02:02 - 00:09:06:03
in the certificate authority
that signed your certificate.

00:09:06:08 - 00:09:08:01
So the better way, or a proper way-

00:09:08:01 - 00:09:10:00
So this is an honest moment
for you as a viewer:

00:09:10:00 - 00:09:11:00
Do you do this?

00:09:11:00 - 00:09:14:00
And if yes, listen on.
Yeah. So.

00:09:14:00 - 00:09:17:21
And the proper way to do it is you go to
your server where you need a certificate,

00:09:18:08 - 00:09:21:08
and there you create a private key
and a signing request.

00:09:21:20 - 00:09:23:01
You can do that with OpenSSL.

00:09:23:01 - 00:09:26:01
I think that's the most common tool,
but there are multiple.

00:09:26:11 - 00:09:30:00
And you create the signing request,
and the private key sticks on your

00:09:30:15 - 00:09:34:01
server, and then the signing request
you send to the certificate authority

00:09:34:01 - 00:09:36:02
that needs to sign your certificate.
So the sign

00:09:36:02 - 00:09:40:03
request does not contain the key itself,
but a fingerprint that’s basically-

00:09:40:03 - 00:09:43:03
It contains the public information
and it is more or less the fingerprint.

00:09:43:14 - 00:09:46:14
And then they can generate
the certificate out of it

00:09:46:19 - 00:09:48:01
and they send you the certificate.

00:09:48:01 - 00:09:50:05
But that's only the public part,
the public key.

00:09:50:05 - 00:09:50:11
Yeah.

00:09:50:11 - 00:09:54:00
So and if something in
that channel is broken,

00:09:54:00 - 00:09:57:10
so either someone steals my signing
request or the response to that.

00:09:57:10 - 00:10:00:00
Is that a problem?
No. No. That’s great.

00:10:00:00 - 00:10:01:16
What you get back is public information.

00:10:01:16 - 00:10:03:13
And what you send, yeah,

00:10:03:13 - 00:10:06:15
you want to have it signed by a trusted
authority; if someone else signs it...

00:10:06:15 - 00:10:10:07
Yeah. Yeah.
[ ] not going to sign.

00:10:10:07 - 00:10:12:15
Okay, I understand. Okay.

00:10:13:19 - 00:10:19:03
So, we talked about the
root, the intermediates

00:10:19:03 - 00:10:23:16
and the actual server certificates
that are... is that,

00:10:23:16 - 00:10:26:13
can you see the difference between
those, by the way? Is it ...

00:10:26:13 - 00:10:29:20
In most operating systems
it's quite easy to see it.

00:10:30:02 - 00:10:31:19
Because you can go to the certificate

00:10:31:19 - 00:10:34:19
and then open the certificate
and you see who has signed it.

00:10:35:18 - 00:10:37:22
Quite often you can see it even in names,

00:10:37:22 - 00:10:40:22
because people also,
like to work smart and...

00:10:41:08 - 00:10:44:08
Oh, this is the intermediate
because it’s called intermediate or

00:10:45:00 - 00:10:48:04
but you can see the whole chain in most
operating systems, by simply opening

00:10:48:08 - 00:10:49:23
the certificate. Yeah, okay.

00:10:49:23 - 00:10:52:16
If you go to on2it.net, you click
in the browser on view

00:10:52:16 - 00:10:55:03
certificate, there’s actually three tiers,
one is the root certificate.

00:10:56:08 - 00:10:58:21
Yeah, probably. It’s probably signed,
I don't know by whom

00:10:58:21 - 00:11:01:15
from the top of my head,
but then there is an intermediate.

00:11:01:15 - 00:11:05:11
And there’s a certificate... What if my private key
gets compromised on my web server?

00:11:05:17 - 00:11:09:18
Then I cannot use that to use it
as an intermediate, yeah?

00:11:09:18 - 00:11:11:21
Because there's no rights
on that certificate.

00:11:11:21 - 00:11:13:04
Yeah. Because it has a type.

00:11:13:04 - 00:11:14:05
Yeah. As a type.

00:11:14:05 - 00:11:14:13
Yeah, yeah.

00:11:14:13 - 00:11:17:13
The intermediate is sometimes
called the subordinate,

00:11:17:13 - 00:11:20:13
but official wording is intermediate,
and subordinate is

00:11:20:19 - 00:11:23:11
if it is an intermediate with a layer

00:11:23:11 - 00:11:26:07
on top of it, if it has multiple layers,
it's not a subordinate anymore.

00:11:26:07 - 00:11:30:14
So it's ... kind of a terminology
thing. Okay, good.

00:11:31:12 - 00:11:33:02
So how do we set this up?

00:11:33:02 - 00:11:37:19
Yeah. So we start with creating our root.

00:11:37:19 - 00:11:42:12
Sign itself, put a private key,
create an intermediate after it,

00:11:42:12 - 00:11:49:06
and then immediately put the root
certificate private key offline.

00:11:49:06 - 00:11:50:15
So we create a root,

00:11:50:15 - 00:11:53:08
the root creates an intermediate,
and then the root is going offline.

00:11:53:08 - 00:11:55:09
So nobody can touch it.

00:11:55:09 - 00:11:58:09
And then the intermediate
can sign certificates.

00:12:00:00 - 00:12:03:00
So it's more or less
three steps to start with it.

00:12:04:01 - 00:12:06:05
And that's just, how then?

00:12:06:05 - 00:12:09:05
I mean, do I get my laptop
or you say... Yeah.

00:12:09:05 - 00:12:12:18
So, we can now do this with, this is
also, I think, one of the problems

00:12:12:18 - 00:12:15:21
why a lot of companies don't have
set it up properly.

00:12:16:07 - 00:12:18:06
You can do it with OpenSSL.

00:12:18:06 - 00:12:21:22
But you really need to understand
the concept of

00:12:21:22 - 00:12:25:07
the chain of trust from the
root CA, in order to do so.

00:12:26:05 - 00:12:27:23
And OpenSSL is a command-line tool.

00:12:29:04 - 00:12:33:01
Once you know the steps, I don't
think it's really hard to do.

00:12:33:01 - 00:12:38:00
But most administrators that do set up
the PKI, it's just kind of a side task.

00:12:38:00 - 00:12:42:01
So they don't do this full time, or maybe
they don't see through the whole process.

00:12:43:05 - 00:12:46:19
And there is not a lot of good tooling,
I think Microsoft did an okay

00:12:46:19 - 00:12:50:13
job with the Active Directory
certificate services,

00:12:50:13 - 00:12:54:23
I believe it's called, which
gives kind of a UI to it.

00:12:55:14 - 00:12:59:06
So it makes it maybe less scary to,

00:13:00:10 - 00:13:03:10
to set it up, but still,
you need to do the same,

00:13:03:23 - 00:13:05:04
you follow the same principle.

00:13:05:04 - 00:13:07:06
So if you use the Active Directory

00:13:07:06 - 00:13:09:23
certificate service and you
have set up a root server

00:13:09:23 - 00:13:10:22
containing the private key,

00:13:10:22 - 00:13:15:08
bring it offline and only bring it online in a
kind of a process, when you’re updating a server [ ]

00:13:17:11 - 00:13:17:16
Yeah.

00:13:17:16 - 00:13:23:12
It makes, yeah, I understand, but I think it makes it
more accessible for some people now.

00:13:23:12 - 00:13:25:22
Okay, I would do it in a completely
different... actually.

00:13:25:22 - 00:13:27:19
Yeah. So how did you do it? Yeah.

00:13:27:19 - 00:13:31:18
Well, we have our own root certificate
at on2it.net, for example.

00:13:31:18 - 00:13:37:05
And the first thing we did,
we created an offline system,

00:13:37:05 - 00:13:39:20
right? So we have an offline system.

00:13:39:20 - 00:13:45:23
And, it's, actually, it's just a Raspberry Pi.
That's all it takes. Literally.

00:13:45:23 - 00:13:48:23
And what we did is, we took
our operating system,

00:13:50:03 - 00:13:52:19
stripped it down, like choose a Linux distro

00:13:52:19 - 00:13:56:10
that's really simple, with
not a lot of packages

00:13:56:10 - 00:13:58:16
and everything; it’s not the most important.
But the most important things is

00:13:58:16 - 00:14:00:17
you boot it and you never
connect it anywhere.

00:14:00:17 - 00:14:03:19
The only thing you need to make sure of
is that the OpenSSL tools are on there.

00:14:04:01 - 00:14:05:18
Because it's simple enough.

00:14:05:18 - 00:14:08:07
I mean you need to document it.
Just document how you do this.

00:14:08:07 - 00:14:11:14
And anyone listening who
wants to know, just reach out,

00:14:11:14 - 00:14:13:05
we can share actually how we build it.

00:14:13:05 - 00:14:15:06
It's not all that difficult.

00:14:15:06 - 00:14:19:23
So and indeed the first step is,
we generated a private public key pair.

00:14:19:23 - 00:14:22:18
Now, this operating system
itself is a read only file system.

00:14:22:18 - 00:14:24:23
So we are sure that even,

00:14:24:23 - 00:14:27:21
that nobody really can tamper with it
if it's, it’s an extra precaution,

00:14:27:21 - 00:14:30:23
because it's air gapped anyway,
so nobody's going to touch it.

00:14:31:22 - 00:14:34:22
But the key itself is on a removable drive.

00:14:35:01 - 00:14:36:05
And we made a copy of that.

00:14:36:05 - 00:14:39:05
We actually made two copies of it.

00:14:39:08 - 00:14:43:10
With different phrases on it, because there
needs to be a pass phrase on the private key.

00:14:43:10 - 00:14:46:10
Because even if our private key would leak,

00:14:46:11 - 00:14:49:22
you still couldn't do anything with it,
because you'll need a private key.

00:14:49:22 - 00:14:53:11
And we have people called key bearers,
and we have two of those.

00:14:53:23 - 00:14:58:06
And they keep their passwords,
in a non-digital way.

00:14:58:06 - 00:14:59:14
So in their mind.

00:14:59:14 - 00:15:03:14
They are allowed to write it down
somewhere, but not within ON2IT,

00:15:03:14 - 00:15:06:12
in a very secure location-
Not on the back of the USB stick.

00:15:06:12 - 00:15:09:10
No. And also not on a like, a yellow

00:15:09:10 - 00:15:12:11
marker and a monitor, that kind of thing.
No, and it’s a very long one.

00:15:12:11 - 00:15:15:18
And come to think of it,
a phrase like: “ON2IT

00:15:15:18 - 00:15:19:08
was founded in 2005, and we've
been having a lot of fun since

00:15:19:08 - 00:15:22:06
exclamation mark”, that’s a good
password for this, right?

00:15:22:06 - 00:15:25:22
And not like, it should be
easier to remember

00:15:25:22 - 00:15:27:16
or your favorite poem or whatever.

00:15:27:16 - 00:15:30:02
And those two key bearers have their own key.

00:15:30:02 - 00:15:33:10
With their own password
that only they can know.

00:15:33:10 - 00:15:35:11
And of course we just select those.

00:15:35:11 - 00:15:36:20
And that's an important role.

00:15:36:20 - 00:15:38:07
They don't have to be anyone technical.

00:15:38:07 - 00:15:41:12
They need to be able to carry
a USB stick and to memorize

00:15:41:12 - 00:15:45:09
a very long password and not forget it
and don't throw it away or,

00:15:45:21 - 00:15:50:14
because that would be not nice.
Because what we figured is,

00:15:52:09 - 00:15:55:18
on one hand, we want the key
to exist as long as possible.

00:15:56:17 - 00:15:59:03
The root key, why?
Because we need the public part.

00:15:59:03 - 00:16:06:12
We need to, this is a problem. We are now
at on2itca3.crt is the file name.

00:16:06:14 - 00:16:09:03
That we spread around
the company like crazy.

00:16:09:03 - 00:16:10:13
So all our endpoints have it.

00:16:10:13 - 00:16:14:00
So we have Jamf for our Mac for example.
That pushes it everywhere, all the oparting systems...

00:16:14:00 - 00:16:17:00
This is the part where you put the public part
in the trusted certificate authority.

00:16:17:03 - 00:16:18:07
Yes, yes.

00:16:18:07 - 00:16:19:07
And that's a job.

00:16:19:07 - 00:16:22:07
That's a tough job.
Yeah, especially for unmanaged devices.

00:16:22:11 - 00:16:23:08
Yeah. Indeed. Yeah.

00:16:23:08 - 00:16:26:06
So for Macs it's easy, because we have
a tool for this and it can push it.

00:16:26:06 - 00:16:28:22
And we have integration with DEP
with Apple and all that,

00:16:28:22 - 00:16:30:23
to make that happen.

00:16:30:23 - 00:16:33:11
But we also have a lot of containers
running everywhere,

00:16:33:11 - 00:16:35:18
that's based on Docker files.

00:16:35:18 - 00:16:40:06
In every Docker file, you download
the certificate file, put it in the

00:16:40:22 - 00:16:44:15
operating system chain and then
say update certificates binary.

00:16:45:00 - 00:16:49:03
You don't want to have a root that expires
every month, or even every day.

00:16:49:03 - 00:16:53:08
So our current, I actually looked it up,
our current, CA3,

00:16:53:08 - 00:16:58:00
it was signed in 2020 for 20 years,
because I remember this conversation.

00:16:58:00 - 00:16:59:21
We were there like, okay, what shall we do.

00:16:59:21 - 00:17:02:03
And of course there's all kinds
of regulations and stuff.

00:17:02:03 - 00:17:04:21
So we have SOC2 and ISO
and all those requirements,

00:17:04:21 - 00:17:08:12
we have a crypto policy, and it states,
we actually changed it.

00:17:08:12 - 00:17:11:06
We said, listen, we need to
because it was like one year or so.

00:17:11:06 - 00:17:13:07
And for a root that is unacceptable.

00:17:13:07 - 00:17:13:20
That’s very short.

00:17:13:20 - 00:17:15:12
It's 20 years now.

00:17:15:12 - 00:17:22:10
And we said because, probably
there’s really not a solution

00:17:22:10 - 00:17:25:06
anyway, the world has changed so much by then.

00:17:25:06 - 00:17:29:09
We did a lot of things to never have to
change it again, unless disaster happens.

00:17:30:13 - 00:17:33:12
The reason, by the way,
we were signing this in 2020

00:17:33:12 - 00:17:35:19
because our company existed already
for 15 years before that.

00:17:35:19 - 00:17:39:01
The previous one actually
was still valid till 2025, but

00:17:39:01 - 00:17:42:09
it was RSA 4096 crypto.

00:17:42:16 - 00:17:50:21
And we shifted to the elliptic curve one, what’s that,
ECDSA, I always forget what the acronym stands for.

00:17:51:01 - 00:17:55:06
So the reason we revoked, well, we
didn't revoke the one initially, but,

00:17:55:12 - 00:17:59:05
the reason we wanted to go for a new one
is to have the best encryption algorithm

00:17:59:05 - 00:18:00:05
commonly accepted.

00:18:00:05 - 00:18:02:13
So that's why we
did it, for a long time.

00:18:02:13 - 00:18:04:16
So that’s on one hand. We want to
have this as long as possible.

00:18:04:16 - 00:18:06:19
We never want to replace it again.
On the other hand.

00:18:06:19 - 00:18:10:06
We want to have really short
lived certificates, because if

00:18:11:09 - 00:18:12:14
one of our containers that

00:18:12:14 - 00:18:15:23
has a certificate gets compromised,
we don't want it to be a problem.

00:18:15:23 - 00:18:18:05
So if it only lives for a day...
That’s enough.

00:18:18:05 - 00:18:19:01
That's best.

00:18:19:01 - 00:18:20:06
And that's what we actually do.

00:18:20:06 - 00:18:22:15
That's where the Let’s Encrypt
comes in. We'll get to that in a bit.

00:18:22:15 - 00:18:26:10
So now I'm also curious; how long
is the intermediate valid?

00:18:27:00 - 00:18:29:16
That is, I didn't write...
I think it was five years.

00:18:29:16 - 00:18:32:08
For the, well, we have two
intermediates, actually.

00:18:32:08 - 00:18:33:10
Okay. Make sense.

00:18:33:10 - 00:18:37:11
One is for offline certificates,
and that's valid for five years.

00:18:38:01 - 00:18:41:23
Offline certificates means... Or maybe
it's two? Come to think of it.

00:18:42:08 - 00:18:45:07
Offline means that we sign those,

00:18:45:07 - 00:18:47:14
we use it to sign offline
in a similar way.

00:18:47:14 - 00:18:50:19
So with the same Raspberry Pi,
with the same read only file system

00:18:51:02 - 00:18:54:02
with a different key, because
there's two other key bearers

00:18:54:06 - 00:18:56:16
that have our intermediate
offline signing key.

00:18:56:16 - 00:18:57:15
Okay. Makes sense.

00:18:57:15 - 00:19:00:00
And that one we use to do stuff that,

00:19:00:00 - 00:19:03:00
actually requires a signing request
that you just mentioned.

00:19:03:00 - 00:19:06:18
So if there for example, a firewall
that doesn't supports more dynamic ways

00:19:06:18 - 00:19:12:01
like the ACME stuff, and that
from time to time needs to get here

00:19:12:01 - 00:19:15:11
because, every month or so we
figure out what certificates

00:19:15:11 - 00:19:19:21
are going to expire in the next two months
because we keep... that’s a pain.

00:19:19:21 - 00:19:24:15
You need to figure out - You don’t want
too much manually signed certificates.

00:19:24:15 - 00:19:29:07
No because you need, they expire, I mean,
didn't Office 365 go down once, because...

00:19:29:08 - 00:19:33:19
Yeah. Not that long ago and I think
everyone knows about sites

00:19:33:19 - 00:19:37:07
and even internally that, went down
or at least gave a certificate warning

00:19:37:07 - 00:19:39:20
because they forgot
to update the certificate.

00:19:39:20 - 00:19:42:09
If you suffer from the same problem
that you have to resign

00:19:42:09 - 00:19:46:02
certificates all the time manually,
you're probably on a good path, actually.

00:19:46:05 - 00:19:47:06
Sorry to tell you.

00:19:47:06 - 00:19:49:04
Well, there is a better one online.

00:19:49:04 - 00:19:51:01
But not every technology is online.

00:19:51:01 - 00:19:53:21
Maybe a nice anecdote here is that,

00:19:53:21 - 00:19:58:04
I have the bad habit of not closing down
my computer and certificates here

00:19:58:04 - 00:20:01:07
at ON2IT expire in one day,
so sometimes it’s cached

00:20:01:23 - 00:20:04:23
with my browser and then
it says, okay, but now

00:20:05:07 - 00:20:08:18
our internal server is not trusted
anymore, and I really need

00:20:08:18 - 00:20:12:04
to clear the cache or close the browser
and reopen it to get rid of that

00:20:12:17 - 00:20:15:07
message, because the certificates
are being being renewed.

00:20:15:07 - 00:20:16:03
Yeah. Yeah, indeed.

00:20:16:03 - 00:20:18:08
Well, and that's the other signing certificate

00:20:18:08 - 00:20:20:14
and that's what we call an
online signing certificate.

00:20:20:14 - 00:20:22:12
It's signed by the same route.

00:20:22:12 - 00:20:24:23
And that we have to renew every year.

00:20:26:04 - 00:20:30:14
So every year the root certificate, one of
the key bearers needs to come in.

00:20:30:14 - 00:20:32:01
Remember the password.

00:20:32:01 - 00:20:38:12
Go with one of the IT guys, go into a room,
we boot up this Pi and with the USB

00:20:38:13 - 00:20:42:11
we transfer the signing with a signing request.

00:20:43:09 - 00:20:50:19
And we put that on, we are going to sign
all the files of the website or whatever

00:20:50:19 - 00:20:54:12
it is, typically a little bit older
equipment that needs all that.

00:20:55:01 - 00:20:57:22
But we really, of course, hate that.

00:20:57:22 - 00:21:02:11
So the one thing we actually want to do
is every year, right now,

00:21:02:15 - 00:21:05:18
we re-sign our online signing certificate,

00:21:05:18 - 00:21:09:03
and that is, there is an ACME server,
it's in a separate protect surface.

00:21:09:03 - 00:21:12:02
So there's really little traffic
that can go back and forth from it,

00:21:12:02 - 00:21:14:13
because that is the only
signing certificate

00:21:14:13 - 00:21:18:18
we own in the company, that is
online and in memory of a machine.

00:21:18:18 - 00:21:23:06
So that is close to the keys
to the kingdom, I would say.

00:21:23:21 - 00:21:26:21
So we heavily guard that,
and once in a year we refresh it,

00:21:28:00 - 00:21:30:03
and that is the ACME protocol.

00:21:30:03 - 00:21:32:01
That's what Let's Encrypt is built off.

00:21:32:01 - 00:21:35:01
And every web server,
every container that needs a certificate,

00:21:35:21 - 00:21:40:01
talks to this server and identifies
themselves and then get’s

00:21:40:18 - 00:21:43:18
their signing request signed,
and therefore they have their,

00:21:45:05 - 00:21:48:21
yeah, their signing request, so they generate
their own key pair, the web server.

00:21:48:21 - 00:21:51:23
And then they generate a signing request,

00:21:51:23 - 00:21:54:10
get it to the ACME server,
and ACME should have a response to it.

00:21:54:10 - 00:21:59:13
Yeah, the ACME server will basically do a check
to check if you really own the domain

00:22:00:09 - 00:22:04:07
that you are requesting a certificate
for, it can do that in several ways,

00:22:04:11 - 00:22:08:17
I think HTTP01 it’s called,
is the most easiest one.

00:22:08:17 - 00:22:12:18
It will just run a file with an
authentication code on a specific address.

00:22:13:01 - 00:22:14:07
Just plain text.

00:22:14:07 - 00:22:17:16
But it's only to prove that
you own that domain.

00:22:17:16 - 00:22:17:22
Yeah.

00:22:17:22 - 00:22:21:03
So our web server talks to the ACME server, hey,
I want this certificate here’s my .... And then,

00:22:21:04 - 00:22:23:02
yeah, you can say that you are that server

00:22:23:02 - 00:22:26:02
prove it to me and it’ll connect
back to your [ ] ID

00:22:26:06 - 00:22:30:10
and because it's fully automated
so we can, do this like crazy.

00:22:30:10 - 00:22:32:18
Like indeed. Like you say, it's
every day. Every day resign.

00:22:32:18 - 00:22:34:17
So if any key that is signed by this online

00:22:34:17 - 00:22:38:21
certificate, online signing certificate is
being compromised a day later before we,

00:22:39:20 - 00:22:44:04
can ever replace any key or put it
or whatever, it's impossible.

00:22:44:05 - 00:22:47:06
[ ] This is a good process
because also, for example,

00:22:47:22 - 00:22:53:19
Google with Chrome, they have a consortium
that really is pushing for short lived certificates.

00:22:53:19 - 00:22:57:14
I believe they are now pushing for three months,
but I think they want to be shorter.

00:22:57:14 - 00:22:58:05
Yeah.

00:22:58:05 - 00:23:02:07
So what I would think we should do as an industry,
is make sure it's like an hour or so.

00:23:02:07 - 00:23:04:07
So every hour all certificates renew.

00:23:04:07 - 00:23:06:15
And ACME protocol actually can make that happen.

00:23:06:15 - 00:23:09:18
Because if you're halfway your expiry
then you are going to renew

00:23:09:18 - 00:23:11:22
so you can miss a few tries.
That's not a problem.

00:23:11:22 - 00:23:14:22
And then whenever a key is
compromised, no problem.

00:23:15:05 - 00:23:17:22
Because before the hacker is
able to do something

00:23:17:22 - 00:23:21:14
meaningful with it like phishing
users, it's not there anymore.

00:23:21:14 - 00:23:26:08
So it's already expired.
Yeah. It's expired. So that's all good.

00:23:26:08 - 00:23:27:13
So that’s the second thing you need to put.

00:23:27:13 - 00:23:31:13
So one thing, you need to put that
Pi in, with read only files, so

00:23:31:13 - 00:23:33:15
you just need a Linux nerd actually.

00:23:33:15 - 00:23:36:00
That understands OpenSSL
and can read.

00:23:36:00 - 00:23:39:19
Still, in the debate, I agree, this
is way more secure than

00:23:39:19 - 00:23:42:19
having a Windows machine
because there are a lot more

00:23:43:12 - 00:23:47:04
vulnerabilities in there, it’s more,
bigger, more components etc.

00:23:47:10 - 00:23:49:10
But still... [ ] OS, you need to [ ] OS.

00:23:49:10 - 00:23:52:10
But still you can more,
more or less do the same

00:23:53:21 - 00:23:56:00
by just putting those servers offline.

00:23:56:00 - 00:23:57:02
But to really do [ ].

00:23:57:02 - 00:24:02:20
Certainly. But like, Windows on a Pi....
No, it should ... We just need a console.

00:24:02:20 - 00:24:05:03
You can do it virtual or physical, of course,

00:24:05:03 - 00:24:08:07
having a physical like a Pi, completely
separated and hopefully

00:24:08:07 - 00:24:12:13
maybe even stored in a safe
or somewhere, that's way better.

00:24:12:18 - 00:24:17:13
But if you want to start and you’re
not feeling comfortable with

00:24:17:13 - 00:24:21:15
Linux, for example, then I think
Windows can function

00:24:21:15 - 00:24:25:22
as well, but make sure that you put it,
especially the root, offline,

00:24:25:22 - 00:24:28:07
but even the intermediate
if it is for manual signing.

00:24:28:07 - 00:24:33:23
Yeah. The intermediate has the
same protection mechanisms in place

00:24:33:23 - 00:24:37:20
as the root, we guard it as well,
with key bearers and all that. Why.

00:24:37:21 - 00:24:39:20
Because it's also valid for a longer time.

00:24:39:20 - 00:24:43:09
Maybe good to add here;
if you’re a larger company,

00:24:43:16 - 00:24:47:07
there is also special hardware
that we call hardware security modules

00:24:47:07 - 00:24:50:07
where you can store the private key
and then the hardware

00:24:50:07 - 00:24:53:07
security modules,
take care of all the security.

00:24:53:17 - 00:24:56:21
Still, to be fair, I'm a big fan
of keeping it offline.

00:24:57:12 - 00:25:00:15
Even though systems are hardened and
are there to protect your private keys.

00:25:00:20 - 00:25:05:03
They are still online, because systems need
to access that hardware security module.

00:25:05:06 - 00:25:05:20
Yeah, exactly.

00:25:05:20 - 00:25:08:22
So just, the smaller
the simpler, the better.

00:25:08:22 - 00:25:11:19
Really. And make two copies.

00:25:11:19 - 00:25:15:02
I mean, of course, there's two different key
bearers in different locations and all that.

00:25:15:22 - 00:25:19:12
And setting up ACME server,
by the way, isn't all that hard.

00:25:20:16 - 00:25:23:16
That’s just googling for ACME
or Let's Encrypt or... Let's maybe,

00:25:24:03 - 00:25:25:14
I saw, I was looking online,

00:25:25:14 - 00:25:32:03
if there's also an ACME server for the
Active Directory certificate services.

00:25:32:03 - 00:25:36:09
There's not official[ly], but there are some
third parties that can make it work for you.

00:25:36:09 - 00:25:39:17
So if you really want to go that way,
there are options to also do ACME

00:25:40:00 - 00:25:40:22
with the Windows server.

00:25:40:22 - 00:25:41:12
Yeah, yeah.

00:25:41:12 - 00:25:44:23
And I’d recommend, use ACME all the time.

00:25:45:07 - 00:25:45:18
So yeah.

00:25:45:18 - 00:25:49:17
And it's fairly simple, two projects
that you need to run, guard this

00:25:49:21 - 00:25:55:17
online signing certificate thing,
the ACME, in a separate VLAN,

00:25:55:17 - 00:25:57:07
make sure that nobody can access it.

00:25:57:07 - 00:26:01:12
It's just the protocol that's enabled and that's...
Yeah, and maybe good to add here,

00:26:02:13 - 00:26:05:20
and maybe we skipped that a bit,
you have the root certificate,

00:26:05:20 - 00:26:07:09
then you have an intermediate,
but you can also have

00:26:07:09 - 00:26:09:19
multiple intermediates
like you just saw, or told.

00:26:09:19 - 00:26:12:09
So you have an intermediate for

00:26:12:09 - 00:26:15:00
the manual signing and one for automatic.

00:26:15:00 - 00:26:17:11
What I would suggest
if you, going for decryption,

00:26:17:11 - 00:26:20:18
so that's why we ended up in
this topic, is create another intermediate

00:26:20:18 - 00:26:23:18
because that's going to your
firewall in this case.

00:26:25:00 - 00:26:27:20
And if something goes wrong with
your firewall management interface,

00:26:27:20 - 00:26:29:17
it gets compromised, or
there is a vulnerability,

00:26:29:17 - 00:26:32:17
or you don't trust it any more,
then you can easily only

00:26:33:12 - 00:26:36:11
pull that one back instead
of all the certificates.

00:26:36:11 - 00:26:38:06
Yeah, indeed.

00:26:38:06 - 00:26:38:12
Yeah.

00:26:38:12 - 00:26:41:16
So, what if you lose a key?

00:26:42:02 - 00:26:45:15
So if it is for a certificate,
there are two processes,

00:26:46:01 - 00:26:48:17
so certificate revocation list and,

00:26:48:17 - 00:26:52:18
the online certificate status protocol.
Those two processes, what will happen

00:26:52:18 - 00:26:56:05
is, if a certificate is being presented
to, let's say, your browser,

00:26:56:14 - 00:27:01:04
your browser can look up what's the CRL
or the OCSP belonging to the certificate.

00:27:01:04 - 00:27:04:06
With the CRL is more or less a static text

00:27:04:06 - 00:27:07:06
file, that's been downloaded
and it can look up, hey

00:27:07:07 - 00:27:08:22
is this certificate on this list?

00:27:08:22 - 00:27:13:02
If it is, then it’s revoked.
With OCSP, it's more of a dynamic

00:27:14:11 - 00:27:18:04
question to the server: hey,
is this certificate still valid?

00:27:18:04 - 00:27:19:04
Yeah.

00:27:19:04 - 00:27:21:18
Who likes this, besides you?

00:27:21:18 - 00:27:24:23
Well, I think it's for everything
where you don't manage the device.

00:27:24:23 - 00:27:26:16
Nobody.

00:27:26:16 - 00:27:30:18
I think there are no better
options if it is a public

00:27:30:18 - 00:27:32:15
infrastructure. That is true.
There's no other way, right?

00:27:32:15 - 00:27:35:10
The point here is, I mean,
suppose you are,

00:27:35:10 - 00:27:39:02
uou issue certificates, and every time
a certificate is used, you get a request

00:27:39:02 - 00:27:42:18
by that entity, whether or not
the certificate is still valid.

00:27:42:18 - 00:27:45:00
That's crazy, right?
Nobody likes it.

00:27:45:00 - 00:27:46:12
That's the whole point. And it’s slow.

00:27:46:12 - 00:27:48:16
It's also slow. Browsers don't like it,
because it's slow, right? Yeah.

00:27:48:16 - 00:27:51:03
But I know where you're heading.

00:27:51:03 - 00:27:54:06
And we talked a bit
about DigiNotar and

00:27:55:05 - 00:28:01:00
the update that was delayed for the Dutch people
because we could not retract it from the

00:28:01:17 - 00:28:03:02
the trusted root certificate authority.

00:28:03:02 - 00:28:06:02
If you do that for your
private public key

00:28:06:06 - 00:28:09:08
infrastructure, that's perfectly fine
if they are managed devices.

00:28:09:08 - 00:28:13:06
But if they are not managed, it's
still hard to [from] everywhere, pull back [ ]

00:28:14:02 - 00:28:18:15
If that ever happens to us, I'll invite you
if you think it's okay to do.

00:28:18:17 - 00:28:21:17
I would really-
Better is to not lose the key.

00:28:23:08 - 00:28:26:13
But if you do. Well, actually, you
know what we would do if,

00:28:26:13 - 00:28:28:19
so the root key, I mean,
then you broke your chain of trust.

00:28:28:19 - 00:28:30:10
You need to start over. Then it's over.
Yeah.

00:28:30:10 - 00:28:33:22
Like when there is, when you need
a stronger protocol, like we did

00:28:33:22 - 00:28:36:22
before when we went from version two
to version three, for example.

00:28:37:01 - 00:28:40:20
Or when you lose it in a DigiNotar scenario

00:28:40:20 - 00:28:43:23
and that just means that you have
to push it to all your endpoints.

00:28:44:13 - 00:28:48:19
If that intermediate would be broken,
it would be, what you can do

00:28:48:19 - 00:28:52:16
is issue that intermediate and push
that through the same mechanisms

00:28:53:10 - 00:28:54:15
as an invalid certificate.

00:28:55:17 - 00:28:58:01
And so that's not a dynamic
revocation thingy, but

00:28:58:01 - 00:29:01:19
you push it into the same
operating systems everywhere.

00:29:01:20 - 00:29:02:16
That's easier to do.

00:29:02:16 - 00:29:06:05
And it's also, if you covered 80%
in the first couple of days,

00:29:06:12 - 00:29:07:19
that's already so much better.

00:29:07:19 - 00:29:10:11
But still, that works only if you
manage the devices. Yeah. True.

00:29:10:11 - 00:29:14:20
That's the whole challenge-
[ ] PKI infrastructure, right?

00:29:14:20 - 00:29:18:22
Well, not necessarily because, it's not
different from Let's Encrypt, PKI,

00:29:19:14 - 00:29:22:01
or GoDaddy over [ ].

00:29:22:01 - 00:29:24:06
Yes. It's the complete same principle.
Yeah, okay.

00:29:24:06 - 00:29:26:14
But that’s if they if they lose their key.

00:29:26:14 - 00:29:27:05
Right.

00:29:27:05 - 00:29:27:07
Yeah.

00:29:27:07 - 00:29:30:18
But if they lose, so that’s-
It's an internal party that does that, right?

00:29:30:18 - 00:29:33:16
Yeah. But if they lose their intermediate
then of course they have a problem.

00:29:33:16 - 00:29:36:08
But still all those trusted certificate

00:29:36:08 - 00:29:39:15
authorities need to be updated
and pull back that trust certificate.

00:29:39:15 - 00:29:42:11
And this is something overlooked
for also with firewall vendors

00:29:42:11 - 00:29:45:20
for example, that can do a check
if the certificate is valid

00:29:45:20 - 00:29:49:15
because they can also check if the chain
is completely valid and trusted.

00:29:50:03 - 00:29:53:03
But if such an intermediate
is being leaked

00:29:53:13 - 00:29:57:03
and compromised, then you should also,
as an administrator of that firewall,

00:29:57:07 - 00:29:59:01
pull back that certificate from the firewall

00:29:59:01 - 00:30:02:03
and I think these are processes
that are often overlooked,

00:30:02:03 - 00:30:06:10
that belongs also to the package If you are
an administrator of a firewall, for example.

00:30:06:10 - 00:30:06:13
Yeah.

00:30:06:13 - 00:30:10:13
Is that something that firewall administrators
need to do or is that, you think,

00:30:10:13 - 00:30:12:23
the responsibility of the vendor to retract it?

00:30:12:23 - 00:30:16:14
I would say it's the administrator and
especially with this kind of hardware,

00:30:16:14 - 00:30:19:14
because if they retract it,
it will often be an update.

00:30:20:03 - 00:30:24:00
And especially with updating
such central equipment,

00:30:24:05 - 00:30:28:06
people are really careful with that
because, if the update goes wrong,

00:30:28:14 - 00:30:30:13
then it can bring down
the whole environment.

00:30:30:13 - 00:30:31:22
So I would not wait for the update.

00:30:31:22 - 00:30:34:03
I would do it myself first and then later-

00:30:34:03 - 00:30:37:02
You're saying vendors, firewall
vendors or any anyone who does

00:30:37:02 - 00:30:39:21
man in the middle encryption,
it's going to be a little bit

00:30:39:21 - 00:30:42:21
conservative about retracting keys
because it will break stuff.

00:30:43:15 - 00:30:49:01
No. So let's say, let's pick Let's Encrypt.

00:30:49:01 - 00:30:52:09
Let's Encrypt as an intermediate
is by default trusted in all the files.

00:30:53:04 - 00:30:55:18
That intermediate gets
somehow compromised.

00:30:55:18 - 00:30:56:08
Hopefully not.

00:30:56:08 - 00:30:59:17
But let's assume.
Then as a firewall administrator,

00:30:59:17 - 00:31:04:02
you should pull back that intermediate
from your firewall as being trusted,

00:31:04:15 - 00:31:07:17
because maybe you have a policy
that you can only visit sites

00:31:08:04 - 00:31:11:04
where the whole chain is being trusted.

00:31:11:15 - 00:31:14:06
And if I don't pull it back,
then all those sites

00:31:14:06 - 00:31:17:12
that were signed by that compromised
certificate are still seen as valid.

00:31:17:12 - 00:31:21:02
Yeah, but why doesn't the firewall vendor,
Fortinet, Palo Alto Networks, do that for you?

00:31:21:02 - 00:31:24:08
They will do, but it will take
them probably more time.

00:31:24:11 - 00:31:29:03
And then they bring out an update and
then I need to find a maintenance window.

00:31:29:03 - 00:31:29:16
Yeah. Okay.

00:31:29:16 - 00:31:32:00
... very careful by updating your firewall.

00:31:32:00 - 00:31:33:08
Yeah. Yeah.

00:31:33:08 - 00:31:36:13
I mean there are many companies-
It is more or less Windows DigiNotar all over again.

00:31:37:00 - 00:31:37:06
Yeah.

00:31:37:06 - 00:31:40:19
Many organizations are two or three major firmware
versions behind on their firewall, unfortunately.

00:31:40:19 - 00:31:41:13
Yeah.

00:31:41:13 - 00:31:44:15
And that [ ]
... all kinds of reasons.

00:31:44:15 - 00:31:45:07
Yeah.

00:31:45:07 - 00:31:46:10
Okay. Clear.

00:31:46:10 - 00:31:49:12
Any other challenges that may arise here?

00:31:52:09 - 00:31:52:14
Yeah.

00:31:52:14 - 00:31:58:22
I think, maybe it is a challenge;
we should make sure that

00:31:58:22 - 00:32:02:14
you always use valid
certificates everywhere you can,

00:32:02:22 - 00:32:06:17
because you don't want to train your users
to click on ‘Okay, I trust this’.

00:32:06:17 - 00:32:10:11
Yeah, I know when you have a PKI infrastructure,
it's much easier to do that.

00:32:10:11 - 00:32:11:18
Yeah. Definitely. Yeah.

00:32:11:18 - 00:32:15:00
So and I think that's really good,
because what I see in a lot of companies

00:32:15:00 - 00:32:19:17
is that we basically try training users
to simply ignore certificate warnings,

00:32:19:17 - 00:32:23:00
and they are there for a reason.
Browsers get more pesky

00:32:23:13 - 00:32:28:13
all the time. Yeah, browsers get updated more.
Yeah. You need to type in texts.

00:32:29:02 - 00:32:31:19
I won’t name them here,
to allow a browser to

00:32:31:19 - 00:32:34:14
actually proceed
to the certificate area.

00:32:34:14 - 00:32:34:21
Okay.

00:32:34:21 - 00:32:38:05
So to-do list, I want a PKI. First.

00:32:38:05 - 00:32:42:22
I buy myself a Pi, then select an
operating system and strip it down.

00:32:42:22 - 00:32:46:06
Make sure OpenSSL is on there, only.
Then you generate a key pair.

00:32:47:16 - 00:32:51:00
Make sure you designate some key bearers
and some procedures around it,

00:32:51:00 - 00:32:57:15
of course, with properly,
don't remove the passphrase.

00:32:58:00 - 00:32:58:19
And that's one thing.

00:32:58:19 - 00:33:01:08
Then you sign a couple of intermediates
to everything you like.

00:33:01:08 - 00:33:04:08
There's actually more, so indeed,
the firewall has an intermediate,

00:33:04:08 - 00:33:06:16
the offline certificate for
the rest of the stuff,

00:33:06:16 - 00:33:10:19
we have the client certificates probably,
that’s probably different. Yeah.

00:33:10:19 - 00:33:13:14
And those are also under
key bearer scrutiny.

00:33:13:14 - 00:33:17:08
And then you have your PKI set up,
more or less, and then you want the online

00:33:17:13 - 00:33:21:09
signing thingy as a second project
to be done, just use the ACME protocol,

00:33:21:09 - 00:33:24:10
it’s the industry standard, everybody
uses it, it’s open source.

00:33:24:10 - 00:33:26:18
The whole cost of this all is $30 so far.

00:33:26:18 - 00:33:29:17
The Raspberry Pi and some time
and a weekend of learning.

00:33:29:17 - 00:33:33:10
Yeah, you should do it,
just, OpenSSL is free.

00:33:33:10 - 00:33:36:08
You can just play around with it,
set up your own- And document it

00:33:36:08 - 00:33:39:08
so everybody, every system
administrator can easily,

00:33:39:12 - 00:33:41:18
you teach everybody
how to generate a key pair,

00:33:41:18 - 00:33:45:12
how to make it a signing request
and how to do the signing thing.

00:33:45:12 - 00:33:45:21
Yeah.

00:33:45:21 - 00:33:48:22
It should be really...
All right. Well.

00:33:50:04 - 00:33:51:07
We have things to do, or not.

00:33:51:07 - 00:33:54:07
And if that's true,
then I congratulate you.

00:33:54:14 - 00:33:55:11
All right.

00:33:55:11 - 00:33:56:22
Thank you very much, Rob.

00:33:56:22 - 00:33:57:16
Thank you.

00:33:57:16 - 00:34:01:09
Thank you for delivering on our promise.

00:34:01:09 - 00:34:03:14
And to you, if you like this video, please like it.

00:34:03:14 - 00:34:05:20
It will help us spread the word further.

00:34:05:20 - 00:34:06:18
We would appreciate it.

00:34:06:18 - 00:34:12:14
And if you click the subscribe button as well, then next week
there will be another episode like this, in your inbox.

00:34:12:14 - 00:34:15:14
And from the security headquarters
here at ON2IT,

00:34:15:18 - 00:34:18:14
I thank you very much. And, goodbye.

00:34:18:14 - 00:34:20:05
See you next time.

00:34:20:05 - 00:34:24:07
Thank you for listening to Threat Talks,
a podcast by ON2IT cybersecurity

00:34:24:12 - 00:34:26:16
and AMS-IX. Did you like what you heard?

00:34:26:16 - 00:34:31:12
Do you want to learn more? Follow Threat Talks
to stay up to date on the topic of cybersecurity.