Active Directory, SSL certificate requests for domain-joined systems

If you are requesting an SSL certificate through the Technology Services SSL Request Portal, and are using this certificate for traditional host encryption practices (i.e., HTTPS for a web server running Microsoft's Internet Information Server) on a system that is joined to the UOFI Active Directory domain, this document details the best practices.

A common practice on the Urbana campus is for domain-joined hosts to have two DNS A records :

1. A public record in the appropriate DNS zone for that department's IP space (which also contains the PTR record for the IP address) - e.g. server01.dept.illinois.edu
2. A private record dynamically registered inside the AD DNS zone, which is created upon domain join - e.g. dept-server01.ad.uillinois.edu

Since the ad.uillinois.edu zone is not resolvable from off-campus, it is discouraged to use such DNS references in SSL requests. Doing so risks failure of the client to resolve the host from off campus. To obtain publicly-trusted SSL certificates for internal resources, IT professionals must use globally unique public domain names.

The best practice is to use the registered host's public DNS name when requesting the certificate.

For general information on how to request SSL certificates, you can read this KB: SSL Certificates, Certificate Service

Frequently Asked Questions for IT Professionals

• Why can't I use the internal *.ad.uillinois.edu domain for SSL?
  Public CAs cannot verify ownership of a name that anyone can use internally, so they are adopting a practice of prohibiting the issuance of certificates for them.
  The ad.uillinois.edu DNS zone is intended for internal Active Directory use and is not resolvable from off-campus networks. Using an AD hostname in an SSL certificate can cause name resolution and accessibility issues for clients outside the campus network. Use the host's globally unique public DNS name when requesting a publicly trusted certificate. 
  
• Can I just use an internal Private CA instead?
  While technically possible, this is not currently supported. While we do operate AD Certificate Services for some internal certificate signing, we do not have the infrastructure or procedures in place to issue internally-signed certificates for campus IT Pros. Even if we allowed this, the process would require significant management overhead (MECM configs and GPO policies) and furthermore, the SSL certificates would still show "Not Trusted" on non-managed devices like guest laptops or mobile phones that are not university-managed equipment.