certbot fails with cannot execute as shared object

[lwsrbrts]

I jumped onboard the WSL bandwagon a while back and saw it as a perfect opportunity to getting Lets Encrypt certificates on Windows without the drama. I used the standard certbot and initially installed when it was around version 0.13. The last time I updated the certificates, everything was fine. I use a certonly command which publishes the challenges to my Windows 10 machine via the /mnt/ folder and a Virtual Folder on the web server points to this location allowing LE to check the validity of the challenges and issue the certs.

Windows version:

Microsoft Windows [Version 10.0.15063]

The command I'm using is similar to the following:

./certbot-auto certonly --webroot -w /mnt/d/LetsEncrypt/www.lewisroberts.com/ -d lewisroberts.com -d www.lewisroberts.com -d vpn.lewisroberts.com -d ftp.lewisroberts.com -d eastgate.lewisroberts.com -m [email protected] --agree-tos --post-hook 'sudo openssl pkcs12 -inkey /etc/letsencrypt/live/lewisroberts.com/privkey.pem -in /etc/letsencrypt/live/lewisroberts.com/fullchain.pem -certfile /etc/letsencrypt/live/lewisroberts.com/chain.pem -export -out /mnt/d/LetsEncrypt/www.lewisroberts.com/lewisroberts.pfx -password pass:NOTTHIS'

As mentioned, previously this worked without issue previously however on the latest run, certbot was automatically updated to 0.19. After the update was completed, I got this:

Requesting to rerun ./certbot-auto with root privileges...
[sudo] password for lewis:
Error: couldn't get currently installed version for /opt/eff.org/certbot/venv/bin/letsencrypt:
Traceback (most recent call last):
  File "/opt/eff.org/certbot/venv/bin/letsencrypt", line 7, in <module>
    from certbot.main import main
  File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/main.py", line 11, in <module>
    from acme import jose
  File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/acme/jose/__init__.py", line 37, in <module>
    from acme.jose.interfaces import JSONDeSerializable
  File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/acme/jose/interfaces.py", line 9, in <module>
    from acme.jose import util
  File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/acme/jose/util.py", line 5, in <module>
    import OpenSSL
  File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/OpenSSL/__init__.py", line 8, in <module>
    from OpenSSL import rand, crypto, SSL
  File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/OpenSSL/rand.py", line 12, in <module>
    from OpenSSL._util import (
  File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/OpenSSL/_util.py", line 6, in <module>
    from cryptography.hazmat.bindings.openssl.binding import Binding
  File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/cryptography/hazmat/bindings/openssl/binding.py", line 13, in <module>
    from cryptography.hazmat.bindings._openssl import ffi, lib
ImportError: /opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/cryptography/hazmat/bindings/_openssl.so: cannot enable executable stack as shared object requires: Invalid argument

I've tried any number of times with the same outcome.

I went off to browse for issues on the GitHub repo for certbot and came away with some possible solutions which I tried (basically deleting some fiiles and folders) but they didn't work. Each time resulting in the same error.

I also came across this issue on their repo saying that it's basically a WSL BoW fault and they won't fix it since it reduces security - which is fine but this problem leaves me without the capability of renewing my certificates unless I spin up a linux VM and jump through the requisite hoops to configure shares as per my WSL BoW install. I'm still a little perplexed that there's no official Windows ACME client.

I was also asked for an strace...that's attached (I think!). Hopefully useful but if anyone needs more info, I'm happy to help.
certbot-strace.txt

[therealkenc]

Yeah like your link says, dupe #286 #442 #916 - executable stack.

[bitcrazed]

@lwsrbrts - Appreciate you taking the time to file this issue.

Alas, it looks like Python's cryptography.hazmat library enables code to be executed from the stack. This is a well known security hazard and is one we cannot unleash against our (usually) unsuspecting users.

As @yorickdowne pointed out, we consider WSL to act as a canary in this case!

If you see "cannot enable executable stack" errors - please contact the owner of the affected component and ask them (politely, of course) to please double-check that they've not accidentally enabled stack-execution. Or if they've enabled it deliberately, please ask them to consider disabling stack execution, and using an alternative approach.

We found similar issues when running several other Linux systems/platforms, and following conversation with the owners of said components, pretty much all found it was accidental, and updated their code to disable stack execution.

The goal here isn't to enable __________ to run on WSL - that's just a by-product - it's more to help eliminate common sources of vulnerabilities that affect us all.

References:

• https://www.usenix.org/legacy/publications/library/proceedings/sec98/full_papers/cowan/cowan_html/node21.html
• http://web.eecs.umich.edu/~aprakash/security/handouts/Stack_Smashing_Vulnerabilities_in_the_UNIX_Operating_System.pdf
• https://www.coresecurity.com/content/multiple-vulnerabilities-in-stack-smashing-protection-technologies

[lwsrbrts]

Thanks for that. It's frustrating that I'm now in a chicken and egg scenario since I had a previously perfectly working solution that I now need to fix, essentially by rebuilding it. Granted, it's only for a blog and other home use but 😒.

[therealkenc]

...known security hazard and is one we cannot unleash...

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!