Could an SSL through LE/Certify the Web be used for an internal Active Directory LDAPS role?
For example - right now we have ourwebsite.ca working for renewals.
If we added behind.ourwebsite.ca as a SAN to that same certificate…
Then setup behind.ourwebsite.ca as an alias in the Apache server settings so that it’s pointing to the same root folder (like if you had bought another website name, but wanted both to load the same website)
Would this produce the ability to then use that SSL in Active Directory to enable LDAPS for internal network encryption?
I’m not sure I follow your configuration exactly but you can use Certify (and Let’s Encrypt) to get a certificate for any domain/subdomain you control [and that Let’s Encrypt can query for in DNS].
You can user either http validation (the default, where Let’s Encrypt checks your website) or you can use DNS validation (where Let’s Encrypt checks for a specific TXT record in your domain DNS). I’d suggest using DNS validation so you don’t need a public webserver pretending to be behind.ourwebsite.ca. DNS Validation (dns-01) | Certify The Web Docs
You can then use a script to apply that certificate to your service or simply apply it manually each time you renew (a script is ideal because it can be automatic with your renewal, in Certify you would add this as a Task). Deployment Tasks | Certify The Web Docs
You mentioned combining the LDAPS cert into the one for your website as a SAN but there is no need for that. You can just have a new managed certificate for that name.
Once you have a certificate something.yourdomain.com it can be used for virtually any service that would referred to using that fully qualified name, you just need to figure out how to apply that cert to whichever service it is (there are thousands of possible services which can use a domain validated cert, not just webservers etc).
1: Obvious but of course the domain must be a valid external doming. So for example since my domain is domain.corp (used to be considered best practice) I can’t do this. Though I keep on dreaming of changing my domain… Yeah easier said than done.
2: Obviously older clients will have trouble connecting to the domain until they get a new list of valid SSL certificates! I can’t find when it was added but it was after XP SP3, that just added the ability to auto update but it might be necessary to first connect to the domain.
3: This might be the hardest part the recommendation is to put it into the personal store for the AD (NTDS) service. I’m not sure how to do that with powershell though I’m sure it can be done.
Clients would need to have ISRG Root X1 in their trust store yes, if they don’t have that then either their firewall blocks the update or the sysadmin switched off automatic CA updates years ago and forgot about it - this is quite common because years ago their was a size limit which some systems hit and so it was popular at the time to just switch off automatic CA certificate updates in group policy.
An alternative approach is to run your own CA using AD CS, then deploy the root to all of your clients trust stores. I believe this is the typical way to do this internally and also your domain doesn’t have to be a public name.