Using Infoblox for DNS Validation with Certbot

You can use DNS-based Let's Encrypt validation through Infoblox's API to avoid exposing your host directly to the public Internet. The following instructions show how to configure your local certbot installation in order to accomplish this. Please note that a service account in Infoblox is required to complete the setup, so if you don't currently have a service account in Infoblox, you can contact the Research Computing Services in order to request one.

Installing the Appropriate Modules

Since certbot is a Python tool, you'll need to install some Python modules to successfully perform DNS validation. Unfortunately, the Certbot Infoblox DNS plugin itself hasn't been packaged in the standard Debian or RedHat repositories, so your best bet is to create a virtualenv for certbot in order to have everything you need.

In the examples below, we'll use /opt/venv/certbot as the virtualenv path, but you can use a different path if that suits you better.

Start by Preparing your Virtualenv

mkdir -p /opt/venv
python3 -m venv /opt/venv/certbot

Install the Certbot Modules

You'll need at least certbot, certbot-dns-infoblox, infoblox-client, and zope pip modules in your virtualenv:

$ source /opt/venv/certbot/bin/activate
(certbot) $ python3 -m pip install certbot certbot-dns-infoblox infoblox-client zope

Prepare your credentials file

Use the service account details you've received from IS&T to create a credentials file so that the certbot plugin knows how to authenticate against our Infoblox servers. By default this file is placed at /etc/letsencrypt/infoblox.ini, but you can put it anywhere you'd like, as long as you include the --certbot-dns-infoblox argument when you run certbot.

The contents of your file should contain:

dns_infoblox_hostname="infoblox.triumf.ca"
dns_infoblox_view="external"
dns_infoblox_username="my-username"
dns_infoblox_password="my-password"

Replace "my-username" and "my-password" as appropriate.

As the credentials file contains sensitive information, it should have its permissions limited so that only the user running certbot can read from it. Ie. chown certbotuser:certbotgroup and chmod 440.

Note: the username and password values come from a service account that will be provided for you from IS&T. Do not use your personal TRIDENT credentials here. If you are missing a service account for your certbot setup, you can request one by emailing the Research Computing Services Helpdesk queue at rt-rcs@helpdesk.triumf.ca.

Fetch your certificate

When generating your certificate, you'll need to pass a few options to make use of the Infoblox DNS plugin:

  1. --authenticator dns-infoblox - this tells certbot to use the custom Infoblox authenticator plugin
  2. --dns-infoblox-propagation-seconds <n> - this option tells the Infoblox that certbot should wait <n> seconds before the Let's Encrypt ACME servers attempt to validate the DNS entry. A longer wait time gives a higher likelyhood that old _acme-challenge DNS entries have fallen out of DNS server cache(s). Default is 10 seconds.
  3. --dns-infoblox-credentials <credentials-file-path> - if you've placed your credentials file at /etc/letsencrypt/infoblox.ini, then you don't need this. If your file exists somewhere else, you can use this option to specify its location.

All other options are the standard ones you'd expect from running certbot with other validation types.

Example

Below is an example of using Infoblox DNS validation with certbot to register certificates for test1.myzone.triumf.ca and test2.myzone.triumf.ca, assuming that our virtualenv is at /opt/venv/certbot, that I've placed credentials at /usr/local/etc/letsencrypt/infoblox.ini, and that my Let's Encrypt email address is letsencrypt@myzone.triumf.ca:

$ source /opt/venv/certbot/bin/activate
(certbot) $ certbot certonly --noninteractive --agree-tos --authenticator dns-infoblox --dns-infoblox-credentials /usr/local/etc/letsencrypt/infoblox.ini --email letsencrypt@myzone.triumf.ca -d test1.myzone.triumf.ca -d test2.myzone.triumf.ca

Automating Renewals

It's a good idea to set up some way of automatically renewing your certificate once it is nearing expiration. Normally, the standard certbot package for your distro installs a systemd service and timer for this purpose. Since we install certbot through pip, we have to manually perform this task ourselves. IS&T follows the practice in RedHat-based distributions of using an environment file in /etc/sysconfig/certbot to simplify the configuration of renewal hooks.

The steps to duplicate this setup are listed below:

Install your Systemd files

In /usr/local/lib/systemd/system (you may need to create this directory - see man systemd.unit for the list of all systemd unit search paths) add a file called certbot-renew.service with the following contents:

[Unit]
Description=This service automatically renews any certbot certificates found

[Service]
EnvironmentFile=/etc/sysconfig/certbot
Type=oneshot
ExecStart=/opt/venv/certbot/bin/certbot renew --noninteractive --no-random-sleep-on-renew $PRE_HOOK $POST_HOOK $RENEW_HOOK $DEPLOY_HOOK $CERTBOT_ARGS
  • Replace /opt/venv/certbot with your virtualenv path, if different.
  • On Debian-based systemd, you might want to use EnvironmentFile=/etc/default/certbot

In the same /usr/local/lib/systemd/system path, add a certbot-renew.timer file to automatically trigger the certbot-renew.service unit:

[Unit]
Description=This is the timer to set the schedule for automated renewals

[Timer]
OnCalendar=*-*-* 00/12:00:00
RandomizedDelaySec=12hours
Persistent=true

[Install]
WantedBy=timers.target

Prepare an /etc/sysconfig/certbot file (or /etc/default/certbot in Debian environments):

## NOTE ##
# If a hook is set here then it will be used for all
# certificates and will override any per certificate
# hook configuration in place.

# 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. When renewing several certificates
# that have identical pre-hooks, only the first will be
# executed.
#
# An example to stop the MTA before updating certs would be
# PRE_HOOK="--pre-hook 'systemctl stop postfix'"
PRE_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. If
# multiple renewed certificates have identical post-
# hooks, only one will be run.
#
# An example to restart httpd would be:
# POST_HOOK="--post-hook 'systemctl restart httpd'"
POST_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 the
# config live subdirectory containing the new certs and
# keys; the shell variable $RENEWED_DOMAINS will contain
# a space-delimited list of renewed cert domains
#
# An example to run a script to alert each cert would be:
# DEPLOY_HOOK="--deploy-hook /usr/local/bin/cert-notifier.sh"
DEPLOY_HOOK=""

# Any other misc arguments for the renewal
# See certbot -h renew for full list
#
# An example to force renewal for certificates not due yet
# CERTBOT_ARGS="--force-renewal"
CERTBOT_ARGS="--authenticator dns-infoblox"

Update the PRE_HOOK, POST_HOOK and DEPLOY_HOOK options as required. You may also need additional arguments passed in CERTBOT_ARGS if you've used any of the other --dns-infoblox-* arguments when fetching certificates.

Once everything is in place, reload systemd, enable your timer and test a renewal:

$ systemctl daemon-reload
$ systemctl enable --now certbot-renew.timer
Created symlink '/etc/systemd/system/timers.target.wants/certbot-renew.timer' → '/usr/local/lib/systemd/system/certbot-renew.timer'.
$ systemctl start certbot-renew.service

If all has gone well, you should see the renew timer in the list of running systemd timers:

$ systemctl list-timers | grep certbot-renew
Tue 2026-02-24 07:31:04 PST      18h -                                      - certbot-renew.timer          certbot-renew.service

results matching ""

    No results matching ""