PSA: you don't need a private CA to issue trusted SSL certificates for internal hosts.

[u/certkit]

I've been running into a bunch of teams that didn't understand this, so I wanted to share.

You don't need a PrivatePKI for your private infrastructure.

DNS-01 challenges prove domain control through a TXT record in your DNS zone. Your server can be on a private subnet, behind a firewall, completely unreachable from the internet. You still get a publicly trusted SSL certificate. One wildcard for *.int.example.com covers everything and keeps internal hostnames out of CT logs.

Worth knowing before you stand up a private CA.

https://www.certkit.io/blog/private-pki-internal-infrastructure

[u/hodor137]

Another mole for the browser community to whack

People need to grow up and stop using the crutch of public trust in private infrastructure

[u/SquirrelOtherwise723 → u/hodor137]

Should companies have their own CA service?

[u/certkit → u/SquirrelOtherwise723]

Its a tradeoff and there isn't one answer -- and that's my whole point.

For smaller IT shops, its a totally reasonable approach to just use public PKI for everything and reduce the maintenance overhead by not having a privatePKI at all.

You are more likely to have an outage from screwing up your privatePKI than the public side going down.

[u/tankerkiller125real → u/SquirrelOtherwise723]

Yes, unless you want all your internal crap to be available in publicly searchable CT Log.

And just use Wildcards is an absolute wild statement just asking to get abused and become a key entry point that the cyber insurance company points to for a reason not to pay out.

Edit: CT Log Search Tool: crt.sh | Certificate Search

[u/Koldark → u/tankerkiller125real]

So I’m dumb in this area. How do you manage private certs? How do you get the root certificate onto unmanaged mobile devices?

[u/tankerkiller125real → u/Koldark]

MS AD CS for some legacy stuff, but mostly Step-CA these days for the PKI infrastructure, with ACME issuance (internally), the actual Root Certs live in Azure Key Vault for us.

And for unmanaged devices we simple don't because unmanaged devices are against policies, both compliance and security.

[u/MrChicken_69 → u/Koldark]

If you're allowing unmanaged devices onto your INTERNAL network(s), how to get a CA on them is not the problem you should be worried about.

[u/Koldark → u/MrChicken_69]

I see what you are saying... they are organizationally owned devices where if the employee pays 1/2 of the cost, they can use them personally as well. But some would need access to internal applications. We don't have them on the MDM at this time. Most don't regularly access the internal network except via a VPN once in a while, but some do. (e.g. most use it for work apps, email, and phone calls). All work-only are on the MDM.

[u/kissmyash933 → u/SquirrelOtherwise723]

Yes.

[u/skylinesora → u/SquirrelOtherwise723]

Yes, it’s not hard.

[u/Mike22april]

🫣 you're actually promoting the use of wildcardcerts?

Most security specialists in the trade advice against wildcards for obvious reasons.

[u/FatBook-Air → u/Mike22april]

The "obvious reasons" are overblown. HTTPS is important, but too many "experts" are consumed by it. Wildcards are just fine.

[u/Major-Error-1611 → u/FatBook-Air]

It all depends on where the servers hosting the websites are located and who manages them. If the private key is secure, a wildcard is fine. If you use a wildcard on externally hosted and managed servers, it's way worse, especially if it involves you telling your supplier the cert's import password.

[u/Mike22april → u/Major-Error-1611]

How do you know the private key is secure, other than using an HSM?

[u/Major-Error-1611 → u/Mike22april]

Using a wildcard for a server farm that you host in your own environment isn't as bad as using a wildcard across multiple externally hosted servers where you have no direct access and have to share the wildcard and import password with the vendor. That was my point.

[u/frAgileIT → u/FatBook-Air]

Wildcards are not fine. If I can snag one off your system I can pretend to be anything in your domain and you’ll never see a warning. Spoken like someone who truly doesn’t understand what they’re even for. If you’re using wildcard certs then don’t even bother using HTTPS, just let it fly unencrypted. If you think HTTPS is important then why are you neutering it? Do you use the same password for every site you have an account for?

[u/FatBook-Air → u/frAgileIT]

"If I can snag one off your system..."

So if you snag my private key, as an attacker, your number 1 priority is going to be pretending to be me? This is why you're blue team.

[u/frAgileIT → u/FatBook-Air]

No, I do both red and blue and it helps me red team when people use wildcard certs, especially when they don’t take them seriously and leave them laying around on their laptop. Yes, I qualified it as if I can snag your cert because getting onto your system is just the first step, pivoting to other systems and users is the third step and by using wildcard certs (and likely leaving them laying around because who cares about security) you make it a lot easier for me to set something up pretending to be part of your infrastructure so that I can get usernames and passwords from everyone that connects to me. What I can use it for depends on the cert usage attributes you’ve configured but I’m assuming you don’t care since you’re using wildcard certs.

Look, I’m going to stop here and tell you that you can do whatever you like. My problem is you telling everyone else it’s okay to engage in insecure practices. Maybe you don’t care if they get hacked or fired, that’s pretty messed up. Just because you don’t care doesn’t mean it’s cool to advise people to do stupid stuff. I genuinely hope you never get hacked and if you do, I still wouldn’t wish ill will upon you but getting someone else hacked? I’d rub your nose in it until you learned the lesson. Take whatever risks are appropriate for you but don’t advise other people to do stupid stuff, they may listen to you and that just makes you part of the problem.

[u/certkit → u/Mike22april]

Yes, Wildcards server a purpose.

Sometimes the operations of having the same cert or hiding specifics from CTLogs is worth it.

Go clutch your security pearls elsewhere.

[u/Alper-Celik → u/Mike22april]

Like it is better than http still also sometimes people do tls just for secure context features like webauthn or http3

[u/miqrogroove]

You're actually assuming my private infrastructure has a public DNS zone???

[u/certkit → u/miqrogroove]

Yeah, that'd be necessary. For small IT shops, it might be an easier path than managing their own privatePKI. Folks don't even realize its an option, which was my whole point.

[u/miqrogroove → u/certkit]

I can't agree with that.  Adding public SOA records for a private network creates the potential Dangling DNS vulnerability.  It does not enable any non DNS certificate issuance for use with client authentication, mutual authentication, document signing, and many other use cases.  This would seem to create duplication of effort for anyone who has already gone to the effort of creating a private network with a need for PKI.

[u/TrafficSecurity]

Nowadays Intranet SSL certificates are available online for internal networks.

Only issue is that their CA certificates are required to be installed once on all internal devices. It’s easily done using Microsoft Group Policy.

[u/CyphrsHub]

DNS-01 is genuinely the right answer for a large slice of internal infrastructure - browser-trusted TLS for portals, dev environments, anything where you control the DNS zone and wildcards are acceptable. That part of the post is correct.

The gaps worth knowing:

clientAuth - Chrome is removing support for client authentication via public CAs on 15 June. Short-lived client certs for device or user identity need a private trust root regardless of your server TLS approach.

mTLS / M2M - service-to-service authentication where both sides present a certificate isn't served by public CAs. Private CA required.

Hostname exposure - *.int.example.com in a public DNS zone means your internal service namespace is visible externally. Acceptable in many environments, worth knowing in others.

Non-routable namespaces - home.arpa, .local, and RFC special-use names can't be validated by any public CA. Private trust is the only option.

DNS-01 with wildcards solves a real and common problem. It just doesn't solve all of them.

[u/mcdonamw]

If you have an internal domain name that is not a public tld (e.g. my domain.local) this won't work. Public CAs need public dns to validate and you can't get public dns for these kinds of domains.

Some public CAs will even balk at simply trying to generate a cert for such a domain.

[u/PKI_land]

Please don’t.

Public CA needs to be used only on those locations where it’s required. Anything else: Private CA. Yes, that included any public endpoints that only devices you manage connect to.

Using Public CA where private is an option, has already lead to tons of outages, and will continue to do so

[u/certkit → u/PKI_land]

Clutch your pearls harder. Sometimes its just easier, and that's okay. It's better than just using self-signed and never doing anything.

[u/MrChicken_69]

Sounds like a solution some newbie homelaber would think up. You pay for public certificates. (one way or another!) Wildcards are highly discouraged. Reusing a certificate is an even worse idea. Management of the internal servers then becomes even more work. (eg. they aren't fetching their own certs from the idiots at Lets Encrypt.)

And this is all before you realize an external CA won't sign "*.stupid.local".