Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I upgraded my Debian from Lenny to Squeeze. BIG MISTAKE.

Now I get:

[Tue Feb 08 16:34:57 2011] [error] Server should be SSL-aware but has no certificate configured [Hint: SSLCertificateFile] ((null):0)

littered throughout /var/log/apache2/error.log.

How to fix? Looking through a mess of forums it is easy to see that Apache changed the way it reads configurations around 2.2.13. Great. But not great for me or the millions of other web administrators who now have web servers that simply won't start, and an error message that says NOTHING about the problem or how to fix.

Anybody else actually solved this issue? I had perfectly working virtual servers with SSL before (for years actually).

share|improve this question
2  
Alas, it's very risky to upgrade to a new OS without having tested your configuration and the upgrade path on a test/staging/preproduction system. Can you post some relevant snippets from your apache configuration? –  daveadams Feb 8 '11 at 19:03
    
To be honest I'm not sure it's relevant. I might withdraw this question. It's just insanity to break thousands of configurations just on a whim. If the functionality is undocumented but most people rely on it then don't change it!!!! –  PP. Feb 8 '11 at 19:20
    
Even worse - the error message is COMPLETELY MISLEADING. It does not pin point the erroneous config line/file. It does not help in ANY way. –  PP. Feb 8 '11 at 19:25
add comment

4 Answers

up vote 9 down vote accepted

This problem is cause by a change in apache 2.2.12 to support SNI.

You can find all the details to fix the problem in the file /usr/share/doc/apache2.2-common/NEWS.Debian.gz on your server :

apache2 (2.2.13-2) unstable; urgency=high

  • The new support for TLS Server Name Indication added in 2.2.12 causes Apache to be stricter about certain misconfigurations involving name based SSL virtual hosts. This may result in Apache refusing to start with the logged error message:

    Server should be SSL-aware but has no certificate configured [Hint: SSLCertificateFile]

    Up to 2.2.11, Apache accepted configurations where the necessary SSL configuration statements were included in the first (default) block but not in subsequent blocks. Starting with 2.2.12, every VirtualHost block used with SSL must contain the SSLEngine, SSLCertificateFile, and SSLCertificateKeyFile directives (SSLCertificateKeyFile is optional in some cases).

    When you encounter the above problem, the output of the command

    egrep -ir '^[^#]*(sslcertificate|sslengine|virtualhost)' \
        /etc/apache2/*conf* /etc/apache2/*enabled
    

    may be useful to determine which VirtualHost sections need to be changed.

    Also, formerly accidentially working constructs like

    <VirtualHost *:80 *:443>
    

    where one virtual host definition is used for both a non-ssl and a ssl virtual host do not work anymore. You can achieve a similar effect with

    <VirtualHost *:80>
    Include /.../vhost.include
    </VirtualHost>
    <VirtualHost *:443>
    SSLEngine on
    SSLCertificateFile ...
    Include /.../vhost.include
    </VirtualHost>
    

    -- Stefan Fritsch Wed, 16 Sep 2009 20:14:59 +0200

Important information for packages upgrade are available in the NEWS.Debian file for a lot of packages. Installing the package apt-listchanges is recommanded to see the changes in this files on each upgrade.

share|improve this answer
1  
It would be more helpful to post relevant snippets from the NEWS.Debian file or at the very least provide a pointer to a webpage with this file, so that this response could be of use to folks who might not have a Squeeze install handy. –  daveadams Feb 8 '11 at 19:08
2  
You are right. I have added a copy of the relevant entry in the file and a link on the file in the package repository. –  jon_d Feb 9 '11 at 6:53
add comment

You need to replace:

Listen 443

with

Listen 443 http

Same time I think it will work only in case if you inherit SSL configuration from corresponding default virtual host and using constructions like <VirtualHost *:80 *:443>. In general that assumed that you using wildcard SSL certificate. These change will disable checks for SSLCertificateFile in corresponding VirtualHost.

It will NOT disable https functionality for that VirtualHost.

While such error you will have since Apache 2.2.12 it was improved in Apache 2.2.14

According changelog for Apache 2.2.14:

mod_ssl: The error message when SSLCertificateFile is missing should at least give the name or position of the problematic virtual host definition.

So if error message indicate name/position of problematic definition - better to check/correct corresponding virtualhost.

This is solution from here

Also you may be interested in messages from Stefan Fritsch here

share|improve this answer
    
It seems like if you specify the protocol you are saying to use http for connection on port 443. Am I wrong? httpd.apache.org/docs/2.2/mod/mpm_common.html#listen –  Lessfoe Aug 20 '12 at 15:55
    
I am saying to use "protocol specific optimizations" as for http. See more description on your link. That does not means that will be not used https protocol!!!! Let see - through VirtualHost we do not indicate neither SSLCertificateFile nor SSLEngine. Since Apache 2.2.12 there was made changes for SNI support which I guess made made as well changes for configuration integrity check. So it blindly gives error when sees '<VirtualHost *:80 *:443>'. With 'Listen 443 http' we disable such check. I am not sure but can guess that same effect you can reach with 'AcceptFilter' directive –  Broomerr Aug 29 '12 at 12:52
    
Thank you so much for posting this. –  aef Nov 10 '12 at 22:42
    
changing Listen 443 to Listen 443 http did the trick for me –  user103138 Jun 17 '13 at 7:51
add comment

I am adding this because this is specifically how I solved the issue. However I'm awarding the answer of this question to @Fussy Salsify who gave me the answer I needed.

As per the link offered, /usr/share/doc/apache2.2-common/NEWS.Debian.gz, I ran the following command from my /etc/apache2 directory:

egrep -ir '^[^#]*(sslcertificate|sslengine|virtualhost)' \
    /etc/apache2/*conf* /etc/apache2/*enabled

I have about 5 different virtual sites on my server. I found the one site that didn't have any SSL options inside the VirtualHost block, e.g.:

<VirtualHost *:443>
</VirtualHost>

Note that other virtual sites on my server had blocks like this:

<VirtualHost *:443>
    SSLEngine on
    SSLCertificateFile /etc/apache2/ssl/apache.pem
</VirtualHost>

So, I opened up my site-specific config file in /etc/apache2/sites-enabled/nnn-specific and inserted the lines:

    SSLEngine on
    SSLCertificateFile /etc/apache2/ssl/apache.pem

inside the <VirtualHost>...</VirtualHost> block.

The server now runs.

Apparently VirtualHost configurations used to inherit from the initial VirtualHost configuration. This was behaviour commonly encouraged to be used by most Apache tutorials - we were instructed to set up a default host (the first one) with the SSL configuration and that would be inherited by all others. I'm very unhappy this was changed.

share|improve this answer
add comment

As SNI was not available in Lenny (and is still not supported under MSIE/WinXP BTW) I used a wildcard domain certificate, then used VirtualDocumentRoot to provide multiple vhosts using the same certificate.

This is how I fixed my install after the upgrade:

In /etc/apache2/ports.conf

<IfModule mod_ssl.c>
     # If you add NameVirtualHost *:443 here, you will also have to change
     # the VirtualHost statement in /etc/apache2/sites-available/default-ssl
     # to <VirtualHost *:443>
     # Server Name Indication for SSL named virtual hosts is currently not
     # supported by MSIE on Windows XP.
     Listen 443
     ############ add this line below ##############
     NameVirtualHost *:443
 </IfModule>

Then in default-ssl, change

<VirtualHost _default_:443>

to

<VirtualHost *:443>

hope this helps others.

Rich / Artful Robot.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.