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.
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
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.
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.
-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.
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