Hosting platform setup with Let's Encrypt, questions

Hello everyone! I am playing around with the idea of building a hosting platform, I've already made quite a lot of progress and it has been a very fun project. I have several questions that came up during my development.

  1. The 90 day expiration of Certs is fixed, meaning, if I store the the day I created the cert, I can be certain that I'll know when it expires?

  2. Accounts, since I provision the certs on behalf of my users, should I use only one account (mine) for these sites that I host, or should I use my users email address and store their private key and email as well? Will this cause any issues for them if they also use this email themselves or something?

  3. I am using the go-acme/lego library, and I am using the HTTP01 challenge type, which opens up the :5002 port, but I am a bit scared since this seems like not scaleable, since only 1 of these can be active at a time since the other will get port occupied error. Any alternatives to this? I've read the pick a challenge type docs, but I am unable to properly grasp what a validation server is, is it something I can write up myself or? So it would be smarter to batch these and process them X at a time and make a request for all of them at once to obtain the certificates? If so, I'll have to take a look if go-acme/lego supports this kind of functionality (seems like I can use webroot option for handling the challenge)

  4. What should be the deletion process like? Eg, a site is deleted, what should happen to the certificate? Since I am no longer maintaining that domain that they registered, I guess that the certificate should just be revoked?

Any other feedback is greatly appreciated! I already have a local setup with pebble that allows me not to even hit staging while developing, only those 4 above points I haven't figured out yet.

  • No, 90 days is the current lifetime with LE but that could change one day and different CAs have different supported lifetimes, generally they currently use 90 days, buypass uses 180, some CAs support custom. You should base renewal decisions around percentage lifetime (e.g. renew at 75%) by reading the cert start and end dates. There is also ACME ARI renewal info which is a method for early signaling that a cert should renew (e.g. it was revoked by the CA because it was mis-issued, this recently happened to buypass and has happened to LE before).

  • You can use a single account if you want to as far as I know. Some per-account rate limits are relevant Rate Limits - Let's Encrypt

  • HTTP validation works by asking the server (on TCP port 80) at the requested domain for a particular response, how to achieve that response is left to the implementation

  • If a site is deleted you should be safe just to delete the associated certificate files. Revokes are generally for compromised privates keys but you were trusted at the time the cert was created and it was your private key. [note that Account private keys and CSR private keys are two different keys, many clients use a new private key for the CSR every time the cert renews]

2 Likes

See Integration Guide - Let's Encrypt

3 Likes

The AccountKey question is somewhat driven by your security and technology design.

An AccountKey can be used to revoke all issued certificates, so you should be considering the potential for a key compromise as that can impact all customers if you use a shared key.

If the account key will reside on a secured server that coordinates everything for your customers, a shared key should be fine. If the key will be stored on customer accessible servers or anything that is less secure than a machine dedicated to DevOPs/SiteOps/etc, I would use a different account key for each customer.

Edit: You should absolutely follow the official guidance from LE in the link shared above; the above statement is meant to illustrate the implications of your choice.

4 Likes

This is true today, but isn't something you should assume long-term. It would be safest to get the not_after date from the certificate itself.

3 Likes