Certificate renewed but didn't update on the website

Help
21

Hello Mike,
After I installed OpenSSL apache2 crashed again and couldn't be restarted. Tried to fix the problem without uninstalling it but it wouldn't start. I uninstalled Apache2 again and re-installed it and it is now running again. However the certificate still hasn't updated.

I will say we have 2 servers we get certificates from Lets's Encrypt. The other server runs on Ubuntu 18 and had an issue renewing the certificate as well. However that was resolved Monday after some changes were made in the server name conf file in the letsencrypt directory. That server is our primary mail server. The server where the certificate did renew but didn't update on the website is our backup mail server and runs on Ubuntu 20.

I only bring the above up because on our primary mail server avmail.alliedvaughn.com the default ssl conf file has all 3 files listed in there and it succeeded in renewing and updating on the website. You had me remove the SSLCertificateFile /etc/letsencrypt/live/mail.alliedvaughndam.com-002/cert.pem from the default ssl conf file on the backup server but it. However I have decided to put that file back in the file since all 3 files are in the conf file on avmail and was able to renew sucessfully and update on the website.

My question is how long does it take the certficate to update on the website after Openssl and Apache2 are running?

22

As soon as sudo certbot renew runs. You can run it any time even if you also run it with systemd timer or cronjob

As for cert chains, please refer back to my post Certificate renewed but didn't update on the website - #6 by MikeMcQ

The current way of setting the cert chain in Apache is as I showed above linked post. You can specify the cert and chain separately but that was deprecated in Apache a very long time ago (after v2.4.8).

On your test Apache system then what does this show? Curious if Apache is even listening on port 443

sudo ss -pant | grep -i listen | grep -Ei ':80|:443'

You can try a certbot renew test like this. What does this say?

sudo certbot renew --dry-run
3 Likes
23

Hello Mike,
I was just able to get port 80 and 443 to listen to apache2. Both apache2 and openssl are running.

illkarl@mail:~$ sudo ss -pant | grep -i listen | grep -Ei ':80|:443'
LISTEN  0  511  *:80  *:*  users:(("apache2",pid=2986,fd=4),("apache2",pid=2985,fd=4),("apache2",pid=2906,fd=4))
LISTEN  0  511  *:443  *:*  users:(("apache2",pid=2986,fd=6),("apache2",pid=2985,fd=6),("apache2",pid=2906,fd=6))

illkarl@mail:~$ sudo certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/mail.alliedvaughndam.com-0001.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Renewal configuration file /etc/letsencrypt/renewal/mail.alliedvaughndam.com-0001.conf is broken.
The error was: error parsing /etc/letsencrypt/renewal/mail.alliedvaughndam.com-0001.conf
Skipping.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/mail.alliedvaughndam.com-0002.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Simulating renewal of an existing certificate for mail.alliedvaughndam.com
Failed to renew certificate mail.alliedvaughndam.com-0002 with error: Could not bind TCP port 80 because it is already in use by another process on this system (such as a web server). Please stop the program in question and then try again.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/mail.alliedvaughndam.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Renewal configuration file /etc/letsencrypt/renewal/mail.alliedvaughndam.com.conf is broken.
The error was: error parsing /etc/letsencrypt/renewal/mail.alliedvaughndam.com.conf
Skipping.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
All simulated renewals failed. The following certificates could not be renewed:
  /etc/letsencrypt/live/mail.alliedvaughndam.com-0002/fullchain.pem (failure)

Additionally, the following renewal configurations were invalid:
  /etc/letsencrypt/renewal/mail.alliedvaughndam.com-0001.conf (parsefail)
  /etc/letsencrypt/renewal/mail.alliedvaughndam.com.conf (parsefail)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 renew failure(s), 2 parse failure(s)
1 Like
24

I also just notice the certificate updated on the website but it now comes up with this error message.

image
image1241×334 24.2 KB

Here is an image of the updated certificate.
image

25

That sounds like progress even though it may not look like it.

Much has changed since the start of this thread so we'll need to review.

Let's not worry about the failing cert request just yet. We were going to modify that anyway.

Let's review your Apache config. Please show output of this

sudo apache2ctl -t -D DUMP_VHOSTS

And, jumping ahead a bit, also show the contents of the file that the above command shows for your port 443 VirtualHost (it might still be /etc/apache2/sites-enabled/default-ssl.conf)

3 Likes
26 
root@mail:/home/illkarl# sudo apache2ctl -t -D DUMP_VHOSTS
VirtualHost configuration:
*:443  mail.alliedvaughndam.com (/etc/apache2/sites-enabled/default-ssl.conf:2)

/etc/apache2/sites-enabled/default-ssl.conf

<IfModule mod_ssl.c>
  <VirtualHost _default_:443>
    ServerName mail.alliedvaughndam.com
    ServerAdmin webmaster@localhost

    # Set the HTTP Strict Transport Security (HSTS) header to guarantee
    # HTTPS for 1 Year, including subdomains, and allow this site to be
    # added to the preload list.
    # Do NOT enable this until you have the final SSL certificate in
    # in place. You can get stuck.
    #Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"


    # Prevent clickjacking by controlling who can put the site into a
    # frame. Only needed for text/html, but doesn't hurt to be applied
    # generally.
    #Header set X-Frame-Options "SAMEORIGIN"

    # Prevent mime based attacks by telling browsers that support it
    # to use the declared mime type regardless of what the content looks
    # like.
    #Header set X-Content-Type-Options "nosniff"

    DocumentRoot /var/www/html
    <Directory "/var/www/html">
      Options FollowSymLinks
      AllowOverride All
    </Directory>

    # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
    # error, crit, alert, emerg.
    # It is also possible to configure the loglevel for particular
    # modules, e.g.
    LogLevel warn

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    # For most configuration files from conf-available/, which are
    # enabled or disabled at a global level, it is possible to
    # include a line for only one particular virtual host. For example the
    # following line enables the CGI configuration for this host only
    # after it has been globally disabled with "a2disconf".
    #Include conf-available/serve-cgi-bin.conf

    #SSL Engine Switch:
    #Enable/Disable SSL for this virtual host.
    SSLEngine on

    #A self-signed (snakeoil) certificate can be created by installing
    #the ssl-cert package. See
    # /usr/share/doc/apache2/README.Debian.gz for more info.
    #If both key and certificate are stored in the same file, only the
    # SSLCertificateFile directive is needed.
    # Use the SnakeOil Certificates
    # SSLCertificateFile    /etc/ssl/certs/ssl-cert-snakeoil.pem
    # SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
    #Use the Let's Encrypt certificate.
    SSLCertificateFile /etc/letsencrypt/live/mail.alliedvaughndam.com-0002/fullchain.pem
     SSLCertificateKeyFile /etc/letsencrypt/live/mail.alliedvaughndam.com-0002/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/apache2/ssl.crt/server-ca.crt
    #Use the Let's Encrypt certificate.

    #   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)
    #   Note: Inside SSLCACertificatePath you need hash symlinks
    #    to point to the certificate files. Use the provided
    #    Makefile to update the hash symlinks after changes.
    #SSLCACertificatePath /etc/ssl/certs/
    #SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt

    #   Certificate Revocation Lists (CRL):
    #   Set the CA revocation path where to find CA CRLs for client
    #   authentication or alternatively one huge file containing all
    #   of them (file must be PEM encoded)
    #   Note: Inside SSLCARevocationPath you need hash symlinks
    #    to point to the certificate files. Use the provided
    #    Makefile to update the hash symlinks after changes.
    #SSLCARevocationPath /etc/apache2/ssl.crl/
    #SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl

    #   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 require
    #SSLVerifyDepth  10

    #   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 OptRenegotiate:
    #  This enables optimized SSL connection renegotiation handling when SSL
    #  directives are used in per-directory context.
    #SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
    <FilesMatch "\.(cgi|shtml|phtml|php)$">
        SSLOptions +StdEnvVars
    </FilesMatch>
    # <Directory /usr/lib/cgi-bin>
        # SSLOptions +StdEnvVars
    # </Directory>
    <Directory "/var/www/html">
       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.
    # BrowserMatch "MSIE [2-6]" \
    #               nokeepalive ssl-unclean-shutdown \
    #               downgrade-1.0 force-response-1.0
    # <Location /phpldapadmin>
    #   AuthType Basic
    #   AuthName "Restricted Files"
    #   # AuthUserFile /etc/apache2/htpasswd
    #   Require valid-user
    # </Location>
  </VirtualHost>
</IfModule>

I will need to correct my self on the dry run for renewing the certificate. I forgot to stop apache2 service before the dry run command was run. Simulation was successful the second time around.

root@mail:/home/illkarl# sudo service apache2 stop
root@mail:/home/illkarl# sudo certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/mail.alliedvaughndam.com-0001.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Simulating renewal of an existing certificate for mail.alliedvaughndam.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/mail.alliedvaughndam.com-0002.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Simulating renewal of an existing certificate for mail.alliedvaughndam.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/mail.alliedvaughndam.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Renewal configuration file /etc/letsencrypt/renewal/mail.alliedvaughndam.com.conf is broken.
The error was: error parsing /etc/letsencrypt/renewal/mail.alliedvaughndam.com.conf
Skipping.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations, all simulated renewals succeeded:
  /etc/letsencrypt/live/mail.alliedvaughndam.com-0001/fullchain.pem (success)
  /etc/letsencrypt/live/mail.alliedvaughndam.com-0002/fullchain.pem (success)

Additionally, the following renewal configurations were invalid:
  /etc/letsencrypt/renewal/mail.alliedvaughndam.com.conf (parsefail)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
27

Yeah, we can fix that Certbot cert profile so that it can auto-renew. That's not the top priority but glad to know the standalone option worked to get a cert anyway. I'd like to see you have a stable system before we finalize the cert config. Otherwise that might fail again as you rework Apache.

There also seems to be a missing VirtualHost for port 80. But, again, we can address that later.

As to your current status ...

Your domain now currently uses a current cert and sends the correct intermediate chain. You can see this for yourself using various tools like this https://decoder.link/sslchecker/mail.alliedvaughndam.com/443 or SSL Labs SSL Server Test: mail.alliedvaughndam.com (Powered by Qualys SSL Labs)

The reason for your Internal Server Error is some sort of Apache config problem. Based on the URL it looks like you are using Roundcube so I would review that first. I can reproduce that problem with a direct request to your "home" page (see below).

You might find further info in the Apache error log
ErrorLog ${APACHE_LOG_DIR}/error.log

This Internal Server failure is not related to your certs. Probably something went wrong as you reconfigured the Apache setup. Once you get this working let us know so we can tidy up the cert profiles and auto-renew.

curl -i https://mail.alliedvaughndam.com/roundcube/
HTTP/1.1 500 Internal Server Error
Date: Thu, 15 Aug 2024 18:08:05 GMT
Server: Apache/2.4.62 (Ubuntu)
...
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>500 Internal Server Error</title>
...
3 Likes
28

I have gone through all the apache config files and believe they are now all setup properly. When I go to the mail.alliedvaughndam.com site an error comes up saying site is not secure.

30

Well, something has gone wrong with your configuration. Apache or otherwise. I saw a valid HTTPS connection to your site yesterday. Both the SSL Checker and SSL Labs reporting success. You also made a successful HTTPS connection but then got the "500 Internal Error".

Today HTTPS fails entirely and looks wrongly directed to port 80.

I'll give it one more try but so far I have only been helping with Apache and system config problems. Nothing yet related to the certs. Without a stable underlying system it is not fruitful to build a cert auto-renew on top of it. You have a valid cert to use so the auto-renew is a problem for the future.

You should learn how to use curl for testing connections. This is a key tool for system admins. You may need to contact your network support team for help

# HTTP request to your domain fails with 503 - is that expected?
curl -I http://mail.alliedvaughndam.com
HTTP/1.1 503 Service Unavailable
P3P: CP="CAO PSA OUR"

# HTTPS request fails 
curl -I https://mail.alliedvaughndam.com
curl: (35) error:0A00010B:SSL routines::wrong version number

# Sending HTTP request to port 443 gets same reply as to port 80
# Often caused by network problem but could be faulty Apache too
# Note it is identical reply as seen for HTTP to port 80
curl -I http://mail.alliedvaughndam.com:443
HTTP/1.1 503 Service Unavailable
P3P: CP="CAO PSA OUR"

As for checking your Apache, I would start by reviewing the outputs of these (again)

sudo ss -pant | grep -i listen | grep -Ei ':80|:443'
sudo apache2ctl -t -D DUMP_VHOSTS
sudo apache2ctl -M  | grep -i ssl
4 Likes
31

Mike,
First off, I am the Network Engineer of my company and I have never seen anything like this. Secondly, this is the third time in a row we had an issue renewing the certificates on both servers. Either certbot software mess something up or a Ubuntu update messed up apache2 and SSL. The last time I had an issue renewing the certificates, after they were renewed, you had me update the certbot software on both servers. Both servers had Certbot 0.27 on them and you had me update the software to 2.11. I have been in the industry for 20 years and believe me I know more then you think. There is no execuse why once a certificate is renewed it doesn't update on the server. You may want to look at your system to see if there are any issues on your end.

32

I'll provide some background on how Let's Encrypt and Certbot works ...

Certbot places the certificates as .pem files on your server. You then configure your system to use these files. The certs have no active code in them they are static files. If something changes from one day to the next it is how they are being used.

A Certbot config that has auto-renew working properly you will get a fresh set of files every 60 days (by default). Depending on the Certbot method used the Apache (or nginx or other) server is restarted by Certbot so it sees these new files.

At the start of this thread your most recent cert had a -0002 profile. Both the original and -0001 revision were damaged. Your Apache was referring to the files in the original profile folders and so was seeing the old cert. Once it was changed to use the -0002 folders it saw the newest cert. This was the state as of yesterday.

Today your system does not process HTTPS on port 443 at all. Something regressed. Let's Encrypt cannot change the files in your local -0002 folders. Unless you modified those files they are the same as they were yesterday.

If you want us to look at your config please show the outputs of the 3 commands at the bottom of my post.

Are you seeing something other than 503 for HTTP requests? Is that what you expect to see?

4 Likes
33

200M certs get renewed every 60 days without issue.
These two servers are clearly the exception.

4 Likes
34

Here are the outputs of the 3 commands.

root@mail:/etc/apache2/sites-enabled# sudo ss -pant | grep -i listen | grep -Ei ':80|:443'
LISTEN 0 511 *:80 : users:(("apache2",pid=1917,fd=4),("apache2",pid=1916,fd=4),("apache2",pid=1915,fd=4),("apache2",pid=1914,fd=4),("apache2",pid=1913,fd=4),("apache2",pid=1868,fd=4))
LISTEN 0 511 *:443 : users:(("apache2",pid=1917,fd=6),("apache2",pid=1916,fd=6),("apache2",pid=1915,fd=6),("apache2",pid=1914,fd=6),("apache2",pid=1913,fd=6),("apache2",pid=1868,fd=6))

sudo apache2ctl -t -D DUMP_VHOSTS
root@mail:/etc/apache2/sites-enabled# sudo apache2ctl -t -D DUMP_VHOSTS
VirtualHost configuration:
*:80 mail.alliedvaughndam.com (/etc/apache2/sites-enabled/00-default.conf:1)
*:443 mail.alliedvaughndam.com (/etc/apache2/sites-enabled/default-ssl.conf:2)

root@mail:/etc/apache2/sites-enabled# sudo apache2ctl -M | grep -i ssl

output is below:
ssl_module (shared)

35

Okay good. Something has improved since our last posts. Both the SSL Checker and SSL Labs are again able to connect using HTTPS and see a cert created Aug16. See my openssl output below or visit those sites which I linked earlier.

The bad news is your server is returning a 500 Internal Error again. That isn't a problem with your certs. The encrypted comms from the certs gets setup but your Apache then rejects the HTTP(s) request. This prevents using Apache to get a cert.

We don't have to use Apache to get the cert we can use --standalone option instead. But, this requires Apache to be stopped and started during the renew (you saw this earlier). We recommend not using --standalone to avoid stopping/starting Apache during the auto-renew but that is up to you. Usually people don't want to suffer random server outages during cert renewal. To use a method that keeps Apache running means Apache must reply properly to HTTP requests on port 80. Which it isn't right now.

The cert your Apache is using on port 443 right now

echo | openssl s_client -connect mail.alliedvaughndam.com:443 | head
---
Certificate chain
 0 s:CN = mail.alliedvaughndam.com
   i:C = US, O = Let's Encrypt, CN = R10
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Aug 16 14:45:41 2024 GMT; NotAfter: Nov 14 14:45:40 2024 GMT
 1 s:C = US, O = Let's Encrypt, CN = R10
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256

The reply your Apache gives to HTTP and HTTPS requests on their respective ports

curl -i http://mail.alliedvaughndam.com/
HTTP/1.1 500 Internal Server Error
Date: Fri, 16 Aug 2024 20:05:30 GMT
Server: Apache

curl -i https://mail.alliedvaughndam.com/
HTTP/1.1 500 Internal Server Error
Date: Fri, 16 Aug 2024 20:05:34 GMT
Server: Apache

I am not sure what more to suggest going forward. We seem to be going in circles. You have been able to get certs (presumably using --standalone).

I, or someone, could advise how to setup a cert auto-renew using --standalone which auto-stops and starts Apache too. But, as I noted, generally it is better to rely on Apache itself to handle the HTTP Challenge. That works with only a graceful reload of Apache so is not disruptive to people using it. However, your Apache needs to reply consistently to HTTP requests for that to work.

Let us know what, specifically, you need help with from here. Perhaps someone else will convey the info in a way that suits you better.

3 Likes
36

We should have a look at that file.

3 Likes
37

Here is the output of the file of the above command:

<VirtualHost *:80>
        # The ServerName directive sets the request scheme, hostname and port that
        # the server uses to identify itself. This is used when creating
        # redirection URLs. In the context of virtual hosts, the ServerName
        # specifies what hostname must appear in the request's Host: header to
        # match this virtual host. For the default virtual host (this file) this
        # value is not decisive as it is used as a last resort host regardless.
        # However, you must set it for any further virtual host explicitly.
        ServerName mail.alliedvaughndam.com

        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html
        # Redirect permanent /avldap https://127.0.0.1/phpldapadmin
        <Directory "/var/www/html">
          Options FollowSymLinks
          AllowOverride All
        </Directory>

        # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
        # error, crit, alert, emerg.
        # It is also possible to configure the loglevel for particular
        # modules, e.g.
        LogLevel warn

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

        # For most configuration files from conf-available/, which are
        # enabled or disabled at a global level, it is possible to
        # include a line for only one particular virtual host. For example the
        # following line enables the CGI configuration for this host only
        # after it has been globally disabled with "a2disconf".
        #Include conf-available/serve-cgi-bin.conf
</VirtualHost>
38

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