SSL Certifcate not Working 80% of the time Apache - ssl

I am having a problem with HTTPS on my domain. fashiontex.co
Across all browsers on (Linux Desktop), it sometimes loads as https without the Not Secured Warning or
"Your connection is not private"
on chrome and its other variation on different browsers.
On, mobile IOS 14, Android, and others it is 100% not secured no matter the configuration.
For the records, I am using PossitiveSSL certificate which isn't free.
here is a snippet of the relevant ssl and virtual host config
Listen 443
<VirtualHost *:443>
ServerName example.co
ServerAlias www.example.co
ServerAdmin webmaster#example.co
DocumentRoot /var/www/example.co/public_html
....
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ALL:+HIGH:!ADH:!EXP:!SSLv2:!SSLv3:!MEDIUM:!LOW:!NULL:!aNULL
SSLHonorCipherOrder on
SSLCertificateFile /etc/pki/tls/certs/ca.crt
SSLCertificateKeyFile /etc/pki/tls/private/ca.key
SSLCACertificateFile /etc/pki/tls/certs/fashiontex.ca-bundle
</VirtaulHost>
For the SSLCipherSuite, I'm not going to exaggerate, I have used over 50 values searching the internet.
and on https://www.ssllabs.com/ssltest/analyze.html?d=fashiontex.co I have gotten ratings of A, B but still, it still doesn't work even after clearing the cache on both windows, iPhone, and ubuntu.
PS: Before writing this entire post, it was showing not secured, when I was done with the above, I refreshed and it showed without the warning and tried again 10 seconds later and it is the same problem of not secured one more time. Please what am I missing?

It turns out that it was truly the Layer 7 SSL Protection which was enabled that was interfering with requests because it intercepts https requests for DDoS protection.
Depending on your hosting provider, mine recommended switching protection to Sensor Mode unless I am been attacked frequently.
So now it works

Related

Apache HTTP VM Behind HTTPS Lets Encrypt

I've read a lot of questions and answers which seem exactly the same as mine, but I can't seem to get my setup to work. I have a VM running Apache with only HTTP support at 192.168.2.101:32773. I can access it on my local network as such just fine. I now am ready to expose it through my Apache web server that has Lets Encrypt setup to generate SSL certificates. So I added this to my server conf file:
<VirtualHost *:32773>
ServerName server.com
SSLEngine on
SSLProxyEngine On
SSLCertificateFile /etc/letsencrypt/live/server.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/server.com/privkey.pem
ProxyRequests Off
ProxyPreserveHost On
ProxyPass / http://192.168.2.101:32773/
ProxyPassReverse / http://192.168.2.101:32773/
</VirtualHost>
However, I get an ERR_SSL_PROTOCOL_ERROR when I try to load it up as https://server.com:32773. If I however change my address to http://server.com:32773, it loads just fine. Anything look wrong in this snippet? Thanks!
HTTP and HTTPS need to be on different ports. Typically HTTPS is served on port 443.
This is embarrassing... At some point I changed my port forward rules to point 32773 directly to 192.168.2.101 so I could validate that the rules were working at all. The above config worked as soon as I realized I wasn't even sending traffic to my Apache SSL enabled server.

Collabora (docker) and NextCloud (snap) problem behind proxy on same machine

I decided to post about my situation after many days of troubleshooting. I recently installed NextCloud as snap on Ubuntu 18.04 and everything worked fine. I did the port forwarding and used Let’s Encrypt (from snap commands) to create the certificates for NC.
Then I decided to install Collabora server on the same machine to use the office functionality. I used the official Collaboration guides for installation mentioned here. However, in this guide, it is assumed that NC is installed manually (not snap). According to guides, I had to install Apache (or any other proxy/web server) to proxy the traffic to whether NC or Collabora.
I think there is a problem with my proxy configuration or something wrong with SSL certificates. When both Apache and snap are running, I can get to Apache page and Collabora should be running, but cannot get to NC page.
I can go to (port 443) link below and get to the page (meaning Collabora is responding?)
https://collabora.domain.com/loleaflet/dist/admin/admin.html
But when accessing the NC domain, the browser says “Did Not Connect: Potential Security Issue” and complain that the certificates are not for that NC domain I am trying to connect but the certificate is for Collabora domain. If I stop the Apache and let Snap running, I can access the NC domain with no issues (except I need to set the ports to 443 and 80 again! Is this problematic?)
My Apache proxy config file (located under /etc/apache2/sites-available/) is as follows:
<VirtualHost *:444>
ServerName nextcloud.domain.com:444
ProxyPreserveHost On
ProxyPass / https://192.168.1.50/
ProxyPassReverse / https://192.168.1.50/
SSLProxyEngine on
SSLCertificateFile /etc/letsencrypt/live/nextcloud.domain.com/cert.pem
SSLCertificateChainFile /etc/letsencrypt/live/nextcloud.domain.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/nextcloud.domain.com/privkey.pem
</VirtualHost>
<VirtualHost *:443>
ServerName collabora.domain.com:443
# SSL configuration, you may want to take the easy route instead and use Lets Encrypt!
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/collabora.domain.com/cert.pem
SSLCertificateChainFile /etc/letsencrypt/live/collabora.domain.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/collabora.domain.com/privkey.pem
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-$
SSLHonorCipherOrder on
# Encoded slashes need to be allowed
AllowEncodedSlashes NoDecode
# Container uses a unique non-signed certificate
SSLProxyEngine On
SSLProxyVerify None
SSLProxyCheckPeerCN Off
SSLProxyCheckPeerName Off
# keep the host
ProxyPreserveHost On
# static html, js, images, etc. served from loolwsd
# loleaflet is the client part of LibreOffice Online
ProxyPass /loleaflet https://127.0.0.1:9980/loleaflet retry=0
ProxyPassReverse /loleaflet https://127.0.0.1:9980/loleaflet
# WOPI discovery URL
ProxyPass /hosting/discovery https://127.0.0.1:9980/hosting/discovery$
ProxyPassReverse /hosting/discovery https://127.0.0.1:9980/hosting/discovery
# Main websocket
ProxyPassMatch "/lool/(.*)/ws$" wss://127.0.0.1:9980/lool/$1/ws nocanon
# Admin Console websocket
ProxyPass /lool/adminws wss://127.0.0.1:9980/lool/adminws
# Download as, Fullscreen presentation and Image upload operations
ProxyPass /lool https://127.0.0.1:9980/lool
ProxyPassReverse /lool https://127.0.0.1:9980/lool
# Endpoint with information about availability of various features
ProxyPass /hosting/capabilities https://127.0.0.1:9980/hosting/capabilities retry=0
ProxyPassReverse /hosting/capabilities https://127.0.0.1:9980/hosting/capabilities
</VirtualHost>
To be honest, this is first time I am setting up proxy server that do not know how it works. Most of my config file is copied and think that is the issue :) If someone can have a look at it and guide me to the right direction, that would save me lots of headache and time.
I went through the same pain for a similar amount of time and eventaully got a simple solution.
The online instructions for docker here are correct except that they omit enabling proxy for websockets.
a2enmod proxy
a2enmod proxy_wstunnel
a2enmod proxy_http
a2enmod ssl
The only other change I had to make were to add --cap-add MKNOD to the docker start.
In Nextcloud I then only needed to add https://collab.example.com to the WAPI server address configuration after creating LetsEncrypt certs for my domain (obviously example.com is not my real domain).

Apache 2.4 SSL Config

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

SSL handshake issue with remote apache httpd server, works locally

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

Apache 2 types SSl using VirtualHosts

I have 2 different applications.
1) tools.helpme.com Require Client Certificates from users!
SSLCACertificateFile /usr/local/etc/apache22/certs/cacert.pem
SSLCertificateKeyFile /usr/local/etc/apache22/certs/server.key
SSLCertificateFile /usr/local/etc/apache22/certs/server.crt
SSLCertificateChainFile /usr/local/etc/apache22/certs/server.crt
SSLVerifyClient require
2) apps.helpme.com Requires basic SSL from the Server only!
SSLCACertificateFile /usr/local/etc/apache22/certs/cacert.pem
SSLCertificateKeyFile /usr/local/etc/apache22/certs/server.key
SSLCertificateFile /usr/local/etc/apache22/certs/server.crt
SSLCertificateChainFile /usr/local/etc/apache22/certs/server.crt
SSLVerifyClient none
I have each of them working independently of the other - and it is perfect.
However, I cannot get both of them running together, they are on different VirtualHosts - Name based hosting.
If I try run both of them together, it seems (2) takes preference and works, but (1) gets a GATEWAY_TIMEOUT!
The error log for that virtaul host says: Re-negotiation handshake failed: Not accepted by client!?
You need the sites on two different IP addresses, as the SSL handshake occurs before sending the HOST http header. You can run on separate port numbers though with the same IP, but that doesn't really help for two different web services?