Giter Club home page Giter Club logo

dokku-letsencrypt's Introduction

dokku-letsencrypt

dokku-letsencrypt is the official plugin for dokku that gives the ability to automatically retrieve and install TLS certificates from letsencrypt.org. During ACME validation, your app will stay available at any time.

By running this plugin, you agree to the Let's Encrypt Subscriber Agreement automatically (because prompting you whether you agree might break running the plugin as part of a cronjob).

If you like Let's Encrypt, please consider donating to Let's Encrypt.

Installation

sudo dokku plugin:install https://github.com/dokku/dokku-letsencrypt.git

Upgrading from previous versions

sudo dokku plugin:update letsencrypt

Commands

$ dokku letsencrypt:help
    letsencrypt:active <app>                Verify if letsencrypt is active for an app
    letsencrypt:auto-renew                  Auto-renew all apps secured by letsencrypt if renewal is necessary
    letsencrypt:auto-renew <app>            Auto-renew app if renewal is necessary
    letsencrypt:cleanup <app>               Cleanup stale certificates and configurations
    letsencrypt:cron-job <--add|--remove>   Add or remove an auto-renewal cronjob
    letsencrypt:disable <app>               Disable letsencrypt for an app
    letsencrypt:enable <app>                Enable or renew letsencrypt for an app
    letsencrypt:list                        List letsencrypt-secured apps with certificate expiry
    letsencrypt:revoke <app>                Revoke letsencrypt certificate for app

Usage

If using this plugin with Cloudflare:

  • The domain dns should be setup in "Proxied" mode
  • SSL/TLS mode must be in "Full" mode
    • Using letsencrypt in "Flexible" mode will cause Cloudflare to detect your server as down
    • Using "Full" mode will require disabling SSL/TLS in cloudflare in order to renew the certificate.

If using "Flexible" SSL/TLS mode, avoid using this plugin.

See these two links for more details:

The app which is obtaining a letsencrypt certificate must already be deployed and accessible over the internet (i.e. in the browser) in order to add letsencrypt to your app. This plugin will fail to apply for an app that has otherwise only been created.

Obtain a Let's encrypt TLS certificate for app myapp (you can also run this command to renew the certificate):

$ dokku letsencrypt:set myapp email [email protected]
-----> Setting email to [email protected]
$ dokku letsencrypt:enable myapp
=====> Let's Encrypt myapp...
-----> Updating letsencrypt docker image...
latest: Pulling from dokku/letsencrypt

Digest: sha256:20f2a619795c1a3252db6508f77d6d3648ad5b336e67caaf801126367dbdfa22
Status: Image is up to date for dokku/letsencrypt:latest
       done
-----> Enabling letsencrypt proxy for myapp...
-----> Getting letsencrypt certificate for myapp...
        - Domain 'myapp.mydomain.com'

[ removed various log messages for brevity ]

-----> Certificate retrieved successfully.
-----> Symlinking let's encrypt certificates
-----> Configuring SSL for myapp.mydomain.com...(using /var/lib/dokku/plugins/available/nginx-vhosts/templates/nginx.ssl.conf.template)
-----> Creating https nginx.conf
-----> Running nginx-pre-reload
       Reloading nginx
-----> Disabling letsencrypt proxy for myapp...
       done

Once the certificate is installed, you can use the certs:* built-in commands to edit and query your certificate.

You could also use the following command to set an email address for global. So you don't need to type the email address for different application.

dokku letsencrypt:set --global email [email protected]

Automatic certificate renewal

To enable the automatic renewal of certificates, a cronjob needs to be defined for the dokku user which will run daily and renew any certificates that are due to be renewed.

This can be done using the following command:

dokku letsencrypt:cron-job --add

Configuration

dokku-letsencrypt uses the Dokku environment variable manager for all configuration. The important environment variables are:

Variable Default Description
dns-provider (none) The name of a valid lego dns-provider
email (none) REQUIRED: E-mail address to use for registering with Let's Encrypt.
graceperiod 2592000 (30 days) Time in seconds left on a certificate before it should get renewed
lego-docker-args (none) Extra arguments to pass via docker run. See the lego CLI documentation for available options.
server default Which ACME server to use. Can be 'default', 'staging' or a URL

You can set a setting using dokku letsencrypt:set $APP $SETTING_NAME $SETTING_VALUE. When looking for a setting, the plugin will first look if it was defined for the current app and fall back to settings defined by --global.

Note: See "DNS-01 Challenge" for more information on configuration a dns-provider for DNS-01 based challenges and wildcard support.

Redirecting from HTTP to HTTPS

Dokku's default nginx template will automatically redirect HTTP requests to HTTPS when a certificate is present.

You can customize the nginx template if you want different behaviour.

Design

dokku-letsencrypt gets around having to disable your web server using the following workflow:

  1. Temporarily add a reverse proxy for the /.well-known/ path of your app to https://127.0.0.1:$ACMEPORT
  2. Run the acme/lego Let's Encrypt client in a Docker container binding to $ACMEPORT to complete the ACME challenge and retrieve the TLS certificates
  3. Install the TLS certificates
  4. Remove the reverse proxy and reload nginx

For a more in-depth explanation, see this blog post

Dockerfile and Image-based Deploys

When securing Dockerfile and Image-based deploys with dokku-letsencrypt, be aware of the proxy mechanism for dokku 0.6+.

For Dockerfile deploys - as well as those via git:from-image - Dokku will determine which ports a container exposes and proxies all those exposed ports in the Docker container by listening on the same port numbers on the host. This means that both the proxies for HTTP port 80 and HTTPS port 443 to the app's container need to be manually configured using the dokku proxy:ports-* commands in order for certificate validation and browsing to the app via HTTPS to work.

A full workflow for creating a new Dockerfile/Image-based deployment (where the app is listening on port 5555) with dokku-letsencrypt would be:

  1. Create a new app myapp in dokku and push to the [email protected] remote. This guide assumes that the Docker container will be listening for connections on port 5555 so replace container port numbers accordingly if necessary.
  2. On the dokku host, use dokku ports:add myapp http:80:5555 to proxy HTTP port 80 to port 5555 on the Docker image
  3. On the dokku host, use dokku letsencrypt:enable myapp to retrieve HTTPS certificates.
  4. On the dokku host, use dokku ports:add myapp https:443:5555 to proxy HTTPS port 443 to port 5555 on the Docker image
  5. (optional) On the dokku host, use dokku ports:remove myapp http:5555:5555 to remove a potential leftover proxy that was automatically configured on first deploy.

After these steps, the output of dokku ports:list myapp should look like this:

-----> Port mappings for myapp
-----> scheme             host port                 container port
https                     443                       5555

Replace the container port (5555 in the above example) with the port your app is listening on.

Note: Step 2 and step 4 cannot be joined together since a configured HTTPS proxy will include a ssl_certificate line in the app's nginx config that will cause nginx config validation to fail because no valid HTTPS certificate is available until step 3 is completed.

Dealing with rate limit

Be aware that Let's Encrypt is subject to rate limiting. The limit about the number of certificates you can add on a domain per week is a concern for dokku because of the default domain added to your new applications, named like <app>.<dokku-domain>: using dokku-letsencrypt on all your applications would create a certificate for each application subdomain on <dokku-domain>.

As a workaround, if you want to encrypt many applications, make sure to add a proper domain for each one and remove their default domain before running dokku-letsencrypt. For example, if your dokku domain is dokku.example.com and you want to encrypt your foo app:

dokku domains:add foo foo.com
dokku domains:remove foo foo.dokku.example.com
dokku letsencrypt:enable foo

While playing around with this plugin, you might want to switch to the let's encrypt staging server by running dokku letsencrypt:set myapp server staging to enjoy much higher rate limits and switching back to the real server by running dokku letsencrypt:set myapp server once you are ready.

Generating a Cert for multiple domains

Your default dokku app is accessible under the root domain too. So if you have an application 00-default that is running under 00-default.mydomain.com it is accessible under mydomain.com too. Now if you enable letsencrypt for your 00-default application, it is not accessible anymore on mydomain.com. You can add the root domain to your dokku domains by typing:

dokku domains:add 00-default mydomain.com
dokku letsencrypt:enable 00-default

DNS-01 Challenge

Functionality sponsored by Orca Scan Ltd.

In order to provide a Letsencrypt certificate for a wildcard domain, a DNS-01 challenge must be used. To configure, the dns-provider property must be set to a supported Lego provider. Additionally, the environment variables used by the DNS provider must be set as letsencrypt properties with the prefix dns-provider-. Both global and app-specific properties are supported.

Warning: Before using a DNS-based challenge, ensure all DNS records - including wildcard records - are pointing at your server.

# set the provider to namecheap
dokku letsencrypt:set --global dns-provider namecheap

# set the properties necessary for namecheap usage
dokku letsencrypt:set --global dns-provider-NAMECHEAP_API_USER user
dokku letsencrypt:set --global dns-provider-NAMECHEAP_API_KEY key

Due to limitations in how certain DNS providers work, environment variables must not use the _FILE based method for referring to values in files.

Please see the Lego documentation for your DNS provider for more information on what configuration is necessary to utilize DNS-01 challenges.

Conditional enabling

dokku letsencrypt:enable <app> enables letsencrypt for an application or renews the certificate. This may lead to hitting rate limits with letsencrypt.

To avoid renewals, for example in a continuous deployment scenario, you could first check if letsencrypt has already been enabled for the app:

dokku letsencrypt:active <app> || dokku letsencrypt:enable <app>

License

This plugin is released under the MIT license. See the file LICENSE.

dokku-letsencrypt's People

Contributors

256dpi avatar adam12 avatar alecgorge avatar alexanderbabel avatar billialpha avatar blopker avatar bobwhitelock avatar boredland avatar cellane avatar chiedo avatar chilts avatar dean1012 avatar ebeigarts avatar eymaddis avatar febeling avatar fruitl00p avatar henrik avatar jameysharp avatar jdugan1024 avatar jimmy0017 avatar johnfraney avatar josegonzalez avatar joshmanders avatar michaelsp avatar mlebkowski avatar morrisjobke avatar oelmekki avatar sseemayer avatar timaschew avatar yggdrasil avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

dokku-letsencrypt's Issues

Documentation: upgrade compatibilities

In response of all the great work you're doing for the new dokku 0.5 refactoring...

Just a quick question regarding the new dokku 0.5+ / dokku-letsencrypt compatibility matrix. Currently its not mentioned anywhere (neither your plugin nor dokku itself) on how to handle / check dokku compatibility with plugins... Without doing the ol' fingers-crossed-and-lets-see-what-it-does-in-production: dokku plugin:update Are you aware of any compatibility issues for dokku-letsencrypt with older dokku versions?

If not, it might be worthwhile to mention this in the upgrading-section of the readme

Thanks!

One certificate per domain in app

Hi!

First of, nice work on this plugin. Works beautifully!

As I understand it, the current solution is to create one certificate for all domains in an app. Are there any plans on supporting the creation of one certificate per domain in an app? This would be really helpful in some cases.

Thanks!

Cannot get certificate: You must set at least one -d/--vhost

First, great job and great blog post, seems very useful.

I am trying to setup SSL with custom domain dokku running with vhost.
The app works, I can ping it at name.apps-my-domain.com.
I installed both the latest dokku-letsencrypt and tag 0.7.0 and for both got the following

root@dokku:~# dokku letsencrypt hello
=====> Let's Encrypt hello...
-----> Updating letsencrypt docker image...
latest: Pulling from m3adow/letsencrypt-simp_le
420890c9e918: Already exists 
acbaf1e6012f: Already exists 
5f71a1a2d3dc: Already exists 
Status: Image is up to date for m3adow/letsencrypt-simp_le:latest
       done
-----> Enabling ACME proxy for hello...
-----> Getting letsencrypt certificate for hello...
darkhttpd/1.11, copyright (c) 2003-2015 Emil Mikulic.
listening on: http://0.0.0.0:80/
You must set at least one -d/--vhost

Debugging tips: -v improves output verbosity. Help is available under --help.
-----> Certificate retrieval failed!
-----> Disabling ACME proxy for hello...
       done

Running dokku 0.4.14

letsencrypt not updating nginx config

I have just updated dokku from 0.4 to 0.5.6 and updated the letsencrypt plugin. When I run letsencrypt on a new site I have pushed to my dokku box, it claims to finish successfully, but it cannot be accessed via https, I just get 502 Bad Gateway nginx.

I have looked at the nginx.conf file for the new site, and it has nothing in it regarding ssl certs. The other sites that I had already been running are working fine over SSL, and letsencrypt auto-renew worked fine for them (one of the sites was about to expire).

Here is the output from running dokku letsencrypt:

=====> Let's Encrypt www.example.com
-----> Updating letsencrypt docker image...
latest: Pulling from dokkupaas/letsencrypt-simp_le

420890c9e918: Already exists
e4a2ae244258: Already exists
5c6ac6d1c950: Already exists
Digest: sha256:18a19b34beceba79dd5be458abe7e132fc7486da1da19cc4d0395ad4578031ef
Status: Image is up to date for dokkupaas/letsencrypt-simp_le:latest
       done updating
-----> Enabling ACME proxy for www.example.com...
-----> Getting letsencrypt certificate for www.example.com...
        - Domain 'www.example.com'
darkhttpd/1.11, copyright (c) 2003-2015 Emil Mikulic.
listening on: http://0.0.0.0:80/
2016-05-15 19:22:37,824:INFO:requests.packages.urllib3.connectionpool:758: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2016-05-15 19:22:38,063:INFO:requests.packages.urllib3.connectionpool:758: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2016-05-15 19:22:38,305:INFO:requests.packages.urllib3.connectionpool:758: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2016-05-15 19:22:38,564:INFO:requests.packages.urllib3.connectionpool:758: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2016-05-15 19:22:38,924:INFO:requests.packages.urllib3.connectionpool:207: Starting new HTTP connection (1): www.example.com
2016-05-15 19:22:38,975:INFO:__main__:1305: www.example.com was successfully self-verified
2016-05-15 19:22:38,992:INFO:requests.packages.urllib3.connectionpool:758: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2016-05-15 19:22:39,251:INFO:__main__:1313: Generating new certificate private key
2016-05-15 19:22:40,083:INFO:requests.packages.urllib3.connectionpool:758: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2016-05-15 19:22:40,345:INFO:requests.packages.urllib3.connectionpool:758: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2016-05-15 19:22:40,652:INFO:requests.packages.urllib3.connectionpool:758: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2016-05-15 19:22:40,911:INFO:__main__:391: Saving fullchain.pem
2016-05-15 19:22:40,912:INFO:__main__:391: Saving chain.pem
2016-05-15 19:22:40,913:INFO:__main__:391: Saving cert.pem
2016-05-15 19:22:40,913:INFO:__main__:391: Saving key.pem
-----> Certificate retrieved successfully.
-----> Symlinking let's encrypt certificates
-----> Configuring www.example.com...(using built-in template)
-----> Creating https nginx.conf
-----> Running nginx-pre-reload
       Reloading nginx
-----> Disabling ACME proxy for www.example.com...
       done

I gather from reading other issues here that there have been some problems recently with changes to dokku, but I haven't been able to find anything that would help me solve this problem. Is this a bug, or am I doing something wrong?

Edit: running dokku domains appname returns www.example.com, running dokku urls appname returns https://www.example.com.

[Discussion] API

Hey! First off, congratulations on becoming an official Dokku plugin. I think this plugin really is the 'killer app' for Dokku, nice work.

Anyway, I came by to see how things are going since my last PR and I think the API could be cleaned up a little. These ideas will be breaking changes, but I hope to make the plugin easier to use and easier to add features later. Feel free to say 'no'. ๐Ÿ˜„

The first issue I noticed is user on-boarding got more complicated. Right now the minimum a new user has to do is:

sudo dokku plugin:install https://github.com/dokku/dokku-letsencrypt.git
sudo dokku letsencrypt:email <app> <e-mail>
sudo dokku letsencrypt <app>

Ideally all a user should have to do is:

sudo dokku plugin:install https://github.com/dokku/dokku-letsencrypt.git
sudo dokku letsencrypt <app>

This can be easily done because letsencrypt (and simp_le) lets you get new certs without an email address. See https://github.com/kuba/simp_le/blob/master/simp_le.py#L1233

Although it's recommended to add an email it raises the barrier for entry. I think the main appeal of this plugin is taking something that used to be massively complicated and turn it in to a one-liner.

Second issue I noticed is people are asking for more configuration options. This isn't a bad thing (shows popularity!), but the plugin will need a way to add more options in the future without increasing complexity.

I propose the API is reduced to:

$ dokku help
    letsencrypt <app>                 Enable or renew letsencrypt certificate for app
    letsencrypt:revoke <app>          Revoke letsencrypt certificate for app
    letsencrypt:info <app>            Print letsencrypt info about <app>

And use environment variables to add configuration options. The email setting workflow would go from:

sudo dokku letsencrypt:email <app> <e-mail>
sudo dokku letsencrypt <app>

To:

sudo LE_EMAIL=<e-mail> dokku letsencrypt <app>

On second run config can be read from the app so to renewing is just: letsencrypt <app>.

The main advantage is this will scale when more options are requested, like setting the ACME server:

sudo LE_EMAIL=<e-mail> LE_SERVER=staging dokku letsencrypt <app>

The list of commands wont need new set/get methods for every option. The letsencrypt:info command will be the universal get command.

The other advantage of this approach is people can set up their environment globally once for all apps.

Thoughts?

If the certificate is revoked, $APP_ROOT/letsencrypt needs to be removed manually

As requested in #19 - getting the following errors after having manually revoked my certificates:

6-04-11 09:04:12,559:INFO:requests.packages.urllib3.connectionpool:758: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2016-04-11 09:04:13,007:INFO:requests.packages.urllib3.connectionpool:758: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2016-04-11 09:04:13,339:INFO:requests.packages.urllib3.connectionpool:758: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2016-04-11 09:04:13,607:INFO:requests.packages.urllib3.connectionpool:758: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2016-04-11 09:04:13,957:INFO:requests.packages.urllib3.connectionpool:207: Starting new HTTP connection (1): my.app.url
2016-04-11 09:04:13,966:WARNING:__main__:1292: my.app.url was not successfully self-verified. CA is likely to fail as well!
2016-04-11 09:04:13,986:INFO:requests.packages.urllib3.connectionpool:758: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2016-04-11 09:04:14,246:INFO:__main__:1302: Generating new certificate private key
2016-04-11 09:04:16,148:INFO:requests.packages.urllib3.connectionpool:758: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2016-04-11 09:04:16,391:ERROR:__main__:1260: CA marked some of the authorizations as invalid, which likely means it could not access http://example.com/.well-known/acme-challenge/X. Did you set correct path in -d example.com:path or --default_root? Is there a warning log entry about unsuccessful self-verification? Are all your domains accessible from the internet? Failing authorizations: https://acme-v01.api.letsencrypt.org/acme/authz/g6pR4I21X1sUOpBnIAmZotZdGpVTP5882BX-v_L3q7w
Challenge validation has failed, see error log.

Full dokku trace (URLs & email changed):
https://gist.github.com/haywirez/726f8f916cfd33beea42191fa8968aca

letsencrypt fails with "PythonDialogBug" error

Greetings! First let me say thank you for this excellent plugin. It worked perfectly for me the first time I tried it, but I redeployed my dokku server with ansible and now I can't seem to letsencrypt anything at all.

Googling the error message shows some hits in the letsencrypt issues queue from back in October, but they're all closed and none of them seem to apply to me, because it doesn't seem to be writing any logs when invoked from within dokku.

Here's the error:
An unexpected error occurred:
PythonDialogBug
Please see the logfiles in /var/log/letsencrypt for more details.

Of course there is no letsencrypt log anywhere on the system (dokku doesn't write to the real /var/log, obviously, so I would expect there to be a var/log/ in the ~dokku/.letsencrypt directory, but it doesn't exist. I tried creating a 'log' directory in the 'var' directory that does exist, but that didn't work either. It's really hard to troubleshoot what is going on here exactly without being able to see any error logs.

Any suggestions? I wouldn't ever assume that a recent change to the plugin could have caused this, but it did work fine on Monday this week (with a different subdomain; when I re-deployed I also changed my subdomain from *.docker.example.com to *.apps.example.com (example.com as placeholder; I did actually use a working/resolving subdomain with appropriate wildcard dns.))

I tried changing my TERM to various things, thinking perhaps python was having issues opening a dialog as it did Monday the first time I ran it to prompt me for my email address. At first I thought it didn't like 'xterm' so I changed it to 'vt100' and then I remembered on Monday I was probably running in screen, so I ran screen and verified that my TERM was set to 'screen'. I think I've done as much troubleshooting as is possible without access to an actual verbose log file.

Thanks in advance for your time.

edit to include various random possibly-useful info:
system OS: Ubuntu 14.04.2 x64, fully updated
dokku version: 0.4.7
docker version: 1.9.1

I'm happy to provide any additional information, if needed!

further edit: I guess the logs end up in the docker container that gets created/destroyed, so I really don't have a good idea of what to do next.

Certificates for redirect domains

I'm using dokku redirect plugin (https://github.com/dokku/dokku-redirect). Redirect domain names should be added to certificate for correct https redirects (for example, https://www.example.net to https://example.com). Plugin stores domains in the $APP/REDIRECTS file.

Workaround:

  1. add redirect domains using "dokku domains:add"
  2. issue certificate ("dokku letsencrypt")
  3. remove redirect domains to fix nginx config ("dokku domains:clear")
  4. add non-redirect domains using "dokku domains:add" (if you need more than 1)

Setting up HTTP/2

Heya,

I'm trying to experiment with HTTP/2, and Dokku seems like a good path to work down, but I have a question about setting this up.

The nginx template that comes with this plugin looks to add in a custom location section, though from my tinkering around locally I have some further configurations in the server block like this:

server {
    listen                     443 ssl http2;
    server_name                localhost;

    ssl                        on;
    ssl_protocols              TLSv1 TLSv1.1 TLSv1.2;
    ssl_certificate            cert.pem;
    ssl_certificate_key        cert.key;

    location / {
        proxy_pass          http://localhost:8080;
        proxy_set_header    Host      $host;
        proxy_set_header    X-Real-IP $remote_addr;
        proxy_set_header    X-HTTPS   'True';
    }
}

I feel like I don't really understand this is being set up in the end, so I could be overthinking this or underthinking it.... but any help with this would be really appreciated!

Thanks for the cool software.

What configurations are currently working?

After the dokku 0.5 upgrade debacle, It would be helpful to know what is currently working from a broad user base both for troubleshooting and for having a list of known-good configurations to make upgrading less scary/surprising. Please let me know the following:

  • Your current dokku version and dokku-letsencrypt commit hash (go to /var/lib/dokku/plugins/available/letsencrypt and run git rev-parse HEAD)
  • Your operating system + version (cat /etc/isue)
  • What are you deploying?
  • Is letsencrypt myapp working?
  • Is letsencrypt:ls working?
  • Is letsencrypt:auto-renew working?

Support dokku backup

Add hooks for the backup-export and backup-import triggers so that let's encrypt certificates and keys are backed up.

Can I use this with AWS CloudFront?

Could I somehow set this up so it will upload the new certs on Amazon CloudFront automatically each time they are renewed? I ask this because I'm running my dokku on an AWS EC2 instance, and would like to add CDN to supercharge my website speeds.

Making this an official plugin

@sseemayer this plugin is super legit and I'd like to make it official, similar to how we handle the datastores etc.

Up to you, but would you be open to moving it into the dokku org? You obviously still get full admin access to the plugin :)

Can't revoke certificate on app

I was trying to revoke a certificate that I installed a few minutes earlier. The revoke process fails, app still redirects to https. When I try to revoke again, I get no existing certificate. Here is the full console log:

admin@host:~$ dokku letsencrypt:revoke ob-app-prod
=====> Revoke Let's Encrypt certificate from ob-app-prod...
-----> Updating letsencrypt docker image...
latest: Pulling from dokkupaas/letsencrypt-simp_le
420890c9e918: Already exists 
e4a2ae244258: Already exists 
5c6ac6d1c950: Already exists 
Digest: sha256:18a19b34beceba79dd5be458abe7e132fc7486da1da19cc4d0395ad4578031ef
Status: Image is up to date for dokkupaas/letsencrypt-simp_le:latest
       done updating
-----> Revoking letsencrypt certificate for ob-app-prod...
        - Domain 'app.mydomain.ch'
darkhttpd/1.11, copyright (c) 2003-2015 Emil Mikulic.
listening on: http://0.0.0.0:80/
No existing certificate

Debugging tips: -v improves output verbosity. Help is available under --help.
-----> Certificate revocation failed (code 2)!
       done

After that, the letsencrypt:ls shows:

admin@host:~$ dokku letsencrypt:ls
-----> App name           Certificate Expiry        Time before expiry        Time before renewal      
ob-app-prod               2016-08-21 17:51:00       89d, 8h, 10s              59d, 8h, 10s        

Using dokku 0.5.5 and letsencrypt 0.8.2, Ubuntu 14.04.

Error on digital ocean dokku droplet

When I install the plugin and try to encrypt an app on a digital ocean droplet running dokku 0.5.4 I get the following error.

root@dokku-messenger-512mb-sfo1-01:~# dokku letsencrypt isitsunny
=====> Let's Encrypt isitsunny
-----> Updating letsencrypt docker image...
latest: Pulling from dokkupaas/letsencrypt-simp_le
420890c9e918: Already exists 
e4a2ae244258: Already exists 
5c6ac6d1c950: Already exists 
Digest: sha256:18a19b34beceba79dd5be458abe7e132fc7486da1da19cc4d0395ad4578031ef
Status: Image is up to date for dokkupaas/letsencrypt-simp_le:latest
       done updating
-----> Enabling ACME proxy for isitsunny...
-----> Getting letsencrypt certificate for isitsunny...
        - Domain 'isitsunny.southfacingsoftware.com'
/var/lib/dokku/plugins/enabled/letsencrypt/subcommands/default: line 82: 60: command not found
darkhttpd/1.11, copyright (c) 2003-2015 Emil Mikulic.
listening on: http://0.0.0.0:80/
simp_le.py: error: argument --valid_min: invalid int value: ''
-----> Certificate retrieval failed!
-----> Disabling ACME proxy for isitsunny...
       done

Securing subdomain

Hi

I am hosting an application that uses websockets, and goes through CloudFlare.

Since CF does not support websockets, I have to route these seperately to a CNAME ws -> mydomain.com, and disable the CF for that specific record.

I get the following error:

WebSocket connection to 'wss://ws.mydomain.com/socket/websocket?vsn=1.0.0' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED

I'm guessing that's because the SSL is not properly setup on the subdomain

How can I fix this?

Conflict with dokku-http-auth

LetsEncrypt is unable to verify a domain behind http authentication. Since dokku-http-auth is an official plugin, it might be good to find a way to get these plugins to work together. If not, we can always add a note in the documentation that dokku-http-auth has to be disabled for this plugin to work correctly.

Here's the dokku output when trying to add letsencrypt to an app with http-auth turned on: https://gist.github.com/johnfraney/62b1dc5ccddd2c8a7358

Multiple apps on same domain

Thanks for the great plugin!

It looks like the plugins does not support multiple apps that share the same domain but operate on different ports. In my setup I have an app that is available through nginx on port 80/443 and another on 8000/8080. While creating a certificate for the first app was easy, it didn't work for the second one:

=====> Let's Encrypt api
-----> Updating letsencrypt docker image...
latest: Pulling from dokkupaas/letsencrypt-simp_le
420890c9e918: Already exists 
e4a2ae244258: Already exists 
5c6ac6d1c950: Already exists 
Digest: sha256:18a19b34beceba79dd5be458abe7e132fc7486da1da19cc4d0395ad4578031ef
Status: Image is up to date for dokkupaas/letsencrypt-simp_le:latest
       done updating
-----> Enabling ACME proxy for api...
-----> Getting letsencrypt certificate for api...
        - Domain 'tunnel.connectingspaces.ch'
darkhttpd/1.11, copyright (c) 2003-2015 Emil Mikulic.
listening on: http://0.0.0.0:80/
2016-04-26 21:31:22,045:INFO:__main__:1211: Generating new account key
2016-04-26 21:31:22,805:INFO:requests.packages.urllib3.connectionpool:758: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2016-04-26 21:31:23,132:INFO:requests.packages.urllib3.connectionpool:758: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2016-04-26 21:31:23,353:INFO:requests.packages.urllib3.connectionpool:758: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2016-04-26 21:31:24,187:INFO:requests.packages.urllib3.connectionpool:758: Starting new HTTPS connection (1): letsencrypt.org
2016-04-26 21:31:24,892:INFO:requests.packages.urllib3.connectionpool:758: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2016-04-26 21:31:25,132:INFO:requests.packages.urllib3.connectionpool:758: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2016-04-26 21:31:25,392:INFO:requests.packages.urllib3.connectionpool:207: Starting new HTTP connection (1): tunnel.connectingspaces.ch
2016-04-26 21:31:25,395:INFO:requests.packages.urllib3.connectionpool:758: Starting new HTTPS connection (1): tunnel.connectingspaces.ch
2016-04-26 21:31:25,444:WARNING:__main__:1303: tunnel.connectingspaces.ch was not successfully self-verified. CA is likely to fail as well!
2016-04-26 21:31:25,466:INFO:requests.packages.urllib3.connectionpool:758: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2016-04-26 21:31:25,697:INFO:__main__:1313: Generating new certificate private key
2016-04-26 21:31:33,397:INFO:requests.packages.urllib3.connectionpool:758: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2016-04-26 21:31:33,600:ERROR:__main__:1271: CA marked some of the authorizations as invalid, which likely means it could not access http://example.com/.well-known/acme-challenge/X. Did you set correct path in -d example.com:path or --default_root? Is there a warning log entry about unsuccessful self-verification? Are all your domains accessible from the internet? Failing authorizations: https://acme-v01.api.letsencrypt.org/acme/authz/2p5I0c2PcYSCNtvBRLaNjRnKpmYX-cT7WYD4PidChiw
Challenge validation has failed, see error log.

Debugging tips: -v improves output verbosity. Help is available under --help.
-----> Certificate retrieval failed!
-----> Disabling ACME proxy for api...
       done

I guess the different port configuration didn't allow the acme servers to reach the app... In that particular case it wouldn't actually be necessary to get a certificate as there is already one existing for that domain.

Maybe the plugin could store the certificates per domain and retrieve them if valid?

Now I ended up just symlinking the other apps certificate to the other, but that would break the autorenew process...

Any suggestions?

Let's Encrypt fails with `You must set at least one -d/--vhost`

Any ideas here? Of course the cert expires today. Not even revoke works - I'd appreciate any tips on getting nginx to disable the cert in the meantime. Just updated to the latest plugin version too.

# dokku letsencrypt:auto-renew aqueousband.com
=====> Auto-renew aqueousband.com...
=====> Let's Encrypt aqueousband.com...
-----> Updating letsencrypt docker image...
latest: Pulling from m3adow/letsencrypt-simp_le
Digest: sha256:be1d7aca214d5277af18d7bf75a2bc78afa5a1eabf98aaa8a606c4ca2a7fdeb5
Status: Image is up to date for m3adow/letsencrypt-simp_le:latest
       done
-----> Enabling ACME proxy for aqueousband.com...
-----> Getting letsencrypt certificate for aqueousband.com...
darkhttpd/1.11, copyright (c) 2003-2015 Emil Mikulic.
listening on: http://0.0.0.0:80/
You must set at least one -d/--vhost

Debugging tips: -v improves output verbosity. Help is available under --help.
-----> Certificate retrieval failed!
-----> Disabling ACME proxy for aqueousband.com...
       done

Cert info:

# dokku certs:info aqueousband.com
-----> Fetching SSL Endpoint info for aqueousband.com...
-----> Certificate details:
=====> Common Name(s): 
=====>    aqueousband.com
=====>    aqueousband.com
=====> Expires At: Apr  5 04:28:00 2016 GMT
=====> Issuer: C=US, O=Lets Encrypt, CN=Lets Encrypt Authority X1
=====> Starts At: Jan  6 04:28:00 2016 GMT
=====> Subject: CN=aqueousband.com
=====> SSL certificate is self signed.

OCSP Stapling

Add

ssl_trusted_certificate {{ .DOKKU_ROOT }}/{{ .APP }}/letsencrypt/certs/current/fullchain.pem;

in nginx config for apps with Lets Encrypt enabled.

This plugin should do this since it's not possible to handle effectively yourself because:

  • You can't add stuff to you repo that end up in <dokku_app>/nginx.conf.d/
  • <dokku_app>/nginx.conf cannot be extended. And creating a nginx.cong.sigil thats identical to the default with the only difference being the staplin', ain't a good solution.

Fix warning messages for non-SSL apps when using letsencrypt:ls

As reported by @fruitl00p #18 , we currently get warning messages on non-SSL apps when running dokku letsencrypt:ls:

140668729374368:error:02001002:system library:fopen:No such file or directory:bss_file.c:398:fopen('/home/dokku/app1-without-tls/tls/server.crt','r')
140668729374368:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:400:
unable to load certificate
Error opening Certificate /home/dokku/mediaweb/tls/server.crt
140609668568736:error:02001002:system library:fopen:No such file or directory:bss_file.c:398:fopen('/home/dokku/app2-without-tls/tls/server.crt','r')
140609668568736:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:400:
unable to load certificate
Error opening Certificate /home/dokku/mediaweb2/tls/server.crt
140405065541280:error:02001002:system library:fopen:No such file or directory:bss_file.c:398:fopen('/home/dokku/app3-without-tls/tls/server.crt','r')
140405065541280:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:400:
unable to load certificate
Error opening Certificate /home/dokku/vraagsturing/tls/server.crt
139854962603680:error:02001002:system library:fopen:No such file or directory:bss_file.c:398:fopen('/home/dokku/app4-without-tls/tls/server.crt','r')
139854962603680:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:400:
unable to load certificate
Error opening Certificate /home/dokku/www-kerkenijmondnoord-nl/tls/server.crt
140535163012768:error:02001002:system library:fopen:No such file or directory:bss_file.c:398:fopen('/home/dokku/app4-without-tls/tls/server.crt','r')
140535163012768:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:400:

Add a filter to only list and attempt to get certificate information for SSL-secured apps to fix warning messages.

Command dokku letsencrypt:ls not working

Hi,

It seems command dokku letsencrypt:ls returns empty result.

Please have a look, thanks!

root@ubuntu:~/nginx/sites-enabled# dokku letsencrypt:auto-renew temp
       temp still has 59d, 22h, 55m, 36s days left before renewal
root@ubuntu:~/nginx/sites-enabled# dokku letsencrypt:ls
-----> App name           Certificate Expiry        Time before expiry        Time before renewal
root@ubuntu:~/nginx/sites-enabled# dokku letsencrypt:ls
-----> App name           Certificate Expiry        Time before expiry        Time before renewal

Add command to clean up stale certificates / keys

Since 68a53ca, account keys, private keys and certificates are stored in a subdirectory whose name is generated from the parameters that are passed to the simp_le client. Since every configuration change will thus result in a new folder being created, it would be nice to have a command to remove all old certificates that are not linked to by the $APP_ROOT/letsencrypt/certs/current symlink.

Symlink certs to /etc/letsencrypt/ instead of copying

First, thanks for making this. The other plugin's approach is not nearly as good. ๐Ÿ˜„

Anyway, it appears you copied one of the bad practices from the other plugin. Namely owning /etc/letsencrypt with the user dokku: https://github.com/sseemayer/dokku-letsencrypt/blob/master/install#L7

The cert folder should only be readable/writable by root. This should be fine since they are only read when nginx starts up (as root to bind to port 80) and written to when created. You can use sudo for that. As far as I can tell just removing those two lines should let the plugin keep working, but I'm not 100% on that.

Cheers!

Creating Cronjob doesn't work

I've tried to add a cronjob with the
dokku letsencrypt:cron-job --add command, but neither dokku user nor admin or root have any crontab entries after that.

I'm using Dokku v0.5.5 with letsencrypt 0.8.2.

Stopped working

Hello,

Today I tried to update one of my apps but it stopped at "Enabling ACME". I also tried updating the plugin and removing the TLS folder but without success.

Here is the log:
=====> Let's Encrypt youtrack...
-----> Updating letsencrypt docker image...
latest: Pulling from dokkupaas/letsencrypt-simp_le
420890c9e918: Already exists
e4a2ae244258: Pull complete
5c6ac6d1c950: Pull complete
Digest: sha256:18a19b34beceba79dd5be458abe7e132fc7486da1da19cc4d0395ad4578031ef
Status: Downloaded newer image for dokkupaas/letsencrypt-simp_le:latest
done
-----> Enabling ACME proxy for youtrack...

Support for multiple domains

An app might have multiple domains. dokku-letsencrypt should be able to obtain a certificate for all domains.

BTW, thanks for this plugin! This will definitely help a lot of people.

dokku-letsencrypt broken for me with dokku 0.5.3

I've updated to dokku 0.5.3 and dokku-letsencrypt stopped working.

I've tracked first part of my problem and it turned out to be a problem with port in domain name, I fixed it with this patch:

diff --git a/functions b/functions
index f83e3e6..49c78f9 100755
--- a/functions
+++ b/functions
@@ -194,7 +194,7 @@ letsencrypt_configure_and_get_dir() {
   fi

   # construct domain arguments
-  DOMAINS=$(dokku urls "$APP" | sed "s,\\s,\n,g" | sed -re "s,https?://,," | sed -re "s,\\*\\.,," | uniq | xargs)
+  DOMAINS=$(dokku urls "$APP" | sed "s,\\s,\n,g" | sed -re "s,https?://,," | sed -re "s,\\*\\.,," | sed -re "s,:[0-9]+$,," | uniq | xargs)   DOMAIN_ARGS=''
   for DOMAIN in $DOMAINS; do
     dokku_log_verbose " - Domain '$DOMAIN'" >&2

After that .well-known is written in /var/www/html:

2016-04-03 15:35:48,444:DEBUG:__main__:978: Saving validation (u'e5qZ5J8e7jqE-5besOmhTGOnp9WeVzcBzoj0_ypyiZI.7FK3qYS8ifxcMDmTmvKh6yFmj1JAUKSQWVb64aEWnlM') at /var/www/html/.well-known/acme-challenge/e5qZ5J8e7jqE-5besOmhTGOnp9WeVzcBzoj0_ypyiZI

I've checked container filesystem (removed --rm and then commited a snapshot), and this file exists there. But:

2016-04-03 15:35:48,502:DEBUG:requests.packages.urllib3.connectionpool:387: "GET /.well-known/acme-challenge/e5qZ5J8e7jqE-5besOmhTGOnp9WeVzcBzoj0_ypyiZI HTTP/1.1" 404 None

Soo... Not really sure what to do now. Any pointers?

private key permissions

kuba/simp_le#29 says that simp_le creates private key as world readable.
dokku uses the files by root user. So I think they can set more secure permissions.

How about this patch?

diff --git a/functions b/functions
index 67e092a..7685bb3 100755
--- a/functions
+++ b/functions
@@ -68,6 +68,7 @@ letsencrypt_create_root () {
   # Set up folders
   if [ ! -d "$LETSENCRYPT_ROOT" ]; then
     mkdir -p "$LETSENCRYPT_ROOT"
+    chmod 600 "$LETSENCRYPT_ROOT"
   fi
 }

or this one?

diff --git a/functions b/functions
index 67e092a..a965ee4 100755
--- a/functions
+++ b/functions
@@ -69,6 +69,7 @@ letsencrypt_create_root () {
   if [ ! -d "$LETSENCRYPT_ROOT" ]; then
     mkdir -p "$LETSENCRYPT_ROOT"
   fi
+  chmod 600 "$LETSENCRYPT_ROOT"
 }

 letsencrypt_get() {

adding certificate to second application failing at verification

  • dokku 0.5.4 with dokku-letsencrypt 5338510
  • Ubuntu 14.04.4 LTS

letsencrypt app1 worked great for the first app, but on the second app, letsencrypt app2 fails at the verification stage:

2016-04-15 04:13:20,170:ERROR:acme.challenges:267: Unable to reach http://app2.apps.example.com/.well-known/acme-challenge/FdhXO8u3IWsE7VNqZZXphq-JeHWcFycEMy-uu4uveh4: hostname 'app2.apps.example.com' doesn't match 'app1.apps.example.com'
2016-04-15 04:13:20,170:WARNING:__main__:1292: app2.apps.example.com was not successfully self-verified. CA is likely to fail as well!

Any ideas? Is this related to dokku 0.5 compat?

cronjob fails (enabling tty)

Renewal doesn't work as cron job

Easy to reproduce by executing:

:| dokku letsencrypt APP
-----> Let's Encrypt APP...
-----> Updating letsencrypt docker image...
...
-----> Enabling ACME proxy for APP...
-----> Getting letsencrypt certificate for APP...
        - Domain 'APP.TLD'
cannot enable tty mode on non tty input

Documentation : Set up dokku lets encrypt with cloudflare

Hi

I am kinda new to all these server set up.
Does this play well with cloudflare?

My understanding is that if you are using the flexible SSL certificate and once you have implemented letsencrypt you may change flexible to full SSL but on a free account users will still see that the cert is provided by cloudflare. Is this correct?

If so is it really that easy to just follow your steps in the readme after you get the cert successfully (and nginx restarted auto configured) you go to your cloudflare domain panel and change to full ssl everything will work? Seems too easy for me lol ;) so i want make sure this is the case before i implement

thanks in advance for your help! would love to contribute some documentation regarding cloudflare and this excellent plugin

Certificate limit easily hit

Hi there,

Thanks for dokku-letsencrypt, it's almost magical after being used to
non letsencrypt ssl configuration :)

One problem with it is that the rate limit for letsencrypt is very
easily hit:

An unexpected error occurred:
There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for: <domain>
Please see the logfiles in /var/log/letsencrypt for more details.

The problem is that it will try to issue a certificate for every single
domain of the app, included the default <app>.<dokku_domain> one (so
making sure to use a domain per app wouldn't help).

Do you think it would be possible to either omit the default domain, or
maybe to specify which domains should have a ssl certificate?

Enabling letsencrypt certificate does nothing

I've successfully used this great plugin on few servers running dokku, but now one simply does nothing when running the following:

dokku letsencrypt <myapp>

It doesn't give any error messages whatsoever. Any suggestions what could be causing this?

Domains

It's not clear from the readme which domains this gets certificates for. If I've added multiple domains to an app before running this, will it get a certificate to cover all the domains. If not, is there a way to specify which domain I want to get a certificate for (I've looked through the source code, and this doesn't look possible).

Cert generation fails for apps with multiple domains

When requesting certs for apps with more than one vhost, simp_le fails.

-----> Enabling ACME proxy for my-app...
-----> Getting letsencrypt certificate for my-app...
        - Domain 'sub1.myapp.tld
sub2.myapp.tld'
darkhttpd/1.11, copyright (c) 2003-2015 Emil Mikulic.
listening on: http://0.0.0.0:80/
simp_le.py: error: unrecognized arguments: sub2.myapp.tld
-----> Certificate retrieval failed!

A dokku trace confirms that it's due to a malformed call to simp_le.py: dokku-letsencrypt parses the domains as a single string with newlines, hence fails to split them into separate "-d" arguments.

Add automatic crontab installation for auto-renew command

@256dpi asks in #55:

Another Question: Is there a reason that the plugin does not have a command that automatically adds the autorenew to the roots crontab?

The reason that there is no command yet is that doing it manually is fairly easy and educative while automating could be more complicated. If anyone is interested in providing a PR for adding and removing cron entries I'd be happy to add this to the plugin, though! ๐Ÿ‘

The best way would be to add the entry to the dokku (not root) user's crontab since that should theoretically be the most secure.

Pass e-mail address to letsencrypt from plugin

Since it is important that the letsencrypt command can be run from cron (i.e. no TTY), it is important that we're able to run the letsencrypt docker container without a TTY attached.

On first run of the plugin, the container will currently ask for the user's e-mail address to register a new account. In some configurations (ref. #14), the current terminal detection methods fail and the docker container crashes with the PythonDialogBug error.

Add a letsencrypt:register command that can be performed once to create a user account with let's encrypt and to ensure that future interactions with the docker container can run fully automated.

Simplify automatic renewal

First of all, I'm love with this plugins. It's AMAZING!

Could be interesting add a flag option or something similar to activate crontab auto-renew.

Or add in the documentation an example of how to do it for newbies :-)

Bug with latest letsencrypt image

Potentially related: alex/letsencrypt-aws#30

root@dokku:~# dokku letsencrypt visualcosita
=====> Let's Encrypt visualcosita...
-----> Updating letsencrypt docker image...
latest: Pulling from m3adow/letsencrypt-simp_le
420890c9e918: Already exists
acbaf1e6012f: Pull complete
5f71a1a2d3dc: Pull complete
Digest: sha256:be1d7aca214d5277af18d7bf75a2bc78afa5a1eabf98aaa8a606c4ca2a7fdeb5
Status: Downloaded newer image for m3adow/letsencrypt-simp_le:latest
       done
-----> Enabling ACME proxy for visualcosita...
-----> Getting letsencrypt certificate for visualcosita...
        - Domain 'visualcosita.dokku.josediazgonzalez.com'
darkhttpd/1.11, copyright (c) 2003-2015 Emil Mikulic.
listening on: http://0.0.0.0:80/
2016-04-16 20:18:11,149:INFO:__main__:1207: Generating new account key
2016-04-16 20:18:11,830:INFO:requests.packages.urllib3.connectionpool:758: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2016-04-16 20:18:11,999:INFO:requests.packages.urllib3.connectionpool:758: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2016-04-16 20:18:12,192:INFO:requests.packages.urllib3.connectionpool:758: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
2016-04-16 20:18:12,498:INFO:requests.packages.urllib3.connectionpool:758: Starting new HTTPS connection (1): letsencrypt.org
2016-04-16 20:18:13,125:INFO:requests.packages.urllib3.connectionpool:758: Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Traceback (most recent call last):
  File "/simp_le-master/simp_le.py", line 1397, in main
    return main_with_exceptions(cli_args)
  File "/simp_le-master/simp_le.py", line 1382, in main_with_exceptions
    new_data(args, existing_data)
  File "/simp_le-master/simp_le.py", line 1283, in new_data
    for vhost in args.vhosts
  File "/simp_le-master/simp_le.py", line 1283, in <genexpr>
    for vhost in args.vhosts
TypeError: request_domain_challenges() got an unexpected keyword argument 'new_authzr_uri'

Unhandled error has happened, traceback is above

Debugging tips: -v improves output verbosity. Help is available under --help.
-----> Certificate retrieval failed!
-----> Disabling ACME proxy for visualcosita...
       done

Thoughts?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.