./letsencrypt-auto certonly -d domainname gives error "ImportError: No module named interface"



I am trying to use letsencrypt on ec2

NAME="Amazon Linux AMI"

When I run below command it gives error, what is the issue can some one please help.

./letsencrypt-auto certonly -d “mydomainname.com

Checking for new version…
Creating virtual environment…
Installing Python packages…
Installation succeeded.
Requesting root privileges to run letsencrypt…
/root/.local/share/letsencrypt/bin/letsencrypt certonly -d fryingpanadventures.com
Traceback (most recent call last):
File “/root/.local/share/letsencrypt/bin/letsencrypt”, line 7, in
from letsencrypt.main import main
File “/root/.local/share/letsencrypt/local/lib/python2.7/dist-packages/letsencrypt/main.py”, line 11, in
import zope.component
File “/root/.local/share/letsencrypt/local/lib/python2.7/dist-packages/zope/component/init.py”, line 16, in
from zope.interface import Interface
ImportError: No module named interface



I’m getting the exact same error. Any ideas folks?


Should the domain have quotes around it? That seems wrong. FQDNs can’t have spaces or special characters, so quotes are unnecessary.

Also, what authentication method are you using? The main question didn’t specify whether you’re using standalone, webroot, apache/nginx, or manual.


The quotes will be eaten by the shell, so aren’t a problem here.

This problem appears to concern a Python package, and so is probably OS or Python-version specific.


Still, shouldn’t there also be an authentication method specified? The output shows the fryingpanadventures domain but not authentication method. I’d assumed that the python errors were due to “no named import” (that it was missing a command line argument).


If one Googles for “no module zope interface” this isn’t the first time this zope + interface issue has crept up.

Can the LE team stop using such an unstable module?


Well, technically, they have. (Certbot is now with the EFF!) But I’ve had trouble with some of the python modules myself, and the vague error messages make it hard to identify exactly what the problem is.

I can totally understand why people are using third party clients.


Well I hope we can find a work-around soon as I have a cert expiring on June 1st that I currently cannot renew.


@noc_amaeya never responded to our questions, so it’s hard to tell if his issues are the same as yours (even if the errors look the same).

When I had my python problems, it was due to letsencrypt (0.5) requiring more recent versions of python libraries than was available through ports (I’m on FreeBSD). I was able to solve the issue by downgrading letsencrypt to 4.2, everything worked fine after that. (I’ve since been able to upgrade again.)

As silly as it sounds, have you tried going backwards? (To an earlier version?)


I believe this is a similar issue as before with Amazon Linux path issues being all out of whack. Amazon has never been able to get Python working correctly since day one so this doesn’t surprise me.

It appears that this is just another case of lib64 vs lib and path issues.


We all have our cross to bear, 0.7 has been released and FreeBSD ports is still stuck on 0.5!

I can see I’m going to have to eventually move to acme.sh or similar.


Actually my memory was jogged. This is entirely caused by AMazon Linux having massively oudated versions of pip and virtualenv installed.

Updating pip/virtualenv solved it:

pip install --upgrade pip
pip install --upgrade virtualenv

I came across a similar issue with other packages.


Slight modification, if you want to minimize the impact on Amazon’s original setup:

sudo pip install --upgrade pip
sudo cp /usr/local/bin/pip2.7 /usr/bin/pip-2.7
sudo ln /etc/alternatives/pip /usr/bin/pip
sudo rm /usr/local/bin/pip
sudo pip install --upgrade virtualenv
sudo cp /usr/local/bin/virtualenv /usr/bin/virtualenv-2.7
sudo ln /etc/alternatives/virtualenv /usr/bin/virtualenv
sudo rm /usr/local/bin/virtualenv

Manually installing pip deletes the /usr/bin version and puts it under /usr/local/bin, even on an upgrade, so you have to fix that up manually. I’m not entirely sure what will happen if Amazon ever bothers to update it, but this definitely needs to be part of the Amazon-specific script.

If you don’t set the links back up, then it needs hash -r to run pip at all, and stops working with sudo.

Once done, LE works like a charm again.


Try this on Amazon Linux:

~/.local/share/letsencrypt/bin/pip install pip --upgrade
~/.local/share/letsencrypt/bin/pip install virtualenv --upgrade
~/.local/share/letsencrypt/bin/pip install zope.interface
~/.local/share/letsencrypt/bin/pip install cryptography
/opt/letsencrypt/letsencrypt-auto renew