Certbot - apache 2.2 support?

Does certbot support Apache 2.2 using the “apache” plugin? I can’t get it working properly on my CentOS 6.8 system…

# /root/bin/certbot-auto --version
letsencrypt 0.9.3
# /root/bin/certbot-auto
...
Version: 1.1-20080819
Certbot doesn't know how to automatically configure the web server on this system. However, it can still get a certificate for you. Please run "certbot-auto certonly" to do so. You'll need to manually configure your web server to use the resulting certificate.

# cat /var/log/letsencrypt/letsencrypt.log
2016-12-08 17:32:22,613:DEBUG:certbot.main:Root logging level set at 20
2016-12-08 17:32:22,614:INFO:certbot.main:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2016-12-08 17:32:22,622:DEBUG:certbot.main:certbot version: 0.9.3
2016-12-08 17:32:22,622:DEBUG:certbot.main:Arguments: []
2016-12-08 17:32:22,622:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#nginx,PluginEntryPoint#standalone,PluginEntryPoint#manual,PluginEntryPoint#webroot,PluginEntryPoint#apache,PluginEntryPoint#null)
2016-12-08 17:32:22,632:DEBUG:certbot.plugins.selection:Requested authenticator None and installer None
2016-12-08 17:32:23,200:DEBUG:certbot.plugins.disco:Other error:(PluginEntryPoint#apache): ('There has been an error in parsing the file (%s): %s', u'/etc/httpd/conf.d/vhosts/ssl/bennish.net-ssl.conf', u'Syntax error')
Traceback (most recent call last):
  File "/root/.local/share/letsencrypt/lib/python2.6/site-packages/certbot/plugins/disco.py", line 106, in prepare
    self._initialized.prepare()
  File "/root/.local/share/letsencrypt/lib/python2.6/site-packages/certbot_apache/configurator.py", line 190, in prepare
    self.check_parsing_errors("httpd.aug")
  File "/root/.local/share/letsencrypt/lib/python2.6/site-packages/certbot_apache/augeas_configurator.py", line 74, in check_parsing_errors
    raise errors.PluginError(msg)
PluginError: ('There has been an error in parsing the file (%s): %s', u'/etc/httpd/conf.d/vhosts/ssl/bennish.net-ssl.conf', u'Syntax error')
2016-12-08 17:32:23,202:DEBUG:certbot.plugins.selection:No candidate plugin
2016-12-08 17:32:23,202:DEBUG:certbot.plugins.selection:Selected authenticator None and installer None

I can’t see anything about the bennish.net-ssl.conf file that is a syntax error and indeed apachectl configtest runs with “Syntax OK” and Apache 2.2 runs happily.

Thanks in advance,
Ben

You need to specify arguments

sudo ./certbot-auto certonly --agree-tos --rsa-key-size 4096 -m dnsadmin@mydomain.com -d www.mydomain.com -d mydomain.com --renew-by-default

or

sudo ./certbot-auto --apache --agree-tos --rsa-key-size 4096 -m dnsadmin@mydomain.com -d www.mydomain.com -d mydomain.com --renew-by-default

Yes,

Can you paste the contents of /etc/httpd/conf.d/vhosts/ssl/bennish.net-ssl.conf somewhere please ( either in somewhere like pastebin.com or here, but place three back ticks ` on the line before it, and on the line affer it to suppress any interpretation by the forum).

Contents of /etc/httpd/conf.d/vhosts/ssl/bennish.net-ssl.conf

(btw if you notice any security flaws, please let me know as I realise that there is a certain risk of posting config files online)

<VirtualHost 87.124.126.135:443>

Include conf.d/vhosts/shared/bennish-shared.conf

# Force redirect to our proper SSL hostname 
# (NOTE: this will *not* stop certificate warnings on the first request)
RewriteEngine on
RewriteCond %{HTTP_HOST} !=www.bennish.net [NC]
RewriteCond %{HTTP_HOST} !=""
RewriteRule ^ https://www.bennish.net%{REQUEST_URI} [R,L]

SSLEngine on

# List the enable protocol levels with which clients will be able to
# connect.  Disable SSLv2 access by default:
# (Ben: and SSLv3 which is vulnerable to POODLE MitM attack)
SSLProtocol all -SSLv2 -SSLv3

# during SSLv3 or TLSv1 handshake, use the servers preference, not the clients
SSLHonorCipherOrder on

#   SSL Cipher Suite:
# List the ciphers that the client is permitted to negotiate.
# See the mod_ssl documentation for a complete list.

SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:!LOW:!RC4:+HIGH:+MEDIUM
#
# explanation:
# add ALL ciphers to the list
# kill ciphers using Anonymous Diffie-Hellman key exchange
# kill all EXPORT (aka EXP) ciphers
# kill all SSL version 2.0 ciphers
# kill all LOW strength cipers ('no export, single DES')
# kill all ciphers using RC4
# move all HIGH grade cipers to top of list
# followed by all MEDIUM grade ciphers 

#   Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate.  If
# the certificate is encrypted, then you will be prompted for a
# pass phrase.  Note that a kill -HUP will prompt again.  A new
# certificate can be generated using the genkey(1) command.
#SSLCertificateFile /etc/pki/tls/certs/www.bennish.net.crt
SSLCertificateFile /etc/letsencrypt/live/www.bennish.net/cert.pem

#   Server Private Key:
#   If the key is not combined with the certificate, use this
#   directive to point at the key file.  Keep in mind that if
#   you've both a RSA and a DSA private key you can configure
#   both in parallel (to also allow the use of DSA ciphers, etc.)
#SSLCertificateKeyFile /etc/pki/tls/private/www.bennish.net.key
SSLCertificateKeyFile /etc/letsencrypt/live/www.bennish.net/privkey.pem

#   Server Certificate Chain:
#   Point SSLCertificateChainFile at a file containing the
#   concatenation of PEM encoded CA certificates which form the
#   certificate chain for the server certificate. Alternatively
#   the referenced file can be the same as SSLCertificateFile
#   when the CA certificates are directly appended to the server
#   certificate for convinience.
#SSLCertificateChainFile /etc/pki/tls/certs/StartSSL/sub.class1.server.ca.pem
#SSLCertificateChainFile /etc/pki/tls/certs/StartSSL/sub.class1.server.sha2.ca.pem
SSLCertificateChainFile /etc/letsencrypt/live/www.bennish.net/chain.pem 

#   Certificate Authority (CA):
#   Set the CA certificate verification path where to find CA
#   certificates for client authentication or alternatively one
#   huge file containing all of them (file must be PEM encoded)

# trust client certs from StartSSL only..
#SSLCACertificateFile /etc/pki/tls/certs/StartSSL/ca.pem

# a bundle of X.509 certificates of public CAs.  
# It was generated from the Mozilla root CA list
SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt 

# all the cert files in here are also CAs that we trust (symlinks named after the hash)
SSLCACertificatePath /etc/pki/tls/certs/CAs/

#   Client Authentication (Type):
#   Client certificate verification type and depth.  Types are
#   none, optional, require and optional_no_ca.  Depth is a
#   number which specifies how deeply to verify the certificate
#   issuer chain before deciding the certificate is not valid.
SSLVerifyClient none
SSLVerifyDepth  10

#   Access Control:
#   With SSLRequire you can do per-directory access control based
#   on arbitrary complex boolean expressions containing server
#   variable checks and other lookup directives.  The syntax is a
#   mixture between C and Perl.  See the mod_ssl documentation
#   for more details.
#<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>

#   SSL Engine Options:
#   Set various options for the SSL engine.
#   o FakeBasicAuth:
#     Translate the client X.509 into a Basic Authorisation.  This means that
#     the standard Auth/DBMAuth methods can be used for access control.  The
#     user name is the `one line' version of the client's X.509 certificate.
#     Note that no password is obtained from the user. Every entry in the user
#     file needs this password: `xxj31ZMTZzkVA'.
#   o ExportCertData:
#     This exports two additional environment variables: SSL_CLIENT_CERT and
#     SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
#     server (always existing) and the client (only existing when client
#     authentication is used). This can be used to import the certificates
#     into CGI scripts.
#   o StdEnvVars:
#     This exports the standard SSL/TLS related `SSL_*' environment variables.
#     Per default this exportation is switched off for performance reasons,
#     because the extraction step is an expensive operation and is usually
#     useless for serving static content. So one usually enables the
#     exportation for CGI and SSI requests only.
#   o StrictRequire:
#     This denies access when "SSLRequireSSL" or "SSLRequire" applied even
#     under a "Satisfy any" situation, i.e. when it applies access is denied
#     and no other module can change it.
#   o OptRenegotiate:
#     This enables optimized SSL connection renegotiation handling when SSL
#     directives are used in per-directory context. 
#SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
<Files ~ "\.(cgi|s?html|phtml|php3?)$">
    SSLOptions +StdEnvVars
</Files>
<Directory "/var/www/cgi-bin">
    SSLOptions +StdEnvVars
</Directory>


#   SSL Protocol Adjustments:
#   The safe and default but still SSL/TLS standard compliant shutdown
#   approach is that mod_ssl sends the close notify alert but doesn't wait for
#   the close notify alert from client. When you need a different shutdown
#   approach you can use one of the following variables:
#   o ssl-unclean-shutdown:
#     This forces an unclean shutdown when the connection is closed, i.e. no
#     SSL close notify alert is send or allowed to received.  This violates
#     the SSL/TLS standard but is needed for some brain-dead browsers. Use
#     this when you receive I/O errors because of the standard approach where
#     mod_ssl sends the close notify alert.
#   o ssl-accurate-shutdown:
#     This forces an accurate shutdown when the connection is closed, i.e. a
#     SSL close notify alert is send and mod_ssl waits for the close notify
#     alert of the client. This is 100% SSL/TLS standard compliant, but in
#     practice often causes hanging connections with brain-dead browsers. Use
#     this only for browsers where you know that their SSL implementation
#     works correctly. 
#   Notice: Most problems of broken clients are also related to the HTTP
#   keep-alive facility, so you usually additionally want to disable
#   keep-alive for those clients, too. Use variable "nokeepalive" for this.
#   Similarly, one has to force some clients to use HTTP/1.0 to workaround
#   their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
#   "force-response-1.0" for this.
SetEnvIf User-Agent ".*MSIE.*" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0

# Allow non-SNI clients to connect to this SSL VHost
SSLStrictSNIVHostCheck off

#   Per-Server Logging:
#   The home of a custom SSL log file. Use this when you want a
#   compact non-error SSL logfile on a virtual host basis.
CustomLog logs/bennish/bennish_ssl_log \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

# Set an environment variable we can use for ensuring that HTTPS is used for Basic HTTP Auth 
# NB: must use SetEnvIf and *not* SetEnv as it is processed too late - using a regexp that always matches
SetEnvIf Remote_Addr ^ usingSSL=yes

</VirtualHost>

Note: I have previously configured this vhost to use Let’s Encrypt, I think using the certonly plugin but I am interested in getting the ‘apache’ plugin working instead.

Cheers,
Ben

Hi Ben,

The first things that spring to mind is you are missing;

ServerName bennish.net
ServerAlias www.bennish.net

or similar unless these are in conf.d/vhosts/shared/bennish-shared.conf ?

Hi serverco,

They are indeed in the bennish-shared.conf file. I decided to try to be clever and have a shared config file used by my https and http config files.

Remember that apachectl configtest is returning "Syntax OK" and Apache is running and serving requests fine.

Cheers, Ben

I’m not sure if the apache plugin reads the include files - it might be worth a test of adding the content into the file and removing the include. I’m sure someone who uses certbot regularly will be able to answer that one ( I don’t - I use a different client).

I think I will stick to the ‘certonly’ plugin for now as I don’t wish to mess with my Apache config files. Thanks for the help.

1 Like

glad it’s working for you, have fun

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