Syntax Error

O

oguruma

I am setting up Nextcloud in a jail. I am following this guide.

I got the cert from letsencrypt, but the virtual host that's given as an example is breaking something.

I am getting syntax error
Code: 
AH00526: Syntax error on line 27 of /usr/local/etc/apache24/Includes/cloud.rangelmedianetwork.com.conf:
SSLCertificateFile takes one argument, SSL Server Certificate file ('/path/to/file' - PEM or DER encoded)

My virtualhost file is below. Obviously it's my domain and not YOURSITE.COM


Code: 
<VirtualHost *:443>
  ServerAdmin YOUREMAIL
  ServerName YOURSITE.COM
  DirectoryIndex index.php
  DocumentRoot /usr/local/www/apache24/data/nextcloud
  SSLCertificateFile /usr/local/etc/letsencrypt/live/YOURSITE.COM/fullchain.pem
  SSLCertificateKeyFile /usr/local/etc/letsencrypt/live/YOURSITE.COM/privkey.pem
  SSLEngine on
  # Intermediate configuration, tweak to your needs
  SSLProtocol  all -SSLv2 -SSLv3
  SSLCipherSuite  ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
  SSLHonorCipherOrder  on
  SSLCompression  off
  SSLOptions +StrictRequire
  <Directory /usr/local/www/apache24/data/nextcloud>
  AllowOverride all
  </Directory>
  <IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"
  </IfModule>
  </VirtualHost>
 
Have you actually read the error?

So why not share the contents of /usr/local/etc/apache24/Includes/cloud.rangelmedianetwork.com.conf? That's obviously where the problem is located, according to the error message at least.

(edit): or just check line 27, see how it has set up SSLCertificateFile and either comment it out or fix its syntax if applicable.

PS:

Considering that we're apparently talking about FreeNAS also heed this warning: PC-BSD, FreeNAS, NAS4Free, and all other FreeBSD Derivatives
 
ShelLuser said:
Have you actually read the error?

So why not share the contents of /usr/local/etc/apache24/Includes/cloud.rangelmedianetwork.com.conf? That's obviously where the problem is located, according to the error message at least.

(edit): or just check line 27, see how it has set up SSLCertificateFile and either comment it out or fix its syntax if applicable.

PS:

Considering that we're apparently talking about FreeNAS also heed this warning: PC-BSD, FreeNAS, NAS4Free, and all other FreeBSD Derivatives
Click to expand...

...../cloud.rangelmedianetwork.com.conf is the virtualhost file.... The contents are in my OP....


(edit): or just check line 27, see how it has set up SSLCertificateFile and either comment it out or fix its syntax if applicable.

That's the problem... I don't see an issue with the syntax....
 
So what does /usr/local/etc/letsencrypt/live/YOURSITE.COM/fullchain.pem look like? Maybe the format is wrong, that could also explain something.
 
Perhaps a space somewhere in that line? Depending on your editor and the font used a single space somewhere in the path may not be easy to spot.
 
Always check the lines above/before the one with the error. A lot of times, syntax errors occur before the line mentioned, but it's the syntax on that line that "breaks" the issue above it.

For example, if you missed a semi-colon in the line above, it won't actually be a syntax error until the next reserved word that shouldn't occur. Or, if you miss a closing quote, it will consider everything until the next opening quote as part of the previous string, and the next reserved word will be the "syntax error". And so on.

Also, check the permissions on all the directories up to the certificate file, and on the certificate file, to make sure the Apache process can read it. A single directory that can't be opened will lead to "file not found" errors, and change the number or arguments to a option.

Finally, are you sure you don't have 2 separate errors here? There's only 21 lines in that VirtualHost entry, so it's not the one giving you an error on line 27. :) You didn't show us the contents of that file.
 
Maybe it'll help - here's my nextcloud conf file that works (you can see some differences):

Code: 
<VirtualHost *:443>
    DocumentRoot "/usr/local/www/nextcloud"
    ServerName cloud.somecloud.com
    ErrorLog "/var/log/httpd/somecloud-cloud-httpd-error.log"
    TransferLog "/var/log/httpd/somecloud-cloud-httpd-access.log"
    SSLEngine on
    SSLCertificateFile "/usr/local/etc/letsencrypt/live/cloud.somecloud.com/fullchain.pem"
    SSLCertificateKeyFile "/usr/local/etc/letsencrypt/live/cloud.somecloud.com/privkey.pem"
    <Directory "/usr/local/www/nextcloud">
       Options Indexes FollowSymLinks
       DirectoryIndex index.php index.html
       Order Deny,Allow
       Allow from 10.10.10.0/24
       AllowOverride All
       Require all granted
    </Directory>
    <IfModule php5_module>
        DirectoryIndex index.php index.html
        AddType application/x-httpd-php .php
        AddType application/x-httpd-php-source .phps
    </IfModule>
    <IfModule dir_module>
        DirectoryIndex index.php index.html
    </IfModule>
    <IfModule mod_headers.c>
        Header always add Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
    </IfModule>
    <Files ".ht*">
        Require all denied
    </Files>
    <FilesMatch "\.php$">
        SetHandler application/x-httpd-php
    </FilesMatch>
    <FilesMatch "\.phps$">
        SetHandler application/x-httpd-php-source
    </FilesMatch>
</VirtualHost>

This is for FreeBSD 11.1-p10, Apache24, Nextcloud-12.0.5 (custom ports), PHP56. It should work with Nextcloud-13.* which is "stable" in the ports, while Nextcloud-12 is "release".

Since it's FreeNAS, I would read through the thread you posted - others had the same problem and it was a bad linefeed or extra space character in the virtual host config file. -- Read the last comment, then go through pages 6 and 7, then 2 and 3.
 
I spotted something bad, not necessarily related to this (can't rule it out though): why are you mixing up the permission schemes? That's bad practice: either use the 2.4 scheme or the 2.2 scheme (using backwards compatibility) but mixing both can lead to problems.

Referring to this:
Code: 
    <Directory "/usr/local/www/nextcloud">
       Options Indexes FollowSymLinks
       DirectoryIndex index.php index.html
       Order Deny,Allow
       Allow from 10.10.10.0/24
       AllowOverride All
       Require all granted
    </Directory>
This is quite a mess. See also upgrading from 2.2 on the Apache website as well as the chapter about access control.

I'd suggest using something like:

Code: 
  Options Indexes FollowSymLinks
  DirectoryIndex index.php index.html
  AllowOverride all
  Require ip 10.10.10.0/24
That is basically all you need to secure this setup.
 
Arguments to directives are separated by whitespace. If an argument contains spaces, you must enclose that argument in quotes.
 
VladiBG said:
If an argument contains spaces, you must enclose that argument in quotes.
Click to expand...
Or escape the spaces. But yes, it's typically better to enclose it in quotes. I'm just trying to say it's not a requirement and won't result in syntax errors if you don't use quotes. Looking at the original issue there are no spaces in the argument so quotes aren't necessary.
 
Here is my httpd.conf I use with Let'e Encrypt it scores an A+ with SSL Labs It's also optimize for PCI-DDS/HIPPA/NIST so I use the same cipher and settings not just for nextcloud but for all my apache/SSL setups.

Apache config: 
ServerName nextcloud.example.com
   DocumentRoot /usr/local/www/nextcloud.example.com
   Redirect permanent / https://nextcloud.example.com/
   ServerAdmin youremail@example.com
    # Directory for the file stored
    DocumentRoot "/usr/local/www/nextcloud.example.com"
    #Domain
    ServerName nextcloud.example.com
    ErrorLog "/var/log/nextcloud.example.com.error.log"
    CustomLog "/var/log/nextcloud.example.com.access.log" common
    SSLEngine on
    SSLCertificateFile /usr/local/etc/letsencrypt/live/nextcloud.example.com/cert.pem
    SSLCertificateChainFile /usr/local/etc/letsencrypt/live/nextcloud.example.com/chain.pem
    SSLCertificateKeyFile /usr/local/etc/letsencrypt/live/nextcloud.example.com/privkey.pem 
    #enable Forward Secrecy,
    SSLProtocol all -SSLv2 -SSLv3
    SSLHonorCipherOrder on
    SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH EDH+aRSA :!RC4: !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"

    Directory "/usr/local/www/nextcloud.example.com;
    Options Indexes FollowSymLinks MultiViews
    Options All
    AllowOverride All
    Require all grant

Don't forget to setup a script and cron job that will auto renew the cert since let's encrypt certs expire every 90-days
example of my script

Bash: 
/usr/local/bin/certbot renew --quiet --post-hook "apachectl graceful"
 
@timypcr just a hint. When you renew a certificate the service that is using the certificate must be reloaded to read the new certificate. To do this you shoud use the posthook option that is awailable in certboot.
for example:
/usr/local/bin/certbot renew --post-hook "service apache24 restart"
 
VladiBG said:
@timypcr just a hint. When you renew a certificate the service that is using the certificate must be reloaded to read the new certificate. To do this you shoud use the posthook option that is awailable in certboot.

for example:

/usr/local/bin/certbot renew --post-hook "service apache24 restart"
Click to expand...


I recall reading in the Let's Encrypt forums sometime ago that when certbot obtains a new cert that it automatically performs a graceful restart of apache, I also recall in early versions that an apache restart was required.

Just to be on the safe side I have updated my last reply, I always prefer to use "apachectl graceful" when I can in the event apache happens to be serving requests at the time of renewal. Also when using certbot renew with --post-hook within a cron job the --quite flag should be used.

example:
Bash: 
 /usr/local/bin/certbot renew --quiet --post-hook "apachectl graceful"

Thanks for the feedback

Tim
 
The "--quiet" option is optional if you want to see what's going on in your daily report then don't use "--quiet". A reload is not sufficient as it does not reload the SSL certificates so yes ether restart or graceful restart should work. The difference is that in graceful it doesn't interrupt the current connections.
 
You must log in or register to reply here.
Back
Top