-
Just discovered this lovely package, and have been doing some reading before beginning. I was not aware that LE could be used for private devices, and find this encouraging! I have some questions/confirmations I'd like to make before I get too deep into it.
First some info about my intended use: I would like to use this service to sign a variety of internal admin GUIs that may not have internet access (as well as pfsense on the edge). I plan to use Route53's API to automate renewal, etc. I assume I need to use a public domain I control, but have internal DNS records for eg example.com, registered w/ Route53, but with local resolution to private IPs.
Now my questions:
-
I'd read in a thread that there may be a change to AWS's API calls that renders that method non-functioning in the package right now, is that true, or has that been fixed?
-
With respect to AWS, I'm not quite sure what "API id" is. I have my key–but have had some trouble identifying an ID--is it the IAM user ID?
-
In terms of automating renewal for non-pfsense private devices: What manual steps will need to be run on these devices? Forgive my ignorance, but do I need to load a new cert on those every 60 days? Or do I need to reboot the devices or at least their web servers ala the configurator reboot?
-
Do I need public hostnames (subdomains) configured for my private-IP'd devices?
-
Lastly (again revealing my ignorance), can a single cert sign SANs for multiple domains? For example, test.example.com, test2.example.com AND test3.my-other-example.com?
Thanks for any insight you all may be able to offer!
-
-
I figured out the answer to #2 so far (should have been simple, and it was), You just need to create an IAM "user" for your needs, assigning appropriate access policies, etc. The credentials Amazon creates for new API entities are only accessible upon creation (which is why I couldn't find them later). You can reissue new ones at any time, of course.
I got this working well w/ dyndns, so I assume #1 may be moot as well–should know soon.
Still looking for guidance on #3-5 though, if anyone feels like chiming in.
-
#3 - it really depends on the device; Usually it's a swap of the certificate and a graceful reload, but this depends solely on the device. If they're HTTP(s), you can also use HAProxy to do the encryption for you (see [1] below) so you have
Clients –https--> HAProxy (PFSense) --http--> internal server
This way, you only need to refresh the certificates on haproxy (note that internal communication is then unencrypted, so ensure your network is appropriately protected from sniffers)
#4 No -- depends on the way you're doing letsencrypt certs. If you're using the http certbot, then yes you would need them since it requires a specific string at that server, but using Route53 should work without creating a public subdomain.
#5 Yes a single certificate can have multiple SANs, but this does leak information. If "https://www.example.com" certificate has SANs for "https://something-secret.example.com" you can read this out of the certificate; I tend to create one cert per subdomain. Also don't forget that as of recently, Chrome is enforcing the RFC such that the CN= must also be in the SAN (so create a certificate for CN=www.example.com with a SAN of www.example.com)
[1] http://loredo.me/post/116633549315/geeking-out-with-haproxy-on-pfsense-the-ultimate