Using LetsEncrypt in my Lab

Help
#1

Hi Guys, my first post so if I have posted in the wrong place, please advise.
My webserver is using LetsEncrypt, and works perfectly. However, setting that up was relatively simple: I have a LetsEncrypt cert on the server, clients get it and refer to LetsEncrypt for validation.

Now I want to go to the next stage: I’m building a security Lab, within which I run a Microsoft CA (Win2K12R2). I want to have that CA act as an intermediary to LetsEncrypt, so when random client devices log into the network, they see a certificate which is chained to LetsEncrypt and so don’t show cetificate warnings, as they do when I just use the “private” certificates from my existing CA.

Are there any guidance documents you can recommend? I could just blunder ahead and do what feels right and works, but this is security and I’d rather start off conforming to best practices rather than making it up s I go along :slight_smile:

Thanks for any advice!

Jim

#2

Hi @Jimbo1

that’s not possible.

Letsencrypt certificates are “end certificates”, not intermediate certificates.

So you can’t create such a system with Letsencrypt.

2 Likes
#3

Hi Juergen,
Thanks for the response. Do you know if there are any free public CAs that I could use, that deliver the kind of certificate I need? Or will I have to go to a paid certficate if I want to run a full enterprise network emulation?
Thanks
Jim

#4

@Jimbo1

You could consider using a Let’sEncrypt Wildcard Certificate on your public facing webserver and distribute it to the rest of the devices on your network via your own automated scripts.

Many members of this forum have opted to use this method and it works reliably once configures and tested…

Hope this helps
Rip

#5

Typically when you run your own CA in an enterprise network, you are running the entire chain all the way up to the root CA. You don’t have any connection to a public CA and the certs are only trusted by clients who trust your root. But because you likely control/manage the clients, this isn’t a problem. You can use existing client management solutions to provision your root CA on the devices you control.

2 Likes
#6

Hi Ryan,

Its a fair point you raise. The circumstances I have in mind specifically relate to handling wireless guests. Because my (internal) CA is the root CA for the network, all the devices that are “not guest”, i.e. are running EAP-TLS security, are provided with the correct certification through active directory and GPO. That works fine. However, when I attach a client as a guest, that doesn’t know about my internal CA, I get certificate errors (not unexpectedly). However, if I was to have an “authoritative” certificate derived from a chain from an external CA, through my internal CA on my Wireless Controller, the guest client would “know” of the external CA, and I wouldn’t have cert errors. (I think…please feel free to correct me if I’m wrong - it’s not unknown! :slight_smile:

It’s not critical, it’s just a matter of tidying the operation so it looks like the real thing in the lab.

Thanks

Jim

#7

Hi Rip,

Sounds like it may be a way forward I could try…Thanks

Jim

1 Like
#8

I’m not terribly familiar with the intricacies of TLS in relation to wireless access, but couldn’t you just provision a normal public end certificate on your wireless controller rather than one from your own CA?

#9

At a push, I could do that, (I think, though I’ve never tried it) but I’m trying to stay accurate to the environement in an Enterprise environment.

#10

Bottom line, enterprise environments don’t have their internal PKI chained from a public root. So you have the same choice to make. You either find a way to get all necessary clients to pre-trust your root CA or you put a publicly trusted cert on the services that are being used by “guests” or other unmanaged clients.

#11

Well, technically you could purchase an intermediate chained to a public root if you really wanted. But with the webtrust auditing and HSM requirements you’d probably end up spending several hundred thousand dollars.

#12

That behavior is intentional in the design of the web PKI, though: if clients who are guests automatically trusted your CA root, you would be able to spy on their connections to Gmail or something. The web PKI is designed to make sure that network operators don’t have that power! If you, as the network access provider, intercept their connections to any outside site, the browser is supposed to warn the user about the interception and stop the connection.

This is related to @Rip’s suggestion above: if the services that you want to authenticate are all your internal services, run under your own domain, you could use a wildcard certificate from Let’s Encrypt, applying only to your own domain name. While that wouldn’t let you create additional subsidiary certificates, guests would (appropriately) accept the wildcard certificate when connecting to your internal services by following or typing in addresses that are explicitly using your domain name.

#13

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.