Self-Registering Private Instances

[bflad]

Hi There!

I stumbled across this project when it was mentioned in the LE dns-01 challenge thread. This looks awesome and very similar to functionality we'd be looking for in our environment. In addition to ELB management, basically we'd want to have our non-externally accessible backend instances self-register with ACME via the dns-01 challenge (so we don't need to manage their SSL certificates via our own CA). Seems like all we'd need is to tell your project that its not for an ELB, but rather the node itself.

Would you be interested in this functionality since you already have most of the legwork? I don't mind writing code or tests to support it if necessary. Thanks!

[alex]

Not sure! Until DNS challenges are properly launched for letsencrypt and I've got the whole flow provable working, I don't want to think about expanding the scope of this.

[bflad]

Makes sense. :) Let me know if you need any help.

[alex]

Now that everything is working on the staging env :-)

@bflad with a scheme like this, how would you expect letsencrypt-aws to get the cert to your server?

[bflad]

Thanks for the followup! I will explain our use case in more detail.

We have some auto-scaling backend services/storage that we'd like to manage their SSL certificates for in an automated fashion. They have either NAT or proxy access out to the Internet, but no method of being accessed in the opposite direction, hence why a DNS challenge would work well.

I'm thinking it would work like this:

• AWS launches instance (manually or via ASG) and runs user data
• Instance has access to the access key (baked into AMI or fetched prior, but not really letsencrypt-aws's concern) and issues a call to letsencrypt-aws with separate flags/config that would:
  • Generate CSR for its own FQDN
  • Send request for challenge to ACME
  • In response, receive information to add to the challenge DNS record for the FQDN
  • Upserts DNS record via IAM role permissions
  • Grabs certificate and writes to specified location
• Instance finishes first boot and any service handling
• Later we call letsencrypt-aws with same flags/config via cron so we can capture status then do additional processing or run the persistent daemon, which re-runs above process to update certificate

If I'm understanding correctly, I think the only changes necessary are:

• a way to call "register myself" via letsencrypt-aws flags/config
• skipping ELB handling when above code path is triggered
• a flag/config for where to drop the certificate

[alex]

So the desired behavior would be to just write the certs/private key to local disk?

[bflad]

Yep that's exactly it.

[viyh]

+1. I'd love to run this and end up with a certificate stored in S3 and no ELB modification.

[alex]

Ok, I've thought of a way to refactor the code to make this use case much
easier to accomodate.

On Thu, Jan 21, 2016 at 11:26 AM, Joe Richards [email protected]
wrote:

+1. I'd love to run this and end up with a certificate stored in S3 and no
ELB modification.

—
Reply to this email directly or view it on GitHub
#4 (comment).

"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084

[alex]

Ok! I've refactored the code a bit to make this usecase easier. If you look at letsencrypt-aws.py, all that needs to be done to support alternate storage locations for certificates it to write a class that implements the same API as ELBCertificate, and instantiate it in update_certificates. Not quite sure what implementations we'd want to include directly with letsencrypt-aws, but that should be a decent starting point.