1. Overview
2. Module Description - What the module does and why it is useful
3. Setup - The basics of getting started with letsencrypt_nginx
4. Usage - Configuration options and additional functionality
5. Reference - An under-the-hood peek at what the module is doing and how
6. Limitations - OS compatibility, etc.
7. Development - Guide for contributing to the module

The goal of Let's Encrypt is to automate ssl certificates.

This module is a helper to manage letsencrypt for puppet managed nginx servers.

Works with puppet/letsencrypt and puppet/nginx

The goal of this module is to enable ssl on puppet managed nginx servers as simple as possible. The module reuses the domains configured in the server server_name

For the authorization, the webroot challenge is used and a custom location is automatically added to the ngninx server so that the challenge path is using the letsencrypt webroot. This allows to solve the challenge even if the server is just a proxy to another server.

• configure locations for the letsencrypt challenge path for defined servers and default server
• Define default server for nginx that catches all requests that do not match a server_name
• Uses letsencrypt::certonly to get certificate (requires puppet-letsencrypt)
• Tell letsencrypt::certonly to manage cron for renewals

• Manage nginx server ssl configuration. Configure the server ssl and certificate as seen in the examples below.

Requests to Port 80 (and 433) of the IPv4 address of the domains to encrypt need to reach your server.

This module uses the puppet/letsencrypt module, see it's documentation for the letsencrypt options

See the following example for encrypting a nginx server. This will successfully configure nginx, the server and the ssl certificat in one run, if added to a blank Server.

Important: You should declare letsencrypt_nginx resources after the nginx resources. The fetching of the configured domains is parse order dependent.

nginx::resource::server { 'letsencrypt-test1.example.com':
  server_name      => [
    'letsencrypt-test1.example.com',
    'letsencrypt-test2.example.com',
  ],
  proxy            => 'http://10.1.2.3',
  ssl              => true,
  ssl_redirect => true,
  ssl_key          => '/etc/letsencrypt/live/letsencrypt-test1.example.com/privkey.pem',
  ssl_cert         => '/etc/letsencrypt/live/letsencrypt-test1.example.com/fullchain.pem',
}
class { ::letsencrypt:
  email => '[email protected]',
}
class { 'letsencrypt_nginx':
  firstrun_webroot => '/var/www/html',
  servers           => {
    'letsencrypt-test1.example.com' => {},
  },
}

To add ssl configuration to an existing installation, you need first to configure the locations for your default server and your existing server.

class { 'letsencrypt_nginx':
  locations => {
    'default' => {}
    'letsencrypt-test1.example.com' => {}
  }
}

If this is applied successfully, you can then add the ssl configuration to your nginx server as above and declare your letsencrypt_nginx::server

classes:
  - nginx
  - letsencrypt
  - letsencrypt_nginx

nginx::servers:
  'letsencrypt-test1.example.com':
      server_name:
                            - 'letsencrypt-test1.example.com'
                            - 'letsencrypt-test2.example.com'
      proxy:                'http://10.1.2.3'
      ssl:                  true
      ssl_redirect:     true
      ssl_key:              '/etc/letsencrypt/live/letsencrypt-test1.example.com/privkey.pem'
      ssl_cert:             '/etc/letsencrypt/live/letsencrypt-test1.example.com/fullchain.pem'

letsencrypt::email: '[email protected]'
# use staging server for testing
letsencrypt::config:
  server: 'https://acme-staging.api.letsencrypt.org/directory'

letsencrypt_nginx::firstrun_webroot: '/var/www/html'
letsencrypt_nginx::servers:
  'letsencrypt-test1.example.com': {}

Let's Encrypt base configuration and hiera interface.

• default_server_name: name of nginx server that catches all requests that do not match any other server_name

• webroot: This directory is configured as webroot for the webroot authentication locations added to the server to allow renewals

• firstrun_webroot: Use different webroot on first run. Set this to the default webroot of the webserver if the service starts automatically when installed. E.g. For Nginx on Ubuntu: /var/www/html

• firstrun_standalone: Use standalone mode on first run. Set this to true if the webserver does not start automatically when installed. letsencrypt will use standalone mode to get the certificate before the webserver is started the first time.

• locations, servers: These Parameters can be used to create instances of these defined types through hiera

Automatically get ssl certificate for nginx server

• domains: Array of domains to get ssl certificate for. If not defined, it uses the server_name array defined in the server. Use these domains instead of reading server_name array of server.

• exclude_domains: Array of servernames that should not be added as alt names for the ssl cert. E.g. Elements of server_name that are defined in the server, but are not public resolvable or not valid fqdns.

• webroot_paths: Passed to letsencrypt::certonly, not recommended to change An array of webroot paths for the domains in domains. Required if using plugin => 'webroot'. If domains and webroot_paths are not the same length, webroot_paths will cycle to make up the difference.

• additional_args: Passed to letsencrypt::certonly An array of additional command line arguments to pass to the letsencrypt-auto command.

• manage_cron: Passed to letsencrypt::certonly, default: true Boolean indicating whether or not to schedule cron job for renewal. Runs daily but only renews if near expiration, e.g. within 10 days.

Configure acme-challenge location webroot for a nginx server

• server: server to configure location for, defaults to $name

Run bundle exec rake to execute the spec tests. There are already some basic tests for each class and define, but not all options are covered.

See CHANGELOG.md

• Philipp Gassmann [email protected]

Apache 2.0

• Automatically configure SSL certificate and key on the server
• Add Domains to existing Certificates
• Support for RedHat, CentOS etc.