LetsEncrypt SSL Error - SSL routines:ssl3_get_record:wrong version number - apache

I've managed to pull down a fresh cert from LetsEncrypt. My VirtualHost config is set up as:
<VirtualHost *:80>
ServerName example.com
Redirect 301 / https://example.com/
</VirtualHost>
<VirtualHost *:443>
Servername example.com
DocumentRoot /var/www/example.com/wav
ErrorLog /var/log/apache2/example.com/www/error.log
SSLEngine On
SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
</VirtualHost>
When trying to verify this with openssl:
openssl s_client -connect example.com -port 443
I get the following:
CONNECTED(00000003)
140229655213824:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:252:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 202 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1541086087
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
So, looks like the handshake is okay but the cert isn't being sent.
Worth pointing out that the Apache logs don't report any errors - just the usual - "starting up/shutting down" messages. apache2ctl configtest reports no issues.

So, looks like the handshake is okay but the cert isn't being sent.
The handshake is not ok. The Client has sent the ClientHello to start the handshake but received nothing useful back:
|- ClientHello
---
SSL handshake has read 5 bytes and written 202 bytes
---
|- nothing useful from server
I don't know what it is getting back in the 5 bytes but it does not look like TLS (too short for a TLS message). It might be some server misconfiguration which can not be seen from the part of the config you've shown. It might also be some middlebox (firewall, load balancer...) hurting the connection. It might also be that you don't connect to the expected server (i.e. example.com does not resolve to your actual server).
I recommend that you first check on the server itself (i.e. localhost) and if this works move further away from the server with your checks. You might also do a packet capture and have a look what you'll find in the 5 bytes received by the client.

Just sharing for anyone who ends up here with the same problem.
This is my experience in Ubuntu 20 with Apache
I was editing the default-ssl.conf in SITES-AVAILABLE folder but nothing happened. The above same error was repeating no matter what i did.
I copied the default-ssl.conf from sites-available into SITES-ENABLED folder without the IfModule mod_ssl.c tag and THAT SOLVED THE PROBLEM.
Hope this info helps someone.
Thanks

It seems apache's default *:80 HTTP handler will also listen on 443 for unmatched VirtualHost IPs including loopback.
For example, my machine has a NAT ip 192.168.32.5 and of course the 127.0.0.1 loopback. If my site conf uses <VirtualHost 192.168.32.5:443> then any requests that resolve to 127.0.0.1:443 are actually answered by the default HTTP handler...not HTTPS. Simply setting my hosts entry for the SSL hostname to 192.168.32.5 fixed the issue.

I had the same issue. My example.com.conf file did have HTTPS set up properly, but my 000-default.conf file did not. I seemed to have forgotten to include the SSL certificate and turn on the SSL engine for my 000-default.conf, but after I fixed that, it worked perfectly.
The code I added to 000-default.conf:
SSLEngine On
SSLCertificateFile /etc/ssl/example.com/domain.cert.pem
SSLCertificateKeyFile /etc/ssl/example.com/private.key.pem

I got the same error with you. suggest you test your https connection on local, add your domain name to /etc/hosts, ex:
127.0.0.1 yourdomain.com
in order to keep packet not going out.
then using "links" to test the https connection in local environment, if no problem, then it's caused by ISP firewall issue or setting, I finally found local https connection ok and throw the problem to ISP to solve this problem finally, good luck!

set your file types for ssl as well, this is confirmed working
See the FilesMatch section? If that is missing, you will see this error.
SSLEngine on
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
SSLCertificateFile /etc/letsencrypt/live/mysite.net/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/mysite.net/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
SSLHonorCipherOrder on
SSLProtocol all -SSLv2 -SSLv3
#SSLCipherSuite EECDH+AES:EDH+AES:-SHA1:EECDH+RC4:EDH+RC4:RC4-SHA:EECDH+AES256:EDH+AES256:AES256-SHA:!aNULL:!eNULL:!EXP:!LOW:!MD5
#SSLCipherSuite "AES256-SHA"
SSLCipherSuite HIGH:!aNULL:!MD5

We had the problem that our HTTPS-port was serving unencrypted HTTP.
The reason was that we had two VirtualHosts on the same port and one was configured to use SSLEngine on and the other one not.
Deactivating the unencrypted site fixed the problem. Using SSLEngine on on both VirtualHosts would also fix it.
Also, we needed a proper service restart to get out of that problem. A reload had not fixed the problem, although the config was correct at that time.

Related

Apache 2.4.37 with openssl 1.1.1: cannot perform post-handshake authentication

I updated apache to last version 2.4.37 and openssl to 1.1.1 and now, when client authenticates, I get this error only with Firefox 63, but not in Chrome:
[ssl:error] AH: verify client post handshake, referer: https://******/login
[ssl:error] AH10158: cannot perform post-handshake authentication, referer: https://******/login
[ssl:error]SSL Library Error: error:14268117:SSL routines:SSL_verify_client_post_handshake:extension not received
I used wireshark to try to find the problem, and I apreciate Firefox uses TLS 1.3, while Chrome uses TLS 1.2. In fact, if I set TLS max version in FF to TLS 1.2, it works fine.
I would like to get TLS 1.3 compatibility or, if it is not yet possible, to force, in my Apache configuration, the client always uses TLS 1.2, but I don't get it :(
This is my apache vhost config file:
[...]
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/server.crt
SSLCertificateKeyFile /etc/apache2/ssl/server.key
SSLCertificateChainFile /etc/apache2/ssl/intermediate.crt
SSLCACertificateFile /etc/apache2/ssl/ca.pem
SSLVerifyDepth 3
SSLProtocol TLSv1.2
SSLHonorCipherOrder on
<Directory /var/www/html/>
Options -Indexes +FollowSymLinks -MultiViews
AllowOverride All
Order deny,allow
Allow from 10.55.12.0/24
Deny from all
</Directory>
<Files "login-ssl.php">
SSLVerifyClient optional
SSLOptions +StdEnvVars +StrictRequire
</Files>
[...]
Can someone help me, please?
Thanks.
Edited
I found the solution. SSLProtocol directive should be in /etc/apache2/mods-enabled/ssl.conf.
The problem is that Firefox doesn't support TLS 1.3 post-handshake authentication. I've reported this issue to Firefox at https://bugzilla.mozilla.org/show_bug.cgi?id=1511989
I'm not suggesting a workaround or fix here; I'm merely telling others who come across this page (as it is high up for this error message in the search results) what the situation is and where to find the latest information as Firefox works to resolve this issue.
In case this helps other, for my reverse proxy test configuration with Apache HTTP 2.4.41 on Windows, I wanted to protect only the balancer-manager URI with client certificate authentication, that I had generated using OpenSSL with CA certs, server certs signed by CA and client cert signed by CA, imported the P12 in my browser.
For my other back end URLs (Spring Boot with AJP enabled and running same application on 2 different set of ports to test balancing via Apache HTTP) that were being proxied, configuration was to do not perform any client certificate authentication.
Accessing https://myhostname.com was working and hitting my back end
via balancer, returning the expected response.
Accessing https://myhostname.com/balancer-manager was expected to
prompt me for selecting client certificate that I imported earlier,
but gave this error on Chrome 80.0 ( and did not work for other
browsers as well).
Forbidden You don't have permission to access this resource.Reason:
Cannot perform Post-Handshake Authentication.
In Apache error log, it showed:
SSL Library Error: error:14268117:SSL
routines:SSL_verify_client_post_handshake:extension not received
In Apache access log, it showed:
GET /balancer-manager HTTP/1.1" 403 199
Non working configuration for Virtual host config in httpd.conf looked like:
<VirtualHost *:443>
ServerName myhostname.com
ServerAlias myhostname.com
SSLEngine on
SSLCipherSuite ALL:!EXP:!eNULL:!aNULL:!MD5:-LOW:-RC4:-SSLv2:+HIGH:+MEDIUM
#no certificate authentication required except balancer manager
SSLVerifyClient none
SSLVerifyDepth 5
SSLProtocol all -SSLv3
SSLCertificateFile "path/to/server/certificate"
SSLCertificateKeyFile "path/to/server/key"
SSLCACertificateFile "path/to/CA/certificate"
<Location "/balancer-manager">
SSLVerifyClient require
SetHandler balancer-manager
Require host myhostname.com
</Location>
<Proxy balancer://cluster>
BalancerMember ajp://localhost:9090/ loadfactor=25 timeout=1
BalancerMember ajp://localhost:9091/ loadfactor=75 timeout=1
ProxySet lbmethod=byrequests
</Proxy>
ProxyPreserveHost off
ProxyRequests Off
ProxyPass / balancer://cluster/ stickysession=JSESSIONID
ProxyPassReverse / balancer://cluster/ stickysession=JSESSIONID
</VirtualHost>
To fix the issue, change SSLProtocol directive to use:
SSLProtocol -all +TLSv1.2
See these links also
Enable TLS in Apache
TLS-1-2
I used TLS 1.2 for tests (TLS 1.1 also worked but recommended to use TLS 1.2 or higher version).
Note:The Apache version 2.4.38 or higher versions support TLS v1.3. You
must upgrade Apache packages before enabled TLS 1.3 in SSL settings.
*

Apache 2.4 SSL Config

I've got a question regarding ssl config for apache 2.4. I got the following ssl settings for my vhost. There are more than 1 Directory but the config is mostly the same, only IPs are different. If I active the the three commented lines the apache should check the requests against the cert and not just pass the request through, correct? I assume the apache breakts the encryption for all requests from the internet and re-encrypts again to pass the request on. Am I right? Is there a way to not break the encryption and just delegate the cert checks to the next system?
RequestHeader set ClientProtocol HTTPS
SSLEngine On
SSLProtocol ALL -SSLv2 -SSLv3
SSLProxyEngine On
SSLProxyProtocol ALL -SSLv2 -SSLv3
SSLHonorCipherOrder On
SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:HIGH:!MD5:!aNULL:!EDH
SSLCertificateFile /path/to/file.crt
SSLCertificateKeyFile /path/to/file.key
<Directory /folder-name>
#SSLVerifyClient optional_no_ca
#SSLVerifyDepth 1
#SSLOptions +OptRenegotiate +ExportCertData
ProxyPass https://10.20.30.40:8443/
ProxyPassReverse https://10.20.30.40:8443/
</Directory>
Thanks for your help guys and regards. Sebastian
Yes, this Apache acting as a proxy terminates SSL. It then makes or reuses a pooled SSL connection to the backend.
There's no way to truly let the backend think it's handshaking with the client unless it accessed apache as a forward proxy using the mod_proxy_connect module.
Some application servers accept the body of the client certificate in a proprietary header, making that identity available in the backend server. But they are not actually authenticating it in the handshake like the proxy/apache has done.

SSL handshake issue with remote apache httpd server, works locally

I'm getting strange issue:
I have installed/configured ssl certificate/key and ca certs etc in apache, and now can access it on latest chrome/firefox browser from local machine, and they show the certificate is all good (total green lock icon), and also shows it using modern cipher suite.
Note that i'm accessing it from local machine via server name itself, not from localhost etc, and not by changing hosts file.. Also it is accessible from another computer in same network without any issue..
But when i try to access this from different, remote machine (not in same network) or via a vpn etc, i get ssl connection error. Firefox indicates "Peer reports it experienced an internal error. (Error code: ssl_error_internal_error_alert)".
I used openssl command on remote machine to mimic a client:
*openssl s_client -connect xyz.com:443 -state -nbio 2>&1*
it shows:
WARNING: can't open config file: /usr/local/ssl/openssl.cnf
Loading 'screen' into random state - done
CONNECTED(00000170)
turning on non blocking io
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:error in SSLv2/v3 read server hello A
write R BLOCK
SSL3 alert read:fatal:internal error
SSL_connect:error in SSLv2/v3 read server hello A
7020:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error:.\ssl\s23_clnt.c:762:
- - -
no peer certificate available
- - -
No client certificate CA names sent
- - -
SSL handshake has read 7 bytes and written 307 bytes
- - -
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
- - -
I have to use apache httpd to use https, and fwd requests to tomcat, which is only using http, and used ajp-proxy for this purpose.
I tried to remove proxy configuration, restarted and still no luck - on local machine it show "it works" page, and on remote machine, same ssl connection error.
Nothing in apache logs also corresponding to the tries from remote machine (i.e. they are not reaching till those logs).
BUT strangely, the existing configuration do work from remote machine for 30-40 minutes (i.e. for some time) after a long not-working period. and then same configuration go for toss again.. can't understand why. During whole this period, it always remain accessible/fine from the local machine..
Here is ssl-conf:
SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:SSL_RSA_WITH_RC4_128_SHA:HIGH:MEDIUM:!MD5:!RC4
SSLProxyCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:HIGH:MEDIUM:!MD5:!RC4
SSLHonorCipherOrder on
SSLProtocol all -SSLv2 -SSLv3
SSLProxyProtocol all -SSLv2 -SSLv3
SSLSessionCache "shmcb:c:/Apache24/logs/ssl_scache(512000)"
SSLSessionCacheTimeout 300
SSLUseStapling On
SSLStaplingCache "shmcb:c:/Apache24/logs/ssl_stapling(150000)"
SSLStaplingStandardCacheTimeout 3600
<VirtualHost *:443>
DocumentRoot "c:/Apache24/htdocs"
ServerName www.xyz.com
ServerAlias xyz.com
ServerAdmin info#xyz.com
ErrorLog "c:/Apache24/logs/error.log"
TransferLog "c:/Apache24/logs/access.log"
SSLEngine on
SSLCertificateFile "C:/Apache24/xyz/certs/server.crt"
SSLCertificateKeyFile "C:/Apache24/xyz/certs/private_key_no_pswd.pem"
SSLCertificateChainFile "C:/Apache24/xyz/certs/gd_bundle-g2-g1.crt"
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory "c:/Apache24/cgi-bin">
SSLOptions +StdEnvVars
</Directory>
CustomLog "c:/Apache24/logs/ssl_request.log" \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
#ProxyRequests Off
ProxyPreserveHost On
SSLProxyEngine on
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
<Proxy *>
#Order allow,deny
Allow from all
Deny from none
Require all granted
#Deny from all
#Allow from 127.0.0.0/255.0.0.0 ::1/128
# Order deny,allow
# Allow from localhost
# Require ip 127.0.0.1
</Proxy>
ProxyPass / ajp://localhost:8009/
</VirtualHost>
You can see many things tried in virtualHost configs (was getting permission denied and other problems), and tried many things till it worked from local machine..
My env is:
Win-XP sp3 (i know its old), ApacheLounge httpd- VC-10 v-2.4.x (on port 443), tomcat-1.6 (on 8080)
Please let me know if i'm doing anything wrong, or you need any other config to see.
Thanks.
This at works in the local network and not outside it sounds very much like a firewall protecting your network. Another possibility is that the same hostname resolves to different IP addresses within your local and the remote network and thus it tries to reach different hosts from local and remote. And yet another thing could be that the hostname resolves to IPv4 and IPv6 addresses but your server uses only IPv4. If you then do only IPv4 in your local network and the other network can do IPv6 you will see similar effects.
To debug this problem I would suggest to do packet captures at your local client, at the remote client and compare them. Also check with packet capturing if the data from the remote client reaches the server at all (or if a firewall blocks it).
Edit: from the comment it looks like that local and remote client see different IP addresses for the same server. To debug why this is the case first check that both sides actually use the same server, because often you see that one uses www.example.com and the other example.com (without www) but there are different IP addresses for the names. If you are sure that this is not the case check what the real IP address should be and then look in more detail at the party which has the wrong name. This wrong name might be caused by an entry in the hosts file (from testing?), by cached entries (changes to the DNS take some time to propagate, sometimes a day or longer) or because a split DNS setup is used. Split DNS is not uncommon in companies where they have servers facing extern and intern and they want the intern cients to use the internal IP address and extern clients to use the external IP address.

Untrusted certificate - Apache & StartSSL

Trying to setup SSL on Apache (on AWS Linux). Firefox gives me these details in it's nastygram:
The certificate is not trusted because it is self-signed.
The certificate is only valid for ip-###-##-#-##
I'm currently working under the assumption that this is a problem with the ChainFile or CA cert - quite possibly because I dont have the correct info in httpd.conf. Can you comment on the code below or let me know where else to look for the error?
httpd.conf:
<VirtualHost *:443>
DocumentRoot /var/www/html
ServerName https://###-##-#-##
SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM
SSLCertificateFile /home/ec2-user/StartSSLcert.pem
SSLCertificateKeyFile /home/ec2-user/StartSSLkey.pem
SSLCertificateChainFile /home/ec2-user/sub.class1.server.sha1.ca.pem
SSLCACertificateFile /home/ec2-user/ca.pem
</VirtualHost>
This page has been my primary reference: http://www.startssl.com/?app=21 However, it includes many lines of code not in other examples I've found online with no description of what they do.
I've been guess-and-checking between the example above and a simpler example like: http://www.sslshopper.com/apache-server-ssl-installation-instructions.html
Everything I try is either untrusted by Firefox or I get errors when restarting apache. Ideas?
by default, the ssl settings in:
/etc/httpd/conf.d/ssl.conf
override the corresponding block in:
/etc/httpd/conf/httpd.conf
When using AWS you need to edit ssl.conf
"The certificate is only valid for ip-###-##-#-##"
credit due here:
Cannot setup SSL keys on my apache server in AWS EC2
If your server have more than one IP address, replace the * with IP address inside""
See: http://httpd.apache.org/docs/2.4/mod/core.html#virtualhost
Whats more, make sure you create your private key, CSR correctly.
See:https://library.linode.com/security/ssl-certificates/commercial#sph_create-a-certificate-signing-request

Apache SSL Configuration Error (SSL Connection Error)

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