Is https meant only for public-facing sites on the Internet?

Help
1

I have a locally-hosted site behind a router. I put my caddy configuration in it like so

nextcloud.localdomain {
	root   /var/www/localhost/htdocs/nextcloud
	log    /var/log/caddy/caddy-access.log
	errors /var/log/caddy/caddy-errors.log
....
}

And it complains

Activating privacy features...2017/04/22 17:17:29 [nextcloud.localdomain] failed to get certificate: acme: Error 400 - urn:acme:error:malformed - Error creating new authz :: Name does not end in a public suffix

How can I use a public suffix? It will think my domain is a real entity on the Internet or is this feature meant only for real public-facing sites?

2

Caddy auto-enables HTTPS for sites that look like they could be “real” (as in, not localhost). We don’t code in every possible fake TLD used for local development, but you can put tls off in your site’s Caddyfile instead.

A hostname must be “real” (as in, a publicly-recognized domain name) in order for auto HTTPS to work.

3

I’m not sure what you mean by the hostname being real, being real as in being in /etc/hosts?

What does “tls off” do? It avoided the error, but caused caddy to launch the site bound to http on port 2015. When I tried passing a port in the configuration, it didn’t recognize it:
Parse error: Unknown directive ':443'

When I tried passing it (443) on the command line, it correctly recognized it as https, but then the web browser complained it couldn’t make a secure connection.

4

Real as in globally resolvable. So no, /etc/hosts won’t cut it because a public CA (Let’s Encrypt in this case) has to verify it.

It turns off automatic HTTPS. (HTTPS is HTTP over TLS.) Caddy’s default port is 2015, which automatic HTTPS changes to 443. But with automatic HTTPS off, the port doesn’t change.

5

Does this mean there is no way to do https for a local server?

6

Sure there is, but not from a public CA.

You have a few options. You can use self-signed certificates, but they aren’t trusted by browsers so you’ll have to bypass a warning. But if you don’t mind that, this is what I usually do and it’s very easy, just put tls self_signed in your Caddyfile.

You can also add a custom root cert to your trust store so that your self-signed certificate is trusted and you don’t get warnings.

The last option is the most intensive, and that is to run your own internal CA. But I would only do that for enterprise intranets that need that…

1 Like
7

if you would like to run your site on :80 without TLS you should put the following in your Caddyfile

nextcloud.localdomain:80 {
    tls off
root   /var/www/localhost/htdocs/nextcloud
log    /var/log/caddy/caddy-access.log
errors /var/log/caddy/caddy-errors.log
 }

Actually the TLS off is redundant once you have put :80 at the end of the host

8

“tls self_signed” doesn’t work for nextcloud. It says there is a problem with SSL handshaking. It does work in Apache. This suggests a bug in caddy.
Also, the self-signed in caddy appears to expire in a week.

9

Strange, what’s the handshake error?

Self-signed certs are intended for development, which sessions don’t usually last longer than a week… are you serving a long-running HTTPS service with an untrusted certificate?

10

Nextcloud doesn’t get more specific than that and the caddy log file doesn’t record anything. Since I’m running locally, I’d want my self-signed certificate to work indefinitely.

It seems to work OK in the Mac browsers.

11

Oh, it works on Safari? But not Chrome? That’s even more interesting. Does Chrome give any particular error when you make the request?

12

Safari, no complaints, seems to work 100%
Firefox, complains about it and offers to take an exception.
Chrome, complains about it but allows it to go forward. Insists the site is not secure.
Nextcloud, cannot connect at all, claims SSL handshake failure.

The order I tested these may matter because one of them, Firefox, perhaps, saved the caddy certificate in my keychain.

I think there Caddy ought to be capable of more debug logging in so that we can see the steps of the SSL handshake failure.

13

I’m a bit confused by the wording here. Isn’t Nextcloud the website you’re loading? How can you connect to Nextcloud, via Safari for example, but Nextcloud cannot connect - what’s it connecting to?

14

Hmm, I would also like to know. Caddy does write to its log when there are TLS errors. I’m confused as to whether the error is with Nextcloud or with Caddy, first, and then figure out what error the browsers are really showing.

15

Oh, sorry, I meant the nextcloud Mac application. That’s what giving the SSL handshake error. I type in the address https://192.168.1.50 to connect and it fails. The preferences screen shows that error.

The app works fine if I am just using http.

16

So to clarify, when you configure Caddy to serve Nextcloud over :443 with a self-signed certificate, the Nextcloud Mac App fails to connect and only shows a message along the lines of “SSL handshake error”.

However, when you configure Apache to serve Nextcloud over :443 with a self-signed certificate, the Nextcloud Mac App connects just fine?

Incidentally, I’d expect most, if not all apps to bail out of HTTPS with a self-signed certificate unless it has some option to ignore validation errors - simply because you won’t ever have a method of trusting that certificate. To do that, you’d need to manually generate your certs and add their root CA to your MacOS trusted store, which the app may ignore anyway.

17

This is correct.

I now notice this in the log:
http: TLS handshake error from 192.168.1.152:61389: tls: client offered an unsupported, maximum protocol version of 301

18

Oh, so it is Caddy’s fault!

It’s not very well published, but protocol version 301 is TLS1.0, which is below the default minimum protocol level - see the Protocols section of the TLS docs.

The best case scenario would be for Nextcloud to update their app and stop using an old, vulnerable protocol; barring that, you can lower Caddy’s default minimum to support TLS1.0 connections with self-signed certificates using the following syntax:

tls self_signed {
  protocols tls1.0 tls1.2
}
19

Progress. Now the error is

http: TLS handshake error from 192.168.1.152:64428: tls: no cipher suite supported by both client and server

It doesn’t say, though, which ciphers it’s expecting.

20

This does not bode very well for the security of the Mac app, I’m afraid :confused:

The list of Caddy’s supported cipher suites can be found here - at this point I have to question the decision to use HTTPS as using an insecure protocol and outdated or blacklisted ciphers does not leave much merit to the argument for security.

You might consider configuring Caddy to serve on both HTTP and HTTPS (and disable upgrade redirects) so that up-to-date apps can use HTTPS and older apps can use HTTP.