kuba / simp_le Goto Github PK

View Code? Open in Web Editor NEW

886.0 886.0 59.0 361 KB

Simple Let's Encrypt Client

License: GNU General Public License v3.0

Shell 4.45% Makefile 0.09% Python 95.46%

simp_le's People

Contributors

Stargazers

Watchers

simp_le's Issues

Further instructions

Some more details instructions would be great.

A couple things that aren't so clear:

Do we just need to send request for /.well-known/acme-challenge/* through to the directory set in --default_root?
Where and what file does this write to?
Do you suggest installing this in /usr/local/bin or elsewhere?

Use ComparableX509 and ComparableRSAKey

For example, for data imported from the official client:

# simp_le -d ${domain?}:/var/www/html --account_key_size 2048 -f account_key.json  -f key.pem -f cert.pem -f fullchain.pem -f chain.pem
Some plugins returned conflicting data for the "chain" component
Debugging tips: -v improves output verbosity. Help is available under --help.

This is because OpenSSL.crypto.X509.__eq__ is not defined sensibly. Similar applies to -f key.pem -f key.cert et al (OpenSSL.crypto.PKey.__eq__ broken).

acme library has convenience wrappers: jose.ComparableX509 and jose.ComparableRSAKey that should be used throughout simp_le code

AssertionError when domains on command line don't match domains in existing cert

The error message in this case should be clearer, not just an obscure stack trace, since it's very easy to hit.

Allow exact webroot path without appending .well-known/acme-challenge/

In some scenarios, it might be convenient for users to specify exact path including .well-known/acme-challenge/ without appending this in the code. For more context see #37 (comment).

cc @ThiefMaster

Underscores are pretty uncommon for --long-args

Most applications use dashes, i.e. --foo-bar instead of --foo_bar for multi-word argument names (argparse automatically converts them to underscores for dest of the argument).

Is there any specific reason for using underscores?

Silent/quiet mode usable for automation

I'd like to run automated simp_le jobs that produce zero output if they work as expected. It should report errors still.

As an example, if it's not clear what I mean, I'm thinking of the following scenarios that should produce no output:

no persisted certificate, generation was successful
persisted certificate, renewal not needed
persisted certificate, needs renewal, renewal was successful

These situations, however, should be an error:

Invalid combination of arguments
Generation/renewal failed
Persisted certificate could not be parsed

Add example wrapper script for multi-cert/multi-account management.

Why is it a directive that output paths must not be specified? It's inconvenient, at the very least I would like to be able to output the files with their own names. I don't understand why we can't assume that the user knows what they're doing.

Allow --csr

Rename external_pem.sh to external.sh

pem in the name is no longer accurate - account_key is in JWS format

"E: Unable to locate package virtualenv" is confusing (although not real error)

When running ./bootstrap.sh on Ubuntu 14.04 server LTS, it fails with this error:

E: Unable to locate package virtualenv

This is because the virtualenv package is actually called "python-virtualenv" on 14.04. Since this is the most recent Ubuntu LTS release it might be worth adding a check for this case so that bootstrap.sh can complete without errors.

Transient integration test failure on stat results comparison

https://travis-ci.org/kuba/simp_le/jobs/100912995#L1424

======================================================================
FAIL: test_it (simp_le.IntegrationTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/travis/build/kuba/simp_le/simp_le.py", line 1494, in test_it
    self.assertEqual(initial_stats, self.get_stats(*files))
AssertionError: {'acc[142 chars]199437, st_mtime=1452199437, st_ctime=14521994[376 chars]437)} != {'acc[142 chars]199438, st_mtime=1452199437, st_ctime=14521994[376 chars]437)}
Diff is 1097 characters long. Set self.maxDiff to None to see it.
----------------------------------------------------------------------
Ran 1 test in 1.675s
FAILED (failures=1)

wrapped/unwrapped OpenSSL problem

My first try running simp_le, it successfully verified with the CA and generated the certificate, but crashed before returning it to me. Traceback:



Traceback (most recent call last):
  File "/usr/bin/simp_le", line 1407, in main
    return main_with_exceptions(cli_args)
  File "/usr/bin/simp_le", line 1392, in main_with_exceptions
    new_data(args, existing_data)
  File "/usr/bin/simp_le", line 1322, in new_data
    certr = get_certr(client, csr, authorizations)
  File "/usr/bin/simp_le", line 1259, in get_certr
    max_attempts=(10 * len(authorizations)))
  File "/usr/lib/python3.5/site-packages/acme/client.py", line 386, in poll_and_request_issuance
    return self.request_issuance(csr, updated_authzrs), updated_authzrs
  File "/usr/lib/python3.5/site-packages/acme/client.py", line 310, in request_issuance
    headers={'Accept': content_type})
  File "/usr/lib/python3.5/site-packages/acme/client.py", line 631, in post
    data = self._wrap_in_jws(obj, self._get_nonce(url))
  File "/usr/lib/python3.5/site-packages/acme/client.py", line 508, in _wrap_in_jws
    jobj = obj.json_dumps().encode()
  File "/usr/lib/python3.5/site-packages/acme/jose/interfaces.py", line 189, in json_dumps
    return json.dumps(self, default=self.json_dump_default, **kwargs)
  File "/usr/lib/python3.5/json/__init__.py", line 237, in dumps
    **kw).encode(obj)
  File "/usr/lib/python3.5/json/encoder.py", line 199, in encode
    chunks = self.iterencode(o, _one_shot=True)
  File "/usr/lib/python3.5/json/encoder.py", line 257, in iterencode
    return _iterencode(o, 0)
  File "/usr/lib/python3.5/site-packages/acme/jose/interfaces.py", line 214, in json_dump_default
    return python_object.to_partial_json()
  File "/usr/lib/python3.5/site-packages/acme/jose/json_util.py", line 263, in to_partial_json
    return self.fields_to_partial_json()
  File "/usr/lib/python3.5/site-packages/acme/jose/json_util.py", line 251, in fields_to_partial_json
    jobj[field.json_name] = field.encode(value)
  File "/usr/lib/python3.5/site-packages/acme/jose/json_util.py", line 96, in encode
    return self.fenc(value)
  File "/usr/lib/python3.5/site-packages/acme/jose/json_util.py", line 401, in encode_csr
    OpenSSL.crypto.FILETYPE_ASN1, csr.wrapped))
AttributeError: 'X509Req' object has no attribute 'wrapped'

Unhandled error has happened, traceback is above

Information I got on IRC:

06:18:22   bmw | Looks like it's a simp_le bug, not a python-acme bug.
06:19:03   bmw | To try and shorten a long story, python-acme wraps OpenSSL cert and req objects in a wrapper class for convenience.
06:20:14   bmw | Recently, we found out that the module was sloppy in how it passed around those objects, using the wrapped/OpenSSL version interchangeably.
06:20:46   bmw | This caused bugs which was recently fixed in the python-acme. simp_le is using the OpenSSL object when it should be using the wrapped object.
06:21:08   bmw | We should file an issue about this on simp_le. Would you like to do it or would you like me to?
06:21:21   bmw | Also, as for simply using simp_le, you can try downgrading your python-acme version to 0.1.1.

Boulder integration tests

account_key.json should be an IOPlugin

This will make it possible for user to take full control over persistence store.

Infinite connection loop while generating new (not renewed) cert

2015-12-03 15:39:02 [INFO] Creating certificate for gitlab.notoriousdev.com
2015-12-03 15:39:02 [INFO] Running simp_le from /etc/ssl/letsencrypt/certs/gitlab.notoriousdev.com as: simp_le --cert_key_size 2048 --email [email protected] --server https://acme-v01.api.letsencrypt.org/directory --default_root /etc/letsencrypt/webrootauth -f key.pem -f cert.pem -f chain.pem -f fullchain.pem -d gitlab.notoriousdev.com -d gitlab.ndev.me
2015-12-03 20:39:02,972:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-03 20:39:03,945:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-03 20:39:04,093:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-03 20:39:04,284:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-03 20:39:04,514:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-03 20:39:04,765:INFO:requests.packages.urllib3.connectionpool:207: Starting new HTTP connection (1): gitlab.ndev.me
2015-12-03 20:39:04,921:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): gitlab.notoriousdev.com
2015-12-03 20:39:05,483:WARNING:simp_le:801: gitlab.ndev.me was not successfully verified by the client. CA is likely to fail as well!
2015-12-03 20:39:05,499:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-03 20:39:05,709:INFO:requests.packages.urllib3.connectionpool:207: Starting new HTTP connection (1): gitlab.notoriousdev.com
2015-12-03 20:39:05,797:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): gitlab.notoriousdev.com
2015-12-03 20:39:06,309:WARNING:simp_le:801: gitlab.notoriousdev.com was not successfully verified by the client. CA is likely to fail as well!
2015-12-03 20:39:06,322:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-03 20:39:06,760:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-03 20:39:06,881:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-03 20:39:11,030:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-03 20:39:11,182:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-03 20:39:15,333:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-03 20:39:15,470:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-03 20:39:19,737:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-03 20:39:19,895:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Traceback (most recent call last):
  File "/opt/simp_le/venv/bin/simp_le", line 9, in <module>
    load_entry_point('simp-le', 'console_scripts', 'simp_le')()
  File "/opt/simp_le/simp_le.py", line 871, in main
    raise SystemExit(_main(cli_args))
  File "/opt/simp_le/simp_le.py", line 864, in _main
    _new_data(args)
  File "/opt/simp_le/simp_le.py", line 809, in _new_data
    certr, _ = client.poll_and_request_issuance(csr, authorizations.values())
  File "/opt/simp_le/venv/local/lib/python2.7/site-packages/acme/client.py", line 366, in poll_and_request_issuance
    time.sleep(seconds)
KeyboardInterrupt

Without the keyboard interrupt, the new HTTPS connection message just repeats forever.

In the interest of transparency, I am using a wrapper script, but this shouldn't affect anything as the only thing this script does is generate a simp_le command based on variables and runs it. The final command that gets ran is printed in the log.

This problem only started a few hours into the public beta launch today, simp_le was working perfectly before that. I've also tested it under the following conditions and everything works as expected.

Existing cert that doesn't need renewing. (skips)
Attempting to generate a new cert while rate limited (fails, as expected, but doesn't get stuck in a connection loop).

It's only when generating a completely new cert for a domain that hasn't had a cert with Let's Encrypt yet that this problem occurs.

Let me know if there's more info I could provide.

Special-Use Domain Names instead of le*.wtf

*.example.{com,net,org} or *.test as defined in RFC6761 should be used instead of le*.wtf (mainly for integration testing with Boulder)

Exit code 1 for "renewal not necessary" and python traceback/errors.

When an error occurs like the one in #21 then python will exit with code 1.
That is bad because I'd like to distinguish "renewal not necessary" from such an unexpected error.

Can you put a try block around the complete application that catches these errors, prints a stacktrace and exits with 2?

Alternatively, you could just swap the 1 and 2 exit code meanings, but this would be a breaking change.

Move tests in sepeate module

The code would be much easier to read and understand when the unit tests would be extracted in to a seperate python module or package.

Why check for EEXIST?

While auditing this project I found a weird check in two places for errno.EEXIST:

class ExternalIOPlugin(OpenSSLIOPlugin):
    # ...

    def persisted(self):
        """Call the external script and see which data is persisted."""
        try:
            output = subprocess.check_output([self.script, 'persisted'])
        except OSError as error:
            if error.errno != errno.EEXIST:
                return self.EMPTY_DATA
            raise
        return self.Data(
            key=('key' in output),
            cert=('cert' in output),
            chain=('chain' in output),
        )

Why would you return empty when the script cannot be executed (EPERM - insufficient permissions, ENOENT - file does not exist) while you raise an error for EEXIST ("File exists")? Under what circumstances can this occur?

Another place where such a check exists is:

def _load_existing_data(ioplugins):
    """Load existing data from disk.

    Returns:
      `IOPlugin.Data` instance with all components set or
      `IOPlugin.EMPTY_DATA`.
    """
    components = tuple(IOPlugin.EMPTY_DATA._asdict())
    existing = IOPlugin.EMPTY_DATA
    for plugin_name in ioplugins:
        try:
            data = IOPlugin.registered[plugin_name].load()
        except IOError as error:
            if not error.errno != errno.EEXIST:
                raise

None of the load() functions seem to raise an EEXIST. Is this coming from the OpenSSL library?

Additionally, this logic "not X != y" is not pretty readable.

Mention default --valid_min in README

@Rotonen requested (at IRC) that --valid_min default value (

simp_le/simp_le.py

Line 72 in 8f258bc

DEFAULT_VALID_MIN = LE_CERT_VALIDITY / 3

) should be mentioned in README.

private key permissions

Hi,

I think the permissions on the private key should be more restrictive by default, they're currently set to world readable and should probably be chmod 600

(I noticed this because opensmtpd considers insecure file perms on the private key a fatal error:
must be at most rwx------)

Revocation

This client should also support revocation.

--revoke?

Retain Order of Domains

For certificates that authenticate multiple sites, I'd like to specify which domain goes in the CN field. This should probably be the first -d domain specified. But since simp_le uses a dictionary, the ordering provided by the user is lost.

Could you have the ordering of -d be preserved, or add another switch to specify explicitly which domain should be in the CN?

Thanks.

Log to syslog instead of stdout/stderr

Hi,

is it possible to add an option to log messages directly to syslog instead of stdout/stderr.
With that we can easily extract debug, info, warning or error messages.

Unhandled Exception for non-whitelisted error.

Traceback (most recent call last):
  File "/opt/simp_le/bin/simp_le", line 9, in <module>
    load_entry_point('simp-le==0.0.0', 'console_scripts', 'simp_le')()
  File "/root/src/simp_le/simp_le.py", line 845, in main
    _main(cli_args)
  File "/root/src/simp_le/simp_le.py", line 839, in _main
    _new_data(args)
  File "/root/src/simp_le/simp_le.py", line 779, in _new_data
    for vhost in args.vhosts
  File "/root/src/simp_le/simp_le.py", line 779, in <genexpr>
    for vhost in args.vhosts
  File "/root/src/simp_le/venv/lib/python2.7/site-packages/acme/client.py", line 215, in request_domain_challenges
    typ=messages.IDENTIFIER_FQDN, value=domain), new_authz_uri)
  File "/root/src/simp_le/venv/lib/python2.7/site-packages/acme/client.py", line 195, in request_challenges
    response = self.net.post(new_authzr_uri, new_authz)
  File "/root/src/simp_le/venv/lib/python2.7/site-packages/acme/client.py", line 628, in post
    return self._check_response(response, content_type=content_type)
  File "/root/src/simp_le/venv/lib/python2.7/site-packages/acme/client.py", line 544, in _check_response
    raise messages.Error.from_json(jobj)
acme.messages.Error: unauthorized :: The client lacks sufficient authorization :: Error creating new authz :: Name is not whitelisted

Please upload package to PyPI

Installing from pypi can be simpler and more user friendly than cloning and running some scripts.

fullchain.pem does not contain the full certificate chain

The fullchain.pem file seems to only contain the /O=Digital Signature Trust Co./CN=DST Root CA X3 besides the actual cert.

AttributeError: 'X509' object has no attribute '_req'

After running bootstrap and venv.sh:

blog$~/cert/simp_le>./simp_le.py --email [email protected] -f key.pem -f cert.pem -f chain.pem -f account_key.json -d x.x --default_root /usr/share/wordpress
Traceback (most recent call last):
  File "./simp_le.py", line 1390, in main
    return main_with_exceptions(cli_args)
  File "./simp_le.py", line 1370, in main_with_exceptions
    if valid_existing_cert(existing_data.cert, args.vhosts, args.valid_min):
  File "./simp_le.py", line 1193, in valid_existing_cert
    existing_sans = pyopenssl_cert_or_req_san(cert)
  File "./simp_le.py", line 1161, in pyopenssl_cert_or_req_san
    return crypto_util._pyopenssl_cert_or_req_san(cert)
  File "/usr/lib/python2.7/dist-packages/acme/crypto_util.py", line 178, in _pyopenssl_cert_or_req_san
    text = func(OpenSSL.crypto.FILETYPE_TEXT, cert_or_req).decode("utf-8")
  File "/usr/lib/python2.7/dist-packages/OpenSSL/crypto.py", line 2346, in dump_certificate_request
    result_code = _lib.X509_REQ_print_ex(bio, req._req, 0, 0)
  File "/usr/lib/python2.7/dist-packages/acme/jose/util.py", line 42, in __getattr__
    return getattr(self.wrapped, name)
AttributeError: 'X509' object has no attribute '_req'

Unhandled error has happened, traceback is above

These are the package versions reported of I run bootstrap again:

ca-certificates is already the newest version (20160104).
gcc is already the newest version (4:5.3.1-1).
libffi-dev is already the newest version (3.2.1-4).
libssl-dev is already the newest version (1.0.2f-2).
python is already the newest version (2.7.11-1).
python-dev is already the newest version (2.7.11-1).
virtualenv is already the newest version (1.11.6+ds-1).

Use --email in README

--email, although not essential, should be specified by all users - I wouldn't anyone to get bitten by not specifying the contact channel (that is used for renewal reminders and some methods of revocation)

Support for SSL vhost verification

I don't know if letsencrypt supports this, but could simp_le allow the verification url (/.well-known/acme-challenge/STRING) to be hosted on an SSL server?

I have only one vhost running, it's using an existing SSL cert, and I want to replace it with letsencrypt.

At the present time I have to setup an additional vhost without SSL running on port 80 just to do the verification part. I don't think any security would be lost by allowing the verification to occur over SSL.

Virtualenv activate is bash specfic; fix shebang of venv.sh?

Hi,

just had a look at venv.sh, and it currently starts with: #!/bin/sh. That should probably be either: #!/usr/bin/env bash, or possibly #!/bin/bash. As can be seen in the top of the activate-script virtualenv generates: # This file must be used with "source bin/activate" *from bash*.

This means the loop at: https://github.com/kuba/simp_le/blob/master/venv.sh#L5 might not invoke the venv pip, but rather the system pip, if /bin/sh isn't bash.

If I'm not mistaken, it will generally work (better) to not source the activate-script, and rather call the venv-pip directly, like so: ./venv/bin/pip install -U "${pkg?}". That should work on most shells, as far as I know.

As I've not really played with this package, I haven't prepared a pull request -- perhaps the authors are better informed than me. But I've managed to "trick" myself in a similar fashion setting up venvs from dash (default /bin/sh on Debian) before.

simp_le support cli.ini file like operation ?

I am looking at simp_le as an alternative to official letsencrypt clients webroot authentication for use on low memory VPS systems 128MB to 768MB based in light of certbot/certbot#1081

Question is whether simpl_le supports a cli.ini type approach ?

Or better yet does it direct support official letsencrypt clients cli.ini set parameters ? Or is it essentially via full command line ?

cheers

George

Unnecessarily overwrites plugin files even if content didn't change

PollError traceback

When running this on the server:

env/bin/simp_le -f fullchain.pem -f key.pem \
                -d nsupdate.info -d www.nsupdate.info -d ipv4.nsupdate.info -d ipv6.nsupdate.info \
                --default_root /my/htdocs \
                --cert_key_size 2048 --email my@email

I get that:

2015-12-04 12:41:57,641:INFO:simp_le:157: Creating new account key
2015-12-04 12:41:59,567:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-04 12:41:59,956:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-04 12:42:00,162:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-04 12:42:00,387:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): letsencrypt.org
2015-12-04 12:42:02,743:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-04 12:42:04,992:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-04 12:42:06,244:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-04 12:42:08,494:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-04 12:42:10,752:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-04 12:42:11,994:INFO:requests.packages.urllib3.connectionpool:207: Starting new HTTP connection (1): httprelay.int.thinkmo.de
2015-12-04 12:42:11,996:WARNING:simp_le:801: ipv6.nsupdate.info was not successfully verified by the client. CA is likely to fail as well!
2015-12-04 12:42:12,009:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-04 12:42:14,247:INFO:requests.packages.urllib3.connectionpool:207: Starting new HTTP connection (1): httprelay.int.thinkmo.de
2015-12-04 12:42:14,248:WARNING:simp_le:801: nsupdate.info was not successfully verified by the client. CA is likely to fail as well!
2015-12-04 12:42:14,261:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-04 12:42:16,500:INFO:requests.packages.urllib3.connectionpool:207: Starting new HTTP connection (1): httprelay.int.thinkmo.de
2015-12-04 12:42:16,502:WARNING:simp_le:801: www.nsupdate.info was not successfully verified by the client. CA is likely to fail as well!
2015-12-04 12:42:16,514:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-04 12:42:18,760:INFO:requests.packages.urllib3.connectionpool:207: Starting new HTTP connection (1): httprelay.int.thinkmo.de
2015-12-04 12:42:18,762:WARNING:simp_le:801: ipv4.nsupdate.info was not successfully verified by the client. CA is likely to fail as well!
2015-12-04 12:42:18,774:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-04 12:42:20,015:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-04 12:42:22,231:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-04 12:42:24,436:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-04 12:42:26,645:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Traceback (most recent call last):
  File "env/bin/simp_le", line 9, in <module>
    load_entry_point('simp-le==0.0.0', 'console_scripts', 'simp_le')()
  File "/srv/nsupdate.info/simp_le/simp_le/simp_le.py", line 874, in main
    raise SystemExit(_main(cli_args))
  File "/srv/nsupdate.info/simp_le/simp_le/simp_le.py", line 867, in _main
    _new_data(args)
  File "/srv/nsupdate.info/simp_le/simp_le/simp_le.py", line 812, in _new_data
    max_attempts=(10 * len(authorizations)))
  File "/srv/nsupdate.info/simp_le/env/local/lib/python2.7/site-packages/acme/client.py", line 383, in poll_and_request_issuance
    raise errors.PollError(waiting, updated)
acme.errors.PollError

So, it says "not successfully verified" some times, but not WHY.

Also, the PollError, should it be catched and a good error msg be given?

The web server is behind a https reverse proxy, could that be a problem?

Recommended configuration for apache is now to have the full chain in the cert file

In the "examples" page (https://github.com/kuba/simp_le/wiki/Examples) you write that for apache we need to use the 3 files with 3 different directives.

But since Apache 2.4.8 (source: http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatefile) this is not longer recommended anymore and we can simply concatenate the full chain into the leaf certificate. March 2014 is when this was released first (in 2.4.9).

PollError

Tried to get a new cert, got the following error:

2015-12-15 21:57:55,264:INFO:simp_le:159: Creating new account key
2015-12-15 21:57:55,726:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-15 21:57:55,997:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-15 21:57:56,259:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-15 21:57:56,529:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): letsencrypt.org
2015-12-15 21:57:57,643:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-15 21:57:57,905:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-15 21:57:58,176:INFO:requests.packages.urllib3.connectionpool:207: Starting new HTTP connection (1): <domain>
2015-12-15 21:57:58,204:INFO:simp_le:805: <domain> was successfully verified by the client
2015-12-15 21:57:58,213:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2015-12-15 21:57:58,990:INFO:requests.packages.urllib3.connectionpool:756: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Unhandled error has happened:
Traceback (most recent call last):
  File "/opt/simp_le/simp_le.py", line 877, in main
    raise SystemExit(_main(cli_args))
  File "/opt/simp_le/simp_le.py", line 869, in _main
    _new_data(args)
  File "/opt/simp_le/simp_le.py", line 814, in _new_data
    max_attempts=(10 * len(authorizations)))
  File "/opt/simp_le/venv/local/lib/python2.7/site-packages/acme/client.py", line 383, in poll_and_request_issuance
    raise errors.PollError(waiting, updated)
PollError

Installed simp_le a few days ago and never had an issue with it

Allow reuse of cert key (HPKP)

--reuse_key?

without privilege escalation ?

Owner of ${webroot?}/.well-known/acme-challenge must be able to run the script, without privilege escalation (sudo, root, etc.)

does that mean simp_le can't be run as root user ? as my integration script/wrapper with webroot is run as root user

Cleanup webroot

I am using the following script to generate certificates and noticed the /tmp/letsencrypt dir contents are left intact even after ssl generation. Should I be deleting these after generation?

DOMAIN=domain.com;
sudo mkdir /etc/nginx/ssl/${DOMAIN};
sudo chmod 700 /etc/nginx/ssl/${DOMAIN};
cd /etc/nginx/ssl/${DOMAIN};
simp_le -d ${DOMAIN}:/tmp/letsencrypt -f key.pem -f cert.pem -f fullchain.pem
sudo chmod -R 400 /etc/nginx/ssl/${DOMAIN}/*;

Drop \n\n as required separator for (full)chain certs

This causes some troubles, e.g. when importing data from the official client. For more context see #40

Travis builds fail due to missing Boulder RabbitMQ setup

See certbot/certbot#1640

Travis tests

Debian packaging

For more context (and preferred solution) see #68 (comment).

New account key is not preserved on failure

When an account key is created, but the authorization failed (because the HTTP server is not reachable for example), the account key key is not stored. It should probably persist this key even if it failed to generate a certificate.

Edit: what about allowing simp_le to generate just the account key and nothing else? I.e. allow simp_le.py -f account_key.json to generate the account key. Then a wrapper script can ensure that this file is available and store it appropriately.

Identifier Validation Challenges via TLS

Is it possible to use TLS (port 443, or any other custom protocol/port) for the challenge part?

--version and --help should exit with 0 instead of 2

When an external wrapper wants to check whether the environment is sane, it can use simp_le.py --version or --help to check for sanity (whether all required Python modules are installed).

At the moment it returns 2 though. What about making it behave like the --test option and exit with 0 instead? These options are explicitly requested, it is not like any confusion could arise.

Travis green despite errors

https://travis-ci.org/kuba/simp_le/jobs/95201523

Global evaluation
-----------------
Your code has been rated at 9.96/10
ERROR: InvocationError: '/home/travis/build/kuba/simp_le/.tox/lint/bin/pylint --disable=locally-disabled,fixme simp_le'
___________________________________ summary ____________________________________
ERROR:   lint: commands failed
The command ". ./tests/travis.sh script" exited with 0.
Done. Your build exited with 0.

Allow "extending" of a certificate to add new domains.

I tried to add another vhost to an existing certificate and got the following error;

Traceback (most recent call last):
  File "/home/letsencrypt/simp_le/venv/bin/simp_le", line 9, in <module>
    load_entry_point('simp-le', 'console_scripts', 'simp_le')()
  File "/home/letsencrypt/simp_le/simp_le.py", line 871, in main
    raise SystemExit(_main(cli_args))
  File "/home/letsencrypt/simp_le/simp_le.py", line 859, in _main
    if _valid_existing_data(args.ioplugins, args.vhosts, args.valid_min):
  File "/home/letsencrypt/simp_le/simp_le.py", line 746, in _valid_existing_data
    assert set(existing_sans) == set(vhost.name for vhost in vhosts)
AssertionError

Following patch seems to make things work okay;

diff --git a/simp_le.py b/simp_le.py
index c827b16..a9c7bab 100755
--- a/simp_le.py
+++ b/simp_le.py
@@ -741,9 +741,12 @@ def _valid_existing_data(ioplugins, vhosts, valid_min):
     if existing != IOPlugin.EMPTY_DATA:
         # pylint: disable=protected-access
         existing_sans = crypto_util._pyopenssl_cert_or_req_san(existing.cert)
+        requested_sans = set(vhost.name for vhost in vhosts)
         logger.debug('Existing SANs: %r', existing_sans)

-        assert set(existing_sans) == set(vhost.name for vhost in vhosts)
+        if set(existing_sans) != requested_sans:
+            logger.debug('New SANs: %r', requested_sans)
+            return False

         # Renew?
         if not renewal_necessary(existing.cert, valid_min):

Allow to enforce the renewal of certificates

I was wondering if it would be possible to enable forced certificate renewal in simp_le.
Some parameter like --renew maybe?

--vhost option doesn't appear to be a valid argument

If you run the simp_le command without any arguments you get;

2015-12-04 02:08:30,059:ERROR:simp_le:873: You must set at least one -d/--vhost

--vhost isn't mentioned in --help at all and doesn't appear to be a valid command line argument, only -d seems to work?

kuba / simp_le Goto Github PK

simp_le's People

Contributors

Stargazers

Watchers

Forkers

simp_le's Issues

Recommend Projects

Recommend Topics

Recommend Org