bzed / bzed-dehydrated Goto Github PK

Helllo,

• Debian: Stretch
• Puppet: 5.5.18
• Puppetserver: 5.3.11-1stretch
• puppetdb-termini: 5.2.12-1stretch

I try to get the module working. The base class is included on my dedicated ACME host (which is not the Puppetmaster) and also on the node, for which I try to get a certificate:

• ACME: acme.example.local
  Hiera:

---
classes:
  - dehydrated
...
dehydrated::dehydrated_host: 'acme.example.local'
dehydrated::base_dir: '/etc/letsencrypt'
dehydrated::group: 'ssl-cert'
dehydrated::contact_email: '[email protected]'
dehydrated::letsencrypt_ca: 'v2-production'
dehydrated::challengetype: 'dns-01'
dehydrated::dehydrated_hook: 'tophosting_hook.py'
dehydrated::dehydrated_domain_validation_hook: 'domain_validation_hook.sh'
dehydrated::dehydrated_environment:
  'PROVIDER': 'internetbs'

• node: git.example.com
  Hiera:

---
classes:
  - dehydrated
...
dehydrated::dehydrated_host: 'acme.example.local'
dehydrated::base_dir: '/etc/letsencrypt'
dehydrated::group: 'ssl-cert'
dehydrated::contact_email: '[email protected]'
dehydrated::letsencrypt_ca: 'v2-production'
dehydrated::challengetype: 'dns-01'
dehydrated::dehydrated_hook: 'tophosting_hook.py'
dehydrated::dehydrated_domain_validation_hook: 'domain_validation_hook.sh'
dehydrated::dehydrated_environment:
  'PROVIDER': 'internetbs'
 ....

dehydrated::certificates:
  'git.example.com':
    notify: "Service['nginx']"

I tried also:

dehydrated::certificates:
    - "*.git.example.com"

But nothing happens (except the defaults from the dehydrated class) ..., neither on my acme or git example nodes.
If I have a look on the loaded Puppet classes ...

# facter -p puppet_classes  |grep --color dehy
...
dehydrated, dehydrated::changed, dehydrated::config, dehydrated::cron, dehydrated::domains, dehydrated::p
arams, dehydrated::repo, dehydrated::user
....

I would expect to see dehydrated::certificate or dehydrated::certificates , so I have no idea .. what I missing ...

Two other question I have:

• Is it correct, that also the node, which requires a certificate requires a connection to the internet for register an letsencrypt account ?
• Is it possible, to only request the certificate from the node and lets do everything via the dedicated ACME host ? So no dehydrated needs to be installed :-)

cu denny

ps. thanks a lot for the work !

I'm in the presses of testing dehydrated so that I can migrate from the letsencrypt module. I'm using the following config has part of my testing.

On the dehydrated host:

  class { 'dehydrated' :
      dehydrated_host          => 'puppet.example.com',
      letsencrypt_ca           => 'staging',
      dehydrated_contact_email => '[email protected]',
      dehydrated_hook          => 'hook.py',
      dehydrated_environment   => {
          'CF_EMAIL' => '[email protected]',
          'CF_KEY'   => 'your-long-Cloudflare-api-key',
      }
  }

One host that are requesting certs:

  class { 'dehydrated' :
      dehydrated_host => 'puppet.example.com',
      group    => 'letsencrypt',
      base_dir => '/etc/letsencrypt',
  }

  dehydrated::certificate { 'host.example.com' : 
      notify  => Service['nginx'],
  }

When I look at the requests.json on the dehydrated host I see that letsencrypt_ca_url is set to https://acme-v02.api.letsencrypt.org/directory and dehydrated_hook_script is set to /opt/dehydrated/hooks/dns-01.sh. Given the config that I have on the dehydrated host I'm expecting letsencrypt_ca_url to be set to the staging CA and dehydrated_hook_script to be set to /opt/dehydrated/hooks/hook.py. Am I misunderstanding how this should be setup? Do letsencrypt_ca and dehydrated_hook need to be set on each host? I know that dehydrated_hook can be set for each dehydrated::certificate, but I figured it would default to what was set on the dehydrated host when it was not set.

Also is there a way to manually run the cron job to make the certificate requests?

Hi, I use this module in a custom vhost module to give certificates to internal hosts via dns-01 validation. My current problem is that after adding the vhost apache is configured to add a ssl vhost with the cerifificates but these are not there yet because of the workflow of this module. Therefore I want apache to only reconfigure after the certificates have been deployed. Is there a way (fact or defined resource) to detect that the certificate is finished deploying?

Kind regards Clemens.

Hey! Still using your awesome Puppet module. All of a sudden I see 49 failed certs, all listed as OSCP update failed. Do you happen to know what might have caused that? I think I may need to update to the most recent version of your code / dehydrated, but I also need to read and remember how to do that :)

Hope all is well!

Seems the CA cert won't be changed while switchung CAs.

hi,

I saw in this issue, that it is possible to overwrite the default. I wonder, how the Hiera syntax is looking. Can you give me a short example ?

cu denny

The letsencrypt change from "DST Root CA X3" to "ISRG Root X1" is not tracked by dehydrated_job_runner.rb if the certificate was first issued before the new intermediate CA became the default because the issuer URI stays the same.

Hey, I'm not totally sure if this will fix my issue, but there was some critical API V1 thing that was fixed in Dehydrated 0.6.5 and it looks like your package pulls in 0.6.2 by default. I'm going to try to open a PR if my latest run works, but without that upgrade it looks like all requests to LE fail with a Account ID malformed thing.

Lukas sold off dehydrated, so the repository URL changed to:

• https://github.com/dehydrated-io/dehydrated

Will add Pull request soon.

Hi,

if I understood the workflow correctly (see #13) there are 4 puppet runs needed on the target until everything is ready. Wouldn't it be possible to deploy the combined files in run 3 an save the last run?

Kind Regards
Clemens

Hi,

first of all: thanks for this really neat helpful module!

I'm using it on multiple systems with http-01, requesting and deploying certificates works like a charm.

On single webservers (just one webserver which uses the certificate), this works perfect:

• hiera:

  dehydrated::dehydrated_host: "%{facts.fqdn}"

• manifest:

  dehydrated::certificate{$facts['fqdn']: }
  

This requests, retrieves and renews the certificate - perfect.

For one project, we have a load balancer based setup: three nodes with HAProxy (puppetlabs-haproxy) and virtual IP with Corosync/Pacemaker.

• all three nodes should share the same certificates, so the failover will work immediately without having the need to request a new certificate first.
• LB1 is the dehydrated_host, we use again http-01 (no access to DNS)
• the other LBs request certificates
• and lb1 as the mostly-active node will request, validate and retrieve the certificate. This does work.

As three different nodes define their own (but identical!) set of dehydrated::certificate, this will result in three different certificates being requested from Let's Encrypt. Due to (failed) tests I managed to hit the rate limits, which should of course not happen.

My idea now was to use exported Ressources: define just on lb1, but collect on all three.

  if $facts['fqdn'] == $dehydrated::dehydrated_host {
    $certificates.each | $certificate | {
      @@dehydrated::certificate { $certificate[0] :
        subject_alternative_names => $certificate[1],
        tag                       => [
          $facts['domain'],
        ],
      }
    }
  }
  Dehydrated::Certificate <<| tag == $facts['domain'] |>>

Instead of having one single certificate that will only be transferred to multiple nodes, this results also in three seperate requests in /opt/dehydrated/requests.json.

How can I solve this?

• collecting dehydrated::certificate doesn't work, as shown
• using dehydrated::certificate::collect is - of course - decouraged.
• changing the requester attribute, so the certificates will share a single requester FQDN might be possible, but I didn't change the module yet to test this.

Am I holding it wrong, or was this not yet intended use?

Will look into possible fixes now.

Best,
Anton

P.S.: let me know how to compensate your work on this module/issue.

Yo! So this has been working so well, thank you again. Something happened with our PuppetDB instance after an upgrade and I was basically forced to upgrade to PuppetDB5 in a new VM then update the paths for Puppet server. Everything seems to be working with the exception of our dehydrated stuff. During a Puppet run I saw that everything had basically been removed from requests.json and we're left with an empty file.

Checking the requests folder I see that everything is still there, but it's as if all of the knowledge of all of the certs is somehow gone. Do you have any idea what could have caused that / what I can do to get things up and running again?

I love your Instagram, you take the most awesome adventures!

PS: There was one message associated with the run: \ No newline at end of file right after it removed everything, followed by

Info: Computing checksum on file /opt/dehydrated/requests.json
Info: /Stage[main]/Dehydrated::Setup::Dehydrated_host/Concat[/opt/dehydrated/requests.json]/File[/opt/dehydrated/requests.json]: Filebucketed /opt/dehydrated/requests.json to puppet with sum 93a09ba9d702bf75ec30b80a63fd8c12

For some reason when my OCSP files are updated nginx is not getting notified to restart. When that cert is updated the servers is notified and restarts. Bellow is config that I'm using.

  dehydrated::certificate { "${myhostname}" : 
      notify  => Service['nginx'],
  }

Hi. Some of the domains I'll be requesting certs for are on Cloudflare, others are on Route53. How do I indicate which provider to use when requesting a cert from a host?

Thank you!

Right after your cert renews you will get OCSP errors in Firefox and Chrome if you have OCSP stapling set up.

The OCSP response does not include a status for the certificate being verified. Error code: MOZILLA_PKIX_ERROR_OCSP_RESPONSE_FOR_CERT_MISSING

Looking at the host it looks like the OCSP file is older than the new cert file. I'm pretty sure I'm getting this error because my system is using the OCSP file for the old cert. It looks like this is happening because the OCSP files is not getting updated after your cert is renewed. Adding something that checks if the cert if newer than the OCSP files should fix this.

When installing bzed-dehydrated (1.9) together with stdlib >= 9.0.0 you get the following error

Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Unknown function: 'has_key'. (file: /etc/puppetlabs/code/environments/production/modules/dehydrated/manifests/init.pp, line: 238, column: 8) on node <FQDN of Puppetserver>

Since the has_key is deprecated it should be replaced with something modern.

puppetlabs/puppetlabs-stdlib#1319

Don't configure a hook for http-01 if hook was not explicitly configured

Hello,

is there a way to keep the credentials / secrets away from diffs (we keep them in eyaml files) ? If I execute the run, than the json file diff will be shown in the logs and on the screen. We want to make sure, that the username/password/api_key is not published.

The cronjob does not currently take any parameters other than the user.
In my specific case ruby, which is required for the cronjob to run, is not installed on a system level and needs PATH adjustments (possible due to #1).

My idea was to pass the environment set here:

As a parameter to the cronjob too:

I don't know about the impact of that specific change, hence the issue (as opposed to a PR).
What approach would you recommend?
Maybe a second variable?
Exposing all of the cronjob parameters as dehydrated::cron, to be as flexible as possible?