Well, if we're going to spin up our SD-WAN environment, we are going to need
some signed
certificates.
These certificates are going to effectively help us to authenticate and
identify which
devices should be allowed on our SD-WAN and which devices shouldn't.
Because we have a major security risk with SD-WAN, we've got this awesome SD-W
AN environment,
forming IPsec tunnels, but this could very well be the internet.
And it wouldn't take much for a threat actor, if this was a very open
environment, to connect
their own router and then form tunnels and maybe even connections out to our SD
-WAN validator,
which would allow us to get plugged in to the SD-WAN.
We don't want this at all because this could cause major issues as we send real
-world
traffic to a threat actor's router.
And so we want to be able to identify that these devices are allowed because
they have
a certificate on them saying that they are allowed, whereas the threat actor
doesn't
actually have a certificate and therefore it gets rejected from the network.
This is the goal, and while very important for real-world applications in a lab
environment,
this can be very tricky.
I know that I can just spin up a number of routers and switches easily in Cisco
modeling
labs or a different platform, or for that matter, just real hardware.
I can just connect it and I can configure OSPF and Span Entry protocol.
That's really easy.
But spinning up an SD-WAN environment, I can't even get started until I get
these certificates
ironed out.
And so that's what we're going to do in this skill is make it as clear-cut as
possible
how we go about getting our certificates.
And fortunately, we are going to find that Cisco has made this a lot easier for
us than
it used to be.
Because we can actually leverage Cisco's plug-and-play cloud, or plug-and-play
connect.
This cloud service is going to allow us to very quickly sign certificates and
get them
deployed onto our controller devices.
Because even though here on the left we've talked about edge devices, we also
have to
make it so that our controller, our validator, and our manager that these three
devices can
form tunnels to one another.
In order to do that, they also need these certificates because we don't want a
thread
actor to fire up a maybe a controller and connect it in and start feeding
information
and from a control plane perspective.
We wouldn't want that just as much as we don't want them doing things nefar
iously at
the data plane.
And so that's our goal here again is to get our certificates fired up and
generated
and signed and installed.
It's quite a process.
But again, we're just going to walk through this and make it as straightforward
as possible.
So what we're going to want to accomplish here is we're going to start with the
concept
of a certificate authority.
We're going to use our Ubuntu machine that's part of the CML template that we
provided
in the last skill.
And if you didn't use the CML template, we just have to spin up a Linux box.
It's pretty straightforward in most platforms to be able to fire up this
virtual machine
and have access to the CLI.
And as long as it can perform open SSL commands, we're going to be able to
generate certificates.
So what we'll do here is we're going to generate what we call a root
certificate.
The root certificate is more or less our proof that we're part of this whole
architecture.
But we're not just going to distribute the root certificate and allow it to,
you know,
allow devices to prove that, hey, I've got the root certificate or whatever the
situation,
we actually want our certificate authority to weigh in on whether or not it's
allowed.
So let's diagram this out.
Let's say I've got my validator device here.
I'm going to be able to provide it with the root certificate.
But again, if the validator just had to show the root certificate, well, that
itself would
be a little bit of a security risk.
Because that means anybody with the root certificate would be able to prove
that they're authenticated,
even though maybe the thread actor actually, they got their hands on the root
certificate
and that would be bad news.
So we're not just going to suggest that people of the root certificate are
authenticated.
Instead, what we're going to do is we're going to use it to create our own
certificate.
We're going to generate our own certificate and we're going to create a
certificate signing
request or a CSR that will allow us to receive a signed certificate.
And this is what we really want.
Again, think about it this way.
For a thread actor to get a copy of the root certificate might not be that hard
, especially
for passing this root certificate around to a lot of different entities.
So for the thread actor to get the signed certificate, this is going to be much
, much
harder because now the thread actor has to convince this certificate authority,
the CA,
we have to convince it that we are somehow properly part of the network.
And because a lot of that is a manual process in a lot of situations, odds are
good that
even with a root certificate, the thread actor won't actually be able to do all
that much.
Now we're going to redirect this process just a little bit.
We are still going to start with our Ubuntu box as the CA, but we're actually
not really
going to call this a CA at this point because we're not placing it into the
center of the
architecture instead.
We're just going to use it to generate a root certificate.
And this root certificate, we're going to provide to two different entities.
We're going to provide it to our Cisco plug and play cloud.
And we're going to provide it to our manager device, because what we're going
to do is
we're going to leverage this relationship in order to get those signed
certificates,
because passing the certificates around the CSRs and maybe entering a bunch
more Linux
commands can get a little bit complex.
We can do this, and this is more the manual process that is going to not use
Cisco.
And we'll take a quick look at this later on in the scale just to make sure
that we know
how to do this if we decide that we can't or won't want to use Cisco for any
reason.
Again, Cisco is just trying to make this a little bit easier on us.
We don't have to use Cisco if we don't desire to do so.
So we're going to provide the root certificate to these two different entities.
So what this is going to allow us to do now is to leverage our IP connectivity
that we
have with the controller and the validator.
Remember, we as the admin here, we're logged into our SD when manager graphical
user interface.
So I'm on the web browser.
I'm poking around.
I can have it do different things.
And so one of the things I can do since it has the root certificate is it can
actually
generate the CSRs and automatically provide them to the Cisco cloud because the
Cisco
cloud has the root certificate.
And because it now has the CSRs, we've basically just performed this step where
we're passing
it not to a local certificate authority, but to the Cisco cloud as a
certificate authority.
Now, again, we need to get the sign certificate out of that.
So Cisco is going to generate those for us.
And it's going to say, hey, guess what?
Here are our actually, let's say we've got our signed certificates, but we're
going to
need to download these.
And so I as the admin, I go download these to my computer and I provide them
manually
to manager.
And then it's going to install one locally and it will push the signed
certificates to
the controller and validator.
And at that point, we're going to be good.
So we've explored two different processes here.
One kind of gives us an idea of how this works outside of the Cisco world.
But because of all the transferring around, it gets a little bit cumbersome.
So Cisco makes it much easier on the right.
I will say that maybe we'll get to a point where they push the signed
certificates down
automatically.
That would make it even more streamlined.
But it is what it is at this point.
Maybe we're only halfway there and Cisco will eventually give us that
functionality.
But either way, this is going to be our primary process.
If you are in a place where you can leverage the Cisco plug and play cloud,
which does
require by the way, a Cisco account.
So that might be one of the biggest hang ups if we don't have a Cisco account,
then we
might not be able to leverage Cisco PNP.
But if we are able to leverage it, then we're going to use the process on the
right.
Otherwise we can still use the process on the left.
It's just going to take a little bit more Linux commands and transferring
things around.
It gets a little bit, again, more cumbersome.
But either way, either one of these processes is going to get us to the end
result, which
is giving us these signed certificates that will allow us to build out the
tunnels among
our different control devices.