5 AutoACME in a web farm environment
Arsène von Wyss edited this page 2018-11-28 15:27:31 +01:00

In a web farm scenario, the centralized certificate store is usually configured on a UNC path so that all servers have access to the same PFX files.

Since the web farm has several (usually redundant) web servers which shall not have special roles, running a scheduled AutoACME instance on one server is not a desirable configuration. Configuring AutoACME on all servers (which then may concurrently try to renew certificates) would cause issues and it is therefore not a suitable configuration either. Also, for security reasons, you may want to restrict write access to the certificate store UNC path used by the web farm servers.

To deal with this kind of setup, AutoACME can be installed and configured on a back-end server which is independent of the web farm servers. That server does not need to be exposed to the internet directly, and it does not even require IIS to be installed.

Operation with self-hosted HTTP challenge

In this mode, AutoACME provides a HTTP server endpoint which replies to incoming HTTP challenge verification requests from LE. These requests are reverse-proxied to the computer running AutoACME in the same fashion as with file-based HTTP authorization, but no files are ever written and there is no need for a dedicated IIS site for hosting the challenge files.

Differences in configuration compared to getting started with AutoACME

Prerequisites

  • Identical for the web farm servers (they require the same IIS modules).
  • The server running AutoACME only needs Windows Server 2012 or newer (IIS is not required).

Configuration

  • Configure Centralized certificate store

    To be performed on each web farm server. Use a UNC share as physical path and specify a user with (ideally, but at least) read access to that path.

  • Configure web site for handling of ACME challenges

    Skip. Do not configure a web site for ACME challenges.

  • Configure rewriting rule for handling of ACME challenges

    To be performed on each web farm server. Rewrite to http://acme-server/Temporary_Listen_Addresses/AutoACME/{R:1} (where acme-server is the back-end server running AutoACME).

  • Configure AutoACME using the autoacme initcfg command

    To be performed on the AutoACME back-end server. Since IIS is not used, skip the part about configuring the Content-Type header. Instead, edit the configuration file as follows:

    • "PfxFolder": Path accessed by the web farm hosts via UNC, but with write access by the user running AutoACME (remember to use a suitable user for the scheduled task, too).
    • "SelfHostChallenge": true

    Note: Make sure that the firewall on the AutoACME back-end server does allow incoming requests on port 80 from the web farm servers. If you have additional network-level firewalls between the web farm servers and the back-end server, also configure a rule to allow this access.

Maintenance

These steps only need to be done on the single AutoACME back-end server. The challenges should come through from the web farm server to the AutoACME application like so (extract of the AutoACME console output when self-hosting):

    Getting challenge...OK, the following is challenge URI:
    https://acme-v01.api.letsencrypt.org/acme/challenge/eMY4_oPKvWFttZ_-xyQ7-H-ZuQ-x_Wr7zzMESxPN1WQ/9232310302
    Listening on http://+:80/Temporary_Listen_Addresses/AutoACME/
    Completing challenge...OK
    Waiting for authorization...Handling request from 10.10.10.123
    .OK
  Processing certificate:

Configuring a scheduled task is highly suggested. The web farm servers do not require maintenance in regards of AutoACME.

Operation with DNS challenge

In this mode, AutoACME creates temporary DNS TXT challenge records in a dedicated Microsoft DNS Server ACME domain. The domains to be managed require a DNS CNAME record pointing to a record of the ACME domain. This setup allows to avoid problems with DNS caching and replication latencies, since the ACME domain entries are distinct from the managed domain and with a short TTL.

Differences in configuration compared to getting started with AutoACME

Prerequisites

  • The web farm servers only need IIS with Centralized Certificate Store (they do not require URL rewriting or ARR for AutoACME to work).
  • The server running AutoACME only needs Windows Server 2012 or newer (IIS is not required).
  • A Microsoft DNS Server which is accessible from the internet.
  • AutoACME needs to run in a user context which has the right to add and remove DNS records on that DNS server (through WMI).

Configuration

  • Configure Centralized certificate store

    To be performed on each web farm server. Use a UNC share as physical path and specify a user with (ideally, but at least) read access to that path.

  • Configure web site for handling of ACME challenges

    Do not configure a web site for ACME challenges. Instead, create a dedicated primary DNS zone (no AD replication) on the Microsoft DNS Server to be used by AutoACME, such as acme.company.com. Note that the domain name can be anything, it is independent of the domains to me managed (e.g. for which you want to get certificates). Make sure that this zone can be directly queried from the internet (for example with an appropriate NS record on the domain company.com).

  • Configure rewriting rule for handling of ACME challenges

    Do not configure a rewriting rule for handling of ACME challenges. Instead, configure DNS CNAME records on each domain and sub-domain to be managed like so:

    • _acme-challenge.example.com CNAME example.com.acme.company.com.
    • _acme-challenge.www.example.com CNAME www.example.com.acme.company.com.
    • _acme-challenge.test.example.com CNAME test.example.com.acme.company.com.
  • Configure AutoACME using the autoacme initcfg command

    To be performed on the AutoACME back-end server. Since IIS is not used, skip the part about configuring the Content-Type header. Instead, edit the configuration file as follows:

    • "PfxFolder": Path accessed by the web farm hosts via UNC, but with write access by the user running AutoACME (remember to use a suitable user for the scheduled task, too).
    • "DnsChallenge": true
    • "DnsServer": Name of the Microsoft DNS Server (for WMI).
    • "DnsDomain": Name of the AMCE domain on the DNS server (acme.company.com).

Maintenance

These steps only need to be done on the single AutoACME back-end server. The challenges should be processed like so:

  Getting challenge...OK, the following is DNS name:
  exmaple.org
  Completing challenge.OK
Processing certificate:

Configuring a scheduled task is highly suggested. The web farm servers do not require maintenance in regards of AutoACME.

Operation with DNS and self-hosted HTTP fallback

Both operation modes can be configured as described here simultaneously. In this case, AutoACME will test the DNS setup first and fall back to self-hosted HTTP if the DNS setup fails. This allows for mixed setups, for instance when sites without full DNS control are to be managed by AutoACME.