voxpupuli / puppet-letsencrypt Goto Github PK

Could you please update to support puppetlabs/vcsrepo 2?

In my opinion the /etc/cron.d/certbot (default cron job for running certbot twice per day on Debian with official cerbot package) file should be absent when one sets manage_cron to true as both can/will interfere.

I did not check on other distributions but this might also be an issue with other distros.

For your reference here is the contact of that /etc/cron.d/certbot file on Debian 9:

# /etc/cron.d/certbot: crontab entries for the certbot package
#
# Upstream recommends attempting renewal twice a day
#
# Eventually, this will be an opportunity to validate certificates
# haven't been revoked, etc.  Renewal will only occur if expiration
# is within 30 days.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew

What do you think?

does this support the route53 plugin? dont see any documentation on it?

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 6.7.0
• Ruby: 2.5.5p157
• Distribution: Debian 10 (Buster)
• Module version: 4.0.0

How to reproduce (e.g Puppet code you use)

letsencrypt::certonly { 'foo':
    domains       => ['example.com'],
    plugin        => 'dns-rfc2136',
}

What are you seeing

E: Unable to locate package python2-certbot-dns-rfc2136

Any additional information you'd like to impart

I set letsencrypt::plugin::dns_rfc2136::manage_package: false and manually installed python3-certbot-dns-rfc2136 and it works fine.

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: All
• Ruby: All
• Distribution: Ubuntu 14.04/16.04/? Probably all others as well
• Module version: Current master

How to reproduce (e.g Puppet code you use)

root@mbaur-letsencrypt:/# crontab -l
# HEADER: This file was autogenerated at 2018-06-28 14:39:10 +0200 by puppet.
# HEADER: While it can still be managed manually, it is definitely not recommended.
# HEADER: Note particularly that the comments starting with 'Puppet Name' should
# HEADER: not be deleted, as doing so could cause duplicate cron jobs.
# Puppet Name: letsencrypt renew cron mbaur-letsencrypt.invaliddomain.de
VENV_PATH=/opt/letsencrypt/.venv
51 11 * * * /opt/puppetlabs/puppet/cache/letsencrypt/renew-mbaur-letsencrypt.invaliddomain.de.sh
# Puppet Name: test cron
25 15 * * * echo $VENV_PATH > /tmp/mbaur-test
root@mbaur-letsencrypt:/# date
Thu Jun 28 15:24:49 CEST 2018
root@mbaur-letsencrypt:/# date
Thu Jun 28 15:25:07 CEST 2018
root@mbaur-letsencrypt:/# cat /tmp/mbaur-test
/opt/letsencrypt/.venv

What are you seeing

The environment parameter of the cron resource gets interpreted by all cronjobs which can lead to serious problems!

What behaviour did you expect instead

Environment variable should be only valid for one cronjob

Output log

Any additional information you'd like to impart

Hello.

We are running a custom RedHat based distribution and do not have letsencrypt package readily available. We also do not want to use EPEL repo.

I am wondering if pip module letsencrypt can be used? If so, whenever I have tried to add a package with provider 'pip', I get an error of a duplicate declaration.

package {
  'letsencrypt':
    ensure   => present,
    require  => Package['python3-pip'],
    provider => pip3;
}

Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Resource Statement, Duplicate declaration: Package[letsencrypt] is already declared at (file: /etc/puppetlabs/code/environments/puppet6/site-modules/cspuppetmaster/manifests/init.pp, line: 13); cannot redeclare (file: /etc/puppetlabs/code/environments/puppet6/modules/letsencrypt/manifests/install.pp, line: 39) (file: /etc/puppetlabs/code/environments/puppet6/modules/letsencrypt/manifests/install.pp, line: 39, column: 5)

Is there a way around it?

Thank you and happy new year!

Asya

kind of related to: #41

hardcoded parameters are not that good, having $package_name and $dependency as a parameter for letsencrypt::install would be awesome.

https://github.com/danzilio/puppet-letsencrypt/blob/v1.0.0/manifests/install.pp#L56
https://github.com/danzilio/puppet-letsencrypt/blob/v1.0.0/manifests/install.pp#L62
https://github.com/danzilio/puppet-letsencrypt/blob/v1.0.0/manifests/install.pp#L44

class letsencrypt::install (
  $package_name        = $letsencrypt::package_name, # 'letsencrypt' or 'certbot'
  $dependencies        = $letsencrypt::dependencies, # ['python', 'git']
  $manage_install      = $letsencrypt::manage_install,
  $manage_dependencies = $letsencrypt::manage_dependencies,
  $configure_epel      = $letsencrypt::configure_epel,
  $install_method      = $letsencrypt::install_method,
  $package_ensure      = $letsencrypt::package_ensure,
  $path                = $letsencrypt::path,
  $repo                = $letsencrypt::repo,
  $version             = $letsencrypt::version,
)

  if $install_method == 'vcs' {
    if $manage_dependencies {
      ensure_packages($dependencies)
      Package[$dependencies] -> Vcsrepo[$path]
}

    package { $package_name:
      ensure => $package_ensure,
}

because for example ensure_packages($dependencies) causes an error, if a manifest already includes package { 'git': } or package { 'python': } and not ensure_packages(['git']) which sadly is quite common.

Hello,

it would be far better if this module relies on puppetlabs-git instead of installing a "dumb" git — that would prevent some issues, like "git" package being a duplicated resource because puppetlabs' module uses a plain "package {'git': }".

Cheers,

C.

During implementation yesterday I came up to a few "problems":

• The cron outputs senseless info every time:

Checking for new version...
Requesting root privileges to run letsencrypt...
   /opt/letsencrypt/.venv/bin/letsencrypt --agree-tos certonly -a webroot --keep-until-expiring --webroot-path /var/www/html -d test.example.com

• Should we use --no-self-upgrade on cron and certonly?
• Should we use /opt/letsencrypt/.venv/bin/letsencrypt, and call letsencrypt-auto only once?

the current version on the forge has some garbage related to issues with minitar, see dgolja/golja-gnupg#18

Hi,
the problem I noticed is directory which shoud be under /.local//share/letsencrypt/ - I have this directory with real character of "" in various locations, for example:

• /root/~/.local/share/letsencrypt/...
• /etc/letsencrypt/live/~/.local/share/letsencrypt/...
• /etc/apache2/sites-enabled/~/.local/share/letsencrypt/...

In the last example it brokes apache configuration.
Symbol ~ is escaped somewhere and instead of getting home of current user it creates dir "~" in current working directory.

I'm not sure that this is related to this module, it can be bug in let'sencrypt itself. Certificates itself are working.
Enviroment: Puppet 3.7.2, Debian 8

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 3.8.7
• Ruby: 1.8.7.374-5
• Distribution: centos-release-6-3.el6.centos.9.x86_64
• Module version: v2.0.1

How to reproduce (e.g Puppet code you use)

class certbot {

class { ::letsencrypt:
  email => '[email protected]',
}

letsencrypt::certonly { 'install certbot':
  domains => ['www.xxx.com'],
  plugin => 'apache',
  manage_cron => true,
  cron_success_command => 'service httpd restart',
}

}

What are you seeing

puppet agent -t
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Puppet::Parser::AST::Resource failed with error ArgumentError: Could not find declared class ::letsencrypt at /etc/puppet/modules/certbot/manifests/init.pp:5 on node ay131218175445754fb6z
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

What behaviour did you expect instead

Success without error

Output log

Any additional information you'd like to impart

Same code works with v1.1.0.

Affected Puppet, Ruby, OS and module versions/distributions

• Distribution: Ubuntu
• Module version: 2.4.0

How to reproduce (e.g Puppet code you use)

Install on Ubuntu-16.04

What are you seeing

The default letsencrypt package installed is python-letsencrypt 0.4.1-1 https://packages.ubuntu.com/xenial/python-letsencrypt

What behaviour did you expect instead

It should use version 0.9.3 by default

Workaround

install_method => 'vcs',

The whole error:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Puppet::Parser::AST::Resource failed with error ArgumentError: Invalid resource type ini_setting at /etc/puppet/environments/production/modules/letsencrypt/manifests/config/ini.pp:21

Puppet version: 3.8.4
OS: Ubuntu 14.04.3 LTS

Its fixed by using the inifile module from pupppetlabs

Hi,
I manage git with another module. This results in a duplicate declaration error.
I might be better to handle the packages with the
"ensure_resource('package', $packages, {'ensure' => 'present'})"
from the stdlib module.

Thanks in advance
Jan

Could you please update to support puppetlabs/inifile 2?

Please replace the server URLs with:

https://acme-v02.api.letsencrypt.org/directory
And
https://acme-staging-v02.api.letsencrypt.org/directory

See also:

https://community.letsencrypt.org/t/staging-endpoint-for-acme-v2/49605
https://community.letsencrypt.org/t/acme-v2-production-environment-wildcards/55578

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 6.0.2
• Ruby:
• Distribution: Enterprise
• Module version: v2.5.0

How to reproduce (e.g Puppet code you use)

  class { ::letsencrypt:
    configure_epel => false,
    email => '[email protected]',
    config => {
      server => 'https://acme-v02.api.letsencrypt.org/directory',
    }
  }
  package { "python2-certbot-dns-dnsimple":
    ensure => installed
  }

  letsencrypt::certonly{ 'domain':
    domains => ['domain.io', '*.domain.io'],
    custom_plugin => true,
    additional_args => ['--dns-dnsimple', '--dns-dnsimple-credentials ~/.secrets/certbot/dnsimple.ini'],
    manage_cron => true,
    cron_success_command => '/bin/systemctl reload nginx',
    suppress_cron_output => true,
  }

What are you seeing

Its throwing an exception that the domains param is not of the defined signature type Array[Stdlib::Host]

What behaviour did you expect instead

The ability to generate a wildcard ssl via the dns-dnsimple plugin

Output log

Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Resource Statement, Letsencrypt::Certonly[titleboxing-test]: parameter 'domains' index 1 expects a Stdlib::Host = Variant[Stdlib::Fqdn = Pattern[/^(([a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9\-]*[a-zA-Z0-9])\.)*([A-Za-z0-9]|[A-Za-z0-9][A-Za-z0-9\-]*[A-Za-z0-9])$/], Stdlib::Compat::Ip_address = Variant[Stdlib::Compat::Ipv4 = Pattern[/^((([0-9](?!\d)|[1-9][0-9](?!\d)|1[0-9]{2}(?!\d)|2[0-4][0-9](?!\d)|25[0-5](?!\d))[.]){3}([0-9](?!\d)|[1-9][0-9](?!\d)|1[0-9]{2}(?!\d)|2[0-4][0-9](?!\d)|25[0-5](?!\d)))(\/((([0-9](?!\d)|[1-9][0-9](?!\d)|1[0-9]{2}(?!\d)|2[0-4][0-9](?!\d)|25[0-5](?!\d))[.]){3}([0-9](?!\d)|[1-9][0-9](?!\d)|1[0-9]{2}(?!\d)|2[0-4][0-9](?!\d)|25[0-5](?!\d))|[0-9]+))?$/], Stdlib::Compat::Ipv6 = Pattern[/\s*((([0-9A-Fa-f]{1,4}:){7}([0-9A-Fa-f]{1,4}|:))|(([0-9A-Fa-f]{1,4}:){6}(:[0-9A-Fa-f]{1,4}|((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3})|:))|(([0-9A-Fa-f]{1,4}:){5}(((:[0-9A-Fa-f]{1,4}){1,2})|:((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3})|:))|(([0-9A-Fa-f]{1,4}:){4}(((:[0-9A-Fa-f]{1,4}){1,3})|((:[0-9A-Fa-f]{1,4})?:((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3}))|:))|(([0-9A-Fa-f]{1,4}:){3}(((:[0-9A-Fa-f]{1,4}){1,4})|((:[0-9A-Fa-f]{1,4}){0,2}:((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3}))|:))|(([0-9A-Fa-f]{1,4}:){2}(((:[0-9A-Fa-f]{1,4}){1,5})|((:[0-9A-Fa-f]{1,4}){0,3}:((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3}))|:))|(([0-9A-Fa-f]{1,4}:){1}(((:[0-9A-Fa-f]{1,4}){1,6})|((:[0-9A-Fa-f]{1,4}){0,4}:((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3}))|:))|(:(((:[0-9A-Fa-f]{1,4}){1,7})|((:[0-9A-Fa-f]{1,4}){0,5}:((25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(\.(25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3}))|:)))(%.+)?\s*$/]]] value, got String (file: /etc/puppetlabs/code/environments/production/site/profile/manifests/proxy.pp, line: 30) on node proxy.hedev.io

Any additional information you'd like to impart

Had to use custom_plugin because the dnsimple plugin is not in the list, It might be a good idea to add it as well.

When you install letsencrypt using the VCS method, it will create a virtualenv, which would normally be located in ~/.local/share/letsencrypt:

Excerpt from letsencrypt-auto:

XDG_DATA_HOME=${XDG_DATA_HOME:-~/.local/share}
VENV_NAME="letsencrypt"
VENV_PATH=${VENV_PATH:-"$XDG_DATA_HOME/$VENV_NAME"}

However, puppet exec's will not set $HOME, which will stop Debian's /bin/sh, dash, from expanding , so it creates a literal '' folder.

I'm currently fixing this, will create a pull request soon.

The readme states that the server configuration should be changed if you want to use the staging environment. But CertBot itself can handle this using the "-- staging" argument.

Isn't it perhaps a nice feature to make this a solid part of the module? To create a consistent way of testing and keeping the logic of the e.g. the staging server hostname out of the implementation.

Something like:

certbot::certonly { 'foo':
  domains => ['foo.example.com', 'bar.example.com'],
  staging => true,
}

Or make it a machine-wide config:

class { ::certbot:
  staging => true,
}

Any thoughts on this?

I am stuck with a problem, please help.
I want to install an apache with a letsencrypt generated cert, using your puppet module.
My problem is, apache wont start wit missing cert, but letsencrypt wont get cert without apache.
How can I do this with puppet in one pass:

• start apache without ssl vhosts
• get and install letsencrypt cert
• add ssl virtualhosts and restart apache

Tnaks in advance.

Probably just a workaround but since I upgraded with git to the latest version I get this error. So I hacked it out and things work again.

diff --git a/manifests/certonly.pp b/manifests/certonly.pp
index 9ccbaac..3dd0605 100644
--- a/manifests/certonly.pp
+++ b/manifests/certonly.pp
@@ -163,7 +163,7 @@ define letsencrypt::certonly (
     *           => $exec_ensure,
     path        => $facts['path'],
     environment => $execution_environment,
-    provider    => 'shell',
+    # provider    => 'shell',
     require     => [
       Class['letsencrypt'],
       File['/usr/local/sbin/letsencrypt-domain-validation'],

I get the following on the command line:

Package letsencrypt is obsoleted by certbot, trying to install certbot-0.6.0-2.el7.noarch instead

Which results in a constant attempt to install letsencrypt package on systems:

Info: Applying configuration version '1466052442'
Notice: /Stage[main]/Letsencrypt::Install/Package[letsencrypt]/ensure: created
Info: Class[Letsencrypt::Install]: Scheduling refresh of Exec[initialize letsencrypt]
Notice: /Stage[main]/Letsencrypt/Exec[initialize letsencrypt]: Triggered 'refresh' from 1 events
Notice: Finished catalog run in 9.29 seconds

... because "letsencrypt" is not installed. ;)

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: any
• Ruby: any
• Distribution: any
• Module version: 2.5.0

How to reproduce (e.g Puppet code you use)

What are you seeing

When using install_method => vcs, the module use letsencrypt-auto

  $command_init = $install_method ? {
     'package' => $package_command,
     'vcs'     => "${path}/letsencrypt-auto",
   }

What behaviour did you expect instead

Until May 2016, Certbot was named letsencrypt or letsencrypt-auto. Now, the expected used script is certbot-auto.

For the moment letsencrypt-auto and certbot-auto are same, and so the module works as expected.

Output log

Any additional information you'd like to impart

metadata.json:

"requirements": [
{
"name": "puppet",
"version_requirement": ">= 4.7.0 < 5.0.0"
}

readme:

This module requires Puppet >= 3.8.7. and is ...

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: all
• Ruby: all
• Distribution: all
• Module version: all

How to reproduce (e.g Puppet code you use)

Try and set letsencrypt::certonly::plugin parameter to dns-google

What are you seeing

Puppet runs fail, as the Enum data type doesn't support that pattern.

What behaviour did you expect instead

Puppet runs without error

Output log

Any additional information you'd like to impart

Puppet: 3.8.5
Letsencrypt: 0.5.0 via GIT (0.1.0, which is default, doesn't like Centos 6 with Ruby 1.8.7, and adding epel doesn't seem to get me any packages, thus I'm using git.)
Ruby: 2.1.2p95 on the master, 1.8.7 on the node.

 letsencrypt::certonly{"My letsencrypt":
    domains => ['www.my.org', 'my.org'],
    plugin => 'webroot',
    webroot_paths => ['/var/www/html/something/public']  # I also tried specifying it twice but saw use of cycle() 
  }

Error:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Failed to parse inline template: can't convert Enumerable::Enumerator into Array at /etc/puppet/modules/letsencrypt/manifests/certonly.pp:47

Now, I'm not sure what exactly is Enumerable here, so I tried it on command line and it works fine:

irb(main):001:0> webroot_paths = ['/some/path']
=> ["/some/path"]
irb(main):002:0> domains = ['www.my.org','my.org']
=> ["www.my.org", "my.org"]
irb(main):003:0> domains.zip(webroot_paths.cycle).map { |domain| "--webroot-path #{domain[1]} -d #{domain[0]}"}.join(" ")
=> "--webroot-path /some/path -d www.my.org --webroot-path /some/path -d my.org"

Obviously I had to drop the '@' signs.

I'm not that familiar with rake and couldn't get the tests to work, so this remains unsolved on my end.

Error while evaluating a Resource Statement, Evaluation Error: Error while evaluating a Function Call, Failed to parse inline template: undefined methodcycle' for nil:NilClass at /etc/puppetlabs/code/environments/production/modules/letsencrypt/manifests/certonly.pp:47:18`

CentOS7
# /opt/puppetlabs/puppet/bin/ruby --version ruby 2.1.9p490 (2016-03-30 revision 54437) [x86_64-linux]

what am I missing?

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: all
• Ruby: all
• Distribution: all
• Module version: all

How to reproduce (e.g Puppet code you use)

Set letsencrypt::certonly::plugin parameter to 'dns-cloudflare'.

What are you seeing

Puppet run fails due to 'dns-cloudflare' not being a valid enum value in Letsencrypt::Plugin.

What behaviour did you expect instead

Puppet run succeeds without error, and DNS-01 challenge is issued.

Output log

Any additional information you'd like to impart

Certbot's site recommends running the cron job two times a day:

"if you're setting up a cron or systemd job, we recommend running it twice per day (it won't do anything until your certificates are due for renewal or revoked, but running it regularly would give your site a chance of staying online in case a Let's Encrypt-initiated revocation happened for some reason)."
~ (https://certbot.eff.org/#pip-apache at the bottom of the page)

It seems that the current cron job runs once daily. Should this be updated?

Thank you.

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 4.10.12
• Module version: 2.4.0

How to reproduce (e.g Puppet code you use)

Set letsencrypt::certonly::manage-cron to true, sync, set to false, sync

What are you seeing

crontab record and script are still present

What behaviour did you expect instead

at least the crontab record should be removed

--pre-hook PRE_HOOK Command to be run in a shell before obtaining any
certificates. Intended primarily for renewal, where it
can be used to temporarily shut down a webserver that
might conflict with the standalone plugin. This will
only be called if a certificate is actually to be
obtained/renewed. (default: None)

--post-hook POST_HOOK
Command to be run in a shell after attempting to
obtain/renew certificates. Can be used to deploy
renewed certificates, or to restart any servers that
were stopped by --pre-hook. This is only run if an
attempt was made to obtain/renew a certificate.
(default: None)

--renew-hook RENEW_HOOK
Command to be run in a shell once for each
successfully renewed certificate.For this command, the
shell variable $RENEWED_LINEAGE will point to
theconfig live subdirectory containing the new certs
and keys; the shell variable $RENEWED_DOMAINS will
contain a space-delimited list of renewed cert domains
(default: None)

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: any
• Ruby: any
• Distribution: any
• Module version: 2.5.0

How to reproduce (e.g Puppet code you use)

Use install_method => vcs

What are you seeing

The used repository is https://github.com/letsencrypt/letsencrypt.git

What behaviour did you expect instead

Since it was renamed certbot, the repository used should be https://github.com/certbot/certbot.git. A redirect is done on Github, so the puppet module continues to work.

Output log

Any additional information you'd like to impart

I'll propose a PR

The code below consistently produces the following valid certs:
www.hatf2.com
hatf2.com
schema.tf

but fails to generate a valid certificate for
www.schema.tf

It doesn't seem to give any errors, and unfortunately the only logs provided in /var/log/letsencrypt/letsencrypt.log are for the hatf2.com entry. No sign of schema.tf or www.schema.tf anywhere in this log file, almost as if the logs are being overwritten... The only evidence of activity is in the separate puppet provisioning logs:

2016-12-01 02:16:46 +0000 /Stage[main]/Main/Letsencrypt::Certonly[schema.tf]/Exec[letsencrypt certonly schema.tf]/returns (notice): executed successfully
2016-12-01 02:16:46 +0000 /Stage[main]/Main/Letsencrypt::Certonly[schema.tf]/Cron[letsencrypt renew cron schema.tf]/ensure (notice): created
2016-12-01 02:16:53 +0000 /Stage[main]/Main/Letsencrypt::Certonly[hatf2.com]/Exec[letsencrypt certonly hatf2.com]/returns (notice): executed successfully
2016-12-01 02:16:53 +0000 /Stage[main]/Main/Letsencrypt::Certonly[hatf2.com]/Cron[letsencrypt renew cron hatf2.com]/ensure (notice): created

Just at a glance, is this usage incorrect?

class { ::letsencrypt:
  email => '[email protected]',
}->

letsencrypt::certonly { 'schema.tf': 
  domains => ['schema.tf','www.schema.tf'],
  manage_cron => true,
} ->
letsencrypt::certonly { 'hatf2.com':
  domains => ['hatf2.com','www.hatf2.com'],
  manage_cron => true,
} ->

class { 'nginx': }

Hello,

1.0.0 on puppet forge is old (end of January), and there are some nice improvements in the current code base.

Thank you!

Hi,

I just deployed the module and try to get a certificate. It appears that it never worked. Looking at the logs I see an error :

2019-04-17 14:51:49,562:DEBUG:certbot.storage:Creating directory /etc/letsencrypt/archive.
2019-04-17 14:51:49,562:DEBUG:certbot.storage:Creating directory /etc/letsencrypt/live.
2019-04-17 14:51:49,562:DEBUG:certbot.log:Exiting abnormally:
Traceback (most recent call last):
  File "/usr/bin/certbot", line 11, in <module>
    load_entry_point('certbot==0.28.0', 'console_scripts', 'certbot')()
  File "/usr/lib/python3/dist-packages/certbot/main.py", line 1340, in main
    return config.func(config, plugins)
  File "/usr/lib/python3/dist-packages/certbot/main.py", line 1225, in certonly
    lineage = _get_and_save_cert(le_client, config, domains, certname, lineage)
  File "/usr/lib/python3/dist-packages/certbot/main.py", line 121, in _get_and_save_cert
    lineage = le_client.obtain_and_enroll_certificate(domains, certname)
  File "/usr/lib/python3/dist-packages/certbot/client.py", line 410, in obtain_and_enroll_certificate
    self.config)
  File "/usr/lib/python3/dist-packages/certbot/storage.py", line 1026, in new_lineage
    cli_config.renewal_configs_dir, lineagename)
  File "/usr/lib/python3/dist-packages/certbot/util.py", line 280, in unique_lineage_name
    return safe_open(preferred_path, chmod=chmod), preferred_path
  File "/usr/lib/python3/dist-packages/certbot/util.py", line 229, in safe_open
    os.open(path, os.O_CREAT | os.O_EXCL | os.O_RDWR, *open_args),
FileNotFoundError: [Errno 2] No such file or directory: '/etc/letsencrypt/renewal/api-partenaires-recette.domain.com/.conf'
2019-04-17 14:51:49,563:ERROR:certbot.log:An unexpected error occurred:

Not sure if this error is generated by the module or by letsencrypt.
Here is my hiera configuration :

letsencrypt::email: '[email protected]'
letsencrypt::certonly:
      'api-partenaires-recette.domain.com':
         domains:
           - 'api-partenaires-recette.domain.com'
         plugin: 'webroot'
         webroot_paths:
           - '/applis/www/api_partenaire/public'

The thing is I don't know what is the following file : : '/etc/letsencrypt/renewal/api-partenaires-recette.domain.com/.conf'

The second issue is that has puppet run every 30 minutes I blocked the domain :

2019-04-17 16:54:09,419:ERROR:certbot.log:There were too many requests of a given type :: Error creating new cert :: too many certificates already issued for exact set of domains: api-partenaires-recette.domain.com: see https://letsencrypt.org/docs/rate-limits/

I don't know if we can do something to prevent this situation.

Any idea ?

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: All
• Ruby: All
• Distribution: All
• Module version: Current master

How to reproduce (e.g Puppet code you use)

class { 'letsencrypt':
  install_method => 'vcs',
}

What are you seeing

v.0.30.0 of certbot has a critical bug which renders the tool useless because the installation fails.

--> certbot/certbot#6692
--> https://github.com/certbot/certbot/blob/master/CHANGELOG.md#0301---2019-01-24

What behaviour did you expect instead

Certbot should be installed.

Output log

Any additional information you'd like to impart

letsencrypt::environment, with its default of [] has the potential to break hiera lookups where %{::enviornment} is used as a branch key

1.0.0 package in puppetforge broken:

These files existed in the module's tar file, but are invalid filetypes and were not unpacked: ["PaxHeader/danzilio-letsencrypt-1.0.0", "danzilio-letsencrypt-1.0.0/PaxHeader/CHANGELOG.md", "danzilio-letsencrypt-1.0.0/PaxHeader/checksums.json", "danzilio-letsencrypt-1.0.0/PaxHeader/Gemfile", "danzilio-letsencrypt-1.0.0/PaxHeader/LICENSE", "danzilio-letsencrypt-1.0.0/PaxHeader/manifests", "danzilio-letsencrypt-1.0.0/PaxHeader/metadata.json", "danzilio-letsencrypt-1.0.0/PaxHeader/Rakefile", "danzilio-letsencrypt-1.0.0/PaxHeader/README.md", "danzilio-letsencrypt-1.0.0/PaxHeader/spec", "danzilio-letsencrypt-1.0.0/spec/PaxHeader/classes", "danzilio-letsencrypt-1.0.0/spec/PaxHeader/defines", "danzilio-letsencrypt-1.0.0/spec/PaxHeader/spec_helper.rb", "danzilio-letsencrypt-1.0.0/spec/defines/PaxHeader/letsencrypt_certonly_spec.rb", "danzilio-letsencrypt-1.0.0/spec/classes/PaxHeader/letsencrypt_install_spec.rb", "danzilio-letsencrypt-1.0.0/spec/classes/PaxHeader/letsencrypt_spec.rb", "danzilio-letsencrypt-1.0.0/manifests/PaxHeader/certonly.pp", "danzilio-letsencrypt-1.0.0/manifests/PaxHeader/config", "danzilio-letsencrypt-1.0.0/manifests/PaxHeader/config.pp", "danzilio-letsencrypt-1.0.0/manifests/PaxHeader/init.pp", "danzilio-letsencrypt-1.0.0/manifests/PaxHeader/install.pp", "danzilio-letsencrypt-1.0.0/manifests/PaxHeader/params.pp", "danzilio-letsencrypt-1.0.0/manifests/config/PaxHeader/ini.pp"]
remote: ERROR    -> undefined method `full_module_name' for nil:NilClass

Code of package 0.4.0 broken too:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Syntax error at 'Optional'; expected ')' at /etc/puppet/environments/*/modules/letsencrypt/manifests/init.pp:31 on node dev3.*.site
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 3.8.7
• Ruby: 2.1.5
• Distribution: Debian 8.7
• Module version: 1.0.0

How to reproduce (e.g Puppet code you use)

We changed the certonly plugin from standalone to webroot and the module seems to be trying to regenerate the certs during the puppet run.

However, since the certificates already exist, letsencrypt-auto is prompting for user input, upon which the puppet run fails.

Running the script manually and selecting option 1 (keep existing certificates) did not improve the situation. How does the puppet module know whether to generate certificates or only run the renew cron job but not the certonly script?

What are you seeing

[…]
Notice: /Stage[main]/Profile::Letsencrypt/Letsencrypt::Certonly[my.domain.tld]/Exec[letsencrypt certonly my.domain.tld]/returns: 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Notice: /Stage[main]/Profile::Letsencrypt/Letsencrypt::Certonly[my.domain.tld]/Exec[letsencrypt certonly my.domain.tld]/returns: Creating virtual environment...
Notice: /Stage[main]/Profile::Letsencrypt/Letsencrypt::Certonly[my.domain.tld]/Exec[letsencrypt certonly my.domain.tld]/returns: Updating letsencrypt and virtual environment dependencies.......
Notice: /Stage[main]/Profile::Letsencrypt/Letsencrypt::Certonly[my.domain.tld]/Exec[letsencrypt certonly my.domain.tld]/returns: Running with virtualenv: ~/.local/share/letsencrypt/bin/letsencrypt --agree-tos certonly -a webroot --webroot-path /var/tmp/letsencrypt -d domain.tld --webroot-path /var/tmp/letsencrypt -d my.domain.tld --webroot-path /var/tmp/letsencrypt -d cms.domain.tld --webroot-path /var/tmp/letsencrypt -d www.domain.tld
Notice: /Stage[main]/Profile::Letsencrypt/Letsencrypt::Certonly[my.domain.tld]/Exec[letsencrypt certonly my.domain.tld]/returns: Saving debug log to /var/log/letsencrypt/letsencrypt.log
Notice: /Stage[main]/Profile::Letsencrypt/Letsencrypt::Certonly[my.domain.tld]/Exec[letsencrypt certonly my.domain.tld]/returns: You are running with an old copy of letsencrypt-auto that does not receive updates, and is less reliable than more recent versions. We recommend upgrading to the latest certbot-auto script, or using native OS packages.
Notice: /Stage[main]/Profile::Letsencrypt/Letsencrypt::Certonly[my.domain.tld]/Exec[letsencrypt certonly my.domain.tld]/returns: Cert not yet due for renewal
Notice: /Stage[main]/Profile::Letsencrypt/Letsencrypt::Certonly[my.domain.tld]/Exec[letsencrypt certonly my.domain.tld]/returns: 
Notice: /Stage[main]/Profile::Letsencrypt/Letsencrypt::Certonly[my.domain.tld]/Exec[letsencrypt certonly my.domain.tld]/returns: You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry.
Notice: /Stage[main]/Profile::Letsencrypt/Letsencrypt::Certonly[my.domain.tld]/Exec[letsencrypt certonly my.domain.tld]/returns: (ref: /etc/letsencrypt/renewal/my.domain.tld-0002.conf)
Notice: /Stage[main]/Profile::Letsencrypt/Letsencrypt::Certonly[my.domain.tld]/Exec[letsencrypt certonly my.domain.tld]/returns: 
Notice: /Stage[main]/Profile::Letsencrypt/Letsencrypt::Certonly[my.domain.tld]/Exec[letsencrypt certonly my.domain.tld]/returns: What would you like to do?
Notice: /Stage[main]/Profile::Letsencrypt/Letsencrypt::Certonly[my.domain.tld]/Exec[letsencrypt certonly my.domain.tld]/returns: -------------------------------------------------------------------------------
Notice: /Stage[main]/Profile::Letsencrypt/Letsencrypt::Certonly[my.domain.tld]/Exec[letsencrypt certonly my.domain.tld]/returns: 1: Keep the existing certificate for now
Notice: /Stage[main]/Profile::Letsencrypt/Letsencrypt::Certonly[my.domain.tld]/Exec[letsencrypt certonly my.domain.tld]/returns: 2: Renew & replace the cert (limit ~5 per 7 days)
Notice: /Stage[main]/Profile::Letsencrypt/Letsencrypt::Certonly[my.domain.tld]/Exec[letsencrypt certonly my.domain.tld]/returns: -------------------------------------------------------------------------------
Notice: /Stage[main]/Profile::Letsencrypt/Letsencrypt::Certonly[my.domain.tld]/Exec[letsencrypt certonly my.domain.tld]/returns: Select the appropriate number [1-2] then [enter] (press 'c' to cancel): An unexpected error occurred:
Notice: /Stage[main]/Profile::Letsencrypt/Letsencrypt::Certonly[my.domain.tld]/Exec[letsencrypt certonly my.domain.tld]/returns: EOFError: EOF when reading a line
Notice: /Stage[main]/Profile::Letsencrypt/Letsencrypt::Certonly[my.domain.tld]/Exec[letsencrypt certonly my.domain.tld]/returns: Please see the logfiles in /var/log/letsencrypt for more details.
Error: /opt/letsencrypt/letsencrypt-auto --agree-tos certonly -a webroot --webroot-path /var/tmp/letsencrypt -d domain.tld --webroot-path /var/tmp/letsencrypt -d my.domain.tld --webroot-path /var/tmp/letsencrypt -d cms.domain.tld --webroot-path /var/tmp/letsencrypt -d www.domain.tld returned 1 instead of one of [0]
Error: /Stage[main]/Profile::Letsencrypt/Letsencrypt::Certonly[my.domain.tld]/Exec[letsencrypt certonly my.domain.tld]/returns: change from notrun to 0 failed: /opt/letsencrypt/letsencrypt-auto --agree-tos certonly -a webroot --webroot-path /var/tmp/letsencrypt -d domain.tld --webroot-path /var/tmp/letsencrypt -d my.domain.tld --webroot-path /var/tmp/letsencrypt -d cms.domain.tld --webroot-path /var/tmp/letsencrypt -d www.domain.tld returned 1 instead of one of [0]
Notice: /Stage[main]/Profile::Letsencrypt/Module::Letsencrypt::Dhparam[my.domain.tld]/Dhparam[/etc/letsencrypt/live/domain.tld/dhparam.pem]: Dependency Exec[letsencrypt certonly my.domain.tld] has failures: true
Warning: /Stage[main]/Profile::Letsencrypt/Module::Letsencrypt::Dhparam[my.domain.tld]/Dhparam[/etc/letsencrypt/live/domain.tld/dhparam.pem]: Skipping because of failed dependencies

What behaviour did you expect instead

letsencrypt-auto certonly should not be run or should interact with the prompt.

Output log

See above

The cronjob deployed by this module needs the command line options '--text --non-interactive' to avoid PythonDialogBug occurring under certain platforms. I get this under CentOS 7. The issue filed below with certbot reports it occurring under Ubuntu 14.04.
certbot/certbot#1154

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 4.10.0
• Ruby: ruby 2.1.9p490
• Distribution: Ubuntu 16.04.2 LTS (Xenial Xerus)
• Module version: commit e72470c (May 9th - latest commit)

How to reproduce (e.g Puppet code you use)

    letsencrypt::certonly { "LE ${server}":
      domains                           => [$server,],
      manage_cron                   => true,
      plugin                               => 'webroot',
      webroot_paths                 => [$webroot],
      cron_success_command => '/bin/systemctl reload nginx.service',
    }

What are you seeing

Note with the space in the name above, the module improperly creates a file with a space in the name. When running the command from cron, it would fail due to the space not being escaped.

What behaviour did you expect instead

The cron script substituting a character for space.

Any additional information you'd like to impart

Obviously this is an edge case and I fixed my issue by substituting the space with a -.

When running spec tests, there is an error because the CertBot command is not specified in the correct way:

error during compilation: Validation of Exec[initialize certbot] failed: 'certbot -h' is not qualified and no path was specified. Please qualify the command or specify a path. at ../modules/certbot/manifests/init.pp:98

Issue seems to be in this part:

if $install_method == 'package' {
    $command      = $package_command
    $command_init = $package_command
  } elsif $install_method == 'vcs' {
    $command      = "${venv_path}/bin/certbot"
    $command_init = "${path}/certbot-auto"
  }

And the params.pp set it to:

  } elsif $::osfamily == 'RedHat' and versioncmp($::operatingsystemmajrelease, '7') >= 0 {
    $install_method = 'package'
    $package_name = 'certbot'
    $package_command = 'certbot'

We have to excplitly set the $package_command now, which works, but does not feel right.

Is there a reason or incompatibility why the version currently defaults to v0.1.0 here?
lets-encrypt released v0.4.0 a couple of days ago, and I think I would be nice to upgrade the default.

And with this new release there is now support for a renew command, which could be used in the cron job.
https://letsencrypt.readthedocs.org/en/latest/using.html#renewal

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 5.9 + Hiera 4
• Ruby:
• Distribution: Stretch
• Module version: 2.1.0

How to reproduce (e.g Puppet code you use)

letsencrypt::certonly { 'somehost.subdomain.com':
  domains => ['somehost.subdomain.com', 'a.subdomain.com', 'b.subdomain.com'],
  plugin  => 'webroot',
}
letsencrypt::certonly { '*.subdomain.com':
  custom_plugins  => true,
}

What are you seeing

When I want to create a certificate for a wildcard domain, using the wildcard character *, this one is interpreted by the shell and replaced by all files present in current working directory of the command
The shell globbing function work by replacing all * with all files that match. So if you have previously defined a certificate that match the pattern (see exemple below) the problem occur

This problem may not have already occur because when no file match, the shell leave the wildcard in place as in this example :

[root@laptop-pg03 test]$ ls    # an empty directory
[root@laptop-pg03 test]$ echo *
*
[root@laptop-pg03 test]$ touch fic
[root@laptop-pg03 test]$ echo *
fic

What behaviour did you expect instead

The certbot command must be run with all domain name single quoted.

Output log

Certonly[letsencrypt-*.example.com]/Exec[letsencrypt certonly letsencrypt-*.example.com]/returns: usage:
Certonly[letsencrypt-*.example.com]/Exec[letsencrypt certonly letsencrypt-*.example.com]/returns: certbot [SUBCOMMAND] [options] [-d DOMAIN] [-d DOMAIN] ...
Certonly[letsencrypt-*.example.com]/Exec[letsencrypt certonly letsencrypt-*.example.com]/returns:
Certonly[letsencrypt-*.example.com]/Exec[letsencrypt certonly letsencrypt-*.example.com]/returns: Certbot can obtain and install HTTPS/TLS/SSL certificates.  By default,
Certonly[letsencrypt-*.example.com]/Exec[letsencrypt certonly letsencrypt-*.example.com]/returns: it will attempt to use a webserver both for obtaining and installing the
Certonly[letsencrypt-*.example.com]/Exec[letsencrypt certonly letsencrypt-*.example.com]/returns: certificate.
Certonly[letsencrypt-*.example.com]/Exec[letsencrypt certonly letsencrypt-*.example.com]/returns: certbot: error: unrecognized arguments: local.*.example.com preprod.*.example.com uat.*.example.com uat2.*.example.com
Error: 'certbot --text --agree-tos --non-interactive certonly -d *.*.example.com --manual --manual-auth-hook /usr/local/bin/certbot_rfc2136_auth.sh' returned 2 instead of one of [0]
Error: /Stage[main]/Profile::Letsencrypt/Brscommon::Define::Letsencrypt_certificate[*.*.example.com]/Letsencrypt::Certonly[letsencrypt-*.example.com]/Exec[letsencrypt certonly letsencrypt-*.example.com]/returns: change from notrun to 0 failed: 'certbot --text --agree-tos --non-interactive certonly -d *.*.example.com ' returned 2 instead of one of [0]
Certonly[letsencrypt-*.example.com]/File[/opt/puppetlabs/puppet/cache/letsencrypt/renew-letsencrypt-*.example.com.sh]/content:
--- /opt/puppetlabs/puppet/cache/letsencrypt/renew-letsencrypt-*.example.com.sh 2019-03-05 18:26:24.915103204 +0100
+++ /tmp/puppet-file20190305-11226-1ccf8ao    2019-03-05 18:31:11.273970967 +0100
@@ -1,2 +1,2 @@
 #!/bin/sh
-certbot --text --agree-tos --non-interactive certonly --keep-until-expiring -d *.example.com
\ No newline at end of file
+certbot --text --agree-tos --non-interactive certonly --keep-until-expiring -d *.*.example.com
\ No newline at end of file 

Any additional information you'd like to impart

I will provided a PR to fix this issue

I installed this module and ran it against a CentOS 6.7 system. I made sure to set the configure_epel option to true but I received the following error when applying the manifest:

Error: Execution of '/usr/bin/yum -d 0 -e 0 -y list letsencrypt' returned 1: Error: No matching Packages to list
Error: /Stage[main]/Letsencrypt/Letsencrypt::Install/Package[letsencrypt]/ensure: change from absent to present failed: Execution of '/usr/bin/yum -d 0 -e 0 -y list letsencrypt' returned 1: Error: No matching Packages to list
Notice: /Stage[main]/Letsencrypt/Exec[initialize letsencrypt]: Dependency Package[letsencrypt] has failures: true

(I should note that I had include epel in my primary manifest already, so EPEL should have already been configured.)

Looking through the EPEL package list I don't see letsencrypt listed anywhere (I assume here is the right place to look). I'm wondering if I'm missing something? I suppose it's possible that support for an RPM for letsencrypt got dropped from EPEL somewhere along the line. If that's true and there is no current RPM for letsencrypt, should the documentation be changed to reflect that?

Hello,
I too created a puppet module for letsencrypt. See: https://github.com/pgassmann/puppet-letsencrypt

Main Differences:

• Puppet 3.x and 4.x compatible
• Built to allow full automation in one run.
• Nginx vhost integration
• Has spec tests, but currently not not for many features.
• Missing documentation

Your module is actually the first Puppet 4.x module that I see. I would like to merge the modules, but this is probably not going to happen if you want to use the type features of Puppet 4.x

I welcome your feedback on my module.

There is currently no way for the module to clean up cronjobs when a domain is no longer in use.

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: any
• Ruby: any
• Distribution: any
• Module version: 3.0.1-rc1

How to reproduce (e.g Puppet code you use)

• Provision some certificate using letsencrypt::certonly with the ensure_cron option enabled.
• This domain stops being available for any reason (domain expired, DNS changed etc.)
• Try to de-provision cronjobs for renewing the certificate by setting ensure_cron to disabled.
• Module still tries (and of course fails) to get a certificate for the domain.
• Removing cronjobs fails because of failed dependencies.

Output log

Error: 'certbot --text --agree-tos --non-interactive certonly --rsa-key-size 4096 -a apache --cert-name LE_redacted.com -d redacted.com' returned 1 instead of one of [0]
Error: /Stage[main]/Profile::Lydia/Profile::Lydia::User[redacted]/Site_apache::Vhost::User[redacted.com]/Letsencrypt::Certonly[LE_redacted.com]/Exec[letsencrypt certonly LE_redacted.com]/returns: change from 'notrun' to ['0'] failed: 'certbot --text --agree-tos --non-interactive certonly --rsa-key-size 4096 -a apache --cert-name LE_redacted.com -d redacted.com' returned 1 instead of one of [0]

Any additional information you'd like to impart

This is a feature request, not a bug as the module is intended to function as it is doing, but there currently seems to be no options to deal with this sort of cleanup.

Using 'letsencrypt::certonly' it appears that adding extra domain names does not work once the certificate has been issued.

Running the command that eventually happens reveals that the certbot code goes user-interactive and asks if you wish to expand the certificate to cover the new domains, but the puppet module does not deal with this and the current certificate remains in place.

I have had a look on the letsencrypt community board and issue tracker, it seems that this is still something undergoing change but there is an '--expand' flag that certbot should honour to add new domains, possibly ONLY if they are a complete superset (you can't remove any).

I'm not sure what a good solution is here, possibly adding '--expand' for now but it will probably still fail when domains are removed since doing this does not affect the currently issued certificate and does not change the renewal paramters in /etc/letsencrypt/renewal/.conf