Now that we have our trusted certificates published to our clients,
our endpoints, our issuing CAs, our root CAs, and so forth, we're
ready to deploy end‑entity certificates. And there's two options for
doing this that are available to Intune administrators, and that is
PKCS and SCEP. Now.
PKCS stands for Public Key Cryptography Standards, and PKCS has some
real advantages for us in the case of deploying certificates with
Intune because it's really easy to configure. There's no roles or
features required to be installed.
You just have to have a domain‑joined member server for
which to install the Intune connector on.
And this is a huge advantage is that there's no inbound access required,
so you don't have to publish this to the internet.
The connector itself just simply talks outbound to Intune, and it pulls
periodically, so anytime there is a certificate request that needs to be
performed, then that basically is placed into a work queue in Intune,
the connector then pulls Intune, grabs that information,
generates a key pair, has the public key signed by your internal CA.
It will then encrypt that public and private key pair, send it back to
Intune. Intune decrypts it and encrypts it again and sends it to the
endpoint, and the endpoint imports the certificate there.
So, the advantages again,
really super simple to configure, and it just works quite
reliably and importantly does not require inbound access. Now
SCEP, on the other hand, is much, much more complex. By the way,
SCEP stands for Simple Certificate Enrollment Protocol.
This is a legacy protocol that's been around for quite some
time, and it's really kind of showing its age.
It is very complex.
It does require that you install the NDES role, which also includes IIS.
Now NDES stands for Network Device Enrollment Service.
It is Microsoft's implementation of the SCEP standard.
So SCEP is an open standard.
NDES Microsoft's implementation of it.
Here's the real challenge is that when you deploy this, it does
require inbound access, so you have to expose this server to the
public internet, and you can't add any sort of preauthentication or
any sort of authentication checks.
So here's the real problem with this is that the server, the SCEP
NDES server, is a highly privileged machine in your environment.
Using the Microsoft enterprise access model,
it is considered a control plane access, so on par with a domain controller.
In the old tiered model, it was a Tier 0 asset.
So fundamentally, this server is one that should be very,
very highly protected and should have very limited access.
And here's the real challenge is that we now have this control
plane asset, or Tier 0 asset, for which we've installed IIS and
exposed it directly to the internet.
That is a really, really bad idea.
You would never install IIS on a domain controller and push it to the
internet. You shouldn't do so for the NDES SCEP server either.
So for me and for my customers,
that's always a real showstopper because it violates some
of our most basic security practices.
And with that, we recommend that you, as an
administrator, use PKCS whenever possible.
Now, I'm not here to tell you that you can never use NDES SCEP.
If you do that, obviously you're going to accept the risk associated with that.
There may very well be some corner cases where NDES and SCEP are required.
I'm not aware of what those are.
Certainly in the context of Always On VPN,
PKCS works, and we can deploy our device certificates and our user
certificates, and it works flawlessly, so I recommend using PKCS, and that's what we're going to cover in this course.