Sorry for cross posting, but I wasnt sure whether to post here, or on serverfault.
Safari tells me that it couldnt open the page, because it couldnt establish a secure connection to the server. However, other browsers (opera, firefox) can open the page. Also, theres nothing in the apache error log.
The certificate is selfsigned, and uses standart values. (seen here: http://www.knaupes.net/tutorial-ssl-zertifikat-selbst-erstellen-und-signieren/ )
ssl config:
SSLEngine on
#SSLInsecureRenegotiation on
SSLCertificateFile /home/gemeinde/certs/selfsigned/gemeinde.crt
SSLCertificateKeyFile /home/gemeinde/certs/selfsigned/gemeinde.key
#SSLCACertificateFile /home/gemeinde/certs/Platinum_G2.pem
#SSLOptions +StdEnvVars
<Location "/">
SSLOptions +StdEnvVars +OptRenegotiate
SSLVerifyClient optional
SSLVerifyDepth 10
</Location>
Try SSLInsecureRenegotiation on
I got the same issue , it got resolved when I unchecked the Web Proxy and Secure Web Proxy from System Preferences
Related
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.
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.
*
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.
Warning: please only use the recommendations for Apache configuration from the answers below. For which cipher(s) to use - security norms change over time and some of the security advice below is already out of date.
In the wake of recent events, I have been reconsidering my Apache setup. Currently, my apache site config looks something like this:
<IfModule mod_ssl.c>
<VirtualHost *:80>
ServerName example.com
ServerAlias www.example.com
Redirect permanent / https://example.com
</VirtualHost>
<VirtualHost *:443>
ServerAdmin webmaster#localhost
ServerName example.com
DocumentRoot /var/www-wordpress
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www-wordpress>
Options Indexes FollowSymLinks MultiViews
AllowOverride FileInfo
Order allow,deny
allow from all
</Directory>
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin">
AllowOverride None
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all
</Directory>
ErrorLog ${APACHE_LOG_DIR}/error.log
LogLevel warn
CustomLog ${APACHE_LOG_DIR}/ssl_access.log combined
SSLCertificateFile /etc/ssl/certs/example.com.crt
SSLCertificateKeyFile /etc/ssl/private/example.com.key
SSLCertificateChainFile /etc/ssl/certs/sub.class1.server.ca.pem
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
BrowserMatch "MSIE [2-6]" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
</VirtualHost>
What do I have to do to support perfect forward secrecy? How can I enable SSL perfect forward secrecy by default? How could I enforce it?
How about:
SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder On
SSLCipherSuite EECDH+AES:EDH+AES:-SHA1:EECDH+RC4:EDH+RC4:RC4-SHA:EECDH+AES256:EDH+AES256:AES256-SHA:!aNULL:!eNULL:!EXP:!LOW:!MD5
Note the addition of the -SSLv3 flag to disable SSLv3. This is added to protect against the POODLE attack.
This will prefer perfect forward secrecy, but not at the expense of being vulnerable to the BEAST attack. Since Apache lacks a way to configure cipher preference based on protocol version, I fake it by referring to ciphers only available in the newer protocols. Specifically, AES was only available with SHA1 hashing until TLSv1.2. Thus the list starts with the TLSv1.2 ephemeral Diffie-Hellman ciphers, then RC4 (first with ephemeral DH, then without), and finally a BEAST-vulnerable AES option. Excluding no auth / weak encryption / weak hashing at the end is just for good hygiene and could be omitted since no such ciphers were introduced. If performance is a concern, use EECDH only and omit EDH.
In combination with Apache 2.2 (thus no EECDH as #Bruno says), per https://www.ssllabs.com/ssltest/analyze.html, this achieves PFS for iOS Safari only. IE and Firefox are TLSv1.0 so they get RC4 to avoid BEAST. (Alas, there is no such thing as EDH RC4, so without EECDH, you give up PFS). This is, I believe, the best one could hope for with those browsers on Apache 2.2. Chrome is the only one poorly served, since it supports TLSv1.1 and could use EDH AES without being vulnerable to BEAST. Instead, it gets RC4-RSA like Firefox and IE. Upgrading Apache to enable EECDH RC4 should get PFS for Firefox, IE, and Chrome.
Update 2013-11-09:
I've found a few alternate recommendations around the web. They put less emphasis on BEAST protection (perhaps wise; BEAST is mostly mitigated client-side now) and more emphasis on perfect forward secrecy. To varying degrees they also have stronger preferences for GCM and greater reluctance to accept RC4.
Of particular note are, I think, the following recommendations:
Mozilla OpSec
Ivan Ristic (of Qualys)
Geoffroy Gramaize
Personally, I'm going to go with Mozilla OpSec's. Their reasoning is well explained on their page. Of note, they prefer AES128 over AES256. In their words: "[AES128] provides good security, is really fast, and seems to be more resistant to timing attacks."
Noteworthy in Ivan Ristic's and Geoffroy Gramaize's recommendation is that SSLv3 is disabled. I think this mostly just breaks IE6, though some security related differences between SSLv3 and TLS v1.0 are mentioned on Wikipedia.
Also before I didn't talk about CRIME and BREACH. To protect against CRIME, disable SSL compression. This is included in the examples linked. To protected against BREACH, you need to disable compression at the HTTP level. For Apache 2.4, just do this once globally:
<Location />
SetEnvIfExpr "%{HTTPS} == 'on'" no-gzip
</Location>
For older versions of Apache, place this in each VirtualHost where SSLEngine is on:
<Location />
SetEnv no-gzip
</Location>
Update 2014-10-14:
The Mozilla OpSec guide is now split into recommendations for old/intermediate/modern compatibility. With the settings from intermediate or modern, you end up with SSLv3 disabled. That will protect against the POODLE attack.
From my own understanding, you need to activate SSLHonorCipherOrder and to prepend SSLCipherSuite with ECDHE and DHE ciphers from openssl ciphers -v
From my /etc/apache2/mods-available/ssl.conf:
SSLHonorCipherOrder on
SSLCipherSuite ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:AES128-SHA:RC4-SHA:HIGH:!aNULL:!MD5:!ADH
To test your website, you can use: https://www.ssllabs.com/ssltest
Note: Eliptic Curve DHE only seems to work with Apache 2.3.3 or higher (see source and Bruno's comment).
The cipher suites that provide Perfect Forward Secrecy are those that use an ephemeral form of the Diffie-Hellman key exchange. Their disadvantage is their overhead, which can be improved by using the elliptic curve variants (see Vincent Bernat's blog.)
The cipher suites in Apache Httpd (provided you're using mod_ssl compiled with OpenSSL) are configured using SSLCipherSuite, which takes a list as you would see when using the openssl ciphers command. If you look at the OpenSSL man page, you'll find kEDH is what you're looking for. (You can also list cipher suites individually.)
Enter this cipher code in your httpd.conf in the main/core conf directive:
SSLCipherSuite AES128+EECDH:AES128+EDH
SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder On
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
Header always set X-Frame-Options DENY
Header always set X-Content-Type-Options nosniff
# Requires Apache >= 2.4
SSLCompression off
SSLUseStapling on
SSLStaplingCache "shmcb:logs/stapling-cache(150000)"
You can even check the status of how secure it is by testing it at: https://www.ssllabs.com/ssltest/analyze.html?
Try this code in your ssl.conf:
SSLProtocol +TLSv1.2 +TLSv1.1 +TLSv1
SSLCompression off
SSLHonorCipherOrder on
SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:RC4-SHA:AES256-GCM-SHA384:AES256-SHA256:CAMELLIA256-SHA:ECDHE-RSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:CAMELLIA128-SHA
By the way,
Expert tip: The (1/n-1) split record trick is implemented in Firefox since a while. Thus, you can safely disable RC4 on Firefox in the advanced configuration menu. To do so, enter ‘about:config’ in your address bar, then search for ‘rc4′ and toggle all the found values to ‘false’. If you experience connections issues, toggle back those parameters to true.
https://cc.dcsec.uni-hannover.de/
This websites gives you information on the SSL cipher suites your browser supports for securing HTTPS connections.
Have a look at https://cipherli.st
There you find copy & paste config snippets for several services, that should ensure strong ssl security settings.
This article will help you configure forward security and get you up to date on current standards - https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy
As of 09/16/2015, this will get you an A on SSLLabs test results.
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:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4
I got a grade A (Sept. 2016) on SSLLabs still supporting Windows XP / Internet Explorer 8 using this ssl.conf configuration on Apache:
SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite EECDH+AESGCM:AES256+EECDH:DES-CBC3-SHA
In brief: only TLS is allowed: all versions are supported for compatibility and DES-CBC3-SHA cipher is allowed for compatibility too. The first, preferred two ciphers are using Elliptic curve Diffie-Hellman, the last was added as a fallback because this a good option among the ciphers available XP/IE. If you've installed the last OpenSSL version available this mix is enough to get an A at the time I'm writing.
Hope this is helpful.
I have apache2 httpd version 2.2.9 listening on port 443 with SSLEngine on. All URLs have SSLVerifyClient require and this works fine.
I want to make an exception for a specific URL (/ca.crt) so that my clients can download the certificate of the CA that the certificates we issue them are signed with. I try the following:
SSLVerifyClient require
Alias /ca.crt /my/ssl/certs/ca.crt
<Location /ca.crt>
SSLVerifyClient none
</Location>
My problem is that Apache only seems to want to increase the strength of the SSL client certificate requirement. If I flip the two requirements around, it works as specified. As it is configured above, Apache effectively ignores the SSLVerifyClient none directive.
What's going on? Is this a bug?
Ok, it turns out that the answer to this question is in the documentation (as it usually is!)
In per-server context [the SSLVerifyClient directive] applies to
the client authentication process used
in the standard SSL handshake when a
connection is established.
See Apache Docs - SSLVerifyClient
Basically the first SSLVerifyClient directive was in the per-server context. I made an explicit <Directory> declaration for the root directory and put the SSLClientVerify require directive in there. This did the trick.