Installing cert on multiple servers (subdomains)

Help
1

Some parameters of what I'm doing

  • I am moving from a paid (ssl.com) cert for our domain to letsencrypt.org.
  • I am deploying the new cert on our DEV box (we also have QA and PROD).

Then the steps I've taken

  • I was able to manually generate a certificate for the base domain
  • I am attempting to install the new cert
  • I get the message

We were unable to find a vhost with a ServerName or Address of usaftechconnect.com.
Which virtual host would you like to choose?

and lists the 55 different hosts we have configured in 37 .conf files in /etc/httpd/conf, some of which are this domain, some are other domains (we have 3 currently).

  • I created a /etc/letsencrypt/options-ssl-apache.conf file for usaftechconnect.com (though that actually resolves to the PROD server, not the DEV one I'm working on).
  • When I select this from the list, it then gives me the list of all the configurations that pointed to the old certificate, I hit return to update all of them.
  • Looking at the .conf files, they now point to the new certificate
    Include /etc/letsencrypt/options-ssl-apache.conf
    SSLCertificateFile /etc/letsencrypt/live/usaftechconnect.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/usaftechconnect.com/privkey.pem
  • However I get the error below:
Failed redirect for usaftechconnect.com
Unable to set the redirect enhancement for usaftechconnect.com.
Unable to find corresponding HTTP vhost; Unable to create one as intended addresses conflict; Current configuration does not support automated redirection
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

I get the same results when I run it -i apache and without certonly --manual

The good news is

  • I then reload appache ( sudo systemctl reload httpd ).
  • I hit one of these websites, and get the new certificate. GREAT!

However, I am concerned about this error.
What am I doing wrong to get this? I want to set up automated renewals (on all three servers), but don't want this to cause them to fail.

I'm wondering if this because I'm not on the host for the base domain (I don't want to experiment on our PROD system like I can on DEV).

Lastly, what is the best way to load the cert on multiple servers (i.e. DEV, QA and PROD)? My first thought was to put /etc/letsencrypt on a shared drive, then set up the cron job on one server to generate the new cert, and a later job on the other 2 to just install it.

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: usaftechconnect.com, *.usaftechconnect.com

I ran this command: certbot install --cert-name usaftechconnect.com

It produced this output:

Failed redirect for usaftechconnect.com
Unable to set the redirect enhancement for usaftechconnect.com.
Unable to find corresponding HTTP vhost; Unable to create one as intended addresses conflict; Current configuration does not support automated redirection
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

My web server is (include version):Apache/2.4.57 - httpd

The operating system my web server runs on is (include version):Rocky Linux 9.4 (Blue Onyx)

My hosting provider, if applicable, is: AWS gov-cloud

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):4.2.0

2

Welcome @michael.carter There are a number of issues here but I'll start on these

To be able to automate renewals you'll need to stop using the --manual option. That requires manual actions for every renewal. Are you able to use Certbot's Route53 plugin to acquire the cert: Welcome to certbot-dns-route53’s documentation! — certbot-dns-route53 0 documentation This would allow fully automated renewal.

What Certbot is looking for is a VirtualHost for HTTP on port 80 that names that domain.

Installing the cert is perhaps a misnomer. Installing involves updating your Apache config which is some SSL options and the lines to locate the cert files.

There is no install activity for renewals. Well, at least not if you use the Certbot renew command which is the normal way to handle auto-renew.

Using the Apache plugin as installer updates the Apache config on the system Certbot runs on. Using the Apache plugin for authentication is similar although because you are using a DNS Challenge for a wildcard cert so that does not apply for you.

Personally, I'd avoid using Certbot on all 3 servers and instead acquire / renew the cert in one place and distribute it to the others. Once you have the working Apache config on that system make changes to the other two servers by hand the same as you would any other changes you keep in sync across them.

Storing /etc/letsencrypt in a common location is one way although probably better to just distribute the "options" include file along with fullchain and privkey. Be sure to take precautions with privkey as it is a sensitive file.

Other volunteers may suggest more advance ways of managing "secrets". I just wanted to start framing the discussion.

3

@MikeMcQ is correct, you're going to be way better off having a central place that does ACME and collect your certificates, then distribute them to the servers/endpoints that need them. This is complicated, but doable. You'll need to build some software or scripts (or shared drives) to copy the secrets around to the other hosts, update the configuration files (unless you just overwrite the previous), and then restart the servers.

You may also want to set some timing around things so you don't restart the servers in the middle of a day if they maintain connections like VPNs.

If you don't want to build this sort of thing yourself, there are commercial packages for doing it, (Certificate Lifecycle Management). I build one called CertKit.