We are running a multi-host apache2 environment for several years. Out of a sudden apache no seems to require https.
Some trivial websites are cofigured without certificates on port 80 (and with self signed or let's-encrypt certificates on port 443).
With the recent automatic renewal of a let's-encrypt certificate I got an error message related to problems to retrieve the acme-challenge via http.
It seems to be related to a recent change of the default configuration of apache2 under Debian 4.19.x .
However I did not find any option in apache2 to undo the enforcement for SSL.
Here is my configuration for on of the respective vhost's (the problem exists also for another host):
<VirtualHost *:80 >
ServerName www.antXXX.XX
ServerAlias antXXX.XX *.antXXX.XX
ServerAdmin webmaster#...
DocumentRoot /data/www/htdocsantXXX
ErrorDocument 503 /ausserBetrieb.html
<Directory /data/www/htdocsantXXX>
Options FollowSymLinks MultiViews
<RequireAll>
require all granted
</RequireAll>
RedirectMatch ^/$ /index.html
</Directory>
ErrorLog /var/log/apache2/antXXX/errorantXXX.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel debug
CustomLog /var/log/apache2/antXXX/accessantXXX.log combined
ServerSignature On
</VirtualHost>
<VirtualHost *:443>
ServerName www.antXXX.XX
ServerAlias antXXX.XX *.antXXX.XX
ServerAdmin webmaster#...
DocumentRoot /data/www/htdocsantXXX
...
</VirtualHost>
I was not able to find the respective option in the basic configuration of apache nor the error document that contains the HTML-Text for "This site is configured to require an SSL (https) connection...".
I know that there is the http-option Upgrade-Insecure-Requests: 1 . However the problem also exists, when retrieving the web document locally with curl -v http://www.antXXX.XX .
How can I undo the https-requirement for the respective vhosts?
Thank you for you support
Wallenstein
Oh sorry. Finally I have found the culprit.
I have recently experimented with the yubikey authorization in the module authn-yubikey .
Its activation seemed to enforce https. At least I found the respecitive HTML-code via the strings-command.
After disabling this module http-access was available again.
Wallenstein
So I've got a login script (domain.com/script/index.php) that I need protected with a self-signed certificate, but installing a cert with Apache will apply it to my whole domain. My domain is a personal website, and the last thing I would want is for someone to go through the hassle of having to jump through the hoops of having to 'trust' my self-signed certificate.
Right now I have Webmin running on my server, and it currently has its own self-signed without applying it to my root website directory. Is there any way to secure my script directory without applying it to my root directory?
I'm gonna assume this is php and apache:
Just add this lines to your vhost configs:
SSLEngine on
SSLCertificateFile {{SERVER CRT PATH}}
SSLCertificateKeyFile {{SERVER CRT PATH}}
Make sure SSL dll is on in the php.ini
and apply like so:
# Local Php site
<VirtualHost *:83>
ServerName localhost
DocumentRoot C:/xampp2/htdocs/scripts/php
<Directory C:/xampp2/htdocs/scripts/php>
AllowOverride All
Require all granted
</Directory>
SSLEngine on
SSLCertificateFile C:\xampp2\apache\conf\ssl.crt\server.crt
SSLCertificateKeyFile C:\xampp2\apache\conf\ssl.key\server.key
</VirtualHost>
Reference: http://robsnotebook.com/xampp-ssl-encrypt-passwords
restart apache then visit: https://localhost:83
I have my gitlab working locally, but somehow i cannot access it externally. Can't figure out the problem. I'm running Debian 8 system.
Current conf files :
/etc/gitlab/gitlab.rb
gitlab_url = "http://127.0.0.1:9999"
external_url "http://gitlab.example.ee"
gitlab_rails['gitlab_host'] = "gitlab.example.ee"
gitlab_rails['gitlab_email_from'] = "gitlab#example.ee"
gitlab_rails['internal_api_url'] = "http://localhost:9999"
web_server['external_users'] = ['www-data']
unicorn['port'] = "9999"
nginx['enable'] = false
apache vhost (/etc/apache2/sites-available/gitlab.conf)
<VirtualHost *:9999>
ServerAdmin info#example.ee
DocumentRoot /opt/gitlab/embedded/service/gitlab-rails/public
ServerName gitlab.example.ee
ServerAlias gitlab.example.ee
ProxyPreserveHost On
<Location />
Order deny,allow
Allow from all
Options FollowSymLinks
Require all granted
ProxyPassReverse http://localhost:9999/
ProxyPassReverse http://gitlab.example.ee/
</Location>
RewriteEngine on
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RewriteRule .* http://localhost:9999%{REQUEST_URI} [P,QSA]
ErrorDocument 404 /404.html
ErrorDocument 422 /422.html
ErrorDocument 500 /500.html
ErrorDocument 503 /deploy.html
LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b" common_forwarded
ErrorLog /${APACHE_LOG_DIR}/gitlab.error.log
CustomLog /${APACHE_LOG_DIR}/gitlab.forwarded.log common_forwarded
CustomLog /${APACHE_LOG_DIR}/gitlab.access.log combined env=!dontlog
CustomLog /${APACHE_LOG_DIR}/gitlab.log combined
</VirtualHost>
You may need to ensure that your firewall is not blocking connections to port 9999. On Ubuntu you might need to do something like:
sudo ufw allow 9999/tcp
I realize this question is a few years old, but I've been playing with a similar setup recently (but without the ISPConfig installation). Throwing in my 2 cents for others who may run across this (this is my first time answering, so take it easy on me).
NOTE The op has not specified the version of GitLab being used. More recent versions of GitLab are probably using newer versions of gitlab.rb so I'm not sure if that will make a difference.
NOTE 2 I have found great information directly from GitLab at this site: https://docs.gitlab.com/omnibus/settings/nginx.html#using-a-non-bundled-web-server. This is basically a copy and paste, but I'm throwing in my own notes to help out where I had issues as a complete n00b.
Disable bundled Nginx
In /etc/gitlab/gitlab.rb set:
nginx['enable'] = false
Set the username of the non-bundled web-server user
By default, omnibus-gitlab has no default setting for the external
webserver user, you have to specify it in the configuration. For
Debian/Ubuntu the default user is www-data for both Apache/Nginx
whereas for RHEL/CentOS the Nginx user is nginx.
Note: Make sure you have first installed Apache/Nginx so the webserver
user is created, otherwise omnibus will fail while reconfiguring.
Let's say for example that the webserver user is www-data. In
/etc/gitlab/gitlab.rb set:
web_server['external_users'] = ['www-data']
Note: This setting is an array so you can specify more than one user
to be added to gitlab-www group. Personal Note: Please pay
close attention to the single-quotes and the array here. While
developing, I've rebuild my gitlab server multiple times and entered
in JUST a string or JUST an array and both will fail. The Chef script
will use this value to set up file permissions for its internal
directories, so Apache will not be able to write to files if this is
not correct.
Run sudo gitlab-ctl reconfigure for the change to take effect.
Note: if you are using SELinux and your web server runs under a
restricted SELinux profile you may have to loosen the restrictions on
your web server.
*Note: make sure that the webserver user has the correct permissions on all directories used by external web-server, otherwise you will
receive failed (XX: Permission denied) while reading upstream errors.
Add the non-bundled web-server to the list of trusted proxies (OPTIONAL: This is only required if your web server is on a
different machine from your gitlab instance)
Normally, omnibus-gitlab defaults the list of trusted proxies to the
what was configured in the real_ip module for the bundled NGINX.
For non-bundled web-servers the list needs to be configured directly,
and should include the IP address of your web-server if it not on the
same machine as GitLab. Otherwise users will be shown as being signed
in from your web-server's IP address.
gitlab_rails['trusted_proxies'] = [ '192.168.1.0/24', '192.168.2.1', '2001:0db8::/32' ]
(Optional) Set the right gitlab-workhorse settings if using Apache PERSONAL NOTE: I believe this is the missing config from the op's question.
Note: The values below were added in GitLab 8.2, make sure you have
the latest version installed.
Apache cannot connect to a UNIX socket but instead needs to connect to
a TCP Port. To allow gitlab-workhorse to listen on TCP (by default
port 8181) edit /etc/gitlab/gitlab.rb:
gitlab_workhorse['listen_network'] = "tcp"
gitlab_workhorse['listen_addr'] = "127.0.0.1:8181"
Run sudo gitlab-ctl reconfigure for the change to take effect.
Download the right web server configs
Go to GitLab recipes repository and look for the omnibus configs
in the webserver directory of your choice. Make sure you pick the
right configuration file depending whether you choose to serve GitLab
with SSL or not. The only thing you need to change is YOUR_SERVER_FQDN
with your own FQDN and if you use SSL, the location where your SSL
keys currently reside. You also might need to change the location of
your log files.
For the sake of completeness, here is an example of the Apache v2.4 config without the SSL configuration: READ THE COMMENTS: If you followed my above notes, in step 4 the gitlab_workhorse has already been configured to listen on tcp instead of a unix socket so that line may be ignored. DO NOT IGNORE the module dependencies! These are required for Apache to be able to proxy requests to your gitlab instance. On Ubuntu (I'm using Ubuntu Server 16.04.4, but I believe most other Ubuntu version react the same), these modules can be activated using sudo a2enmod rewrite proxy proxy_http.
# This configuration has been tested on GitLab 8.2
# Note this config assumes unicorn is listening on default port 8080 and
# gitlab-workhorse is listening on port 8181. To allow gitlab-workhorse to
# listen on port 8181, edit or create /etc/default/gitlab and change or add the following:
#
# gitlab_workhorse_options="-listenUmask 0 -listenNetwork tcp -listenAddr 127.0.0.1:8181 -authBackend http://127.0.0.1:8080"
#
#Module dependencies
# mod_rewrite
# mod_proxy
# mod_proxy_http
<VirtualHost *:80>
ServerName YOUR_SERVER_FQDN
ServerSignature Off
ProxyPreserveHost On
# Ensure that encoded slashes are not decoded but left in their encoded state.
# http://doc.gitlab.com/ce/api/projects.html#get-single-project
AllowEncodedSlashes NoDecode
<Location />
# New authorization commands for apache 2.4 and up
# http://httpd.apache.org/docs/2.4/upgrading.html#access
Require all granted
#Allow forwarding to gitlab-workhorse
ProxyPassReverse http://127.0.0.1:8181
ProxyPassReverse http://YOUR_SERVER_FQDN/
</Location>
# Apache equivalent of nginx try files
# http://serverfault.com/questions/290784/what-is-apaches-equivalent-of-nginxs-try-files
# http://stackoverflow.com/questions/10954516/apache2-proxypass-for-rails-app-gitlab
RewriteEngine on
#Forward all requests to gitlab-workhorse except existing files like error documents
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_URI} ^/uploads/.*
RewriteRule .* http://127.0.0.1:8181%{REQUEST_URI} [P,QSA,NE]
# needed for downloading attachments
DocumentRoot /home/git/gitlab/public
#Set up apache error documents, if back end goes down (i.e. 503 error) then a maintenance/deploy page is thrown up.
ErrorDocument 404 /404.html
ErrorDocument 422 /422.html
ErrorDocument 500 /500.html
ErrorDocument 502 /502.html
ErrorDocument 503 /503.html
# It is assumed that the log directory is in /var/log/httpd.
# For Debian distributions you might want to change this to
# /var/log/apache2.
LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b" common_forwarded
ErrorLog /var/log/httpd/logs/YOUR_SERVER_FQDN_error.log
CustomLog /var/log/httpd/logs/YOUR_SERVER_FQDN_forwarded.log common_forwarded
CustomLog /var/log/httpd/logs/YOUR_SERVER_FQDN_access.log combined env=!dontlog
CustomLog /var/log/httpd/logs/YOUR_SERVER_FQDN.log combined
</VirtualHost>
This config file will not work with a simple copy and paste!
Find and replace "YOUR_SERVER_FQDN" with the Fully Qualified Domain Name of your gitlab instance. Per the op's question, this would be http://gitlab.example.ee, but should basically match the value of external_url from your gitlab.rb file.
Find and replace "httpd" with "apache". The config was not designed with a Ubuntu server in mind and the appropriate directory is called "apache". I would assume you could also use ${APACHE_LOG_DIR}, but I have not tested this myself.
For a basic setup, this should work fine. I would highly recommend looking into using the SSL setup (documentation can be found at the links provided). Even if you don't need a secure setup (maybe this is an internal server), other features in the omnibus, like Mattermost, are prone to throw errors without SSL enabled (and not with a self-signed certificate).
What I am trying to do is direct my website on an Amazon EC2 Instance so that I am able to open on an HTTPS protocol. My site was running before but with a warning that it did not have a valid certificate, using this link example https://my.site.name.edu but now I get a "Webpage is not Available" prompt when I try to visit the site.
Please note that I have:
Installed Drupal for this testing site on a Linux server using Apache
My EC2 Instance attached to an Elastic IP
Used the steps in this guide: Creating, Uploading, and Deleting Server Certificates
Valid CA signed Apache certificates
An openssl-1.0.1f file installed in /home/ec2-user folder
Used this link to create the Virtual Host: http://ananthakrishnanravi.wordpress.com/2012/04/15/configuring-ssl-and-https-for-your-website-amazon-ec2/
Below is when the error occurred, while trying to solve the HTTPS access issue
I tried to change the ssl.conf file in this link to see if it would solve the problem: Setup an SSL certificate on an EC2 instance
I copied a new ssl.conf file, commented the old SSLCertificateKeyFile, SSLCertificateFile and SSLCertificateChainFile. I then pasted the copied, modified file into the directory after I coded the first four lines like this:
<VirtualHost 00.00.00.00:443>
SSLCertificateKeyFile /home/ec2-user/castestingapache/privatekey.pem
SSLCertificateFile /home/ec2-user/castestingapache/my_site_name_edu.pem
SSLCertificateChainFile /home/ec2-user/castestingapache/my_site_name_edu_interm.crt
But when I restarted Apache:
service httpd restart
I received this error message:
Stopping httpd: [FAILED]
Starting httpd: [Wed May 21 14:44:31 2014] [warn] module ssl_module is already loaded, skipping
(98)Address already in use: make_sock: could not bind to address [::]:443
[ OK ]
My httpd.conf is set up like this:
<VirtualHost 00.00.00.00:443> #Same as the IP in the ssl.conf#
ServerAdmin ec2-user#ec2-00-00-00-00.compute.amazonaws.com
DocumentRoot /var/www/html
ServerName https://my.site.name.edu
SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM
# ErrorLog logs/errorlogs
# CustomLog logs/custom
SSLCertificateFile /home/ec2-user/castestingapache/my_site_name_edu.pem
SSLCertificateKeyFile /home/ec2-user/castestingapache/privatekey.pem
SSLCertificateChainFile /home/ec2-user/castestingapache/my_site_name_edu_interm.crt
# SSLCACertificateFile /etc/httpd/conf/bundle.txt
SetEnvIf User-Agent “.*MSIE.*” nokeepalive ssl-unclean-shutdown
# CustomLog /usr/local/apache/logs/ssl_request_log \
# “%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \”%r\” %b”
</VirtualHost>
EDIT: I tried reverting back to the old ssl.conf but when I try to restart Apache it gives me the same error. THIS PROBLEM HAS BEEN SOLVED I had to delete one of the ssl.conf even though I had renamed it...
Update I have added this line onto the httpd.conf file:
NameVirtualHost 00.00.00.00:443
I believe the problem is that my certificates are not pointing to this IP address.
Update I have just ran the certificate installation checker test here http://ssltool.com/?action=sslCheckOpenSSL and this is what I got:
Note: IP 12-34-56-78 is my private IP address on my AWS EC2 Instance.
Any help is greatly appreciated.
Thanks,
Ugh.... the answer was in this link the whole time...
Setup an SSL certificate on an EC2 instance
This line in the ssl.conf:
<VirtualHost 00.000.000.00:443>
Had to be changed to:
<VirtualHost _default_:443>
Add the rest:
SSLCertificateKeyFile /etc/ssl/mydomain_com.key
SSLCertificateFile /etc/ssl/mydomain_com.crt
SSLCertificateChainFile /etc/ssl/mydomain_com.ca-bundle
</VirtualHost>
And voilah! Your HTTPS: link should work...
I'm trying to configure Apache on my server to work with ssl, but everytime I visit my site, I get the following message in my browser:
SSL connection error.
Unable to make a secure connection to the server. This may be a problem with the server, or it may be requiring a client authentication certificate that you don't have.
Error 107 (net::ERR_SSL_PROTOCOL_ERROR): SSL protocol error.
The error message above seems to be native to Google Chrome. However, even though the messages are different, ssl for the site is not working on any browser.
Just some background on the situation: I am using Ubuntu 10.04 desktop edition.
I installed apache by installing zend server (it installed apache automatically).
I then installed openssl. Non-https pages work fine on the site.
I tried getting trial certificates from multiple certificate sites but nothing is working (same error).
I was previously hosting my site on another server on which ssl worked just fine. I also tried using the key and cert file from that server, but I got the same error.
The domain name and IP are still the same though. My SSLCertificateFile and SSLCertificateKeyFile are pointing to the correct directory and files.
I also do not have SSLVerifyClient enabled.
If anyone has any suggestions, it would be most appreciated.
I had the same problem as #User39604, and had to follow VARIOUS advices. Since he doesnt remember the precise path he followed, let me list my path:
check if you have SSL YES using <?php echo phpinfo();?>
if necessary
A. enable ssl on apache sudo a2enmod ssl
B. install openssl sudo apt-get install openssl
C. check if port 443 is open sudo netstat -lp
D. if necessary, change /etc/apache2/ports.conf, this works
NameVirtualHost *:80
Listen 80
<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.
NameVirtualHost *:443
Listen 443
</IfModule>
<IfModule mod_gnutls.c>
Listen 443
</IfModule>
acquire a key and a certificate by
A. paying a Certificating Authority (Comodo, GoDaddy, Verisign) for a pair
B. generating your own* - see below (testing purposes ONLY)
change your configuration (in ubuntu12 /etc/apache2/httpd.conf - default is an empty file) to include a proper <VirtualHost>
(replace MYSITE.COM as well as key and cert path/name to point to your certificate and key):
<VirtualHost _default_:443>
ServerName MYSITE.COM:443
SSLEngine on
SSLCertificateKeyFile /etc/apache2/ssl/MYSITE.COM.key
SSLCertificateFile /etc/apache2/ssl/MYSITE.COM.cert
ServerAdmin MYWEBGUY#localhost
DocumentRoot /var/www
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>
ErrorLog ${APACHE_LOG_DIR}/errorSSL.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog ${APACHE_LOG_DIR}/accessSSL.log combined
</VirtualHost>
while many other virtualhost configs wil be available in /etc/apache2/sites-enabled/ and in /etc/apache2/sites-available/ it was /etc/apache2/httpd.conf that was CRUCIAL to solving all problems.
for further info:
http://wiki.vpslink.com/Enable_SSL_on_Apache2
http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#selfcert
*generating your own certificate (self-signed) will result in a certificate whose authority the user's browser will not recognize. therefore, the browser will scream bloody murder and the user will have to "understand the risks" a dozen times before the browser actually opens up the page. so, it only works for testing purposes. having said that, this is the HOW-TO:
goto the apache folder (in ubuntu12 /etc/apache2/)
create a folder like ssl (or anything that works for you, the name is not a system requirement)
goto chosen directory /etc/apache2/ssl
run sudo openssl req -new -x509 -nodes -out MYSITE.COM.crt -keyout MYSITE.COM.key
use MYSITE.COM.crt and MYSITE.COM.key in your <VirtualHost> tag
name format is NOT under a strict system requirement, must be the same as the file :)
- names like 212-MYSITE.COM.crt, june2014-Godaddy-MYSITE.COM.crt should work.
I was getting the same error in chrome (and different one in Firefox, IE).
Also in error.log i was getting [error] [client cli.ent.ip.add] Invalid method in request \x16\x03
Following the instructions form this site I changed my configuration FROM:
<VirtualHost subdomain.domain.com:443>
ServerAdmin admin#domain.com
ServerName subdomain.domain.com
SSLEngine On
SSLCertificateFile conf/ssl/ssl.crt
SSLCertificateKeyFile conf/ssl/ssl.key
</VirtualHost>
TO:
<VirtualHost _default_:443>
ServerAdmin admin#domain.com
ServerName subdomain.domain.com
SSLEngine On
SSLCertificateFile conf/ssl/ssl.crt
SSLCertificateKeyFile conf/ssl/ssl.key
</VirtualHost>
Now it's working fine :)
Step to enable SSL correctly.
sudo a2enmod ssl
sudo apt-get install openssl
Configure the path of SSL certificates in your SSL config file (default-ssl.conf) that might be located in /etc/apache2/sites-available. I have stored certificates under /etc/apache2/ssl/
SSLEngine On
SSLCertificateFile /etc/apache2/ssl/certificate.crt
SSLCertificateChainFile /etc/apache2/ssl/ca_bundle.crt
SSLCertificateKeyFile /etc/apache2/ssl/private.key
Enable SSL config file
sudo a2ensite default-ssl.conf
A common cause I wanted to suggest for this situation:
Sometimes a customer is running Skype, which is using port 443 without their realizing it. When they go to start Tomcat or Apache, it appears to start but cannot bind with port 443. This is the exact message that the user would receive in the browser. The fix is to stop what was running on port 443 and re-start the webserver so it can bind with port 443.
The customer can re-start Skype after starting the webserver, and Skype will detect that port 443 is in use and choose a different port to use.
#Make sure that you specify the port for both http and https ie.
NameVirtualHost:80
NameVirtualHost:443
#and
<VirtualHost *:80>
<VirtualHost *:443>
#mixing * and *:443 does not work it has to be *:80 and *:443
I got this problem and the solution was a bit silly.
I am using Cloudflare which acts as a proxy to my website. In order to be able to login via SSH, I added an entry to my /etc/hosts file so I didn't need to remember my server's IP address.
xxx.xx.xx.xxx example.com
So in my browser when I went to https://www.example.com, I was using the Cloudflare proxy, and when I went to to https://example.com I was going directly to the server. Because the Cloudflare setup doesn't require you to add the intermediate certificates, I was seeing this security exception in my browser when I went to https://example.com, but https://www.example.com was working.
The solution: remove the entry from my laptop's /etc/hosts file.
If this isn't your problem, I recommend using one of the many online SSL checker tools to try diagnose your problem.
I also recommend using ping to check the IP address being reported and check it against the IP address expected.
ping https://www.example.com/
Another very helpful SSL resource is the Mozilla SSL Configuration Generator. It can generate SSL configuration for you.
I didn't know what I was doing when I started changing the Apache configuration. I picked up bits and pieces thought it was working until I ran into the same problem you encountered, specifically Chrome having this error.
What I did was comment out all the site-specific directives that are used to configure SSL verification, confirmed that Chrome let me in, reviewed the documentation before directive before re-enabling one, and restarted Apache. By carefully going through these you ought to be able to figure out which one(s) are causing your problem.
In my case, I went from this:
SSLVerifyClient optional
SSLVerifyDepth 1
SSLOptions +StdEnvVars +StrictRequire
SSLRequireSSL On
to this
<Location /sessions>
SSLRequireSSL
SSLVerifyClient require
</Location>
As you can see I had a fair number of changes to get there.
I had this error when I first followed instructions to set up the default apache2 ssl configuration, by putting a symlink for /etc/apache2/sites-available/default-ssl in /etc/apache2/sites-enabled. I then subsequently tried to add another NameVirtualHost on port 443 in another configuration file, and started getting this error.
I fixed it by deleting the /etc/apache2/sites-enabled/default-ssl symlink, and then just having these lines in another config file (httpd.conf, which probably isn't good form, but worked):
NameVirtualHost *:443
<VirtualHost *:443>
SSLEngine on
SSLCertificateChainFile /etc/apache2/ssl/chain_file.crt
SSLCertificateFile /etc/apache2/ssl/site_certificate.crt
SSLCertificateKeyFile /etc/apache2/ssl/site_key.key
ServerName www.mywebsite.com
ServerAlias www.mywebsite.com
DocumentRoot /var/www/mywebsite_root/
</VirtualHost>
I encounter this problem, because I have <VirtualHost> defined both in httpd.conf and httpd-ssl.conf.
in httpd.conf, it's defined as
<VirtualHost localhost>
in httpd-ssl.conf, it's defined as
<VirtualHost _default_:443>
The following change solved this problem, add :80 in httpd.conf
<VirtualHost localhost:80>
This is what fixed it for me on Ubuntu.
Enabled the module: a2enmod ssl
Moved all cert related files to a folder /usr/local/ssl and made it world readable: chmod -R +r /usr/local/ssl
Changed <VirtualHost *:80> to <VirtualHost *:*> in my virtual host.
Added SSLEngine On before all other SSL directives in my virtual host.
If you set a pass phrase on the cert, Apache should prompt you for it on restart.
Similar to other answers, this error can be experienced when there are no sites configured to use SSL.
I had the error when I upgraded from Debian Wheezy to Debian Jessie. The new version of Apache requires a site configuration file ending in .conf. Because my configuration file didn't, it was being ignored, and there were no others configured to serve SSL connections.
I encountered this issue, also due to misconfiguration. I was using tomcat and in the server.xml had specified my connector as such:
<Connector port="17443" SSLEnabled="true"
protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="150" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keyAlias="wrong" keystorePass="secret"
keystoreFile="/ssl/right.jks" />
When i fixed it thusly:
<Connector port="17443" SSLEnabled="true"
protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="150" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keyAlias="right" keystorePass="secret"
keystoreFile="/ssl/right.jks" />
It worked as expected. In other words, verify that you not only have the right keystore, but that you have specified the correct alias underneath it. Thanks for the invaluable hint user396404.
I solved it by commenting out:
AcceptFilter https none
in httpd.conf
according to:
http://www.apachelounge.com/viewtopic.php?t=4461
It turns out that the SSL certificate was installed improperly. Re-installing it properly fixed the problem