bzed / bzed-dehydrated

Puppet module for centralized CSR signing using Let’s Encrypt™ and lukas2511/dehydrated - keeping your keys safe on the host they belong to.
9 stars 11 forks source link

one certificate on multiple servers #11

Open antondollmaier opened 4 years ago

antondollmaier commented 4 years ago

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:

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.

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?

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.

bzed commented 4 years ago

Hi Anton,

implementing something to collect the certificates is the easy part. But as the keys are not passed around, you'd have to find a way to dostribute them. If you distribute the keys, you can also distribute the certificate on the same way.

So the solution to this issue is not as easy as it seems to be... What I usually do - as we have NetApp NFS Metroclusters - is to mount a NFS share on all LB and share the certificates on that way. And generating the certs is forced to be on the first LB by forwarding http requests on the other LBs to the first one if they match the acme path.

Does that help?

Best regards,

Bernd

P.S. https://www.amazon.de/hz/wishlist/ls/1TXINPFZU79GL?ref_=wl_share

antondollmaier commented 4 years ago

Servus Bernd,

implementing something to collect the certificates is the easy part. But as the keys are not passed around, you'd have to find a way to dostribute them. If you distribute the keys, you can also distribute the certificate on the same way.

Ah, I missed that the keys are not transferred.

So the solution to this issue is not as easy as it seems to be... What I usually do - as we have NetApp NFS Metroclusters - is to mount a NFS share on all LB and share the certificates on that way. And generating the certs is forced to be on the first LB by forwarding http requests on the other LBs to the first one if they match the acme path.

Good choice - will obviously work as well.

I'm thinking about collecting the certificate for HAProxy (concatenated private key + cert + CA) and then exporting this file with the key.

Thanks for the insight!

tepecat commented 4 years ago

for me works follow solution really good:

bzed commented 4 years ago

@tepecat nice idea! I'll put that into the README.