I'm building out a proof of concept AWS environment that includes Windows (IIS) and Linux (nginx) EC2 instances and need to attain a SSL cert for each.
LE appears to be a great solution, but is it required that I install a client? Also, it is not likely that I would need to renew the certs.
Now, I can install a LE client of necessary, but is it possible for me to request a cert manually or would it actually be more work than I presume?
No. You must use the ACME protocol to acquire a Let's Encrypt certificate. If you want a super-simple way to acquire a cert in seconds that you can install manually, you can probably use my ACME client that doesn't really require "installing" anything other than one PHP file (you obviously need PHP working):
CertSage has been proven to work both on IIS and on all manner of webservers running on Linux.
For IIS with any ACME client using the HTTP-01 challenge, you will need something like the following file in the /.well-known/acme-challenge directory so that IIS can serve extensionless files (which it won't do by default):
Just drop that file in the /.well-known/acme-challenge directory (you'll need to let CertSage run once and fail for the directory to exist), rename the file to web.config (without the .txt), and try again.
For the Linux nginx EC2 instances, you might want to look into AWS's own Certificate Manager. It has free certificates from their own CA, but AWS is the only one with the private key and it can only be used with their infrastructure. But, they have this enclave concept for nginx on EC2 where nginx uses PKCS11 to talk to an enclave that you can't directly access but that has access to the private keys, so nginx can run a site without knowing the keys. It's neat concept, though I haven't had a chance to play with it yet myself. But if you don't want to do that, running certbot or some other Linux client on it to get Let's Encrypt certs would work just fine as well, and plenty of people do.
For the IIS servers, I don't think you'd be able to stay in the AWS ecosystem so using Let's Encrypt certificates sounds like a good plan to me. But installing an ACME client on the server that just handles everything automatically sure sounds a whole lot easier to me than whatever "manual" solution you're contemplating. Take a look at the Windows/IIS section of the Client List for some options.
For both of those, though, you'd only need that if you're going to be terminating TLS on the server instances themselves. You might be able to use something like the AWS Load Balancer in front of your servers, and have the load balancer (with the free AWS Certificate Manager certificates) handle the TLS stuff and trust Amazon's network to secure the connection between the load balancer and your server. Or there are a bazillion other possibilities along those lines, and while it may be overkill you're discussing what sounds like a more-complicated-than-one-system setup and it may make sense to try to centralize the certificate management part of the application rather than having each server fend for itself, depending on exactly what it is that you're doing.
I'm actually rather curious what makes you think that having software that manages your certificates for you would be harder than trying to do something manually? This isn't a perfect analogy, but what you're saying sounds kind of like "Do I really need to install a web server on my system, or can I just handle user requests manually?" Really the weird thing is that most web servers don't have ACME client support built in, though some actually do. But even the ones that don't have anything built in, the clients like Certbot are designed pretty well to integrate with and configure them to handle the security for you.
I only suggested CertSage if @beav just wants a couple of one-off certificates for proof of concept and doesn't want to mess with installing and learning different clients, dealing with their dependencies, and disabling the autorenewal that most of the mainstream clients automatically assume everyone wants. Admittedly, a builtin solution is probably the easiest, but with varied configurations I'm not sure if that won't require some amount of work as well. This really comes down to the "complexity" of installing the certificate and whether some "automated" assistance is desired to do so. For basic nginx, it's a few lines of code and a reload. For IIS, I don't think it's much more. If the setup is a load balancer or something more complex, there will need to be a degree of manual configuration anyhow as no mainstream client to my knowledge can handle that with any level of automation (with most causing more harm than good trying to install the certificate). To me, trying to build an assembly line for fabricating a prototype seems excessive, but then I suppose it depends on what's beyond the proof of concept.
Are you using AWS Route 53 for DNS? The reason I ask is you need to be able to validate your domain control for each host (e.g. app.yourdomain.com and db.yourdoman.com), which is easiest using http validation for a webserver (because port 80 is already exposed), but that's trickier on machines with no webserver (or no exposed port 80), so DNS validation comes into play.
As we're recommending acme clients, see https://acmeclients.com - I also develop one of those.
You do not have to install a client onto those nodes/images. You can run the Certbot client locally (your desktop/laptop) and use the DNS-01 challenge to prove ownership of the domain(s). You can then manually install the SSL Certificate(s) onto those servers. The same certificate can be used on both servers if applicable.
That's a great tip. Would I need to use a wildcard domain since each of my servers have a different A record as such: host1.example.com, host2.example.com, etc?
Well, a wildcard is one approach that would work fine, or if it's just a handful of names it may be easier for you to just get one certificate that has all the names you're using on it.
Thanks all for the insightful responses! To clarify, I only wanted to keep it simple by making a CSR to LE and install the cert. If a powershell/bash facility allowed me to do it from the command line, then this would suffice. This was the premise of my question...
I have since installed certbot and it appears to be lightweight and simple to use. So, I'm good with this for this POC environment.
CertBot did complain that it would not be able to install the cert automatically. Because of that, I imported the "fullchain.pem" into Windows Certificate Manager via MMC, but when trying to configure it for the https binding in IIS, it does not show up. Does IIS only search for pks files or is there another issue?
Same here... I figured there would be info on the LE website, but I have yet to find it. Hopefully someone can chime in with the solution. Otherwise, I'll post another ? in the forum.
My main concern is that IIS was not complaining because it was not in .cer format or .pfx.
I would expect that if you were using certbot, you'd need to use openssl or the like to convert the private key and full chain together into a pfx for use in IIS. That's part of why I suggested using a Windows/IIS-specific client for that case, because the Windows way of thinking of things and the Linux way of thinking of things are just different enough that rather than converting from one format to the other it's usually easier to use a tool designed from the ground up for the platform you're working on. While certbot can run on Windows fine, it's certainly Linuxy in its thinking, if that makes sense, and is really much more suited for configuring Apache on Windows than for configuring IIS on Windows.
After trying to convert the .pem to .cer (or .pfx) to no avail, I gave up and chose another tool - Certify The Web and it is incredibly easy to use and provides lots of customization.
Hopefully CertBot can auto-configure IIS or provide a better cert in the future.