Apache as Proxy: how to configure TLS on the downstream side? - apache

We want to use an Apache2 (v2.4.51) as a (reverse) proxy to access a downstream server (running Tomcat). That Tomcat is configured to accept only TLS v1.2 and a very limited set of ciphers (and that's not negotiable).
In the logs I found that our Apache tries to open the connection to that Tomcat using TLS v1.3 which causes the downstream server to immediately terminate the connection and no further communication happens.
How can I configure an Apache server to use a specific TLS version and cipher on an outgoing/ downstream connection? Everything I found re. Apache TLS configuration so far was dealing with the front-side, i.e. what Apache receives and accepts. But in my case I need to adjust the back-end-side, i.e. what Apache uses when it forwards a request.
How/where can one configure that?
Edit: Meanwhile I realized that the terms "upstream" & "downstream" are not always used consistently - so just in case: with "downstream" here I mean the connection (2) as sketched below:
{browsers/internet} --(1)--> [Apache reverse proxy] --(2)--> [Tomcat application server].
Edit 2: In Tomcat's log (catalina.out) I keep getting the below exception which seems to suggest that it is addressed using TLS v1.3 (which it can't handle):
Oct 06, 2022 5:22:06 PM org.apache.tomcat.util.net.NioEndpoint setSocketOptions
SEVERE:
javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
at sun.security.ssl.HandshakeContext.<init>(HandshakeContext.java:171)
at sun.security.ssl.ServerHandshakeContext.<init>(ServerHandshakeContext.java:62)
at sun.security.ssl.TransportContext.kickstart(TransportContext.java:220)
at sun.security.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:97)
at org.apache.tomcat.util.net.SecureNioChannel.reset(SecureNioChannel.java:89)
at org.apache.tomcat.util.net.SecureNioChannel.<init>(SecureNioChannel.java:71)
at org.apache.tomcat.util.net.NioEndpoint.setSocketOptions(NioEndpoint.java:666)
at org.apache.tomcat.util.net.NioEndpoint$Acceptor.run(NioEndpoint.java:808)
at java.lang.Thread.run(Thread.java:750)
javax.net.ssl|FINE|B5|http-nio-8443-Acceptor-0|2022-10-06 17:22:07.539 CEST|HandshakeContext.java:304|No available cipher suite for TLS13
javax.net.ssl|SEVERE|B5|http-nio-8443-Acceptor-0|2022-10-06 17:22:07.540 CEST|TransportContext.java:316|Fatal (HANDSHAKE_FAILURE): Couldn't kickstart handshaking (
"throwable" : {
javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
at sun.security.ssl.HandshakeContext.<init>(HandshakeContext.java:171)
at sun.security.ssl.ServerHandshakeContext.<init>(ServerHandshakeContext.java:62)
at sun.security.ssl.TransportContext.kickstart(TransportContext.java:220)
at sun.security.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:97)
at org.apache.tomcat.util.net.SecureNioChannel.reset(SecureNioChannel.java:89)
at org.apache.tomcat.util.net.SecureNioChannel.<init>(SecureNioChannel.java:71)
at org.apache.tomcat.util.net.NioEndpoint.setSocketOptions(NioEndpoint.java:666)
at org.apache.tomcat.util.net.NioEndpoint$Acceptor.run(NioEndpoint.java:808)
at java.lang.Thread.run(Thread.java:750)}
Edit 3: my /etc/apache2/conf.d/proxy.conf file now reads:
Listen 443
<VirtualHost *:443>
SSLEngine On
SSLCertificateFile -name-removed-
SSLProxyEngine On
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLProxyMachineCertificateFile -name-removed-
ProxyPass /foobar https://-name-removed-:8443/foobar
ProxyPassReverse /foobar https://-name-removed-:8443/foobar
SSLProxyProtocol +TLSv1.2
<Proxy "*">
Require all granted
SSLProxyProtocol +TLSv1.2
</Proxy>
LogLevel debug
ErrorLog "-name-removed-"
</VirtualHost>
Note: "foobar" and "-name-removed-" represent values that I replaced for privacy.
Edit 4:
The nmap response was:
# nmap -sV --script ssl-enum-ciphers -p 8443 127.0.0.1
Starting Nmap 7.70 ( https://nmap.org ) at 2022-10-10 16:12 CEST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00011s latency).
PORT STATE SERVICE VERSION
8443/tcp open tcpwrapped
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 3.67 seconds
#
What does that tell me?

I would suggest running a utility like nmap to assess the SSL capabilities of the backend server (Tomcat) in this instance. nmap nicely prints out the TLS protocols and ciphers that a given TLS server supports. Using this information, we could configure Apache HTTPD to use the same protocols and ciphers for the backend connection using SSLProxyProtocol and SSLProxyCipherSuite directives.
How to use nmap:
nmap -sV --script ssl-enum-ciphers -p

The issue has been resolved! I had a typo in the config file! Shame on me and sorry for the bandwidth consumed.

Related

Disabled TLS but SSL online analyzer finds it as enabled. Why?

In my virtual host I specified to disable TLSv1 and TLSv1.1
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
SSLHonorCipherOrder on
SSLCompression off
SSLSessionTickets off
# OCSP Stapling, only in httpd 2.3.3 and later
SSLUseStapling on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache shmcb:/var/run/ocsp(128000)
Then I tested using https://www.ssllabs.com/ssltest/analyze.htm
Buy I anyway continue to see
Protocols
TLS 1.3 No
TLS 1.2 Yes
TLS 1.1 Yes
TLS 1.0 Yes
SSL 3 No
SSL 2 No
For TLS 1.3 tests, we only support RFC 8446.
I restarted both apache2 and sshd before re-run the analizer, but nothing changes.
What am I missing?
EDIT: it's a new VM with debian 9, apache 2 and certbot, with only one virtual host, and I also disabled the default one.
Probably some config in other files are conflicting or overriding my settings, so I'll investigate.
There could be multiple reasons for this, like
You don't actually test your server configuration. This can happen if there is a SSL terminating load balancer or reverse proxy in front of your server or if your server is behind a CDN (Cloudflare, Akamai, ...).
You have multiple virtual hosts on the same IP address and port with different configurations regarding the SSLProtocol. Only one of the settings will be actually used in this case and it might not be the one you expected.
You have different configurations for IPv4 and IPv6 and made the changes only to one of these configuration.
You made the changes to parts of the configuration which take no effect.
Like state in accepted answer, the was some conflicting settings.
In my VHost config I was including
Include /etc/letsencrypt/options-ssl-apache.conf
And I setup my settings outside the vhost. So my settings take less precedence than included one.
And included one WAS NOT disabling TLSv1, for example.
Fixed the included file, all works as expected.
Thanks again #Steffen Ullrich

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

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.

Apache ProxyPass HTTPS and remote server with SNI

I'm wanting to front an AWS APIGateway URL with a reverse proxy in Apache. The reason is due to a process requiring a static IP to provision a service behind a strict firewall and that the current infrastructure has mod_proxy already in place. The solution I'm looking to implement is to simply to route https->https(apiGateway) via mod_proxy.
But.. AWS uses SNI and I can not get mod_proxy to handshake.
I have the following settings enabled
<IfModule mod_ssl.c>
<VirtualHost *:443>
ProxyPreserveHost On
SSLProxyEngine On
ProxyPass /api/1_0/ https://xxx.execute-api.eu-west-1.amazonaws.com/1_0/
ProxyPassReverse /api/1_0/ https://xxx.execute-api.eu-west-1.amazonaws.com/1_0/
The following logs are available in debug mode
proxy_util.c(2020): AH00942: HTTPS: has acquired connection for (xxx.execute-api.eu-west-1.amazonaws.com)
proxy_util.c(2610): AH00962: HTTPS: connection complete to 52.x.x.x:443 (xxx.execute-api.eu-west-1.amazonaws.com)
AH01964: Connection to child 0 established (server domain.com:443)
AH02003: SSL Proxy connect failed
SSL Library Error: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
AH01998: Connection closed to child 0 with abortive shutdown (server domain.com:443)
AH01997: SSL handshake failed: sending 502
If I connect using openssl, I can demonstrate a similar error
openssl s_client -tls1_2 -connect xxx.execute-api.eu-west-
1.amazonaws.com:443
CONNECTED(00000003)
140735866254216:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert
handshake failure:s3_pkt.c:1494:SSL alert number 40
140735866254216:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:659:
adding -servername for SNI, results in a valid connection
SSL handshake has read 3601 bytes and written 489 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
...
I therefore believe that mod_proxy and mod_ssl are not sending the servername to the remote https server and could be a bug.
I am running Ubuntu 14.04 with
Server version: Apache/2.4.7 (Ubuntu)
Server built: Sep 18 2017 16:37:54
OpenSSL 1.0.1f 6 Jan 2014
I have attempted to limit the SSLProxyProtocol to TLS1_2 and the cipher list too however the sslv3 alert handshake failure log still exists regardless.
Has any one come across this and know how to ensure that the SNI values are being sent or is this a restriction in the Apache modules?
This is due to ProxyPreserveHost On being set early in the configuration.
Setting ProxyPreserveHost Off under a proxy tag completes as expected:
<Proxy "https://xxx.execute-api.eu-west-1.amazonaws.com/1_0">
ProxyAddHeaders off
ProxyPreserveHost off
</Proxy>
Info on the directive:
When enabled, this option will pass the Host: line from the incoming
request to the proxied host, instead of the hostname specified in the
ProxyPass line.
This option should normally be turned Off. It is mostly useful in
special configurations like proxied mass name-based virtual hosting,
where the original Host header needs to be evaluated by the backend
server.
The answer above helped us. For the sake of "googling" it I would like to add the following scenario as well:
we use a cloud WAF infront of one of our services. Another service needs to forward specific queries to this host and pass through the WAF.
The working configuration looks like this:
<Proxy "balancer://qwertz">
ProxyPreserveHost off
BalancerMember "https://somehost.somewhere.de:443"
</Proxy>
ProxyPass "/special/webservices/" "balancer://qwertz/special/webservices/"
ProxyPassReverse "/special/webservices/" "balancer://qwertz/special/webservices/"
The apache is configured as reverse proxy and runs inside a docker container.
Note that the balancer has only one host, thus no balancing is done.
Before this answer we were getting SSL erros like:
Error during SSL Handshake with remote server returned by...
pass request body failed to...
or
server certificate does NOT include an ID which matches the server name
Like AWS the Cloud WAF also requires SNI.
Hope this post makes this answer more visible (or findable) to someone else.

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.

Error 107 (net::ERR_SSL_PROTOCOL_ERROR): SSL protocol error

I have configured SSL on my tomcat. I referred to the steps from the following site to configure SSL:
http://wiki.openbravo.com/wiki/How_To_Configure_SSL_For_Windows
I am using Win32 OpenSSL v0.9.8x Light installer and tomcat 7.0.22. But when I access https://server.ensarm.com:8843/ it gives the following error:
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.
I don't understand what could be the problem. :(
Check your Apache error log, see if it has a message similar to:
You configured HTTP(80) on the standard HTTPS(443) port!
This may indicate you have configured Apache to listen on port 443 while the SSLEngine is not on.
In httpd.conf only set ONE listen directive:
Listen *:80
Later in httpd.conf you should have something that looks like:
<IfModule ssl_module>
Include conf/httpd-ssl.conf
</IfModule>
In httpd-ssl.conf (or equivalent config file) make sure you have enabled the SSLEngine prior to the Listen directive:
SSLEngine on
listen *:443
Restart Apache and you should be good to go.