certbot/certbot

Certbot is EFF's tool to obtain certs from Let's Encrypt and (optionally) auto-enable HTTPS on your server. It can also act as a client for any other CA that uses the ACME protocol.

Certbot is part of EFF’s effort to encrypt the entire Internet. Secure communication over the Web relies on HTTPS, which requires the use of a digital certificate that lets browsers verify the identity of web servers (e.g., is that really google.com?). Web servers obtain their certificates from trusted third parties called certificate authorities (CAs). Certbot is an easy-to-use client that fetches a certificate from Let’s Encrypt—an open certificate authority launched by the EFF, Mozilla, and others—and deploys it to a web server.

Anyone who has gone through the trouble of setting up a secure website knows what a hassle getting and maintaining a certificate is. Certbot and Let’s Encrypt can automate away the pain and let you turn on and manage HTTPS with simple commands. Using Certbot and Let's Encrypt is free.

Getting Started

The best way to get started is to use our interactive guide. It generates instructions based on your configuration settings. In most cases, you’ll need root or administrator access to your web server to run Certbot.

Certbot is meant to be run directly on your web server on the command line, not on your personal computer. If you’re using a hosted service and don’t have direct access to your web server, you might not be able to use Certbot. Check with your hosting provider for documentation about uploading certificates or using certificates issued by Let’s Encrypt.

Contributing

If you'd like to contribute to this project please read Developer Guide.

This project is governed by EFF's Public Projects Code of Conduct.

Links

Documentation: https://certbot.eff.org/docs

Software project: https://github.com/certbot/certbot

Changelog: https://github.com/certbot/certbot/blob/master/certbot/CHANGELOG.md

For Contributors: https://certbot.eff.org/docs/contributing.html

For Users: https://certbot.eff.org/docs/using.html

Main Website: https://certbot.eff.org

Let's Encrypt Website: https://letsencrypt.org

Community: https://community.letsencrypt.org

ACME spec: RFC 8555

ACME working area in github (archived): https://github.com/ietf-wg-acme/acme

Current Features

• Supports multiple web servers:
  • Apache 2.4+
  • nginx/0.8.48+
  • webroot (adds files to webroot directories in order to prove control of domains and obtain certificates)
  • standalone (runs its own simple webserver to prove you control a domain)
  • other server software via third party plugins
• The private key is generated locally on your system.
• Can talk to the Let's Encrypt CA or optionally to other ACME compliant services.
• Can get domain-validated (DV) certificates.
• Can revoke certificates.
• Supports ECDSA (default) and RSA certificate private keys.
• Can optionally install a http -> https redirect, so your site effectively runs https only.
• Fully automated.
• Configuration changes are logged and can be reverted.

certbot's Issues

pylint 1.4 no longer supported in Python 2.6

https://bitbucket.org/logilab/pylint/issue/390/py26-compatiblity-broken, which causes our Python 2.6 builds to break.

We should probably restrict pylint<1.4 in setup.py, urm...

setup.py refers to non-existent package

Specifically it refers to "trustify", which isn't anywhere in this repo. This results in trying to install the package failing:

$ pip install .
Unpacking /private/tmp/lets-encrypt-preview
  Running setup.py (path:/var/folders/fm/57qdjdrx6gzgcq1zlym0xwfc0000gn/T/pip-xeUhuw-build/setup.py) egg_info for package from file:///private/tmp/lets-encrypt-preview

    error: package directory 'trustify' does not exist
    Complete output from command python setup.py egg_info:
    running egg_info

creating pip-egg-info/trustify.egg-info

writing requirements to pip-egg-info/trustify.egg-info/requires.txt

writing pip-egg-info/trustify.egg-info/PKG-INFO

writing top-level names to pip-egg-info/trustify.egg-info/top_level.txt

writing dependency_links to pip-egg-info/trustify.egg-info/dependency_links.txt

writing entry points to pip-egg-info/trustify.egg-info/entry_points.txt

writing manifest file 'pip-egg-info/trustify.egg-info/SOURCES.txt'

warning: manifest_maker: standard file '-c' not found



error: package directory 'trustify' does not exist

----------------------------------------
Cleaning up...
Command python setup.py egg_info failed with error code 1 in /var/folders/fm/57qdjdrx6gzgcq1zlym0xwfc0000gn/T/pip-xeUhuw-build
Storing debug log for failure in /Users/alex_gaynor/.pip/pip.log

Challenge Support

Right now the only challenges being handled are DVSNI and RecoveryToken challenges.

All of the challenges are listed here. https://letsencrypt.github.io/acme-spec/#identifier-validation-challenges

If anyone is interested in implementing one of these challenges, you should extend or create an Authenticator. Right now there are only two Authenticators... Apache. (apache.configurator.py) and the Client Authenticator (client_authenticator.py)

https://github.com/letsencrypt/lets-encrypt-preview/blob/master/letsencrypt/client/interfaces.py#L7

See https://github.com/letsencrypt/lets-encrypt-preview/wiki/Documentation#authenticatorsinstallers for more info.

DV Authenticators, like Apache, perform challenges like SimpleHttps and DVSNI. Client Authenticator's perform challenges like RecoveryToken, RecoveryContact, PoP...ect. (All of this is listed in CONFIG.py) The reason for the separation is that the Client Challenges should not have to be reimplemented by modules like nginx... stand-alone (null configurator) ect.

Currently, the demo server is only giving one challenge per domain. However, I will help out and modify the server accordingly if anyone is interested.

.ca_offerings vs ca_offerings

Isn't one of .ca_offerings or ca_offerings redundant?

Finish Validator Class

We need to confirm the server is set up correctly after configuration changes are made. This will allow us to enable HSTS with confidence. (Always use HTTPS at this website and never accept anything less :) )

I created a very simple stub of what I believe to be the necessary API (validator.py) This would be a stand-alone project that would be a great way to get involved and learn more!

ACME client for Windows/IIS

I propose developing an ACME client for Windows + IIS.

Here are some of my thoughts:

• Create a PowerShell-based solution, this would be comparable to the Python-based one already in the works for Linux/Apache (letsencrypt.py):
  • This will also be allow more compatibility with more environments, such as Windows Core, and even remote execution
• Leverage the existing Windows components for any dependencies, for example under the hood, letsencrypt.py uses OpenSSL for all the cert management stuff, whereas on Windows you could use the certreq CLI or the CertEnroll API.
• By structuring the code/libs nicely, we can make parts reusable outside of the main script, for example API/library for the ACME protocol itself to be used in other implementations or projects.
• Try to mimic the letsencrypt.py command-line usage as much as possible/practical so that there is consistency across platforms letsencrypt.py CLI usage

unable to execute 'swig': No such file or directory

Hello Lets-encrypt,
While installing it in my ubuntu VPS i am getting the following error.

Send() failed... may have lost connection to server

After I've chosen the domain to use I get this error:
Send() failed... may have lost connection to server

"LetsEncryptConfiguratorError: Could not find configuration root" on Python 2.6 tests

Tail of the error log:

======================================================================
ERROR: test parse_file.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/jakub/dev/letsencrypt/lets-encrypt-preview/letsencrypt/client/tests/apache_configurator_test.py", line 83, in setUp
    (2, 4, 7))
  File "/home/jakub/dev/letsencrypt/lets-encrypt-preview/letsencrypt/client/apache_configurator.py", line 162, in __init__
    self.location = self._set_locations(ssl_options)
  File "/home/jakub/dev/letsencrypt/lets-encrypt-preview/letsencrypt/client/apache_configurator.py", line 358, in _set_locations
    root = self._find_config_root()
  File "/home/jakub/dev/letsencrypt/lets-encrypt-preview/letsencrypt/client/apache_configurator.py", line 382, in _find_config_root
    "Could not find configuration root")
LetsEncryptConfiguratorError: Could not find configuration root

----------------------------------------------------------------------
Ran 42 tests in 10.849s

FAILED (errors=12)
ERROR: InvocationError: '/home/jakub/dev/letsencrypt/lets-encrypt-preview/.tox/py26/bin/python setup.py test -q'

"Generic" support

I don't use Apache, rather I use Caucho's Resin. It will be challenging for you to support lots of servers out of the box. Perhaps you should concentrate on providing a "generic" variant, that generates the certs and keys, exports them in the appropriate format, and drops them in a local directory, so that we can then manually install them?

Also, do you handle manual naming (in case the reverse DNS isn't what we want to secure)?

Too generic exceptions

1. Catching Exception should always be avoided (e.g. it catches KeyboardInterrupt as well).
2. Let's create our own exception hierarchy starting with class LetsEncryptError(Exception), and use it instead of throwing generic Exception.

Thoughts on RPM builds?

Are there already plans for packaging this as an RPM for easy installation?

If so, great! How can I help?

If not, I'd like to volunteer to build them.

Either way, I'd like to help out in any way that I can.

[enh] Support for lighttpd

Hearing this off of TWiT's Security Now podcast, episode 483. I'm interested! But I'm running lighttpd.

Thankfully configuring SSL is simple. Here's an example from my own server (I have existing free certs through StartSSL):

$SERVER["socket"] == ":443" {
    ssl.engine = "enable"
    ssl.pemfile = "/etc/ssl/domain.pem"
    ssl.ca-file = "/etc/ssl/ca-certs.crt"
    server.document-root = "/home/web-secure/public_html"
}

I would suggest a few command line options to indicate:

• Path to web domain's public files.
• Path to web domain's secured public files.
• Path to command to generate configuration modules (to support other web servers as well), having it be passed through via STDIN.

My main go-to scripting language in Linux is Perl, alas. Looks like I'll have to pick up Python 2 and 3.

list index out of range ERROR

When running i get this error code:
Traceback (most recent call last):
File "./letsencrypt.py", line 121, in
main()
File "./letsencrypt.py", line 93, in main
c.authenticate(args, redirect, eula)
File "/home/pi/lets-encrypt-preview-master/letsencrypt/client/client.py", line 85, in authenticate
self.names = [self.names[0]]
IndexError: list index out of range

requirements.txt: pythondialog==2.7 vs python2-pythondialog in setup.py. Too specific package pins.

requirements.txt lists pythondialog, while setup.py uses python2-pythondialog instead. I personally haven't used requirements.txt much, but aren't these package pins dangerously too specific @skorokithakis (#13)?

Readme doesn't include all dependencies

I had to install both swig and dialog in addition to the existing setup directions on my minimal ubuntu install in order for the script to execute without bailing.

PR incoming.

Need to specify Python 2 when setting up virtualenv

The command to setup the virtualenv should specify Python 2 for compatibility with Linux distributions that use Python 3 as the default interpreter (Arch Linux, for example). Otherwise setup.py fails with syntax errors.

virtualenv --no-site-packages --python=python2 venv

any interest in making this work off a vagrant script?

tests do not run on OSX out of the box - virtualenv needs swig

Hi,
I am running OSX 10.9.5 and tox is not able to run the tests out of the box.

copying M2Crypto/SSL/TwistedProtocolWrapper.py -> build/lib.macosx-10.9-intel-2.7/M2Crypto/SSL

running build_ext

building 'M2Crypto.__m2crypto' extension

swigging SWIG/_m2crypto.i to SWIG/_m2crypto_wrap.c

swig -python -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/usr/include -I/usr/include/openssl -includeall -modern -o SWIG/_m2crypto_wrap.c SWIG/_m2crypto.i

unable to execute swig: No such file or directory

error: command 'swig' failed with exit status 1

Anyone still struggling to get the client running?

I was wondering how many people were still struggling on getting the project to run that are interested in development.

I realized that I had forgotten to make copying down options-ssl.conf down into /etc/letsencrypt/ as a required step to get the program to run. I think the program output was clear what the root of the problem was and shouldn't have been that difficult to solve. But it did make me wonder about the current developer state.

If there is any demand, I will get an IRC channel up and running and will be available to answer questions tomorrow in real-time.

I did post a ton of additional information under the Wiki which includes documentation, some guidance getting a server of your own running and a "how to contribute" section if you are looking for a way to get involved.

Support for Plesk

Hello,
I don't know if this is the right place for this kind of question, but will Plesk be supported?
As you say only lets-encrypt example.com is needed for generating and activating an SSL certificate for this domain I wonder if this works with Plesk's certificate management.
In Plesk you have to add a ca-certificate and your own certificate to a domain/subdomain to get it activated.

Kind regards,
Stefan

support for nginx

Hi guys,

is there a planned support also for nginx to generate the config, or to include the tool into nginx? Can one help on any part making it work for nginx, if so, let me know which file/s need to be altered for that aim to be fulfilled.

Greetins
Martin

Unit Tests

We need unit tests for just about everything in this project. I know this isn't quite as exciting of a task... and that is why I listed it last, but it would be a major help.

It is imperative that we thoroughly test modules so that we can identify fine-grained errors. As @kuba pointed out, it will also help you become familiar with the codebase and how it works. It can enable you to contribute meaningfully without having to read the code in its entirety.

(I am currently working on writing an integration testing suite that I hope can test 100s of example servers quickly, but this only detect end problems and won't provide information about the minor errors that may occur during the course of execution)

How do you prevent mistakenly issuing certificates?

Prominent, expensive certificate authorities go through a fairly elaborate offline background check to verify that a company who purchases their certificates 1. actually exists, 2. is the entity who requested the certificate, and 3. owns the appropriate domain. I guess your certificates are DV (Domain Validated) and what I'm talking about is OV (Organization Validated):
http://www.zdnet.com/will-lets-encrypt-threaten-commercial-certificate-authorities-7000036022/

Improperly issued certificates have been used to spoof legitimate sites, and, in some case, install malicious software or spy on unsuspecting users. Several examples are mentioned in the 2nd or 3rd paragraph here:
http://www.certificate-transparency.org/what-is-ct

How do you prevent this kind of misuse? Or are you planning to coordinate your release with the roll-out of Certificate Transparency (previous link)? Are you relying on DNS to establish identity? I've never heard anyone say that DNS was designed to be secure, but maybe it's better than I think. Maybe if you used enough unrelated DNS servers, accessed through unrelated networks, compared them with a huge local DNS cache, and only issued certificates when all DNS sources have agreed for some length of time...

There is no iron clad security. But a false sense of security is no good either. I don't know what, if any code changes are called for to answer these questions, but I would appreciate if you pointed me to any public documentation about how these concerns are mitigated.

P.S.
It looks like your certificates are all currently registered with the University of Michigan:
https://github.com/letsencrypt/lets-encrypt-preview/blob/master/letsencrypt/client/crypto_util.py#L77

What's in place to protect U of M from being liable if misuse happens?

Not sure if this is the right place to post this... I just signed up for your mailing list, but I didn't see any messages there yet.

Ubuntu 12.04.5 - letsencrypt.py giving error 'ApacheConfigurator' object has no attribute 'location'

I set up a new ubuntu desktop 12.04.5 instance today. I updated to the latest patches.

Then I did the following:

sudo apt-get install git

sudo apt-get install python-virtualenv

sudo apt-get install apache2

git clone https://github.com/letsencrypt/lets-encrypt-preview.git

cd lets-encrypt-preview/

virtualenv --no-site-packages -p python2 venv

sudo apt-get install python python-setuptools python-virtualenv
python-dev gcc swig dialog libaugeas0 libssl-dev

./venv/bin/python setup.py install

All this worked fine.

Then I ran:
sudo ./venv/bin/letsencrypt

And I get the following:

Traceback (most recent call last):
File "./venv/bin/letsencrypt", line 9, in
load_entry_point('letsencrypt==0.1', 'console_scripts', 'letsencrypt')()
File "/home/dneary/lets-encrypt-preview/venv/local/lib/python2.7/site-packages/letsencrypt-0.1-py2.7.egg/letsencrypt/scripts/main.py", line 100, in main
acme = client.Client(server, csr, privkey, args.use_curses)
File "/home/dneary/lets-encrypt-preview/venv/local/lib/python2.7/site-packages/letsencrypt-0.1-py2.7.egg/letsencrypt/client/client.py", line 72, in init
CONFIG.SERVER_ROOT)
File "/home/dneary/lets-encrypt-preview/venv/local/lib/python2.7/site-packages/letsencrypt-0.1-py2.7.egg/letsencrypt/client/apache_configurator.py", line 159, in init
self.location = self._set_locations(ssl_options)
File "/home/dneary/lets-encrypt-preview/venv/local/lib/python2.7/site-packages/letsencrypt-0.1-py2.7.egg/letsencrypt/client/apache_configurator.py", line 355, in _set_locations
default = self._set_user_config_file()
File "/home/dneary/lets-encrypt-preview/venv/local/lib/python2.7/site-packages/letsencrypt-0.1-py2.7.egg/letsencrypt/client/apache_configurator.py", line 396, in _set_user_config_file
case_i("Include"), case_i("httpd.conf"))):
File "/home/dneary/lets-encrypt-preview/venv/local/lib/python2.7/site-packages/letsencrypt-0.1-py2.7.egg/letsencrypt/client/apache_configurator.py", line 632, in find_directive
start = get_aug_path(self.location["root"])
AttributeError: 'ApacheConfigurator' object has no attribute 'location'

Any idea what I missed? I can eventually track this down, but I figure this will come up again, so putting it here may help someone else.

Thanks for any help.

`sudo ./letsencrypt.py` cannot access data installed by `setup.py install --user` in Debian

sys.path doesn't include ~/.local when running as root in Debian wheezy:

jakub@debian-wheezy:~/lets-encrypt-preview$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 7.6 (wheezy)
Release:        7.6
Codename:       wheezy
jakub@test:~/lets-encrypt-preview$ python setup.py install --user >/dev/null 2>&1
jakub@test:~/lets-encrypt-preview$ sudo ./letsencrypt.py 
Traceback (most recent call last):
  File "./letsencrypt.py", line 9, in <module>
    from letsencrypt.client import client
ImportError: No module named letsencrypt.client
$ ./letsencrypt.py 

Only root can run letsencrypt.

jakub@test:~/lets-encrypt-preview$ sudo python -c 'import sys; print sys.path'                                                                                                                         
['', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-linux2', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages', '/usr/lib/pymodules/python2.7']
jakub@test:~/lets-encrypt-preview$ python -c 'import sys; print sys.path'
['', '/home/jakub/.local/lib/python2.7/site-packages/letsencrypt-0.1-py2.7.egg', '/home/jakub/.local/lib/python2.7/site-packages/python2_pythondialog-3.0.1-py2.7.egg', '/home/jakub/.local/lib/python2.7/site-packages/pycrypto-2.6.1-py2.7-linux-x86_64.egg', '/home/jakub/.local/lib/python2.7/site-packages/M2Crypto-0.22.3-py2.7-linux-x86_64.egg', '/home/jakub/.local/lib/python2.7/site-packages/jsonschema-2.4.0-py2.7.egg', '/home/jakub/.local/lib/python2.7/site-packages/requests-2.4.3-py2.7.egg', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-linux2', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/home/jakub/.local/lib/python2.7/site-packages', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages', '/usr/lib/pymodules/python2.7']
$ python --version
Python 2.7.3

and current Debian sid:

jakub@debian-sid:~$ python -c 'import letsencrypt'
jakub@debian-sid:~$ sudo python -c 'import letsencrypt'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named letsencrypt
jakub@debian-sid:~$ sudo python -c 'import sys; print sys.path'
['', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages/PILcompat', '/usr/lib/python2.7/dist-packages/gtk-2.0', '/usr/lib/pymodules/python2.7']
jakub@debian-sid:~$ python -c 'import sys; print sys.path'
['', '/home/jakub/.local/lib/python2.7/site-packages/python2_pythondialog-3.0.1-py2.7.egg', '/usr/lib/python2.7/dist-packages', '/home/jakub/dev/letsencrypt/lets-encrypt-preview', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/home/jakub/.local/lib/python2.7/site-packages', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages/PILcompat', '/usr/lib/python2.7/dist-packages/gtk-2.0', '/usr/lib/pymodules/python2.7']
jakub@debian-sid:~$ python --version
Python 2.7.8

while it's OK in Ubuntu 14.04.1 (trusty):

jakub@ubuntu-trusty$ sudo python -c 'import sys; print sys.path'
['', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/home/jakub/.local/lib/python2.7/site-packages', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages']
$ python --version
Python 2.7.6

Quickfix would be to use SUDO python setup.py install --user, but I guess it's saner to give a guide for virtualenv as suggested in #10...

Also c.f. discussion in #40.

"NullConfigurator" Implementation

This has been a highly requested feature. We would like to allow all servers to receive a trusted certificate even if the project doesn't fully support their system with proper configuration.

This would involve creating a new "NullConfigurator" class (I am not tied to the name, you may call it what you like :) ). This class would essentially only perform challenges for a given domain name and output the certificate, key, and chain file at the end. (in the current working directory)

In order to perform the challenges you will have use a crypto library or spin up a lightweight server to help you perform the challenges. The challenges are at the bottom of the document here - https://github.com/letsencrypt/acme-spec/blob/master/draft-barnes-acme.txt

It would be the admins job to install the certificate, but this would enable all webserver to attain a certificate, no matter what system they are running.

(If you only want to contribute by supporting one of the challenges to begin with.. it would still be a major help.)

error

When running the code I get this error:
Traceback (most recent call last):
File "./letsencrypt.py", line 121, in
main()
File "./letsencrypt.py", line 93, in main
c.authenticate(args, redirect, eula)
File "/home/pi/lets-encrypt-preview-master/letsencrypt/client/client.py", line 63, in authenticate
if not display.generic_yesno(f.read(), "Agree", "Disagree"):
File "/home/pi/lets-encrypt-preview-master/letsencrypt/client/display.py", line 284, in generic_yesno
return display.generic_yesno(message, yes_label, no_label)
File "/home/pi/lets-encrypt-preview-master/letsencrypt/client/display.py", line 101, in generic_yesno
a = self.d.yesno(message, HEIGHT, WIDTH, yes_label = yes, no_label = no)
File "/usr/lib/pymodules/python2.7/dialog.py", line 1571, in yesno
**kwargs)[0]
File "/usr/lib/pymodules/python2.7/dialog.py", line 825, in _perform
child_rfd)
File "/usr/lib/pymodules/python2.7/dialog.py", line 765, in _wait_for_program_termination
"perhaps the dialog-like program could not be executed; "
dialog.PythonDialogErrorBeforeExecInChildProcess: <PythonDialogErrorBeforeExecInChildProcess: perhaps the dialog-like program could not be executed; perhaps the system is out of memory; perhaps the maximum number of open file descriptors has been reached>

Check requirements on startup (instead of failing with a loud traceback later)

Hello,

Since letsencrypt is targeting less experienced system administrators (dare we call them users?), it'd be good to have nice error messages instead of these:

...
  File "/root/.venvs/letsencrypt/local/lib/python2.7/site-packages/python2_pythondialog-3.0.1-py2.7.egg/dialog.py", line 485, in _path_to_executable
    "can't find the executable for the dialog-like "
dialog.ExecutableNotFound

and

...
  File "/root/.venvs/letsencrypt/local/lib/python2.7/site-packages/python_augeas-0.5.0-py2.7.egg/augeas.py", line 75, in _dlopen
    raise ImportError("Unable to import lib%s!" % args[0])
ImportError: Unable to import libaugeas!

Could there be an SMTP/IMAP server ACME client?

I don't expect that this client will support any email servers out of the box, or any time soon. However, am I correct that administrators could use Let's Encrypt to generate certificates for other internet services, like SMTP, IMAP or XMPP?

Running the demo code on Debian Wheezy 7.6

Hi everybody,
I tried the demo code for Ubuntu but on a Debian test server When hitting "./venv/bin/letsencrypt", I got the following in return. Is that return because of the unstable Apache2 conf layout? Anyhow, is there another way to test letsencrypt on Debian?

Traceback (most recent call last):
File "./venv/bin/letsencrypt", line 9, in
load_entry_point('letsencrypt==0.1', 'console_scripts', 'letsencrypt')()
File "/home/stefan/lets-encrypt-preview-master/venv/local/lib/python2.7/site-packages/distribute-0.6.24-py2.7.egg/pkg_resources.py", line 337, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File "/home/stefan/lets-encrypt-preview-master/venv/local/lib/python2.7/site-packages/distribute-0.6.24-py2.7.egg/pkg_resources.py", line 2279, in load_entry_point
return ep.load()
File "/home/stefan/lets-encrypt-preview-master/venv/local/lib/python2.7/site-packages/distribute-0.6.24-py2.7.egg/pkg_resources.py", line 1989, in load
entry = import(self.module_name, globals(),globals(), ['name'])
File "/home/stefan/lets-encrypt-preview-master/venv/local/lib/python2.7/site-packages/letsencrypt-0.1-py2.7.egg/letsencrypt/scripts/main.py", line 7, in
from letsencrypt.client import apache_configurator
File "/home/stefan/lets-encrypt-preview-master/venv/local/lib/python2.7/site-packages/letsencrypt-0.1-py2.7.egg/letsencrypt/client/apache_configurator.py", line 13, in
from letsencrypt.client import augeas_configurator
File "/home/stefan/lets-encrypt-preview-master/venv/local/lib/python2.7/site-packages/letsencrypt-0.1-py2.7.egg/letsencrypt/client/augeas_configurator.py", line 6, in
import augeas
File "/home/stefan/lets-encrypt-preview-master/venv/local/lib/python2.7/site-packages/python_augeas-0.5.0-py2.7.egg/augeas.py", line 78, in
class Augeas(object):
File "/home/stefan/lets-encrypt-preview-master/venv/local/lib/python2.7/site-packages/python_augeas-0.5.0-py2.7.egg/augeas.py", line 82, in Augeas
_libaugeas = _dlopen("augeas")
File "/home/stefan/lets-encrypt-preview-master/venv/local/lib/python2.7/site-packages/python_augeas-0.5.0-py2.7.egg/augeas.py", line 75, in _dlopen
raise ImportError("Unable to import lib%s!" % args[0])
ImportError: Unable to import libaugeas!

Move strings out of raw Python to facilitiate l10n

Currently the client code has built-in English Python strings. These should be switched to gettext or equivalent to facilitate internationalisation.

Rename the Debian package from `trustify` to `letsencrypt`

Do you support Wildcard Subdomain

[Moderator's note: If you'd like to express your support for wildcard issuance, please hit 'like' on this thread on the community forum rather than opening an issue.]

Hi, I have a question. Does Let's Encrypt supports wildcard subdomain or just just the main domain/www only? Thanks.

Command Line Arguments

Potential changes to command line

Nginx support

Please support Nginx.

According to this, it's the challenger of HTTP(S) servers.

Unable to find 'openssl/opensslv.h'

I faced this error

SWIG/_m2crypto.i:30: Error: Unable to find 'openssl/opensslv.h'

and I solved it by installing libssl-dev package.
So I think this is another requirement.

sudo apt-get install libssl-dev

Why do you enable SSLv3?

When I look in lets-encrypt-preview / letsencrypt / client / options-ssl.conf, it looks like you are enabling SSLv3. I thought that the POODLE attack rendered it obsolete?

I've found it really helpful to check my TLS settings here:
https://www.ssllabs.com/ssltest/

IRC channel

It would be a lot easier to discuss some project aspects over IRC rather than GitHub / mailing list. Thanks in advance, @jdkasten :)

Use a virtualenv in the docs

sudo pip isn't recommended in Debian because it could cause problems at a later date when packages are added or removed from Debian proper. Maybe the docs should suggest the use of a virtualenv?

pythondialog is no longer available for Python 2

From the upstream page:

As of version 2.12, the reference implementation of pythondialog (which this file belongs to) requires Python 3.0 or later in the 3.x series.

This means that the pythondialog dependency cannot be fulfilled on Debian jessie and later.

There is an out of date backport, but it comes with this warning:

This version is only here to help users who are somehow forced to still use Python 2, even though Python 3.0 was released on December 3, 2008. It may be the last update for Python 2. In addition, the reference implementation is less likely to have bugs.

and it's not in Debian, nor is it likely to ever be in Debian.

running the script on a different machine than the target webserver.

Goals:

1. I don't want to run the script as root (see issue #83)
2. I don't mind running commands as root on the target machine (see fabric)
3. potentially multiple servers are involved (mass configure: puppet, chef, ansible, salt)

256bit ECC certificate by default?

In my opinion it should install a prime256v1 ecc certificate by default, for pure performance benefits - I'm just wondering if that's going to be the case? :)

This is a very important and great initiative by the way! Thanks 👍

Create a packaging team on alioth.debian.org for the maintenance of letsencrypt in Debian

Instead of having a single maintainer for this package in Debian, we should create a team on https://alioth.debian.org so that anybody wanting to help out can join the team and receive all Debian-related emails via the team mailing list.

onion address support

Hi there,

This is more a server side than a client side issue, but it would be really nice if "let's encrypt" supports TOR's onion services.

Continuous integration

We could set up a continuous integration server to check against the master. One of the candidates would be Travis CI (quite popular here on GitHub), but note it is non-free (as in libre) sofware.

Send() failed may have lost connection

Hello,

i am interested by this project. bu i have this fatal error Send() failed may have lost connection
How can I resolve the problem ?

Plugin architecture

Given the amount of requests for support for other HTTP daemons and setups (#8, #16, #21) and expected requests for support for yet others (lighttpd, etc.), perhaps there should be a (very basic) plugin architecture that lets third parties write a plugin for other servers.

These could then simply be pull-requested back in, and shipped with the main distribution.

running the script should not require root.

I think it is unnecessary for the script to require root for running the script.

• I could be preparing everything on a different machine from where the certs will actually be used (think puppet, chef, ansible ...etc)
• I could be running the script where the configuration files actually are, e.g. on the master where the configuration will be kept or a git clone, or even some workspace that I gets rsync'd to the target machine.

Think of the difference between make and make install, usually I would prefer to do make install DESTDIR=/tmp/inspectme rather than blindly run a script as root.

Better Documentation

I think the structure of the project is finally in a state where documentation can be written to enable more people to get on board.

I will be spending the rest of the day/night writing documentation for the project which will be located in the Wiki.

We also have a new mailing list for client development that is now posted in the README.