Apache certificate modification not successful

Help
1

I recently created a new VirtualHost, wp.boba.org, on my Apache server. This website is in addition to a number of other existing websites. All the other websites were configured with HTTPS using certbot. This new website consistently fails certificate creation.

The core message seems to be “The client lacks sufficient authorization”. I have no idea why. The command is run with sudo. All the other sites’ certificates are are valid and auto renew works. the directory /var/www/wp.boba.org and subdirectories have the same permissions as other directories on the webserver.

The DNS record for this site is the same as the DNS records for other sites on the same certificate.

My domain is: boba.org

I ran this command: sudo certbot --apache

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache

Which names would you like to activate HTTPS for? (list edited because new users limited to 20 URLs in a post)

1: alanboba.net
2: www.alanboba.net
9: boba.org
11: sclc.boba.org
12: train.boba.org
13: training.boba.org
14: wp.boba.org
15: www.wp.boba.org
16: www.boba.org

Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter ‘c’ to cancel): 1 2 9 11 12 13 14 15 16

You have an existing certificate that contains a portion of the domains you
requested (ref: /etc/letsencrypt/renewal/alanboba.net.conf)

to stay within url limits for new users, in the remainder of this post, the 14th and 15th URLs, the new URLs,in the list above will be referred to as NewURL1 and NewURL2 respectively.

It contains these names: #1, #9, #11, #12,
#13, #2, #16

You requested these names for the new certificate: #1, #9, #11, #12,
#13, #2, #16, NewURL2, NewURL1.

Do you want to expand and replace this existing certificate with the new
certificate?

(E)xpand/©ancel: E
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for NewURL2
http-01 challenge for NewURL1
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. NewURL1 (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://wp.boba.org/.well-known/acme-challenge/ahMrRrWS3xQeJa9htNQViX12_HiSKUb9J6xb4F4WPoY [67.86.147.116]: “\n\n404 Not Found\n\n

Not Found

\n<p”, www.wp.boba.org (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://NewURL2/.well-known/acme-challenge/7xeOBOtipDHw9rj5R4b4jZxsuKzcCEFqtgUL5TRz-eQ [67.86.147.116]: “\n\n404 Not Found\n\n

Not Found

\n<p”

IMPORTANT NOTES:

My web server is (include version):
:~$ /usr/sbin/apache2 -v
Server version: Apache/2.4.18 (Ubuntu)
Server built: 2019-10-08T13:31:25

The operating system my web server runs on is (include version):
:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.6 LTS
Release: 16.04
Codename: xenial

My hosting provider, if applicable, is: n/a, it’s me.

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 --version
certbot 0.31.0

1 Like
2

Hi @aboba

what says

apachectl -S

PS: Are you sure your ip address is correct? Checking your domain there is a different certificate - https://check-your-website.server-daten.de/?q=wp.boba.org

CN=andrewboba.org
	01.12.2019
	29.02.2020
expires in 69 days	andrewboba.com, andrewboba.org, 
www.andrewboba.com, www.andrewboba.org - 4 entries

That domain name isn't in your list.

But there is a CNAME

wp.boba.org C boba.org

so the ip address of boba.org is used - 67.86.147.116

1 Like
3

Again, limits on URLs in answers require following substitutiions…

Host01 = andrewboba.com
Host02 = alanboba.net
Host03 = www.alanboba.net
Host04 = boba.org
Host05 = sclc.boba.org
Host06 = train.boba.org
Host07 = training.boba.org
Host08 = www.boba.org

Host01 is the only host name not included in the certificate that is being modified. AFAIK it appears as the first NameVirtualHost for *:443 ad *:80 simply because apachectl lists all NameVirtualHosts in order by name. Since it is identified as the “default server” I didn’t think it should be removed from the listing.

Other NameVirtualHosts that are not included in certificate I am attempting to update have been removed from this listing to stay within the URL limit for my posts.

apachectl -S
VirtualHost configuration:
*:443 is a NameVirtualHost
default server Host01 (/etc/apache2/sites-enabled/andrewboba.com-le-ssl.conf:2)
port 443 namevhost Host04 (/etc/apache2/sites-enabled/boba.org-le-ssl.conf:2)
alias Host08
alias Host02
alias Host03
port 443 namevhost Host05 (/etc/apache2/sites-enabled/sclc.boba.org-le-ssl.conf:2)
port 443 namevhost Host06 (/etc/apache2/sites-enabled/train.boba.org-le-ssl.conf:2)
alias Host07
*:80 is a NameVirtualHost
default server Host01 (/etc/apache2/sites-enabled/andrewboba.com.conf:1)
port 80 namevhost Host04 (/etc/apache2/sites-enabled/boba.org.conf:1)
alias Host08
alias Host02
alias Host03
port 80 namevhost Host05 (/etc/apache2/sites-enabled/sclc.boba.org.conf:1)
port 80 namevhost Host06 (/etc/apache2/sites-enabled/train.boba.org.conf:1)
alias Host07
port 80 namevhost wp.boba.org (/etc/apache2/sites-enabled/wp.boba.org.conf:1)
alias www.wp.boba.org
ServerRoot: “/etc/apache2”
Main DocumentRoot: “/var/www/html”
Main ErrorLog: “/var/log/apache2/error.log”
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
Mutex ssl-stapling: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/var/lock/apache2" mechanism=fcntl
Mutex mpm-accept: using_defaults
Mutex watchdog-callback: using_defaults
PidFile: “/var/run/apache2/apache2.pid”
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
Define: ENABLE_USR_LIB_CGI_BIN
User: name=“www-data” id=33
Group: name=“www-data” id=33

4

You are doing something wrong.

If you want to create one certificate with

really 9 domain names, you should have one vHost with the same list of domain names.

But that's a bad idea, you may hit some rate limits.

So create certificates that match your vHost definition.

One vHost with wp.boba.org + www.wp.boba.org --> create one certificate with the both same domain names, not one certificate with 9 domain names.

1 Like
5

I don’t understand what you mean by “…one vHost with the same list of domain names…”

As for hitting rate limits, my understanding of this documetation, Rate Limits, puts me well within published rate limits.

When I knew much less about Certbot/LetsEncrypt I had ALL my domain and host names under one certificate. It worked and renewed fine.

When I recognized what I had done, ALL domain and host names under one certificate, I decided to separate certificates by domain (except leaving boba.org and alanboba.net on the same certiificate).

The process to remove names from the one certificate and create new certificates for each domain worked without a problem. That was at least 8 months ago.

Now I have a number of certificates all with at least two names, e.g. kevinkellypouredfoundations.com certificate has kevinkellypouredfoundations.com and www.kevinkellypouredfoundations.com on it.

It is just now trying to use certbot to update the alanboba.net certificate to include wp.boba.org and www.wp.boba.org that I’m getting the error.

The error indicates the agent doesn’t have rights to make the changes yet the command is being run with sudo and the webserver’s data directories /var/www… and config files /etc/apache2… and certbot’s config files and certificates directories /etc/letsencrypt/… all have consistent owner, group, and other permissions (that’s not to say the same for all, just consistent in that path).

I believe the solution lies in determining why the certbot agent is unable to modify contents of the webserver directory or, perhaps, the webserver isn’t serving hidden directories for this site. The error message may be misleading. The server must be serving hidden directories for the other sites because their certificate renewals are successful.

1 Like
6

SOLVED - but don’t understand why

Searched and read for a while and began to suspect server wasn’t serving from /.well-known/acme-challenge/

Put a Hello World index.html file there and it was served from the URL http://wp.boba.org/.well-known/acme-challenge/ so that wasn’t the problem.

After some more reading it seemed using a different command to add two domains to the certificate might turn the trick and it did! Problem solved. But I still don’t understand why. If anyone can offer some insight to help understand it would be much appreciated.

To recap…

Trying to expand my alanboba.net certificate to include wp.boba.org and www.wp.boba.org and have my apache server automatically redirect http requests to https.

Every time I tried
sudo certbot --expand --apache --cert-name alanboba.net -d alanboba.net,boba.org,sclc.boba.org,train.boba.org,training.boba.org,www.alanboba.net,www.boba.org,wp.boba.org,www.wp.boba.org
it failed with the message File does not exist: /var/www/wp.boba.org/public_html/.well-known/acme-challenge/

Finally, tonight I tried
sudo certbot run -a webroot -i apache -w /var/www/wp.boba.org/public_html -d alanboba.net,boba.org,sclc.boba.org,train.boba.org,training.boba.org,www.alanboba.net,www.boba.org,wp.boba.org,www.wp.boba.org
and it succeeded!!!

After running the above command, the command sudo certbot certificates -n alanboba.net returns
Found the following matching certs:
Certificate Name: alanboba.net
Domains: alanboba.net boba.org sclc.boba.org train.boba.org training.boba.org wp.boba.org www.alanboba.net www.boba.org www.wp.boba.org

Don’t know why sudo certbot --expand didn’t work and sudo certbot run … did.

Any explanation would be greatly appreciated

2 Likes
7

Sounds like you had a wrong configuration entry. --expand uses that and tries to create a new certificate.

That

starts new, so a new folder (...-0001 / 0002 ...) and a new config file is created.

1 Like
8

@JuergenAuer I wish you could be more specific. Even though the problem is "solved" I'd really like to understand what the problem was.

You suggest a wrong configuration entry. I spent quite a bit of time in the last few weeks trying to find a wrong configuration entry. I suspected maybe the DocumentRoot parameter in Apache was wrong, /var/www/wp.boba.org/public_html. But the server logs all refer to the same location.

/var/log/apache2/wpboba_error.log
File does not exist: /var/www/wp.boba.org/public_html/.well-known/acme-challenge/

/var/log/apache2/wpboba_access.log
52.28.236.88 - - [14/Jan/2020:17:25:10 -0500] "GET /.well-known/acme-challenge/

/etc/apache2/sites-available/wp.boba.org.conf
DocumentRoot /var/www/wp.boba.org/public_html

Plus, I confirmed the server was able to serve files from the /.well-known/acme-challenge/ directory by creating the directories and putting an index.html and test.html file in it.

wp.boba.org/.well-known/acme-challenge/ returned the index.html file as expected.
wp.boba.org/.well-known/acme-challenge/test.html returned that file as expected.

You've said new folder and new config files are created but there are no new folders created in my /etc/letsencrypt directory or sub directories. The config file, alanboba.net.conf, having a last modification date of Jan 15 makes sense because that's when I finally tried the command that worked. However it is not a new file because all the other domain names that are part of the alanboba.net certificate were working before my two additional names were successfully added on Jan 15.

The options-ssl-apache.conf has a last mod date of Jan 16 only because I modified it today so TLSv1 and TLSv1.1 are no longer supported by the server.

Here's the find output that shows files in the letsencrypt directory modified since Jan 14, the day before the problem was solved.

:~$ sudo find /etc/letsencrypt/ -type f -newermt "Jan 14, 2020" -ls 2>/dev/null
1837671 4 -rw-r--r-- 1 root root 1647 Jan 15 21:37 /etc/letsencrypt/archive/alanboba.net/chain18.pem
1837672 4 -rw-r--r-- 1 root root 3721 Jan 15 21:37 /etc/letsencrypt/archive/alanboba.net/fullchain18.pem
1837669 4 -rw-r--r-- 1 root root 1708 Jan 15 21:37 /etc/letsencrypt/archive/alanboba.net/privkey18.pem
1837670 4 -rw-r--r-- 1 root root 2074 Jan 15 21:37 /etc/letsencrypt/archive/alanboba.net/cert18.pem
1837673 4 -rw-r--r-- 1 root root 708 Jan 15 21:37 /etc/letsencrypt/renewal/alanboba.net.conf
1837666 4 -rw-r--r-- 1 root root 1094 Jan 14 17:25 /etc/letsencrypt/csr/0613_csr-certbot.pem
1837668 4 -rw-r--r-- 1 root root 1094 Jan 15 21:37 /etc/letsencrypt/csr/0614_csr-certbot.pem
1837679 4 -rw-r--r-- 1 root root 1617 Jan 16 17:38 /etc/letsencrypt/options-ssl-apache.conf
1837667 4 -rw------- 1 root root 1708 Jan 15 21:37 /etc/letsencrypt/keys/0614_key-certbot.pem
1837665 4 -rw------- 1 root root 1704 Jan 14 17:25 /etc/letsencrypt/keys/0613_key-certbot.pem
1831998 4 -rw-r--r-- 1 root root 1619 Jan 16 17:37 /etc/letsencrypt/options-ssl-apache.conf.bkup20200116

At this point I'm waiting for the expiry date, 2020-04-15 01:37:37+00:00, of the certificate to come back around and see if the auto renew continues to work as it did before the two new names were added.

And I'd like to understand WHY --expand didn't work so when I next need to expand a certificate it works right the first time.

1 Like
9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.