Encountered an odd error during a cert renewal that I was able to resolve but would love someone to shed light on why this happened.
Here’s what happened (this is on Amazon Linux 2, Apache 2.4):
[ec2-user@ip-177-77-77-77 ~]$ sudo certbot renew --debug --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/mydomain.com.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/ssl.conf on line 149: Syntax error',)
Attempting to renew cert (mydomain.com) from /etc/letsencrypt/renewal/mydomain.com.conf produced an unexpected 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/ssl.conf on line 149: Syntax error',). Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/mydomain.com/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates below have not been saved.)
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/mydomain.com/fullchain.pem (failure)
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates above have not been saved.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Exiting abnormally:
Traceback (most recent call last):
File "/bin/certbot", line 9, in <module>
load_entry_point('certbot==0.29.1', 'console_scripts', 'certbot')()
File "/usr/lib/python2.7/site-packages/certbot/main.py", line 1352, in main
return config.func(config, plugins)
File "/usr/lib/python2.7/site-packages/certbot/main.py", line 1259, in renew
renewal.handle_renewal_request(config)
File "/usr/lib/python2.7/site-packages/certbot/renewal.py", line 457, in handl e_renewal_request
len(renew_failures), len(parse_failures)))
Error: 1 renew failure(s), 0 parse failure(s)
Please see the logfiles in /var/log/letsencrypt for more details.
I checked line 149 in ssl.conf, and it was commented out:
#SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \
When I removed that line, it worked. But why? If it’s commented out, why would it matter?
I think I remember seeing something like that before and that it also had a backslash at the end of the line, so that may be relevant - maybe the backslash confuses Certbot’s parser somehow?
Ending with a backslash seems to imply that this line continues on the next.
Does it continue on the next line? Does it just end there?
But if he commented out this part only, how would it then pass syntax checks,
After I pulled my hair out for a while trying to figure out what in the world the problem was, I finally just removed this entire block that included the offending line:
#<Location />
#SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \
# and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
# and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \
# and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \
# and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \
# or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
#</Location>
I’m still confused, though. I thought if the line begins with a # then everything on that line is just ignored. Isn’t that the whole point of having comments? Is this normal or expected behavior? I’ve never run into it before and it’s challenging my understanding of how comment symbols work…
Incidentally, this whole block was in the default ssl.conf that got installed in Apache, as far as I know I never touched it (until now!).