I've read
How to configure playframework server to support ssl
and I also tried to follow http://www.playframework.org/documentation/1.1.1/releasenotes-1.1#https but it doesn't work for me
many thanks~
I read the doc for Play1 because I can't find any more updated information for Play2 about https.
in application.conf, I added these lines:
https.port=9443
certificate.key.file=conf/host.key
certificate.file=conf/host.cert
I type run in the play console, and try to access the server at https://localhost:9443 the browser timed out without anything logged in the console output
It won't work with the approach you are taking. You are mistaking release notes of 1.x branch with 2.x branch.
in 1.x branch, it is possible. Release notes are sufficient, and they worked for me.
For 2.1+ branch, please refer to #Christina's comment. Support has been added in 2.1 and the discussion thread provides details.
Quoting James Roper's response
In dev mode, it's very easy, just:
JAVA_OPTS=-Dhttps.port=9443 play run
Play will generate a private key and self signed certificate, which
obviously your browser will balk at with a big red warning. It will
reuse that generated self signed certificate for each subsequent run
of Play, so you should only get the browser error once. Obviously
this self signed certificate is probably not what you want in
production. Also important to note is that the self signed
certificate generation will only work on JVMs that use the sun
security libraries (eg Oracle and OpenJDK, but most notably not IBM
J9). On JVMs that don't use these, you will get a
NoClassDefFoundError when it tries to generate the certificate.
In prod (and this config also applies to dev) you configure it much
the same way that you configure SSL ordinarily in Java, via system
properties. Here's a summary:
https.port - The port that should be used
https.keyStore - The path to
the keystore containing the private key and certificate, if not
provided generates a keystore for you
https.keyStoreType - The key
store type, defaults to "JKS"
https.keyStorePassword - The password,
defaults to ""
https.keyStoreAlgorithm - The key store algorithm,
defaults to the platforms default algorithm
https.trustStore - This
feature hasn't been fully implemented, currently it will always use
the JDKs trust store for verifying client side certificates (which you
can of course configure yourself) whether you supply a value for this
or not, unless you specify "noCA", in which case, it will use a trust
store that trusts all certificates with no validation or verification,
which is useful for if using webid client side certificate verification.
For 2.0 branch, you have to put another server infront of play i.e either apache/nginx/other which listens on https and forwards the request to play in http.
Instructions to setup a frontend server are available at http://www.playframework.org/documentation/2.0.1/HTTPServer
So run your play server on a port. Have apache forward request from domain.com to 127.0.0.1:9443.
Sample apache config
<VirtualHost *:443>
ServerAdmin webmaster#localhost
ServerName example.com
ServerAlias *.example.com
ErrorLog ${APACHE_LOG_DIR}/error.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog ${APACHE_LOG_DIR}/ssl_access.log combined
ProxyPreserveHost On
# ProxyPass /excluded !
ProxyPass / http://127.0.0.1:9000/
ProxyPassReverse / http://127.0.0.1:9000/
# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on
# A self-signed (snakeoil) certificate can be created by installing
# the ssl-cert package. See
# /usr/share/doc/apache2.2-common/README.Debian.gz for more info.
# If both key and certificate are stored in the same file, only the
# SSLCertificateFile directive is needed.
SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
# Certificate Authority (CA):
# Set the CA certificate verification path where to find CA
# certificates for client authentication or alternatively one
<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
# MSIE 7 and newer should be able to use keepalive
BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
</VirtualHost>
Hope it helps.
The documentation for setting up the current version of Play (2.2.x) is here:
http://www.playframework.com/documentation/2.2.x/ConfiguringHttps
Right now you seem to need a reverse proxy managing the SSL for you. I found a ticket and a thread discussing this.
This is useful for locally testing https:
activator "run -Dhttps.port=9005"
Then point your browser to https://localhost:9005.
One thing we did was to use AWS ELB to handle our SSL, then setup the SSL forwarding (HTTP -> HTTPS) using a plays filters. The main benefit, takes the SSL load off your server and you don't have to run Apache or Nginx in front of play (as some solution point out).
You can see my answer here:
https://stackoverflow.com/a/23646948/690164
I also write a bit more about it in my blog:
http://www.mentful.com/2014/05/25/play-framework-filter-for-aws-elastic-load-balancer-forward-http-to-https/
I'm using securesocial 3.0.3M. Set
securesocial.ssl = true
in securesocial.conf and you should be good to go.
Then restart your sbt or activator with
JAVA_OPTS=-Dhttps.port=9443 activator run
Go to localhost:9443
enjoy
Related
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.
I am having an issue restarting my apache server after enabaling the SSL virtual host.
<IfModule mod_ssl.c>
<VirtualHost _default_:443>
ServerAdmin webmaster#localhost
DocumentRoot /var/www/
#the line above has been added by David Hatton 28/05/2015.
# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the loglevel for particular
# modules, e.g.
#LogLevel info ssl:warn
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
# For most configuration files from conf-available/, which are
# enabled or disabled at a global level, it is possible to
# include a line for only one particular virtual host. For example the
# following line enables the CGI configuration for this host only
# after it has been globally disabled with "a2disconf".
#Include conf-available/serve-cgi-bin.conf
# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on
# A self-signed (snakeoil) certificate can be created by installing
# the ssl-cert package. See
# /usr/share/doc/apache2/README.Debian.gz for more info.
# If both key and certificate are stored in the same file, only the
# SSLCertificateFile directive is needed.
SSLCertificateFile /etc/apache2/ssl/www.XXXXX.com.crt
SSLCertificateKeyFile /etc/apache2/ssl/www.XXXXX.com.p7b
SSLCertificateChainFile /etc/apache2/ssl/www.XXXXX.com.ca-bundle
# Server Certificate Chain:
# Point SSLCertificateChainFile at a file containing the
# concatenation of PEM encoded CA certificates which form the
# certificate chain for the server certificate. Alternatively
# the referenced file can be the same as SSLCertificateFile
# when the CA certificates are directly appended to the server
# certificate for convinience.
#SSLCertificateChainFile /etc/apache2/ssl/www.XXXXX.com.ca-bundle
# Certificate Authority (CA):
# Set the CA certificate verification path where to find CA
# certificates for client authentication or alternatively one
# huge file containing all of them (file must be PEM encoded)
# Note: Inside SSLCACertificatePath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCACertificatePath /etc/ssl/certs/
#SSLCACertificateFile /etc/apache2/ssl.crt/ca-bundle.crt
# Certificate Revocation Lists (CRL):
# Set the CA revocation path where to find CA CRLs for client
# authentication or alternatively one huge file containing all
# of them (file must be PEM encoded)
# Note: Inside SSLCARevocationPath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCARevocationPath /etc/apache2/ssl.crl/
#SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl
# Client Authentication (Type):
# Client certificate verification type and depth. Types are
# none, optional, require and optional_no_ca. Depth is a
# number which specifies how deeply to verify the certificate
# issuer chain before deciding the certificate is not valid.
#SSLVerifyClient require
#SSLVerifyDepth 10
# SSL Engine Options:
# Set various options for the SSL engine.
# o FakeBasicAuth:
# Translate the client X.509 into a Basic Authorisation. This means that
# the standard Auth/DBMAuth methods can be used for access control. The
# user name is the `one line' version of the client's X.509 certificate.
# Note that no password is obtained from the user. Every entry in the user
# file needs this password: `xxj31ZMTZzkVA'.
# o ExportCertData:
# This exports two additional environment variables: SSL_CLIENT_CERT and
# SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
# server (always existing) and the client (only existing when client
# authentication is used). This can be used to import the certificates
# into CGI scripts.
# o StdEnvVars:
# This exports the standard SSL/TLS related `SSL_*' environment variables.
# Per default this exportation is switched off for performance reasons,
# because the extraction step is an expensive operation and is usually
# useless for serving static content. So one usually enables the
# exportation for CGI and SSI requests only.
# o OptRenegotiate:
# This enables optimized SSL connection renegotiation handling when SSL
# directives are used in per-directory context.
#SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
# SSL Protocol Adjustments:
# The safe and default but still SSL/TLS standard compliant shutdown
# approach is that mod_ssl sends the close notify alert but doesn't wait for
# the close notify alert from client. When you need a different shutdown
# approach you can use one of the following variables:
# o ssl-unclean-shutdown:
# This forces an unclean shutdown when the connection is closed, i.e. no
# SSL close notify alert is send or allowed to received. This violates
# the SSL/TLS standard but is needed for some brain-dead browsers. Use
# this when you receive I/O errors because of the standard approach where
# mod_ssl sends the close notify alert.
# o ssl-accurate-shutdown:
# This forces an accurate shutdown when the connection is closed, i.e. a
# SSL close notify alert is send and mod_ssl waits for the close notify
# alert of the client. This is 100% SSL/TLS standard compliant, but in
# practice often causes hanging connections with brain-dead browsers. Use
# this only for browsers where you know that their SSL implementation
# works correctly.
# Notice: Most problems of broken clients are also related to the HTTP
# keep-alive facility, so you usually additionally want to disable
# keep-alive for those clients, too. Use variable "nokeepalive" for this.
# Similarly, one has to force some clients to use HTTP/1.0 to workaround
# their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
# "force-response-1.0" for this.
BrowserMatch "MSIE [2-6]" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
# MSIE 7 and newer should be able to use keepalive
BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
</VirtualHost>
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
I get an Action 'Start' failed message. (The error.log just repeats the command line message essentially!)
The server starts fine when SSL(443) is not enabled and I can access the site. Strangely, however when SSL is NOT enabled, I can still access the site at :443 but over http not https.
It would appear that something is already using port 443 which is probably why I can't start the SSL virtual host. I'm not knowledgeable enough to know how to figure out what is using that port and how to kill it. Any ideas?
Have you enable enable the SSL module in Apache2 ?
a2enmod ssl
then restart Apache:
/etc/init.d/apache2 restart
I am actually trying to see if Puppet can use external certificates because my organization's info security department has came out with a stronger security certificate that I've asked them for a set to see if it works or not. I still intend to have the puppetmaster issue certs, but the two certs to other agents by behaving the same thing as the normal way of the master issuing certs and autosign them.
The set comprises something like the following:
ABCROOTCA2015.pem – ABC Root CA 2015 certificate
ABCSERVERCA2015.pem – ABC Server CA 2015 certificate
puppet2-64.abc.local.p12 (server)
- private key and certificate of glpi-49.abc.local
- password: ###
glpi-49.abc.local.p12 (agent)
- private key and certificate of 10.5.137.175
- password: ###
Since external certs require Apache Passenger to work on this, I've installed the Apache passenger. These two certs above have been placed into their respective folders (/var/lib/puppet/ssl/certs and with another copy the server cert placed at the /private_keys folder.
Given of the two certificate files above, this is my configuration file, Apache end, stored at "/etc/apache2/sites-enabled/puppetmaster" (this is for Ubuntu)
<VirtualHost *:8140>
SSLEngine on
SSLProtocol -ALL +SSLv3 +TLSv1
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP
SSLCertificateFile /var/lib/puppet/ssl/certs/mimosserverca2015.pem
SSLCertificateKeyFile /var/lib/puppet/ssl/private_keys/mimosserverca2015.pem
#SSLCertificateChainFile /var/lib/puppet/ssl/certs/mimosrootca2015.pem
SSLCACertificateFile /var/lib/puppet/ssl/certs/mimosrootca2015.pem
# If Apache complains about invalid signatures on the CRL, you can try disabling
# CRL checking by commenting the next line, but this is not recommended.
SSLCARevocationFile /var/lib/puppet/ssl/ca/ca_crl.pem
SSLVerifyClient optional
SSLVerifyDepth 1
# The `ExportCertData` option is needed for agent certificate expiration warnings
SSLOptions +StdEnvVars +ExportCertData
# This header needs to be set if using a loadbalancer or proxy
RequestHeader unset X-Forwarded-For
RequestHeader set X-SSL-Subject %{SSL_CLIENT_S_DN}e
RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN}e
RequestHeader set X-Client-Verify %{SSL_CLIENT_VERIFY}e
DocumentRoot /usr/share/puppet/rack/puppetmasterd/public
#RackBaseURI /
<Directory /usr/share/puppet/rack/puppetmasterd>
Options None
AllowOverride None
# Apply the right behavior depending on Apache version.
Order allow,deny
Allow from all
</Directory>
#Misc
LoadModule passenger_module /var/lib/gems/1.8/gems/passenger-4.0.53/xxx.so
PassengerRoot /var/lib/gems/1.8/gems/passenger-4.0.53
PassengerRuby /usr/bin/ruby1.8
ErrorLog /var/log/apache2/puppetmaster_ssl_error.log
CustomLog /var/log/apache2/puppetmaster_ssl_access.log combined
</VirtualHost>
For the puppet.conf at the puppetmaster. I only added the following additional lines:
[main]
ca_server = puppet2-64.mimos.local
[master]
ca = false
certname = mimosserverca2015
For one of the agents that is to be tested for this, I've added a ca_server thing in the agent's puppet configuration file. The webrick puppetmaster service has been turned off as the apache2 service has been turned on.
When the agent is executed, Error 400 is shown with the sub-message Master is not a CA.
If I've already defined the host and local root cert inside the puppetmaster file in apache2 folder, shouldn't I be getting the same function as it was usually?
Or is because that the puppetmaster will not take the custom certificate file as its own such that we have to rename that file?
So far I've checked around, but there's not much of material to be checked upon, unless there's steps that might not match my CA setup.
Can anyone help enlighten on this issue? Thanks alot!
M
The error Master is not a CA is caused by the certificate authority function on your Puppet master being disabled, which you're explicitly doing by specifying ca = false in puppet.conf under [master].
Using an external CA is well-covered in the SSL Configuration: External CA Support document. However it includes the following caveat, which is incompatible with your requirement that, "I still intend to have the puppetmaster issue certs, but the two certs to other agents by behaving the same thing as the normal way of the master issuing certs and autosign them."
These configurations are all-or-nothing rather than mix-and-match.
When using an external CA, the built in Puppet CA service must be
disabled and cannot be used to issue SSL certificates.
Additionally, Puppet cannot automatically distribute certificates in
these configurations — you must have your own complete system for
issuing and distributing certificates.
Simply put, when using an external CA with Puppet, you're responsible for signing and distributing the certificates.
(While you could try removing ca = false, it's quite possible that you'll run into problems as it's an unsupported configuration.)
If you put a signed agent cert on your agent system, either replacing the default paths or additionally specifying the host* configuration options, then the agent shouldn't attempt to use the (disabled) CA functions of the Puppet master.
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.