I have just found out today that internal domain names are no longer supported on public certificates. Please view the following article by DigiCert.
http://www.digicert.com/internal-names.htm
For Exchange this is going to increase the requirement for split DNS within organisations to ensure customers can use the same address for both the Internal and External URLs. However there are examples which I can see as being a problem moving forward.
When setting up a Remote Desktop Gateway server (for RDP over HTTPS) you need two public certificates, or one certificate with multiple subject alternative names. One public certificate will terminate the SSL endpoint of the RD Gateway server such as "rdpgateway.example.com" and is enabled within Internet Information Services. The second certificate requires the internal name of the Remote Desktop Session Hosts or Terminal Servers to ensure the RDP traffic is digitally signed such as "terminalserver01.domain.local". This server certificate needs to be installed on the terminal server(s) themselves with the name matching the internal FQDN of the server(s). Most companies do not install digital certificates to sign RDP traffic, instead they leave the default self-signed certificate on the servers (which does not show up in the local MMC certificates store). This is why you always see the following warning when initiating remote desktop to a server:
Now we could use an internal certificate authority to issue the certificates for our RD Session Hosts, however this would require that all computers who access the RD Farm to be on the Active Directory domain to ensure they trust the internal certificate authority. What about if there are users who are connecting in from machines that are not a member of the Active Directory domain? One of my clients develops an application and sells the application by presenting it to clients as a RemoteApp meaning computers all over the world are launching this application. Without having a public certificate containing internal names, my customers would receive warnings relating to the RDP traffic being untrusted.
I spoke to a representative from DigiCert about this today, and I ran this example past him. The advise he presented to me was to rename the Active Directory forest to "local.example.com" to ensure the domain ended with a dot com. I do not see this as practical especially for large Active Directory domains which consist of thousands of users.
I wonder what other headaches these changes to the certificate standard will present for IT professionals around the world.
Please feel free to leave your comments on the matter.
http://www.digicert.com/internal-names.htm
For Exchange this is going to increase the requirement for split DNS within organisations to ensure customers can use the same address for both the Internal and External URLs. However there are examples which I can see as being a problem moving forward.
When setting up a Remote Desktop Gateway server (for RDP over HTTPS) you need two public certificates, or one certificate with multiple subject alternative names. One public certificate will terminate the SSL endpoint of the RD Gateway server such as "rdpgateway.example.com" and is enabled within Internet Information Services. The second certificate requires the internal name of the Remote Desktop Session Hosts or Terminal Servers to ensure the RDP traffic is digitally signed such as "terminalserver01.domain.local". This server certificate needs to be installed on the terminal server(s) themselves with the name matching the internal FQDN of the server(s). Most companies do not install digital certificates to sign RDP traffic, instead they leave the default self-signed certificate on the servers (which does not show up in the local MMC certificates store). This is why you always see the following warning when initiating remote desktop to a server:
Now we could use an internal certificate authority to issue the certificates for our RD Session Hosts, however this would require that all computers who access the RD Farm to be on the Active Directory domain to ensure they trust the internal certificate authority. What about if there are users who are connecting in from machines that are not a member of the Active Directory domain? One of my clients develops an application and sells the application by presenting it to clients as a RemoteApp meaning computers all over the world are launching this application. Without having a public certificate containing internal names, my customers would receive warnings relating to the RDP traffic being untrusted.
I spoke to a representative from DigiCert about this today, and I ran this example past him. The advise he presented to me was to rename the Active Directory forest to "local.example.com" to ensure the domain ended with a dot com. I do not see this as practical especially for large Active Directory domains which consist of thousands of users.
I wonder what other headaches these changes to the certificate standard will present for IT professionals around the world.
Please feel free to leave your comments on the matter.
Hi Clint,
ReplyDeleteWord on the street is:
"It is best to use DNS names that are registered with an Internet authority in the Active Directory namespace. Only registered names are guaranteed to be globally unique. If another organization later registers the same DNS domain name, or if your organization merges with, acquires, or is acquired by other company that uses the same DNS names, then the two infrastructures cannot interact with one another.
Note
Using single label names or unregistered suffixes, such as .local, is not recommended"
I only found out the hard way as well :-) But a better standard is a better standard. As for the renaming part being impractical I think it's mostly challenging saleswise, but it will set you apart in a positive way if you preach the right way and make it clear to the customer what's best nowadays.
Thankyou for your input. This is a huge change as for years many customers have always been using private namespaces internally.
ReplyDeleteDigicert has just posted a writeup for this:
ReplyDeletehttp://www.digicert.com/ssl-support/reconfigure-internal-dns-names-iis-7.htm
I see zero issue with local.example.com or ad.example.com or whatever other subdomain one finds desirable—and have been recommending this to clients since Windows 2000 was released—and this is far better than example.local.
ReplyDeleteGreat read ! Nowadays everything has to be ranked as "Vision is the art of seeing what is invisible to others." – Johnathan Swift. Isn't it ?!
ReplyDelete