What is the best way to generate a certificate for my domain controller? I have a need to enable LDAPS for a few services. From what I am gathering I will need to utilize the "DNS Challenge" and I may have to use a wildcard. If this is true, will impose a security risk? My local domain is "Ad.example.com", public domain is "example.com", and the FQDN of my DC is "DC1.Ad.example.com". I will mention that I also need a certificate for my Pfsense firewall. I've read somewhere online that mentioned I could use the Pfsense to handle the Let's Encrypt certificates. If I address two needs with one that would be excellent but I'm not sure if it works that way. I'm not well versed with SSL certificates, so anything helps. Excited to start getting certificates on my machines. Thanks!
Here's a blog post I wrote about getting the DC cert. You won't need (and shouldn't get) a wildcard for it.
pfSense has an acme package that can handle getting a cert for your router. I've never used it, but it should also not require a wildcard cert provided there's a public DNS name pointing to your routers WAN IP.
https://docs.netgate.com/pfsense/en/latest/packages/acme/index.html
Trying to handle the DC cert using pfSense will likely be more trouble than its worth. Just let the router do its own thing and handle the DC cert (or certs) separately.
We currently don't have a DNS provider that offers API support but that could change soon, especially if this works well. So, I will use the manual approach for now. I understand that the manual plugin option will require me to manually issue and renew the cert every 60-90 days. I'm assuming this can easily be updated once I migrate to a DNS provider who easily integrates with Let's Encrypt DNS validation.
I appreciate the response and hope you don't mind the questions. I bet most of these will make more sense once I actually start using it.
Since I'm going initially start out with manual, what's the best way to manually renew once deployed?
Besides the fact that other people can now lookup the FQDN of my machine is there any other security implications with DNS validation and the TXT record? Should and can the DNS TXT record be deleted once verified?
Specifically, is expanding the "$dc.HostName variable (DC1.Ad.Example.com) portion of the splat. Is this what allows us to use subdomains and NOT have to use a wildcard?
If I have multiple DC's will I have to perform this on every domain controller with new set of DNS TXT challenge questions each time?
Does this technically need to be installed and ran on my domain controller, putting aside the install parameter which installs the cert to the local computers certificate store? If I'm understanding this correctly It sounds like I can use a computer just for generating certificates. Not sure if that's good practice or not.
Thanks!
Correct on both.
If you end up using Posh-ACME specifically. Just re-running the New-PACertificate command will work for manual renewals. But there are other clients you could also use that would have a different process.
I don't believe there are any other security ramifications other than the knowledge of your DC's internal FQDN. For clarity, that FQDN does not need to exist in the public copy of the DNS zone. Only the validation TXT record does. And that TXT record can and should be deleted immediately following a successful validation.
Correct. Though it's also a requirement for AD itself to recognize and pick up the cert once installed. In my experience, the engine won't recognize and pick up a cert unless the actual FQDN is in the SAN field. So a wildcard specifically won't work with AD's LDAPS engine.
Yes. The TXT record values will be different at every renewal and each unique SAN in each unique cert will require a separate validation record. You can see why automation becomes important here. There are also ways to delegate where the records are read from to a DNS service that does provide an API endpoint if your primary DNS does not.
No, the actual process obtaining the cert can technically be run from anywhere when using DNS validation. Only the resulting cert/key (or pfx combo) would need to be copied to and installed on the DC. So yes, you could designate a central machine to coordinate obtaining the certs and then push them out to where they need to go. Though, this comes with its own set of security implications and automation challenges.
@dylan.b All Let's Encyrypt certificates are in public Certificate Transparency logs which can be searched by anyone. I think that is true of all public CA's but not sure if some exceptions. See https://crt.sh as just one tool for searching the CT logs.
Just thought I'd mention it as you said you were new to certs. It is not practical to completely hide your FQDNs with these public certs.
@rmbolger Thanks a bunch for responding to all my questions, really helped. I used your module and was able to generate a Let's Encrypt certificate for my domain controller and deleted the validation TXT records immediately afterwards.
Going to try and use your same Posh-ACME module to generate a cert for one of my IIS servers next!
@MikeMcQ Thats good to know. Thanks for sharing the site, I can see other FQDNs from my domain populate here as is.
Glad everything is working for you!
Just wanted to add that this is not super time sensitive. It's just that you don't want to leave old records around cluttering things up. So any time before the next renewal would be sufficient.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.