ERROR: site default-ssl not properly enabled - shell

I got this error when execute this:
amontoya#ubuntu:~/pruebas$ sudo a2ensite default-ssl
ERROR: Site default-ssl not properly enabled: /etc/apache2/sites-enabled/default-ssl.conf is a real file, not touching it
and this is my default-ssl.conf file:
<IfModule mod_ssl.c>
<VirtualHost _default_:443>
ServerAdmin webmaster#localhost
DocumentRoot /var/www/html
# 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/ssl/certs/apache.crt
SSLCertificateKeyFile /etc/ssl/certs/apache.key
# 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.crt/server-ca.crt
# 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
</VirtualHost>
</IfModule>
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
What do I do?

You must place your "default-ssl.conf" file inside:
/etc/apache2/sites-available
And after, "a2ensite" comand will create a symlink for you inside:
/etc/apache2/sites-enabled

Related

Configure OHS Weblogic 12c / Apache to support TLSv2 only

And thanks for your help and I would like to know if someone has faced this issue, I don't success to configure my SSL configuration for OHS, it seems that TLSV1.2 only doesn't work .
My OHS is embedeed with a weblogic 12C
See below my configuration
###################################################################
# Oracle HTTP Server mod_ossl configuration file: ssl.conf #
###################################################################
# The Listen directive below has a comment preceding it that is used
# by tooling which updates the configuration. Do not delete the comment.
#[Listen] OHS_SSL_PORT
Listen 8443
<IfModule ossl_module>
##
## SSL Global Context
##
## All SSL configuration in this context applies both to
## the main server and all SSL-enabled virtual hosts.
##
#
# Some MIME-types for downloading Certificates and CRLs
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl .crl
# Inter-Process Session Cache:
# Configure the SSL Session Cache: First the mechanism
# to use, second the expiring timeout (in seconds) and third
# the mutex to be used.
SSLSessionCache "shmcb:${ORACLE_INSTANCE}/servers/${COMPONENT_NAME}/logs/ssl_scache(512000)"
SSLSessionCacheTimeout 300
<IfModule !mpm_winnt_module>
Mutex pthread ssl-cache
</IfModule>
##
## SSL Virtual Host Context
##
#[VirtualHost] OHS_SSL_VH
<VirtualHost *:8443>
<IfModule ossl_module>
# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on
# Client Authentication (Type):
# Client certificate verification type and depth. Types are
# none, optional and require.
SSLVerifyClient None
# SSL Protocol Support:
# Configure usable SSL/TLS protocol versions.
SSLProtocol +TLSv1.2 nzos_Version_3_0_With_2_0_Hello nzos_Version_3_0
# SSL Cipher Suite:
# List the ciphers that the client is permitted to negotiate.
# SSL Certificate Revocation List Check
# Valid values are On and Off
SSLCipherSuite ALL
SSLCRLCheck Off
#Path to the wallet
SSLWallet "/data/as/Certificates/OHS"
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/cgi-bin">
SSLOptions +StdEnvVars
</Directory>
BrowserMatch "MSIE [2-5]" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
</IfModule>
</VirtualHost>
See below the errors when I tried to connect with the URL ?
2021-02-04T19:12:18.2523+01:00] [OHS] [ERROR:32] [OH99999] [ossl] [client_id: 172.21.0.68] [host_id: lpacs122] [host_addr: 172.21.20.79] [pid: 29658] [user: as] [VirtualHost: localhost:8443] OHS:2079 Client SSL handshake error, nzos_Handshake returned 29039(server localhost:8443)
[2021-02-04T19:12:18.2523+01:00] [OHS] [ERROR:32] [OH99999] [ossl] [host_id: lpacs122] [host_addr: 172.21.20.79] [pid: 29658] [user: as] [VirtualHost: localhost:8443] OHS:2171 NZ Library Error: SSL negotiation error [Hint: too restrictive SSLCipherSuite]
Does someone has faced this issue ?
Many Thanks for yor help

How can I enable SSLv3 on IBM HTTP Server?

Some of our customers visit the website by using SSL3.0,but fail.
The log in ihs is as follows:
"SSL0222W: SSL Handshake Failed, No ciphers specified (no shared ciphers or no shared protocols)"
how can I solve this problem?
I have modified the configuration in the "httpd.conf" file to enable SSLv3.However, it does not achieve the desired results in implementation.
The same problem still exists.
Now, the "httpd.conf" file as shown below,
Listen 443
<VirtualHost *:443>
ServerName *:443
SSLEnable<br/>
SSLProtocolEnable SSLv3 TLSv1 TLSv11 TLSv12
SSLProtocolDisable SSLv2
SSLClientAuth none
Keyfile "..."
SSLStashfile "..."
</VirtualHost>
You need to enable some ciphers for SSLv3 explicitly.
<VirtualHost *:443>
SSLEnable
SSLCipherSpec SSLv3 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA
SSLProtocolEnable SSLv3
</VirtualHost>
You can see the differences in the output of apachectl -t -DDUMP_SSL_CONFIG before and after.
Obligatory mention: SSLv3 is horrifically out of date and shouldn't be used.

Custom Xcode 9 Server Certificate

Xcode Server that comes with Xcode 9 now automatically generates SSL certificates for communication between server and clients. It also uses this certificate when communicating with the Xcode Server REST API. Is there a way to specify or replace the autogenerated keys and use a certificate from a trusted third party (like LetsEncrypt)?
The apache configuration file located at
/Library/Developer/XcodeServer/Configuration/httpd_os_xcs.conf
contains this information:
Listen 443
<VirtualHost *:443>
# Xcode Server uses its own self-signed certificates
# only if no other SSL configurations for Apache have been found
<IfModule !ssl_module>
LoadModule ssl_module libexec/apache2/mod_ssl.so
SSLEngine on
SSLCertificateFile /Library/Developer/XcodeServer/Certificates/apache.crt
SSLCertificateKeyFile /Library/Developer/XcodeServer/Certificates/apache.key
</IfModule>
[...]
<IfModule mod_proxy.c>
SSLProxyEngine On
SSLProxyCheckPeerCN Off
ProxyPass /xcode/internal/api https://127.0.0.1:20343/api retry=0 timeout=30
ProxyPassReverse /xcode/internal/api https://127.0.0.1:20343/api
ProxyPass /xcode/internal/socket.io https://127.0.0.1:20343/socket.io retry=0 timeout=30
ProxyPassReverse /xcode/internal/socket.io https://127.0.0.1:20343/socket.io
</IfModule>
[...]
</VirtualHost>
I believe the certificate is also part of the apache.keychain file found at
/Library/Developer/XcodeServer/Keychains/apache.keychain
but I haven't been able to verify that.
Every time the Xcode Server service is started in Xcode, the apache.{crt/key} files as well as the httpd_os_xcs.conf files are overwritten, so simple replacing/modifying these files does not appear to be an option.
The only way forward I can see is to implement some other SSL configuration as suggested in the http_os_xcs.conf file, but I can't seem to get that to work either.
Any suggestions or solutions are greatly appreciated.
This is what worked for me on macOS Mojave (10.14).
Installing the certificate via the Server app
Install the "Server" app from the App Store (version 5.8)
Generate a server certificate request from the Server app for your domain
Send the request file to certificate provider to obtain a certificate
From the Server app import the certificate and set it in the dropdown "Secure services using"
These steps could be done in some other way, but initially I wanted to use a "blessed" macOS way, and then the problems started :)
I wanted to use this certificate directly by the system Apache (which is what serves the https://example.com/xcode page), but the documentation is lacking, the only thing I've found is this migration guide
where they speak about mod_secure_transport, which should be used instead of mod_ssl.
This guide assumes that it is already configured, but mod_secure_transport is not present in the default Mojave Apache configs (those reside in /etc/apache2).
So let's do it manually the old-school way:
Preparing the Apache certificate files manually
Copy your certificate file to /etc/apache2/server.crt
Find your certificate in Keychain app, and export your certificate private key in p12 format from there.
Convert your private key to the format expected by Apache:
openssl pkcs12 -in exported_private_key.p12 -nodes -out server.key -nocerts
Copy server.key to /etc/apache2/server.key
Configuring Apache manually
In /etc/apache2/httpd.conf :
Uncomment these lines:
LoadModule ssl_module libexec/apache2/mod_ssl.so
...
LoadModule socache_shmcb_module libexec/apache2/mod_socache_shmcb.so
Find "IfModule ssl_module" section and add:
SSLCertificateFile "/private/etc/apache2/server.crt"
SSLCertificateKeyFile "/private/etc/apache2/server.key"
Test the config:
sudo apachectl configtest
Restart:
sudo apachectl restart
If all is good, it is ready, and you can observe the result at https://example.com/xcode

How to point HostGator domain to EC2 AWS

We have an existing domain name
(ex. webdev.com)
located in hostgator and we have a server in AWS. We wanted to use the domain name that we bought from hostgator
(webdev.com)
in our AWS server.
What we did was, in hostgator we created a DNS (project1.webdev.com) and the address is pointing to our AWS server(ex 150.12.1.0). In our AWS, we deploy the project1 under port 4000.
Now if we access the
project1.webdev.com
we end up to the default apache page. How could we route it to our port 4000 so that everytime we access project1.webdev.com it pointed to our
150.12.1.0:4000
project.
here is our virtual host config:
<VirtualHost *:4000>
ServerName project1.webdev.com
ServerAdmin webmaster#dummy-host.example.com
DocumentRoot "/var/www/html/project1/web"
<Directory "/var/www/html/project1/web">
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
Allow from all
</Directory>
ErrorLog ${APACHE_LOG_DIR}/4000-error_log
CustomLog ${APACHE_LOG_DIR}/4000-access_log common
We have looked for several information but we did not find any possible solution. Looking forward for your help.
Thanks
You're confusing DNS, which has to do with IP addressing, with ports, which have nothing to do with DNS. DNS only deals with converting between human-readable names and IP addresses. DNS does not provide any sort of provision to perform a task like "when a user wants to make an HTTP request use port 4000 instead of port 80".
If your service is listening on port 4000 but you're using the HTTP protocol (which always uses port 80 by default) then you will need to deal with this in one of the following ways:
Require all URL's to explicitly specify port 4000, for example: http://project1.webdev.com:4000
Change your VirtualHost definition to listen on port 80 instead of 4000
Add a new VirtualHost definition in Apache for port 80 that proxies all requests to port 4000
Sharing you the solution we made. Thanks to #Bruce for helping us out. As what he suggested in the comments above, we will create a virtual host porting to 80(which is the default of apache). Then we will route the port 80 to our specific project.
<VirtualHost *:80>
# The ServerName directive sets the request scheme, hostname and port that
# the server uses to identify itself. This is used when creating
# redirection URLs. In the context of virtual hosts, the ServerName
# specifies what hostname must appear in the request's Host: header to
# match this virtual host. For the default virtual host (this file) this
# value is not decisive as it is used as a last resort host regardless.
# However, you must set it for any further virtual host explicitly.
#ServerName www.example.com
ServerName project1.webdev.com
ServerAdmin webmaster#localhost
DocumentRoot "/var/www/html/project1/web"
# 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}/project1-error.log
CustomLog ${APACHE_LOG_DIR}/project1-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
</VirtualHost>
If you have multiple DNS just create another instance of port 80 and route to the project.
Make sure that the Domain name in HostGator matches with the ServerName you created in the virtual host.

Setting up SSL in domain mode mod_cluster JBOSS AS7

I am trying to setup SSL in Jboss domain mode cluster following instructions at domain mode cluster.
Now I need to run these cluster nodes in SSL. I have added following configuration in domain.xml that allows me to run each cluster in domain mode on SSL. If I have two nodes running with offset of 100 and 200 then I can access application separately at 8543 and 8643 on https as default port for jboss SSL is 8443.
<subsystem xmlns="urn:jboss:domain:web:1.0" default-virtual-server="default-host">
<connector name="http" protocol="HTTP/1.1" socket-binding="http" scheme="http" redirect-port="443"/>
<connector name="https" protocol="HTTP/1.1" socket-binding="https" scheme="https" enable-lookups="false" secure="true">
<ssl name="ssl" password="mypassword" certificate-key-file="<path to truststore file>/jbossHttps.keystore" protocol="TLSv1" verify-client="true"/>
</connector>
There are few suggestions related to adding system properties and I have done that too.
<system-properties>
<property name="javax.net.ssl.trustStore" value="<path to truststore file>"/>
</system-properties>
Problem is I am looking to run my application over HTTPS using mod_cluster so as to access application as https://myapplication/
What additional configuration changes I am missing here?
Finally after hours of searching there is no single document/source of information available. Finally following detailed steps helped configure mod_cluster + ssl + jboss7.x
Generate server certificate
Note: If you already have certificate created then this section can be ignored.
Generate Private Key on the Server Running Apache + mod_ssl
First, generate a private key on the Linux server that runs Apache webserver using openssl command as shown below.
[root#s4-app-dev jbossuser]# mkdir /etc/httpd/conf/certs
[root#s4-app-dev jbossuser]# openssl genrsa -des3 -out www.xyz.com.key 1024
Generate a Certificate Signing Request (CSR)
Using the key generate above, you should generate a certificate request file (csr) using openssl as shown below.
[root#s4-app-dev jbossuser]# openssl req -new -key www.xyz.com.key -out www.xyz.com.csr
Generate a Self-Signed SSL Certificate
For testing purpose, you can generate a self-signed SSL certificate that is valid for 1 year using openssl command as shown below.
[root#s4-app-dev jbossuser]# openssl x509 -req -days 365 -in www.xyz.com.csr -signkey www.xyz.com.key -out www.xyz.com.crt
Apache SSL configuration
If you already have mod_cluster configured to listen to port 80 then remove that virtual host entry and make following configuration. Create ssl.conf as following.
[root#s4-app-dev jbossuser]# vi /etc/httpd/conf.d/ssl.conf
This is the Apache server configuration file providing SSL support.
# It contains the configuration directives to instruct the server how to
# serve pages over an https connection. For detailing information about these
# directives see <URL:http://httpd.apache.org/docs/2.2/mod/mod_ssl.html>
#
# Do NOT simply read the instructions in here without understanding
# what they do. They're here only as hints or reminders. If you are unsure
# consult the online docs. You have been warned.
#
LoadModule ssl_module modules/mod_ssl.so
#
# When we also provide SSL we have to listen to the
# the HTTPS port in addition.
#
Listen 1.1.1.1:443
##
## SSL Global Context
##
## All SSL configuration in this context applies both to
## the main server and all SSL-enabled virtual hosts.
##
# Pass Phrase Dialog:
# Configure the pass phrase gathering process.
# The filtering dialog program (`builtin' is a internal
# terminal dialog) has to provide the pass phrase on stdout.
SSLPassPhraseDialog builtin
# Inter-Process Session Cache:
# Configure the SSL Session Cache: First the mechanism
# to use and second the expiring timeout (in seconds).
SSLSessionCache shmcb:/var/cache/mod_ssl/scache(512000)
SSLSessionCacheTimeout 300
# Semaphore:
# Configure the path to the mutual exclusion semaphore the
# SSL engine uses internally for inter-process synchronization.
SSLMutex default
# Pseudo Random Number Generator (PRNG):
# Configure one or more sources to seed the PRNG of the
# SSL library. The seed data should be of good random quality.
# WARNING! On some platforms /dev/random blocks if not enough entropy
# is available. This means you then cannot use the /dev/random device
# because it would lead to very long connection times (as long as
# it requires to make more entropy available). But usually those
# platforms additionally provide a /dev/urandom device which doesn't
# block. So, if available, use this one instead. Read the mod_ssl User
# Manual for more details.
SSLRandomSeed startup file:/dev/urandom 256
SSLRandomSeed connect builtin
#SSLRandomSeed startup file:/dev/random 512
#SSLRandomSeed connect file:/dev/random 512
#SSLRandomSeed connect file:/dev/urandom 512
#
# Use "SSLCryptoDevice" to enable any supported hardware
# accelerators. Use "openssl engine -v" to list supported
# engine names. NOTE: If you enable an accelerator and the
# server does not start, consult the error logs and ensure
# your accelerator is functioning properly.
#
SSLCryptoDevice builtin
#SSLCryptoDevice ubsec
##
## SSL Virtual Host Context
##
<VirtualHost _default_:443>
# General setup for the virtual host, inherited from global configuration
#DocumentRoot "/var/www/html"
#ServerName www.example.com:443
# Use separate log files for the SSL virtual host; note that LogLevel
# is not inherited from httpd.conf.
ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn
# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on
# SSL Protocol support:
# List the enable protocol levels with which clients will be able to
# connect. Disable SSLv2 access by default:
SSLProtocol all -SSLv2
# SSL Cipher Suite:
# List the ciphers that the client is permitted to negotiate.
# See the mod_ssl documentation for a complete list.
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
# Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate. If
# the certificate is encrypted, then you will be prompted for a
# pass phrase. Note that a kill -HUP will prompt again. A new
# certificate can be generated using the genkey(1) command.
SSLCertificateFile /etc/httpd/conf/certs/www.xyz.com.crt
# Server Private Key:
# If the key is not combined with the certificate, use this
# directive to point at the key file. Keep in mind that if
# you've both a RSA and a DSA private key you can configure
# both in parallel (to also allow the use of DSA ciphers, etc.)
SSLCertificateKeyFile /etc/httpd/conf/certs/www.xyz.com.key
# 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/pki/tls/certs/server-chain.crt
# 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)
#SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
# 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
# Access Control:
# With SSLRequire you can do per-directory access control based
# on arbitrary complex boolean expressions containing server
# variable checks and other lookup directives. The syntax is a
# mixture between C and Perl. See the mod_ssl documentation
# for more details.
#<Location />
#SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \
# and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
# and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \
# and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \
# and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \
# or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
#</Location>
# 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 StrictRequire:
# This denies access when "SSLRequireSSL" or "SSLRequire" applied even
# under a "Satisfy any" situation, i.e. when it applies access is denied
# and no other module can change it.
# o OptRenegotiate:
# This enables optimized SSL connection renegotiation handling when SSL
# directives are used in per-directory context.
#SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
<Files ~ "\.(cgi|shtml|phtml|php3?)$">
SSLOptions +StdEnvVars
</Files>
<Directory "/var/www/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.
SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
# Per-Server Logging:
# The home of a custom SSL log file. Use this when you want a
# compact non-error SSL logfile on a virtual host basis.
CustomLog logs/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>
LoadModule slotmem_module modules/mod_slotmem.so
LoadModule manager_module modules/mod_manager.so
LoadModule proxy_cluster_module modules/mod_proxy_cluster.so
LoadModule advertise_module modules/mod_advertise.so
NameVirtualHost 1.1.1.1:443
MemManagerFile /var/cache/httpd
<VirtualHost 1.1.1.1:443>
<Location /mod_cluster_manager>
SetHandler mod_cluster-manager
Order deny,allow
Allow from all
</Location>
KeepAliveTimeout 60
MaxKeepAliveRequests 0
ManagerBalancerName testcluster
AdvertiseFrequency 5
DocumentRoot "/var/www/html"
ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn
SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
SSLCertificateFile /etc/httpd/conf/certs/www.xyz.com.crt
SSLCertificateKeyFile /etc/httpd/conf/certs/www.xyz.com.key
SSLCertificateChainFile /etc/httpd/conf/certs/www.xyz.com.crt
<Files ~ "\.(cgi|shtml|phtml|php3?)$">
SSLOptions +StdEnvVars
</Files>
<Directory "/var/www/cgi-bin">
SSLOptions +StdEnvVars
</Directory>
<Directory "/var/www/html">
AllowOverride None
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
Once these changes have been made you should be able to reach to Apache over SSL [https://1.1.1.1/][1]
Upgrade Jboss for mod_cluster and SSL
The Jboss 7.1.1.Final doesn’t work with mod_cluster and SSL configuration. It basically ignores the certificate configuration to SSL of mod_cluster. We need to upgrade to higher Jboss such as
Download higher source tag from Git https://github.com/jbossas/jboss-as/tree/7.1.3.Final
If you already have Maven 3 installed
$ mvn install
If you don't have Maven 3
$ ./build.sh
Creating self-signed certificates using KeyTool
Generating the key pair into a keystore (JKS), for RSA:
[root#s4-app-dev jbossuser]# keytool -genkey -keyalg RSA -keysize 2048 -keystore xyz_keystore.jks -alias xyz
Import server certificate into keystore
[root#s4-app-dev jbossuser]# keytool -import -alias xyz -file /etc/httpd/conf/certs/www.xyz.com.crt -storetype JKS -keystore /home/jboss-as-7.1.1.final/keystore/xyz_keystore.jks
To list keystore content
[root#s4-app-dev jbossuser]# keytool -list -keystore /home/jboss-as-7.1.1.final/keystore/xyz_keystore.jks
Jboss mod_cluster ssl configuration
In domain.xml add system properties for truststore and password.
<property name="javax.net.ssl.trustStore" value="<path to keystore>/keystore/xyz_keystore.jks"/>
<property name="javax.net.ssl.trustStorePassword" value="xyzmanish"/>
Modify mod_cluster subsystem to now listen to 444 and use keystore that we configured.
<subsystem xmlns="urn:jboss:domain:modcluster:1.1">
<mod-cluster-config advertise-socket="modcluster" connector="ajp" proxy-list="1.1.1.1:443" advertise-security-key="xyzmanish">
<dynamic-load-provider>
<load-metric type="busyness"/>
</dynamic-load-provider>
<!-- SSL/TLS configuration for mod_cluster advertise-security-key -->
<ssl password="xyzmanish" key-alias="xyz" ca-certificate-file="<path to key store>/keystore/xyz_keystore.jks" certificate-key-file="<path to key store>/keystore/xyz_keystore.jks" cipher-suite="ALL" protocol="TLSv1"/>
</mod-cluster-config>
</subsystem>>
Once you make this changes restart the JBOSS server and try to access your application via Apache over SSL.

Resources