Cert install fails on apache 2.2

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. https://crt.sh/?q=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: asacp-ai.org

I ran this command: sudo /usr/local/bin/certbot-auto --apache

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
No names were found in your configuration files. Please enter in your domain
name(s) (comma and/or space separated) (Enter ‘c’ to cancel): asacp-ai.org
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for asacp-ai.org
Waiting for verification…
Cleaning up challenges

We were unable to find a vhost with a ServerName or Address of asacp-ai.org.
Which virtual host would you like to choose?


1: 000-default | | | Enabled
2: 000-default-ssl | | HTTPS | Enabled


Select the appropriate number [1-2] then [enter] (press ‘c’ to cancel): 2
Deploying Certificate to VirtualHost /etc/httpd/conf/sites-enabled/000-default-ssl
An unexpected error occurred:
Traceback (most recent call last):
File “/opt/eff.org/certbot/venv/bin/letsencrypt”, line 11, in
load_entry_point(‘letsencrypt==0.7.0’, ‘console_scripts’, ‘letsencrypt’)()
File “/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/main.py”, line 1378, in main
return config.func(config, plugins)
File “/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/main.py”, line 1140, in run
_install_cert(config, le_client, domains, new_lineage)
File “/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/main.py”, line 764, in _install_cert
path_provider.cert_path, path_provider.chain_path, path_provider.fullchain_path)
File “/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot/client.py”, line 507, in deploy_certificate
fullchain_path=fullchain_path)
File “/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot_apache/configurator.py”, line 386, in deploy_cert
self._deploy_cert(vhost, cert_path, key_path, chain_path, fullchain_path)
File “/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot_apache/override_centos.py”, line 100, in _deploy_cert
self._deploy_loadmodule_ssl_if_needed()
File “/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot_apache/override_centos.py”, line 162, in _deploy_loadmodule_ssl_if_needed
beginning=True)[:-1]
File “/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot_apache/parser.py”, line 464, in get_ifmod
return self.create_ifmod(aug_conf_path, mod, beginning)
File “/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot_apache/parser.py”, line 486, in create_ifmod
“IfModule”, True)
File “/opt/eff.org/certbot/venv/lib64/python3.4/site-packages/augeas.py”, line 369, in insert
raise ValueError(“Unable to insert label!”)
ValueError: Unable to insert label!
Please see the logfiles in /var/log/letsencrypt for more details.

IMPORTANT NOTES:

  • Unable to install the certificate
  • Congratulations! Your certificate and chain have been saved at:
    /etc/letsencrypt/live/asacp-ai.org/fullchain.pem
    Your key file has been saved at:
    /etc/letsencrypt/live/asacp-ai.org/privkey.pem
    Your cert will expire on 2019-11-09. To obtain a new or tweaked
    version of this certificate in the future, simply run certbot-auto
    again with the “certonly” option. To non-interactively renew all
    of your certificates, run “certbot-auto renew”

My web server is (include version): apache 2.2

The operating system my web server runs on is (include version): centos 6.10

My hosting provider, if applicable, is: not applicable

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): certbot 0.37.1

Fix:
The cause of the error is that the configuration for ssl is divided between two files ssl.load and ssl.conf. Making the following change fixes the problem:
In /opt/eff.org/certbot/venv/lib64/python3.4/site-packages/certbot_apache/override_centos.py
changed line 109 LoadModule to IfModule
was: 109 loadmods = self.parser.find_dir(“LoadModule”, “ssl_module”, exclude=False)
now: 109 loadmods = self.parser.find_dir(“IfModule”, “ssl_module”, exclude=False)

Hi @seanstrygg

looks like you don’t have a correct vHost configuration.

And your configuration is incomplete. Your last two certificates ( https://check-your-website.server-daten.de/?q=asacp-ai.org#ct-logs ):

Issuer not before not after Domain names LE-Duplicate next LE
Let’s Encrypt Authority X3 2019-08-11 2019-11-09 asacp-ai.org - 1 entries duplicate nr. 1
RapidSSL RSA CA 2018 2018-10-08 2019-10-08 asacp-ai.org, www.asacp-ai.org - 2 entries

The RapidSSL certificate has two domain names. Your Letsencrypt certificate has only one domain name.

So your www version isn’t secure.

First step: Check your vHost configuration

apachectl -S

Then add an explicit port 80 vHost with

ServerName asacp-ai.org
ServerAlias www.asacp-ai.org

Then create a new certificate with

sudo /usr/local/bin/certbot-auto --apache -d asacp-ai.org -d www.asacp-ai.org

and use that instead.

That

says: There is no named vHost.

1 Like

The fault is not with my configuration. Your software needs to be adaptable to work with more than the defaults that you are aware of. The simple fix I propose does not break anything and will pick up the correct file. Please stop making extra work for people.

The way the software has to work is clearly written in RFC 8555. This is just as JurgenAuer explains. These are not defaults, but an IETF Standard. If you are going to use HTTP challenge the standard says this:

  1. Construct a URL by populating the URL template [RFC6570] “http://{domain}/.well-known/acme-challenge/{token}”, where: * the domain field is set to the domain name being verified; and * the token field is set to the token in the challenge.

Standards are not there to be flexible, either you conform to them or not. If you do not conform you should not complain about the software designed to conform with the standard not being flexible.