When is a connection HTTPS?

Help
#1

My reading of the documentation has clearly left me not understanding something fairly basic.

First, I am not clear when a site is available on port 2015 and when on port 80. Secondly, I’m not clear under what circumstances there is automatic redirection from port 80 to port 443. I have started experimenting, but this has made me more confused.

Because I have a webmail server on the machine concerned, proxying that is the first task I must set Caddy, so that I can let it have those ports permanently. Because the mail server already has a commercial certificate, I specified that in a tls directive. My first attempt at a caddyfile was:

mail.cassland.org {
tls Cert\cass-adet-16-bundled.pem Cert\cass-adet-16-key.pem
proxy / localhost:8800
}

This worked - but only on port 2015. So my next attempt was:

http://mail.cassland.org, https://mail.cassland.org {
tls Cert\cass-adet-16-bundled.pem Cert\cass-adet-16-key.pem
proxy / localhost:8800
}

This worked, accepting both http and https connections; however, the https connection shows as unsecured. There was also the oddity that a browser on the local machine changed the address field to show localhost:8800 - I thought a proxy hides the onward connection (I tried with “transparent”, but that made no difference). So I then tried:

http://mail.cassland.org, https://mail.cassland.org {
tls Cert\cass-adet-16-bundled.pem Cert\cass-adet-16-key.pem
proxy / https://mail.cassland.org:8843
}

In this case connections initiated with http and https both end up as secure - which is fine. But I still don’t understand why the earlier attempts behaved as they did.

#2

Hi Paul, thanks for your questions! There’s a few different, unrelated things going on here. The best debugging steps are those which eliminate complexity and surface area for errors (or unexpected behavior) to arise.

This worked - but only on port 2015.

You’ve specified your own certificate and key, so automatic HTTPS is disabled. Thus the ports are not changed for you. See automatic HTTPS for the conditions where automatic HTTPS is invoked.

This worked, accepting both http and https connections; however, the https connection shows as unsecured.

Your page is probably requesting resources over plain HTTP?

There was also the oddity that a browser on the local machine changed the address field to show localhost:8800

Probably your backend doing a redirect. Take out the proxy directive and try again.

Also, why not just let Caddy manage your certificates for you? You could drastically simplify your config this way:

mail.cassland.org
proxy / localhost:8800
#3

Thanks for the quick response!

[quote=“matt, post:2, topic:832”]
Your page is probably requesting resources over plain HTTP?[/quote]
If I connect to Caddy using https, surely that’s a secure link and should show as such? How does the http onward link to the mail server affect that?

[quote]
Probably your backend doing a redirect. Take out the proxy directive and try again.[/quote]
But it didn’t happen when browsing from a different machine - why would it behave differently. And if I take out the proxy directive I’ve nothing to test - that’s the link to the server…

It just seemed natural to start testing by using the certificate I had to hand for that server; I intend to use Caddy’s facilities in future. But if I want to have Caddy serve this site over HTTPS (whether using my certificate or generating a new one), do I have to make the link to the mail server itself HTTPS as well (see above) even though it’s on the same machine? If so, would it be all right for the backend server to have a self-signed certificate?

PS - the following caddyfile behaves as I expect!

mail.cassland.org {
proxy / https://mail.cassland.org:8843 {
transparent
}
}

Is there not a case for the behaviour introduced by “transparent” being default?

#4

Not necessarily. When your browser loads a web page, it makes many other requests for resources that could be over HTTP if the page doesn’t say to use HTTPS.

I’m guessing the backend app is coded to use HTTP instead of HTTPS.

I dunno, your backend could be doing anything.

That’s the point, take it out and if it “works” then you know it is your backend app, not Caddy, misbehaving.

No. Just make sure your backend isn’t doing bad redirects or something.

#5

[quote=“matt, post:4, topic:832”]
If I connect to Caddy using https, surely that’s a secure link and should show as such?[/quote]

Not necessarily. When your browser loads a web page, it makes many other requests for resources that could be over HTTP if the page doesn’t say to use HTTPS.[quote]
OK, I get that.

The mail server uses whichever it is asked for; that’s why I have a commercial certificate for it, after all!

[quote]pwhodges:
And if I take out the proxy directive I’ve nothing to test - that’s the link to the server…

That’s the point, take it out and if it “works” then you know it is your backend app, not Caddy, misbehaving.[/quote]
If I take out the proxy directive, I am no longer testing the proxy setup, so it tells me nothing at all. If I access the mail server directly, it all works perfectly as expected.

My caddyfile has grown a little; it now reads:

mail.cassland.org {
proxy / https://mail.cassland.org:8843 {
transparent
}
}

michaelgerzonphotos.org.uk, www.michaelgerzonphotos.org.uk {
root …\michaelgerzonphotos.org.uk\html
}

peon.cassland.org {
proxy / localhost:6967
}

These sites all work as expected, with their automatically generated certificates. But I have one continuing problem: when I first configured michaelgerzonphotos.org.uk, the change I had made to the DNS record had not finished propagating, so the certificate acquisition failed (because the CA picked up a different address for the name) and I quite properly got this error logged:

2016/10/18 15:00:56 [INFO][michaelgerzonphotos.org.uk] acme: Obtaining bundled SAN certificate
2016/10/18 15:00:57 [INFO][michaelgerzonphotos.org.uk] acme: Trying to solve TLS-SNI-01
2016/10/18 15:00:58 http: TLS handshake error from 82.70.166.77:54414: remote error: tls: unknown certificate

However, since then the record has propagated, and Caddy has successfully acquired the necessary certificate which works just fine. But in spite of that, nearly nine hours later I am continuing to get every seven seconds the original error repeated, which is making the log file quite unwieldy!

:2016/10/18 23:45:32 http: TLS handshake error from 82.70.166.77:56575: remote error: tls: unknown certificate

How can I stop this?

#6

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.