Feedback and problems: My experience with LE

1

Hello,
I was very excited for Let’s Encrypt to finally arrive, however in it’s current state I’m at least disappointed by the client’s implementation (and some of the CAs policies). This thread is an attempt to document the problems I’ve run into so far. I hope at least some of them get fixed. The following list is not ordered by importance or impact. I’ll mention workarounds where I’ve used them and suggest solutions.

  • LE client starts slowly.
    This is due to the virtual environment dependencies and LE client being checked for updates with every start, even if only the help command is used.
    Workaround: Use /root/.local/share/letsencrypt/bin/letsencrypt directly.
    Solution: Saving the timestamp of the last time checked and updating only every X hours.

  • Inconsitent parameter handling
    The LE client reacts differently when running ./letsencrypt-auto -help all and ./letsencrypt-auto -h all.
    Workaround: Always use -h
    Solution: Drop -help completely or treat it as a true alias.

  • Generated configs are broken under certain circumstances (apache2)
    The LE client did more than silly things with my configs. I ended up with an SSLEngine On statement in the generated vhost (expected) while listening to port 80 (unexpected). Logfile paths were not taken from the original config etc.
    Workaround: Don’t use auto-configuration
    Solution: Way more testing :wink:

  • SSL include config containing lines the LE client should never touch.
    I’ve already mentioned logfile paths. The following options are not in the scope of the LE client:
    ServerSignature Off AcceptPathInfo Off AddOutputFilterByType DEFLATE text/html text/plain text/xml application/pdf
    The following lines can break applications:
    AddDefaultCharset UTF-8 #Header edit Set-Cookie (?i)^(.*)(;\s*secure)??((\s*;)?(.*)) "$1; Secure$3$4"
    Luckily the last line is not active yet. I’m not saying this is not a good practice, but you shouldn’t touch those settings without the admins explicit consent.
    Workaround: Don’t use auto-configuration / Edit the file afterwards
    Solution: Remove those lines or make them opt-in.

  • Private keys have incorrect permissions, which introduces potential security vulnerabilities.
    See privkey1.pem has 644, better is 600

  • Short cert lifetime introduces compatibility problems (e.g. IRC, mail servers, …)
    See Maximum (and minimum) certificate lifetimes?

  • GUI quits immediately for non fatal errors.
    I already deleted a file the LE client wanted to delete from a previous failed attempt. The clients just quits even though this error is not fatal, making it annoying to use.
    Solution: Less disturbing error handling

  • (Needs further testing) GUI doesn’t allow pasteing
    I only tried that once: The GUI doesn’t allow me to paste domain names for example.
    Workaround: Don’t use the GUI.

  • GUI unresponsive
    The GUI will not show any progress indicator. It’s unclear whether the GUI is frozen or not.
    Workaround: Don’t use the GUI.
    Solution: Add progress indicators or “Please wait …” messages.

  • Unclear error messages
    Error message don’t have any value really. “Domain not whitelisted!” Yes, but which of the 30 domains I requested in the SANs?
    Workaround: Search the logfiles carefully.
    Solution: Add more details to error messages.

  • LE client’s presents can introduce further risks for other security vulnerabilities.
    E.g. an exploit that allows attackers to upload generic non executable files will now allow them to issue certs using webroot auth (even easier if the folder is already present).
    Workaround: Move webroot auth directory outside of the document root (with sane permissions for PHP etc.).
    Solution: Allow account key pinning over DNS. Allowing domain wide opt-out from the LE CA via DNS.

  • LE client pollutes harddives
    I have 20 CSR files in my /etc/letsencrypt/csr directory for example now. This number is going to skyrocket when running the LE client for some time.
    Solution: Add cleanup routines.

  • LE client incompatible with HPKP
    There is no option I know of to keep the private key, making HPKP unuseable
    Solution: Add option to keep the private key when renewing.

  • LE client binds to port 443 or 80 when running in standalone mode
    Requires no explanation really.
    Workaround: Use webroot auth, see Using the webroot domain verification method
    Workaround (2): Use the reserve proxy method, see LE client needs to bind to port 80, which I'm already using
    Solution: Allow changing the port used by the ACME server to connect via SRV RRs.

  • Poor client documentation
    The online docs are not really helpful and don’t provide any details on different auth methods, revocation, etc.
    Workaround: Use -h all. Still very bare bones.

  • LE-auto needs to run as root, even though root isn’t really needed
    Webroot auth and when using http-01 on ports above 1024 (with a reverse proxy) for example wouldn’t require root.

  • No documentation on which software supports cert and key reloads or graceful restarts
    Since this is a new policy required by LE for zero downtime use, you should really try to make a list of compatible software.

  • LE client apache2 module scans incorrect directory for configs
    /etc/apache2/sites-available/ is scanned rather than /etc/apache2/sites-enabled/ leading to backup and debug configs being modified

  • LE client apache2 module doesn’t scan subfolders.
    Only the folder /etc/apache2/sites-available/ is scanned for config files, subfolders remain unnoticed. Larger deployments rely on subfolders for organisation and permission purposes.

  • LE client places certificates into the wrong folder
    Under certain circumstances the LE client places certificates into the wrong folder. After deleteing a “domain.tld” folder from /etc/letsencrypt/live, archive and renewal my cert (and keys) were placed in “irc.domain.tld” after the LE client was run. The client just uses the closest match instead of using the first -d paramater to indentify where the key and cert belongs.

Beta issues (No further explanation, since limited to the beta):

  • Strict rate limiting for testing?! The opposite should be encouraged, especially with whitelisted domains
  • Domain whitelisting for subdomains. This is annoying as hell. I’ll probably have to get a cert from another CA because I forgot one subdomain and the cert I was using expires on sunday. I’m not confident at all that the additional request is going through in time.

I probably forgot an issue or two. I’ll update this thread once I encounter more. I didn’t have the time to check spelling yet :wink:

6 Likes
2

Hi, first time that here are so many critical points that can be fixed. Documentation i think is one of the biggest problem.
“ServerSignature Off” i would say the topic should be modified to LE client. Because it is not LE as itself.

1 Like
3

Update 2015/11/20: Added two more non beta issues at the end concerning the apache2 module’s handling of folders.

2 Likes
4

Update 2015/12/10: Added “LE client places certificates into the wrong folder”