HTTP-S not working. HTTP-S only works for LAN IP!

Hi guys,

After many agonising days of trying to set up Nextcloud server on Ubuntu 16.04, I humbly come to you for guidance. I don’t know where the problem is although I have tried implementing many solutions.

To sum up, I have installed Nextcloud 11.0.3 and now I can access the server from HTTP from all: LAN IP and Public IP.

The problem is that: I cannot access by HTTP-S the public IP of the server. However, there seems to be no problem accessing nextcloud server by HTTPS of the LAN IP. For the record, I have checked and I confirm that port-forwarding is functioning and port 443 is open, as I have double checked it.

Also, the checking of my IP server revealed so far:

a. returns the scan of my public IP with message: “No secure protocols supported”.

b. auto self certification command
sudo ./certbot-auto --apache --agree-tos --email --redirect -d
returns with: “Failed to connect to for tls-sni-01 challenge: Server only speaks HTTP, not TLS”.

By the way, my certificates are selfsigned with openssl.

And, finally, I mentioned I have created the bellow 2 vhosts files:

1. nextcloud_https.conf

<IfModule mod_ssl.c>
  <VirtualHost *:443>

 DocumentRoot /var/www/nextcloud

 <Directory /var/www/nextcloud/>
   Options +FollowSymlinks
   AllowOverride All

  <IfModule mod_dav.c>
    Dav off

   SetEnv HOME /var/www/nextcloud
   SetEnv HTTP_HOME /var/www/nextcloud

 <IfModule mod_headers.c>
     # Header always set Strict-Transport-Security "max-age=15768000; preload"
      Header always set Strict-Transport-Security "max-age=15768000;

  SSLEngine on
  SSLProtocol  all -SSLv3 -TLSv1 -TLSv1.1
  SSLHonorCipherOrder on
  SSLCompression          off
  SSLSessionTickets       off
  SSLCertificateFile /etc/ssl/certs/
  SSLCertificateKeyFile /etc/ssl/private/


2. nexcloud.conf

<VirtualHost *:80>

 DocumentRoot "/var/www/nextcloud"

 Alias /nextcloud "/var/www/nextcloud/"

   <Directory /var/www/nextcloud/>
         Options +FollowSymlinks
         AllowOverride All

   <IfModule mod_dav.c>
     Dav off

    SetEnv HOME /var/www/nextcloud
    SetEnv HTTP_HOME /var/www/nextcloud
    Satisfy Any


 ErrorLog ${APACHE_LOG_DIR}/error.log
 CustomLog ${APACHE_LOG_DIR}/access.log combined


And Nextcloud config.php is the following:

$CONFIG = array (
  'instanceid' => 'oc56yzfz9v4x',
  'passwordsalt' => 'jBRlxm7XlumdzS7J5hV+lLfp2FPQ/C',
  'secret' => 'XlToSnjTZSGQZVdSaAKeSHXGahxzq+TtyhyXZlDQg09gY/4+',
  'trusted_domains' =>
  array (
    0 => '',
    1 => '',
    2 => '',
  'datadirectory' => '/var/www/nextcloud/data',
  'overwrite.cli.url' => '',
  'dbtype' => 'mysql',
  'version' => '',
  'dbname' => 'nextcloud',
  'dbhost' => 'localhost',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'dbuser' => 'nextcloud',
  'dbpassword' => 'xxxxxxxxxx',
  'logtimezone' => 'UTC',
  'installed' => true,

All other apache hosts: defaul-ssl.conf and 000-default.conf are disabled from loading.

Sorry for the long lecture, but could you please help me sort things out ?

I have previously tried Owncloud prior to using Nextcloud and I really hadn’t encounter this kind of issues.

Thank you so much !


if really is the hostname, then it doesn’t repsond to https queries from the internet. There is probably a firewall in between, which blocks https… this is also the reason for certbot failling, just as it stated.

Make sure, that the host is reachable from the internet via port 443.


1 Like
  1. TLS 1.1 is not yet known to be broken and a lot of Services and older Browsers use it. Disabling 1.1 may also mitigate attacks. So I suggest this:

SSLProtocol all -SSLv2 -SSLv3 -TLSv1

  1. Why do you not use Let’s encrypt. Far better than anything self-signed. Some Browsers even won’t show self-signed Websites anymore.

Hi budy ,

Although I have disabled the firewall in my router (and previously opened port 443 on both router and nextcloud server) the problem remains.I have also checked port 443 with which confirms the port is clearly open. I have also tried another DDNS from a different provider, but the problem persists.

In addition, I have changed the SSL port from 443 to 4444, but the public IP of server is still not reachable - the internal IP still functions.

In regard of certification [quote=“jakobssystems, post:3, topic:12272”]
2) Why do you not use Let’s encrypt. Far better than anything self-signed. Some Browsers even won’t show self-signed Websites anymore.
Thank you for your suggestion on modifying the SSLProtocol. I have implemented it.

I can’t see a reason why my home server would be blocked from accessing a HTTP-S due to a certification issues especially in my particular case where I don’t even advance enough with loading the page to the point to be asked if I want to accept the certificate in question.

Do you have any other ideas why HTTP-s works for accessing my LAN IP (, but not the public IP or FQDN ?


have you checked the apache Access and Error log if the request to the external IP reach the apache?
This would help you to figure out if it is a problem with your router/firewall or with apache.

Yes, I did and the access.log is saying:

  • for Firefox: "\x16\x03\x01" 400 0 "-" "-"
  • for Internet Explorer: "GET / HTTP/1.1" 302 1218 "" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)"
  • for Chrome "\x16\x03\x01" 400 0 "-" "-"

The error.log reports (it’s not an error that happens simultaneously with accessing the FQDN…it had appeared 3 hours before this moment):
[:error] [pid 11836] [client] script '/var/www/nextcloud/echo.php' not found or unable to stat.

What do you think ?

I’m just woundering, why is the Internet Explorer requesting with http on Port 2222 are this the entries for the HTTP log?
Maby adding to the nextcloud_https.conf would help to only get the https, related errors and access information.

ErrorLog ${APACHE_LOG_DIR}/error-https.log
CustomLog ${APACHE_LOG_DIR}/access-https.log combined

@tacruc I followed your recommendation and added the code for logging.

On the same topic, Firefox still reports:

Secure Connection Failed
An error occurred during a connection to xx.xx.xx.xx.xx. SSL received a record that exceeded the maximum permissible length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG.
The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.

As regard the logs just created, I have just one created by the error-https.log:

[ssl:error] [pid 7664] AH02604: Unable to configure certificate for stapling
[ssl:warn] [pid 7665] AH01906: server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[ssl:error] [pid 7665] AH02217: ssl_stapling_init_cert: can’t retrieve issuer certificate! [subject:,,L=xxxxxxxxxxx,ST=B,C=XX / issuer:,,L=xxxxxxxxx,ST=B,C=XX / serial: A48FD34551DD0BD7 / notbefore: May 8 16:43:54 2017 GMT / notafter: May 8 16:43:54 2018 GMT]

I have tried with no luck enabling/disabling the /etc/apache2/conf-available/ ssl-params.conf which contains to maybe get rid off this problem:
`Preformatted text #from
SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder On

Disable preloading HSTS for now. You can use the commented out header line that includes`

# the "preload" directive if you understand the implications.
#Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"
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 SSLSessionTickets Off SSLUseStapling on SSLStaplingCache "shmcb:logs/stapling-cache(150000)" SSLOpenSSLConfCmd DHParameters "/etc/ssl/certs/dhparam.pem"

I also have the confirmation of the Internet Service Provider that there are no blocked or filtered ports on my IP so everything should be open and available.

What am I missing here ?

Thank you all for support !

Ich would guess that something is wrong this your certificate. Consider
getting one with
It’s free and most browsers trust that authorities without extra client
configuration. Make shure to set the right Common Name should match your

flash62309 schrieb am Mi., 10. Mai 2017, 00:55:

Actually the certbot is the one giving the error

“Failed to connect to for tls-sni-01 challenge: Server only speaks HTTP, not TLS”.

I even registered for a domain, obtained a CA certificate for the respective domain and then redirected that website it to my public IP. The result is the same: I can access via http, but no HTTP access. Firefox returns with :

The connection has timed out
The server at is taking too long to respond.

So there must be something else, I guess.

So from the apache error log I would still think, that it is not an network problem, because the request ist processed by apache.
It apache tell’s you that it can’t configure the certificat for stapling.

So you could try to disable Staling with
SSLUseStapling Off

Had a sumilar issue a while back. If i remember well i solved it by flushing the iptables of my OS (osx)

Hi. I’d like to know your server setup. What software environment are you using. When I setup my nextcloud with ssl I had issues with certbot going through when executing the command. In the end it was missing software for my Dynamic DNS part of my router.

Well… first off, you will make to sure to check whether or not, the HTTPS traffic is actually hitting your Nextcloud server. So you have to fire up tcpdump on your NC box and have it listen on port 443.
The actual command will be something like this:

tcpdump -i ip and port 443

Then you can poke at it from the internet using openssl on a *nix client, or which you have installed OpenSSL by running this in the terminal:

openssl s_client -connect host:443 -crlf

This should either resoond with the certificate of your NC box, or do nothing,if it can’t reach it. At the same time, you should see tcpdump reporting traffic on 443 from your router. If tcpdump doesn’t show any traffic from your router to your NC box, when running openssl, then the traffic is not reaching your NC box.

Thank you all so much for your kind assistance.

After flushing all iptables from linux server and also all port-forwarding permission from router menu, which, by the way, it contained 2 conflicting rules on port 443, HTTP-S has begun working. So now it’s all good.

All the best !