Syntax error in an Apache conf file when updating the certificate, but running $apachectl configtest shows no error

[edwinfg]

Hello, I am having this error when trying to renew the certificate. Could someone help me please?

My domain is: https://webwork.uprm.edu/

I ran this command: $sudo certbot renew

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/webwork.uprm.edu.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert is due for renewal, auto-renewing...
Could not choose appropriate plugin: The apache plugin is not working; there may be problems with your existing configuration.
The error was: PluginError('There has been an error in parsing the file /etc/httpd/conf.d/webwork.conf on line 43: Syntax error',)
Failed to renew certificate webwork.uprm.edu with error: The apache plugin is not working; there may be problems with your existing configuration.
The error was: PluginError('There has been an error in parsing the file /etc/httpd/conf.d/webwork.conf on line 43: Syntax error',)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
All renewals failed. The following certificates could not be renewed:
  /etc/letsencrypt/live/webwork.uprm.edu/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 renew failure(s), 0 parse failure(s)

My web server is (include version):

$httpd -v
Server version: Apache/2.4.6 (CentOS)
Server built:   Mar 24 2022 14:57:57

$ httpd -V
[Tue Oct 18 10:44:44.475675 2022] [so:warn] [pid 11827] AH01574: module status_module is already loaded, skipping
AH00526: Syntax error on line 212 of /etc/httpd/conf.d/ssl.conf:
SSLCertificateFile: file '/etc/letsencrypt/live/webwork.uprm.edu/cert.pem' does not exist or is empty

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

$ cat /etc/centos-release
CentOS Linux release 7.9.2009 (Core)

My hosting provider, if applicable, is: The university UPRM

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 1.11.0

Some of the file content around line 43 is:

And also include apachectl configtest output:

[*********@webwork conf.d]$ sudo apachectl configtest
[sudo] password for *********:
[Tue Oct 18 11:23:30.270541 2022] [so:warn] [pid 12190] AH01574: module status_module is already loaded, skipping
webwork.apache2-config: webwork_server_admin_email for reporting bugs has been set to edwin.florez@upr.edu in site.conf
webwork.apache2-config:  WeBWorK server is starting
webwork.apache2-config:  WeBWorK root directory set to /opt/webwork/webwork2 in webwork2/conf/webwork.apache2-config
webwork.apache2-config:  The following locations and urls are set in webwork2/conf/site.conf
webwork.apache2-config:  PG root directory set to /opt/webwork/pg
webwork.apache2-config:  WeBWorK server userID is apache
webwork.apache2-config:  WeBWorK server groupID is apache
webwork.apache2-config:  The webwork url on this site is https://webwork.uprm.edu/webwork2
webwork.apache2-config:  The webwork smtp server address is localhost
webwork.apache2-config:     The webwork smtp server port is
webwork.apache2-config:     The webwork smtp server protocol is 'not ssl'
WebworkSOAP::WSDL: webwork_directory set to /opt/webwork/webwork2 via $WeBWorK::Constants::WEBWORK_DIRECTORY set in webwork.apache2-config
WebworkSOAP::WSDL: rpc_url set to https://webwork.uprm.edu/webwork2_rpc
WebworkWebservice: webwork_directory set to /opt/webwork/webwork2 via $WeBWorK::Constants::WEBWORK_DIRECTORY set in webwork.apache2-config
Syntax OK

[rg305]

Hi @edwinfg, and welcome to the LE community forum

If you don't know what this is nor why it was put there:

I'd comment it out:
"#<Perl>"

Also, this is rather old:

@edwinfg

Apache/2.4.6

[edwinfg]

The <perl> tag is there because I am using WeBWorK, a homework delivery system primarily used for mathematics and science. It is written in Perl.

The version of Apache is the most updated that the default Centos 7 repositories give me. I'll try to see if I can update it more.

Thanks for the welcome, my bad not to welcome first.

Hello everyone in this community.

[rg305]

If the Perl tag is required, then why does Apache complain about it?

OK, I think I see the problem:
certbot's apache plugin is the one complaining about that tag.
You'll have to use --webroot authentication instead.

[edwinfg]

certbot 's apache plugin is the one complaining about that tag.

It seems that way, I don't understand why it marks a syntax error when Apache doesn't mark it.

You'll have to use --webroot authentication instead.

I used it and I get this error:

$ sudo certbot --webroot renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/webwork.uprm.edu.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator webroot, Installer None
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
Renewing an existing certificate for webwork.uprm.edu
Performing the following challenges:
http-01 challenge for webwork.uprm.edu
Cleaning up challenges
Failed to renew certificate webwork.uprm.edu with error: Missing command line flag or config entry for this setting:
Input the webroot for webwork.uprm.edu:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
All renewals failed. The following certificates could not be renewed:
  /etc/letsencrypt/live/webwork.uprm.edu/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 renew failure(s), 0 parse failure(s)

Thanks to your suggestion, I checked more options with $certbot --help and found that I can use the certonly option. Fortunately I managed to update it that way even though I don't really understand exactly what was done.

Thank you very much for your help.

$ sudo certbot certonly
Saving debug log to /var/log/letsencrypt/letsencrypt.log

How would you like to authenticate with the ACME CA?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: Spin up a temporary webserver (standalone)
2: Place files in webroot directory (webroot)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Plugins selected: Authenticator webroot, Installer None
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
Please enter in your domain name(s) (comma and/or space separated)  (Enter 'c'
to cancel): webwork.uprm.edu
Cert is due for renewal, auto-renewing...
Renewing an existing certificate for webwork.uprm.edu
Performing the following challenges:
http-01 challenge for webwork.uprm.edu
Input the webroot for webwork.uprm.edu: (Enter 'c' to cancel): /var/www/html
Waiting for verification...
Resetting dropped connection: acme-v02.api.letsencrypt.org
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/webwork.uprm.edu/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/webwork.uprm.edu/privkey.pem
   Your certificate will expire on 2023-01-16. To obtain a new or
   tweaked version of this certificate in the future, simply run
   certbot again. To non-interactively renew *all* of your
   certificates, run "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

[rg305]

@edwinfg

I don't really understand exactly what was done.

You can check which certificates and the FQDNs that are being managed by certbot with:
certbot certificates

[which may help explain what was done]

[jvanasco]

@edwinfg

It seems that way, I don't understand why it marks a syntax error when Apache doesn't mark it.

WebWork leverages mod_perl, which embeds a Perl interpreter into the Apache process to accomplish a few tasks – including allowing Perl commands to configure Apache. Your Apache configuration file is no longer a regular "vanilla" Apache configuration but a mod_perl one, and is therefore incompatible with standard Apache. The standard Apache configuration is the only format Certbot can correctly read and manage, so your installation is no longer compatible with Certbot's Apache plugin.

Most likely, WebWork was installed after you got a first Certificate.

If you're familiar with Apache configs, you can use a proxypass directive to map the .well-known/acme-challenge directory onto a higher port, and configure the standalone plugin to listen to that higher port. You can also use the webroot plugin, or DNS plugins. These options can all be automated. In an emergency, you can: (i) shut down Apache, (ii) run Certbot in standalone mode, and (iii) start Apache - a flow that is easier to do, but can't be automated.

In all these options, you need to make sure the apache config references the correct certificate in the /live directory - which will be automatically updated by the renewal.

[rg305]

@jvanasco

a flow that is easier to do, but can't be automated

Not a simple/easy automation, nor a desirable one, but I think that it could be automated.
[just about anything can be automated]

I'd prefer to use --webroot before turning of a web server.
But I suppose that's why there are so many colors.

[jvanasco]

@rg305

I think that it could be automated.

I should have written "but can't be automated in your situation."

Technically, it can easily be automated with the Apache commands as pre/post hooks - but there are so many drawbacks/caveats involved with doing that to a production site running mod_perl apps compiled into the server, that no one should automate it as it can't be done reliably. You run the risk of extended downtime during the renewal or Apache not restarting correctly, so stuff like that really needs to be done manually.

Doing this at 4am for a vanilla Apache install on a sleepy website is not an issue. The OP is dealing with a mod_perl install on the server that handles homework submissions for a university - which means it requires relatively high availability.