I ran this command: certreq -new request.inf domain.csr
It produced this output: domain.csr
My web server is (include version): No web server available (domain controller)
The operating system my web server runs on is (include version): Windows Server 2019
My hosting provider, if applicable, is: My own servers
I can login to a root shell on my machine (yes or no, or I don't know): yes its Windows
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): NA
I run Let's Encrypt on my web server and would like to create a certificate on my domain controllers to enable LDAP SSL. I cannot seem to come up with the correct setup to make Let's Encrypt happy. Part of the problem is that my domain is a subdomain of a major university and they control my DNS.
Has anyone done something like this? The ability to manage all entities of my domain from one Let's Encrypt installation would be nice.
Have you looked into using any native Windows ACME clients?
If the LDAP program can obtain certs from the Windows Cert Store, it should be able to do so.
Thank you rg305 for your reply. I am not well versed in the certificate world and it likely shows here. I had hoped to be able to manage all my certificates from one Let's Encrypt interface installed on my IIS server. Let's Encrypt will use the domain controller's CSR and but DNS issues make this process fail. I do not have access to the DNS that is authoritative to my domain to create the TXT record. Only the DNS on my domain controller which Let's Encrypt does not have access to because of firewall rules. I am not sure I want to open my DNS server for the world to see.
I do have access to a certificate authority on campus that will issue me a free certificate for me to use on my domain controller. It is probably easier to do that then continue down this road.
That's your best option, for another reason... Certificates for aqua.wisc.edu would compete for LetsEncrypt rate limits against all other wisc.edu subdomains, unless wisc.edu were on the Public Suffix List -- which it is not.
If that were not a concern, however, you have two options:
You could have all subdomains under your control redirect the /.well_known/acme-challenge directory on port 80 to a centralized server. That would allow multiple machines to be managed by a single server
You could have the University delegate the _acme_challenge records for your subdomain(s) to a DNS server you control. This is the model used by acme-dns (GitHub - joohoi/acme-dns: Limited DNS server with RESTful HTTP API to handle ACME DNS challenges easily and securely.), and is the recommended implementation for virtually all DNS based challenges, as it creates a framework where the API records and credentials for DNS are fully isolated away from the main DNS records/credentials (i.e. compromised credentials can not affect regular dns).
