I’m trying to understand how this approach to certificate management works, then I can dive into the technobabble. I want to make sure I got the high-level logic down.
I run more than one internal certificate authority using MS Certificate Server and have set up UCC / SAN certs with these for Exchange and Lync, plus I’ve created CAs in OpenSSL for experimenting, so I have a basic handle on cert management.
The impression I’m getting with Let’s Encrypt is, rather than create cert requests in the server and submit them to an online CA, you have a separate client application that does that for you. The client and some verification steps (the ACME protocol), including a new optional DNS record, can help automate the identity verification process. Also, the certificate lifespan is dramatically shorter than with commercial CAs (three months) and as such renewals would need to be automated. Certbot is to be used for this normally, though there are ACME clients for other systems.
It took some FAQ and forum reading to get to this level of understanding… do I have the basic idea correct?
I’ll look at ACMESharp and letsencrypt-win-simple later on; I already know Certbot doesn’t have a Win32 implementation.
[This was from the forum template]
My operating system is (include version): Windows Server 2012 R2 patched as of JAN 2017
My web server is (include version): IIS 8.5
I can login to a root shell on my machine (yes or no, or I don’t know): Yes (local admin, cmd and powershell)
I’m using a control panel to manage my site (no, or provide the name and version of the control panel): IIS Admin and PowerShell
ACME also works with CSR's. Boulder, the Let's Encrypt implementation, doesn't sign them directly, but uses the CSR as a 'validated' (i.e. "I really have the private key corresponding to the public key embedded in this signed CSR") vessle for some information (i.e., public key, SAN's). But ACME álso provides the whole process of user accounts, domain validation, signing et cetera. So there's no human intervention necessary.
Yes. The central cleverness of ACME is its “challenges” which give the ACME server (Let’s Encrypt) confidence that the ACME client asking for a certificate really controls the DNS names it wants listed in that certificate.
With your own CA you take responsibility for achieving a level of confidence you’re happy with, for example maybe the certificate is for a mail server, you know Clive runs the mail servers so you pop over to Clive’s desk to check it’s legitimate. Public CAs for the whole Internet can’t do that, and over the years they’ve come up with a variety of ad hoc processes, ACME learns from those and the result is hopefully a trustworthy & robust solution.
For internal purposes you can probably do better by hand if you put the work in. But for the Internet I believe this is best of breed.
Thanks for either clearing up or confirming what I read, folks.
I’ll have to dive deep into letsencrypt-win-simple for IIS as that’s the best way in for me. While I use Exchange and Lync, these are proxied behind IIS with application request routing, making that server the likely ACME client. For the moment, IIS ARR would work better than the Web Application Proxy until there’s a client that isn’t IIS-specific.
The fancy DNS record can’t happen until I upgrade to Server 2016, whose DNS service supports unknown record types (RFC 3597), but that’s apparently optional for Let’s Encrypt.
I already use an internal CA for most things that I publish to the internet, which is fine for Exchange because anyone using it will trust my CA cert. Now browsers are getting uppity with other things I publish though, and it seems everyone wants TLS even for casual browsing.
I am not a Windows person really, but I believe ACME expects the digest for dns-01 validation to just be in a simple DNS TXT record, and this record type is fairly old so it may be supported in your current Windows Server release in some sub-menu. For example DNS TXT is often used in DKIM email records, and GoToMeeting uses it in their feature for validating control over an email address.
The IIS plan is still likely to be most appropriate, particularly for services accessed outside your organisation as so many of those are proxied through a web server anyway - but I thought I'd mention that DNS may well be possible if you need to go that route.