Domain name doesn't matter, unless you're signing with a public CA. I'd think self-signed vs internal CA vs public CA would depend on what the authentication mechanism supports and how you have to manage the certificates. (i.e. if there are going to be a ton of them it might be easier for the authentication mechanism just to trust certificates signed by a certain internal CA rather than having to make each certificate trusted.
From what I've seen so far, I've come to the same conclusion.
Near-zero value in someone attacking is what I meant. Not a zero-value in what is provided by the systems. Also there is nothing confidential or needing "security" from a business perspective, which is why I ask is SSL worth it for these types of Intranet sites?
You need SSL for everything period. Even if it's a self-signed cert it's fine... just allow the exception in the web browser and be done, or use an internal certificate if your browsers are set to trust the root... or a domain wildcard cert would work just fine. It's easy to do.
You could set out a reverse proxy for use with Let's Encrypt, and use the reverse proxy for all of your internal-only web servers. On the reverse proxy, you can limit each site config to only pass internal IPs only. That's what I did for a few. For example, if you add this in:
@scottalanmiller my problem with Certs on Windows, in general, is that you almost always have to copy it around to multiple servers to make everything work well, and that jsut defeats the purpose of LE.
Based on what is on the site, Microsoft has an intrinsic trust with LE's root store. I should be able to set up a RD Session Host with a LE certificate for publishing and there should be no untrusted publisher for RemoteApps or Session Host desktops once the certificate's thumbprint is published via Group Policy?
One would hope that they would. LE is like the standard in SSL Certs. It's from the EFF, way more trustworthy than other cert authorities, IMHO.
Snag: Valid for 90 days. In larger RDS farm settings this would be a bear to manage. That means the need for an automated process.
It is expected to be automated. SSL Cert updates should not be intrusive. All of the tools for LE SSL Certs are designed around the idea that you will automate them and never need to worry about them again. It's about being less of a snag, not more of one.
Got it thanks. Looks like a bit of a learning curve then. :)
It's not bad. I find learning the LE pieces easier than learning to do it the old fashioned way :) And with LE it is "learn once and ignore", rather than "learn once, forget, do again in a year or two all over again."
Microsoft includes a command-line utility with Certificate Services called certutil. This utility performs various operations on certificate files, including converting them to and from base64 format.
Note that this command is run on your certificate server, which, in your environment, may be different from your Exchange server. If so, you need to copy the binary .req file to the certificate server, or make it accessible via a shared network folder or removable storage device.
Open a command prompt on the certificate server and navigate to the folder where your binary .req file is, then type the following command:
certutil -encode der.exchange.example.com.req pem.exchange.example.com.req
You can then open the output file in Notepad and confirm that it is in the correct format to upload to your certifying authority.